当前位置:   article > 正文

如何防止跨站点脚本 (XSS) 攻击完整指南_sz全防脚本

sz全防脚本

跨站点脚本 (XSS) 攻击的完整指南、如何防止它以及 XSS 测试。

跨站点脚本 (XSS) 是每个高级测试人员都知道的最流行和易受攻击的攻击之一。它被认为是对 Web 应用程序最危险的攻击之一,也可能带来有害后果。

XSS 通常与类似的客户端攻击进行比较,因为在此攻击期间主要使用客户端语言。然而,XSS 攻击被认为风险更大,因为它能够破坏更易受攻击的技术。

在这个 XSS 攻击教程中,我们将通过简单的例子为您提供其类型、工具和预防措施的完整概述,以便您轻松理解。

XSS攻击简介

跨站点脚本攻击是一种恶意代码注入,将在受害者的浏览器中执行。恶意脚本可以保存在网络服务器上,并在用户每次调用相应功能时执行。它也可以使用其他方法执行——无需在网络服务器中保存任何脚本。

这种攻击的主要目的是窃取其他用户的身份数据——cookies、会话令牌和其他信息。在大多数情况下,这种攻击被用来窃取其他人的 cookie。众所周知,cookies 帮助我们自动登录。因此,使用被盗的 cookie,我们可以使用其他身份登录。这就是为什么这种攻击被认为是最危险的攻击之一的原因之一。

正在客户端执行 XSS 攻击。它可以使用不同的客户端编程语言来执行。但是,大多数情况下,这种攻击是使用 Javascript 和 HTML 执行的。

推荐阅读=> HTML 注入教程


推荐工具

#1) Acunetix

Acunetix是一款 Web 应用程序安全扫描器,可让您 360 度全方位了解组织的安全性。这种端到端的网络安全扫描器可以识别超过 7000 个漏洞,例如 XSS 和错误配置。它具有扫描所有页面、Web 应用程序、复杂 Web 应用程序等的功能。

Acunetix 易于使用且直观。它以闪电般的速度执行扫描。它通过验证漏洞是否真实来帮助团队。Acunetix 提供三个版本的解决方案,Standard、Premium 和 Acunetix 360。它可以扫描超过 50,000 个网络漏洞。


#2) Netsparker

Netsparker是一种 Web 应用程序安全扫描程序,可提供更高的可见性和更深入的扫描。它使用独特的 DAST + IAST 方法。它可以与您现有的 Web 基础架构无缝集成。

它使用基于证明的扫描™ 技术。Netsparker 拥有先进的扫描引擎,可以发现最复杂的漏洞,如跨站点脚本、SQL 注入等。

Netsparker 为扫描结果提供详细的漏洞信息,帮助开发人员修复它。它有一套丰富的集成工具来优化渗透测试。


XSS 是如何执行的?

跨站脚本攻击是指发送和注入恶意代码或脚本。恶意代码通常使用 Javascript、HTML、VBScript、Flash 等客户端编程语言编写。然而,Javascript 和 HTML 主要用于执行这种攻击。

这种攻击可以以不同的方式进行。根据 XSS 攻击的类型,恶意脚本可能会反映在受害者的浏览器上或存储在数据库中,并在每次用户调用相应的函数时执行。

这种攻击的主要原因是不适当的用户输入验证,恶意输入可以进入输出。恶意用户可以输入脚本,该脚本将被注入到网站的代码中。然后浏览器无法知道执行的代码是否是恶意的。

因此,恶意脚本正在受害者的浏览器上执行,或者向用户显示任何伪造的表单。XSS 攻击有多种形式。

跨站脚本的主要形式如下:

  • 跨站点脚本可能发生在客户端执行的恶意脚本上。
  • 向用户显示的虚假页面或表单(受害者键入凭据或单击恶意链接)。
  • 在显示广告的网站上。
  • 向受害者发送的恶意电子邮件。

当恶意用户发现网站的易受攻击部分并将其作为适当的恶意输入发送时,就会发生这种攻击。恶意脚本被注入到代码中,然后作为输出发送给最终用户。

让我们分析一个简单的示例: 假设我们有一个带有搜索字段的网站。

 

如果搜索字段易受攻击,当用户输入任何脚本时,它将被执行。

考虑一下,用户输入一个非常简单的脚本,如下所示:

<script>alert('XSS')</script>

 

然后点击“搜索”按钮后,输入的脚本将被执行。

 

正如我们在示例中看到的,输入到搜索字段中的脚本被执行。这只是显示了 XSS 攻击的脆弱性。但是,也可能会键入更有害的脚本。

许多测试人员将 Cross Site Scripting 攻击与Javascript Injection 混为一谈,后者也在客户端执行。在这两种情况下,都注入了攻击恶意脚本。但是,在 XSS 攻击案例中,执行脚本不需要 <script> 标签。

