安全测试重点思考(中)--如何防止漏洞XSS和CSRF漏洞

XSS漏洞的预防

springsecurity框架来预防xss漏洞的步骤

• 配置安全过滤器链： 在 Spring Security 配置文件中配置安全过滤器链，确保请求经过适当的过滤器链以进行安全检查和验证。
• 启用跨站请求伪造（CSRF）保护： 配置 Spring Security 启用 CSRF 保护，以防止恶意网站利用用户的身份进行 CSRF 攻击。可以通过在 Spring Security 配置中启用 csrf() 方法来实现。
• 实施内容安全策略（CSP）： 配置 Spring Security 添加适当的 HTTP 响应标头，如 Content-Security-Policy，以实施内容安全策略，限制浏览器加载和执行内容的方式，从而减少 XSS 攻击的风险。
• 进行输入验证和输出编码： 在应用程序中实施严格的输入验证，以确保用户输入数据的完整性和安全性。同时，在将用户提供的数据显示到页面上时，使用适当的输出编码，如 HTML 编码或 JavaScript 编码，以防止 XSS 攻击。
• 使用安全的渲染技术： 在应用程序中使用安全的模板引擎或渲染技术，如 Thymeleaf 或 FreeMarker，这些技术可以自动进行 HTML 编码，从而减少手动编码的错误和 XSS 攻击的风险。
• 更新和维护依赖项： 定期更新和维护应用程序中使用的依赖项和库，以确保使用的框架和组件没有已知的 XSS 漏洞，并及时应用已发布的安全补丁。
• 进行安全审计和漏洞扫描： 定期进行安全审计和漏洞扫描，以检测和识别应用程序中可能存在的 XSS 漏洞，并及时采取措施修复这些漏洞。

将特殊字符进行实体转义

使用类库和修改cookie属性

使用安全的HTTP Only Cookie

确保你的Cookie被标记为HTTP Only，这样它们就不能通过客户端的JavaScript代码来访问。这可以防止XSS攻击者尝试通过JavaScript来访问Cookie。

document.cookie = "cookieName=cookieValue; HttpOnly";

使用安全的Cookie

将Cookie标记为安全的可以确保它们只在通过HTTPS连接时传输，这样可以减少被窃取的风险。

document.cookie = "cookieName=cookieValue; secure";

使用CSP（内容安全策略）

内容安全策略是一种通过限制页面中的资源加载来减少XSS攻击的方法。它可以通过HTTP标头来实现，或者在HTML页面中设置meta标签。例如，使用类似以下的标头：

Content-Security-Policy: default-src 'self';

使用专门的XSS防护库

使用专门的XSS防护库，比如OWASP ESAPI，可以帮助过滤用户输入并确保安全地在页面上显示。这些库通常提供了一组函数和工具，用于转义特殊字符、过滤输入等。

var userInput = "<script>alert('XSS');</script>";
var safeInput = encodeHTML(userInput); // 使用库中提供的函数来转义HTML特殊字符
document.getElementById("output").innerHTML = safeInput;

输入验证和过滤

对用户输入进行验证和过滤是防止XSS攻击的重要步骤。确保只接受预期格式的输入，并过滤掉不安全的字符。

var userInput = document.getElementById("input").value;
var safeInput = userInput.replace(/<script>/g, ""); // 过滤掉<script>标签
document.getElementById("output").innerHTML = safeInput;

XSS的面试题

你对xss了解，测试如何做xss测试？

• 反射型XSS：恶意脚本通过用户提供的输入被传递到服务器，然后在服务器响应中反射回来并执行。
• 存储型XSS：恶意脚本被存储在服务器上的数据库或文件中，并在请求时从服务器返回给所有用户。
• DOM-based XSS：恶意脚本利用客户端的DOM（文档对象模型）而不是服务器来实施攻击。
• 如何做：找到input框或者接口参数，输入payload查看是否有alert弹窗，如果有，即为xss漏洞。

三种xss漏洞的区别

触发方式

• 反射型XSS通常通过诱使用户点击恶意链接来触发，恶意脚本随请求发送到服务器，然后被反射回用户的浏览器执行。
• 存储型XSS则将恶意脚本存储在服务器上，在用户访问包含该脚本的页面时被触发。
• DOM-based XSS攻击不涉及与服务器的交互，而是直接通过客户端的JavaScript代码执行，恶意脚本被注入到页面中并在解析时被执行。

