跨站点脚本源于信息发送给应用程序用户时缺乏编码。这可以用来注入任意的HTML和JavaScript; 结果是该有效载荷在合法用户的网络浏览器中运行。与其他攻击相反，XSS漏洞针对应用程序的用户，而不是直接针对服务器。
一些漏洞利用的例子包括：
- 注入假登录表单;
- 检索合法用户的Cookie;
- 注入浏览器的漏洞;
- 让用户在Web应用程序中执行任意操作;
- ...
在本节中，我们将只关注跨站脚本的检测。您将不得不等待关于此主题的全面练习，以获取有关如何利用这些漏洞的更多详细信息。
XSS漏洞最简单也是最常见的证据就是弹出一个警告框。这个有效载荷有很多优点：
- 它表明可以触发JavaScript;
- 这很简单;
- 它是无害的。
要触发弹出窗口，您只需使用以下有效负载：alert(‘hello’)。
如果你在注入HTML代码，你需要告诉浏览器这是JavaScript代码。你可以使用<script>标签来做到这一点：
<script>alert('hello');</script>
在测试XSS时，需要记住两件重要的事情：
- 您从服务器获得的响应可能不是唯一的信息将被回显的地方。如果您注入了有效负载内容并且您在页面A中正确编码了它，这并不意味着此信息将在页面B中正确编码。
- 如果您发现编码存在问题，但无法运行您的XSS有效负载，则其他人可能能够运行。报告编码问题总是很重要的，即使某些保护措施阻止了您执行您的有效负载。安全是一个不断发展的领域，每周都会发布新的技巧。即使您现在不能利用XSS漏洞，您或其他人也许可以在稍后获得另一个有效负载。
XSS有三种类型：
- 反映：有效载荷直接回应。
- 存储：有效负载可以直接在响应中回显，但更重要的是，当您返回此页面或其他页面时，会在响应中回显。有效载荷存储在应用程序的后端。
- 基于DOM的：有效载荷不在页面中回显。它在浏览器呈现页面时动态执行。
在测试XSS时，您需要阅读发回的HTML页面的来源，您不能只是等待弹出警报框。检查哪些字符被编码，哪些字符不被编码。从这个角度来看，你可能会发现一个有效载荷。
一些浏览器提供了针对XSS的内置保护。这种保护可以由服务器启用或禁用（它在ISO中已被禁用）。如果您发现您的有效载荷直接在页面中回显，但没有警报框弹出，可能是因为这种保护。您也可以通过告诉浏览器将其禁用来禁用此保护。例如，在Chrome中，可以通过使用该选项运行Chrome来完成此操作--disable-xss-auditor。
Example 1
第一个易受攻击的例子就是让你开始了解当你找到XSS时发生的事情。使用基本的有效载荷，你应该能够得到一个警告框。
文件代码：
<?php require_once '../header.php'; ?>
<html>
Hello
<?php
echo $_GET["name"];
?>
<?php require_once '../footer.php'; ?>
一旦你发送你的有效载荷，你应该得到像这样的东西：
确保您检查HTML页面的源代码，以确定您作为请求的一部分发送的信息在没有任何HTML编码的情况下回显。
Example 2
<?php require_once '../header.php'; ?>
<html>
Hello
<?php
echo $_GET["name"];
?>
<?php require_once '../footer.php'; ?>
在第二个例子中，涉及一些过滤。Web开发人员添加了一些正则表达式，以防止简单的XSS有效负载工作。
如果你玩，你可以看到<script>和</script>被过滤。绕过这些类型的过滤器的最基本的方法之一是大 胆测试：如果你尝试<sCript>，</sCRIpt，例如，你应该能够得到警报框。
Example 3
您向开发人员通知了您的绕开方法。他添加了更多过滤功能，现在似乎可以防止您之前的有效负载。然而，他在他的代码中犯了一个可怕的错误（前面的代码也出现了这个错误）......
如果你继续玩耍，你会意识到如果你使用Pentest<script>erLab有效载荷，则显示为：PentesterLab。
标签：web,负载,浏览器,XSS,站点,编码,页面,有效载荷 From： https://www.cnblogs.com/shanhubei/p/17593731.html