例如

<body οnlοad=alert('something')>;

此外,它可以是在其他事件上执行的脚本。

例如:鼠标悬停。

<b οnmοuseοver=alert('XSS testing!')></b>

让我们分析另一个例子:考虑一下,我们有一个页面,网站上显示最新的书评。

该页面的代码如下所示:

print "<html>"
print "<h1>Latest book review</h1>"
print database.latestReview
print "</html>"

因此,如果恶意用户在评论字段中输入了有害内容,则会将其加载到此页面上。

例如:考虑一下,如果黑客键入以下代码,则在评论字段中。

<script>destroyWebsite();</script>

然后在页面加载函数destroyWebsite();将被调用,它将执行其有害的操作。

我们大多数人都知道,这种攻击主要用于收集对方的 cookie,这些 cookie 可用于以其他身份登录。让我们分析另一个可能存在 cookie 盗窃的 XSS 脚本示例。

例如,黑客通过易受攻击的网站的字段,注入适当的代码。

<script type=”text/javascript”>
var test=’../example.php?cookie_data=’+escape(document.cookie);
</script>

如在所示示例中所见,cookie 被转义并发送到 example.php 脚本的变量“cookie_data”。如果恶意用户将此脚本注入网站代码,那么它将在用户的浏览器中执行,并将 cookie 发送给恶意用户。

跨站点脚本攻击的类型

执行 XSS 攻击的主要目的是窃取他人的身份。如前所述,它可能是 cookie、会话令牌等。XSS 也可能用于为受害者显示伪造的页面或表单。然而,这种攻击可以通过多种方式进行。

这种攻击分为三个主要类别,如下所示:

#1) Reflected XSS – 当恶意脚本没有保存在网络服务器上但反映在网站的结果中时,就会发生这种攻击。
#2) 存储型 XSS –当恶意脚本永久保存在网络服务器上时,就会发生这种攻击。
#3) DOM – 这发生在 DOM 环境发生变化时,但代码保持不变。

让我们深入了解一下它们。

#1) 反射型 XSS

当输入恶意代码后返回恶意结果时,就会出现这种情况。反射的 XSS 代码不会被永久保存。在这种情况下,恶意代码会反映在任何网站结果中。攻击代码可以包含在伪造的 URL 或 HTTP 参数中。

它可以通过不同的方式影响受害者——通过显示虚假的恶意页面或发送恶意电子邮件。

让我们分析一个例子:考虑一下,我们有一个登录页面,用户必须在其中输入他的用户名和密码。

 

在某些网站中,当输入了错误的凭据时,会显示一条错误消息,例如“对不起,您的用户名或凭据错误”。

在此示例中,用户名是用户在登录表单中键入的参数。在输出中包含用户名参数是错误的。这样,攻击者可以键入恶意脚本而不是正确的用户名或电子邮件地址。

 

例如它可能是一个脚本,它被发送到用户的恶意电子邮件信中,受害者可能会在其中点击伪造的链接。

#2) 存储型 XSS

这种攻击被认为风险更大,并且会造成更大的伤害。

在这种类型的攻击中,恶意代码或脚本被保存在网络服务器上(例如,在数据库中),并在用户每次调用适当的功能时执行。这种方式存储的 XSS 攻击会影响许多用户。此外,由于脚本存储在网络服务器上,它会影响网站的时间更长。

为了执行存储型 XSS 攻击,恶意脚本应通过易受攻击的输入表单(例如,评论字段或评论字段)发送。这样,适当的脚本将保存在数据库中,并在页面加载或适当的函数调用时执行。

考虑一下,我们有一个页面正在加载最新的用户意见。因此,在意见或评论字段中将键入如下所示的脚本。

<script>alert(document.cookie)</script>

它将保存在数据库中并在页面加载时执行,因为最新的用户意见将显示在页面上。如果网站易受 XSS 攻击,则会显示带有 cookie 的页面加载弹出窗口。该脚本非常简单且危害较小。但是,可能会输入更有害的代码而不是此脚本。

例如cookie 可能会发送给恶意用户,或者可能会在受害者的浏览器中显示虚假页面。

#3) DOM XSS

这种类型的攻击发生在 DOM 环境发生变化时,但客户端代码没有变化。当在受害者的浏览器中修改 DOM 环境时,客户端代码会以不同的方式执行。

为了更好地了解 XSS DOM 攻击是如何执行的,让我们分析以下示例。

考虑一下,有一个 URL 为http://testing.com/book.html?default=1的网页。我们知道,“default”是一个参数,“1”是它的值。因此,为了执行 XSS DOM 攻击,我们将发送一个脚本作为参数。

例如:

http://testing.com/book.html?default=<script>alert(document.cookie)</script>