依赖方式

• 反射型和存储型XSS通常依赖于用户的行为。
• DOM-based XSS攻击则依赖于页面加载和DOM解析。

时效性质

• 反射型XSS的payload通常在攻击链接被点击后立即触发。
• 而存储型XSS的payload会一直保留在服务器上，直到其他用户访问受感染的页面。
• DOM-based XSS的payload则随着页面加载和DOM解析而触发，且通常具有持久性。

xss的原理和根本原因

• 原理：用户提交的数据被浏览器执行了，比如js代码
• 根本原因：用户提交的payload后端没有经过处理直接返回到前端被浏览器执行了

我们如何利用脚本

为了防止黑客进行XSS攻击，你可以使用window.open和document.cookie来构造一个安全的Payload。

安全测试工具awvs如何做测试

我们只需要找到要扫描的网站，写网址，写登录账号密码，就可以开始对网站扫指了，中间会发现漏洞，并记录，一般持续半天到一天，扫描才会结束。

为什么有了awvs还需要手动挖掘漏洞呢

• 深层次漏洞：自动化扫描工具通常只能检测到一些常见的漏洞类型，如SQL注入、XSS等。而对于一些深层次、定制化或较为复杂的漏洞，往往需要人工挖掘和深入分析
• 定制化场景：某些应用程序具有特定的定制化功能和逻辑，这些功能可能不易被自动化扫描工具发现。手动挖掘可以根据实际情况调整测试策略和探测方法，更好地覆盖特定的定制化场景。
• 逻辑漏洞：某些漏洞不仅仅是由于技术实现上的问题，还可能涉及到业务逻辑上的缺陷。这类漏洞通常需要人工分析和理解应用程序的业务逻辑，以便发现和利用。
• 误报和漏报：自动化扫描工具可能会产生误报或漏报，即报告了不存在的漏洞或未发现真实的漏洞。手动挖掘可以对自动化扫描结果进行验证和补充，确保漏洞的准确性和完整性。
• 漏洞利用：自动化扫描工具通常只能发现漏洞，而无法深入挖掘漏洞的利用方式和后果。手动挖掘可以进一步研究漏洞的利用场景和后果，帮助开发人员和安全团队更好地理解和修复漏洞。

CSRF漏洞的预防

CSRF的定义

跨站请求伪造，冒用Cookie中的信息，发起请求攻击。
CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

CSRF攻击实现过程

• 当用户已经登录成功了一个网站
• 然后通过被诱导进了第三方网站「钓鱼网站」
• 跳转过去了自动提交表单，冒用受害者信息
• 后台则正常走逻辑将用户提交的表单信息进行处理

如何构造CSRF攻击

1.攻击者构造一个恶意的请求，该请求中包含了受害者在目标网站的身份认证信息(身份信息利用网站已经存储的 cookies)和一些具体的操作指令。
2.攻击者通过各种手段(比如诱骗点击或注入恶意代码等)让受害者访问构造好的恶意请求此时受害者的浏览器会向目标网站发出请求,携带了恶意请求所需要的身份信息和操作指令>3.目标网站接收到浏览器发来的恶意请求后，会认为该请求是受害者本人发出的,进而执行对应的操作。攻击者通过这种方式完成了一次 CSRF攻击，并可能窃取到受害者的个人信息、账户资产等

构造请求的代码

如果你想将恶意的 URL 伪装成图片，并通过电子邮件发送给受害者，你可以构造一个包含该 URL 的 HTML 代码，并将该 HTML 代码嵌入到电子邮件的内容中。然后，你可以将这个 HTML 代码保存成一个 HTML 文件，再将该 HTML 文件作为电子邮件的附件发送给受害者

GET类型的CSRF

仅仅须要一个HTTP请求。就能够构造一次简单的CSRF。

• 银行站点A：它以GET请求来完毕银行转账的操作，如：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000 

• 危险站点B：它里面有一段HTML的代码例如以下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