在此示例中,将 page book.html?default=<script>alert(document.cookie)</script >的请求发送到testing.com。因此,对于该页面,浏览器正在创建一个 DOM 对象,其中文档位置对象将包含适当的字符串。

http://testing.com/book.html?default=<script>alert(document.cookie)</script>

 

这样 DOM 环境就会受到影响。当然,除了这个简单的脚本之外,还可以输入一些更有害的东西。

如何针对 XSS 进行测试?

首先,为了测试 XSS 攻击,可以进行黑盒测试。

这意味着,它可以在没有代码审查的情况下进行测试。但是,代码审查始终是一种推荐的做法,它也带来了更可靠的结果。根据我的软件测试经验,我想补充一点,如果选择了一个好的黑盒测试技术并准确地执行,那么这应该足够了。

在开始测试时,测试人员应考虑网站的哪些部分容易受到可能的 XSS 攻击。

最好在任何测试文档中列出它们,这样我们就可以确定不会遗漏任何东西。然后,测试人员应该计划必须检查哪些代码或脚本输入字段。重要的是要记住,结果意味着什么,应用程序是易受攻击的,它会彻底分析结果。

在测试可能的攻击时,检查它如何响应键入的脚本以及这些脚本是否执行等非常重要。

例如,测试人员可能会尝试输入浏览器脚本,例如:

<script>alert(document.cookie)</script>

 

如果这个脚本正在执行,那么就有很大的可能性,即 XSS 是可能的。

此外,在手动测试可能的跨站点脚本攻击时,重要的是要记住,还应该尝试编码括号。

例如:

%3cscript%3ealert(document.cookie)%3c/script%3e

 

有些人试图通过将括号更改为双括号来保护网站和系统免受各种攻击。

例如,如果输入字段将键入括号“<”,那么它将更改为双“<<”。因此,重要的是要记住,还应该执行带有编码括号的测试。

您不应该忘记测试网站的 URL。

例如,我们有一个请求:

http://www.testing.com/test.asp?pageid=2&title=Testing%20Title

 

如果这种攻击是可能的,那么 HTML 代码将包含 <h1>Testing Title</h1>。如果 Web 应用程序中存在此漏洞,则会在 <h1></h1> 标记中插入指示文本。

尝试通过 HTTP 请求传递一些代码,因为这也是检查这种攻击是否可能的一种方法。

通常,在测试可能的 XSS 攻击时,应检查输入验证,并且测试人员在检查网站输出时应有意识。此外,如果正在执行代码审查,重要的是要找到输入如何进入输出。

XSS 测试工具

由于跨站点脚本攻击是最流行的风险攻击之一,因此有很多工具可以自动对其进行测试。我们可以找到各种扫描程序来检查可能的 XSS 攻击漏洞——比如 Nesus 和 Nikto。两者都被认为是相当可靠的。

在我的软件测试生涯中,我想提一下 SOAP UI 工具。SOAP UI可以被认为是一个非常强大的工具,用于检查可能的 XSS 攻击。它包含用于检查此攻击的现成模板。它确实简化了测试过程。

但是,为了使用 SOAP UI 工具测试此漏洞,API 级别测试应该已经使用该工具自动化。另一种针对 XSS 进行测试的解决方案是浏览器插件。但是,插件被认为是检查此类攻击的相当薄弱的工具。

即使在自动测试时,测试人员也应该对这种攻击类型有很好的了解,并且应该能够适当地分析结果。

在选择测试工具时,良好的知识也很有帮助。此外,重要的是要知道,在使用自动工具执行安全漏洞扫描时,手动测试也是一种很好的做法,这样测试人员将能够看到结果并进行分析。

与其他攻击的比较

XSS 被认为是最危险的攻击之一,因为它的主要目的是窃取网站或系统的用户身份。此外,XSS 攻击可以使用不同的客户端语言(如 Javascript、HTML、VBScript、Flash 等)执行。这使得它比其他可能的攻击更具危害性和广泛性。

测试 XSS 攻击与测试其他可能的客户端攻击非常相似。但是,重要的是要记住在测试 XSS 时应该检查哪些其他情况。

使这种攻击风险更大的另一件事是存储在 Web 服务中的可能性——这样它可以在更长的时间内影响许多用户。XSS 有时可以对更不易受攻击的系统执行,其漏洞有时很难被发现。

此外,与其他攻击相比,XSS 的执行方式很多,对网站的影响也很大。

预防 XSS 的方法

尽管这种类型的攻击被认为是最危险和最危险的攻击之一,但仍应制定预防计划。由于这种攻击的流行,有很多方法可以防止它。

常用的主要预防方法包括:

  • 数据验证
  • 过滤
  • 逃跑

预防这种攻击的第一步是输入验证。用户输入的所有内容都应该经过精确验证,因为用户的输入可能会找到输出。数据验证可以称为保证系统安全的基础。我要提醒您,验证的想法是不允许不适当的输入。

因此,它只是有助于降低风险,但可能不足以防止可能的 XSS 漏洞。

另一个好的预防方法是用户输入过滤。过滤的想法是在用户输入中搜索有风险的关键字并将它们删除或替换为空字符串。

这些关键字可能是:

  • <script></script> 标签
  • Javascript 命令
  • HTML 标记

输入过滤很容易练习。它也可以以不同的方式执行。

喜欢:

  • 由编写服务器端代码的开发人员提供。
  • 正在使用适当的编程语言库。

在这种情况下,一些开发人员编写自己的代码来搜索适当的关键字并将其删除。但是,更简单的方法是选择适当的编程语言库来过滤用户的输入。我想评论一下,使用库是一种更可靠的方式,因为这些库已被许多开发人员使用和测试。

另一种可能的预防方法是字符转义。在这种做法中,适当的字符会被特殊代码更改。例如, < 转义字符可能看起来像 <。重要的是要知道,我们可以找到合适的库来转义字符。

同时,也不应该忘记良好的测试。它应该投资于优秀的软件测试人员的知识和可靠的软件测试工具。这样可以更好地保证良好的软件质量。

根据技术预防

如前所述,过滤和字符转义是主要的预防方法。但是,它可以在不同的编程语言中以不同的方式执行。有些编程语言有适当的过滤库,有些则没有。

应该提到的是,在 Java 和 PHP 编程语言中可以很容易地执行过滤,因为它们有相应的库。

Java 技术应用非常广泛,因此有很多解决方案。如果您使用 Spring 技术并且想要为整个应用程序转义 HTML,那么您必须在项目的 web.xml 文件中编写适当的代码。

<context-param>
<param-name>defaultHtmlEscape</param-name>
<param-value>true</param-value>
</context-param>

此代码将为整个应用程序切换 HTML 转义。

如果您想为相应页面的表单切换 HTML 转义,则代码应编写如下:

<spring:htmlEscape defaultHtmlEscape="true" />

有许多现成的 .jar 文件形式的 XSS 过滤器。我会提醒您,必须将 .jar 文件添加到您的项目中,然后才能使用其库。一个这样的 XSS 过滤器是 xssflt.jar,它是一个 servlet 过滤器。这个 .jar 文件可以很容易地从 Internet 下载并添加到您的项目中。

此过滤器检查发送到应用程序的每个请求,并从潜在的注入中清除它。

将 external.jar 文件添加到项目时,还必须在 web.xml 文件中对其进行描述:

<filter> 
<filter-name>XSSFilter</filter-name> 
<filter-class>com.cj.xss.XSSFilter</filter-class> 
</filter>

另一个可能的解决方案是 ESAPI 库。ESAPI 库与许多编程语言兼容。您可以找到适用于 Java 和 PHP 编程语言的 ESAPI 库。它是一个开源和免费的库,有助于控制应用程序的安全性。

XSS 备忘单

XSS 备忘单对于防止跨站点脚本编写非常有帮助。它是开发人员如何防止 XSS 攻击的指南。这些规则非常有用,在开发时不应忘记。XSS 备忘单可以在互联网社区中找到,例如 OWASP(开放 Web 应用程序安全项目)。

不同类型的备忘单:

  • XSS 预防备忘单
  • DOM XSS 备忘单
  • XSS 过滤器规避备忘单

主要指南将是 XSS 预防备忘单,因为它提供了 XSS 攻击预防的通用规则。如果您遵循 DOM XSS Cheat Sheet 和 XSS Filter Evasion Cheat Sheet 规则,您仍然必须遵循 XSS Prevention Cheat Sheet。

如前所述,可以在 OWASP 社区中找到 XSS 预防备忘单。这份备忘单为我们提供了一系列规则,这将帮助我们降低可能的 XSS 攻击的风险。它不仅是编码规则,而且是预防基础上的安全漏洞。

一些规则包括:

  • 不应插入不受信任的数据。
  • 在插入任何不受信任的数据之前,应该对 HTML 进行转义。
  • 在插入不受信任的数据等之前,应该对属性进行转义。

因此,备忘单可能对防止此类攻击非常有帮助。

结论

在测试时,强烈建议评估可能带来 XSS 攻击的风险。XSS 攻击可以影响 Web 应用程序,这似乎也是安全的。

它被认为是最有害和最危险的攻击之一。因此,我们不应该忘记这种类型的测试。在对 XSS 进行测试时,对这种攻击有很好的了解是很重要的。这是正确分析测试结果,选择合适的测试工具的基础。

您是处理过跨站脚本 XSS 攻击的测试人员吗?您是否有任何关于 XSS 攻击的有趣事实也可以帮助我们的读者?请随时在下面的评论部分与我们分享您的经验!

 

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/羊村懒王/article/detail/184618
推荐阅读
相关标签
  

闽ICP备14008679号