在上述场景中，如果银行站点 A 在执行敏感操作（比如转账）时使用了 GET 请求，而不是 POST 请求，那么就存在 GET 类型的 CSRF 漏洞。这样的话，当用户已经登录了银行站点 A 并且在同一浏览器会话中访问了危险站点 B 时，如果危险站点 B 的页面中包含了一个针对银行站点 A 的 GET 请求（比如执行转账操作），那么这个 GET 请求会自动携带上用户的身份验证凭证（比如 Cookie），从而导致银行站点 A 对该用户执行了未经授权的敏感操作（比如转账）。
这种情况下，攻击者可以构造一个伪造的请求链接，然后诱使用户点击这个链接，触发对银行站点 A 的 GET 请求，从而执行转账等操作，而用户可能并没有意识到正在执行这些操作。

POST类型的CSRF

在CSRF攻击流行之初，曾经有一种错误的观点，认为CSRF攻击只能由GET请求发起。因此很多开发者都认为只要把重要的操作改成只允许POST请求，就能防止CSRF攻击。
假设银行网站 A 允许用户通过一个表单来修改密码，该表单使用 POST 方法提交数据。攻击者可以构造一个恶意网站 B，其包含如下 HTML。

<!-- 恶意网站 B 的 HTML 代码 -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Malicious Website</title>
</head>
<body>
    <h1>Click here to get a free gift!</h1>
    <form action="http://bankA.com/change_password" method="POST" id="csrfForm">
        <input type="hidden" name="new_password" value="hacker123">
        <input type="submit" value="Claim Gift">
    </form>
    <script>
        // 自动提交表单
        document.getElementById('csrfForm').submit();
    </script>
</body>
</html>

CSRF面试题

测你对 csrf 的了解，测试如何做csrf的测试

黑客能利用csrf漏洞来修改密码，转账，发qq空间等一系列操作。
我们对于一些重要的操作的地方进行测试，检测是否有二次确认机制，和特殊处理，比如修改密码没有二次确认，或者转账没有二次确认都可能存在csrf漏洞。

csrf的根本原因和原理

执行某项重要操作的时候没有进行二次确认，意思就是可以直接通过链接完成某一项操作。一旦中间有二次确认机制，那么改链接无法一次性执行完这次操作。

黑客如何利用，我们如何编写漏洞利用脚本来测试

直接复制重要操作的ur，修改里面的参数，比如密码和确认密码两个参数的值

我们如何预防csrf

预防 CSRF 攻击的方法包括实施 CSRF 令牌、同源策略、双重确认等防御措施，以确保请求的合法性和用户的安全。

安全测试漏洞

我发现了十多个三-多安全测试的 bugXss有十来个，提交数据的时候提交 payload，下次来访问这个页面的时候就弹出 alert,或者某个 ur 中的参数有 xss 洞，写入 payload 的时候有 alert 弹窗。
文件上传的有十来个，比如没有校验格式，或者前端校验了，后端没有校验，也可能没有校验大小，也可能没有去校验文件的具体内容。

xss和csrf的区别

特征	XSS (跨站脚本)	CSRF (跨站请求伪造)
定义	攻击者在网站上注入恶意脚本，使其在其他用户的浏览器中执行。	攻击者利用用户在其他站点已登录的会话来执行未经授权的操作。
目的	盗取用户会话信息、执行恶意操作（如篡改页面内容、重定向到恶意网站等）。	以用户身份执行敏感操作（如转账、修改密码等）而不需要用户的明确操作。
实现方式	通过在网站的输入字段中注入恶意脚本，如输入框、URL 参数、Cookie 等。	通过伪造请求，构造恶意的 URL 或表单，并诱使用户点击或提交。
例子	1. 在论坛发帖中插入恶意脚本，当其他用户浏览帖子时执行。 2. 在输入框中注入脚本，盗取用户的会话 Cookie。	1. 诱使用户点击恶意链接，执行转账操作。 2. 在恶意网站上自动提交表单，修改用户密码。
防御措施	1. 对用户输入进行充分验证和过滤，对输出进行适当的编码。 2. 使用 Content Security Policy (CSP) 限制脚本执行。 3. 使用 HTTP Only Cookie，减少会话 Cookie 被窃取的风险。	1. 使用 CSRF Token 防止伪造请求。 2. 使用 SameSite Cookie 属性限制跨站请求。 3. 在执行敏感操作前进行双重确认。