XSRF/CSRF
- XSRF:通常作为CSRF的别名使用,两者指向同一类攻击行为。
- CSRF:更常用于技术文档和安全领域,强调攻击者通过伪造用户请求篡改数据或执行操作。
核心区别
CSRF(或XSRF)与XSS(跨站脚本攻击)存在本质差异:
- CSRF:利用用户已登录的会话权限,通过伪造请求篡改数据或执行操作(如转账、发布虚假信息),依赖Cookie等凭证。
- XSS:通过注入恶意脚本到网页中窃取数据或破坏页面完整性,如篡改页面内容、发起进一步攻击,核心是“代码注入”。
防御策略
- CSRF:采用验证码、在请求地址加入token等机制验证用户真实意图。
- XSS:需通过内容过滤、HTTP头安全配置等手段防止恶意脚本注入。 、
1. 针对CSRF的防范,有以下几点要注意:
-
关键操作只接受POST请求
-
验证码
CSRF攻击的过程,往往是在用户不知情的情况下构造网络请求。所以如果使用验证码,那么每次操作都需要用户进行互动,从而简单有效的防御了CSRF攻击。
但是如果你在一个网站作出任何举动都要输入验证码会严重影响用户体验,所以验证码一般只出现在特殊操作里面,或者在注册时候使用
- 检测refer
通过检查Referer的值,我们就可以判断这个请求是合法的还是非法的,但是问题出在服务器不是任何时候都能接受到Referer的值,所以Refere Check 一般用于监控CSRF攻击的发生,而不用来抵御攻击。
- Token
目前主流的做法是使用Token抵御CSRF攻击。下面通过分析CSRF 攻击来理解为什么Token能够有效
CSRF攻击要成功的条件在于攻击者能够预测所有的参数从而构造出合法的请求。所以根据不可预测性原则,我们可以对参数进行加密从而防止CSRF攻击。
另一个更通用的做法是保持原有参数不变,另外添加一个参数Token,其值是随机的。这样攻击者因为不知道Token而无法构造出合法的请求进行攻击。
Token 使用原则
Token要足够随机————只有这样才算不可预测
Token是一次性的,即每次请求成功后要更新Token————这样可以增加攻击难度,增加预测难度
Token要注意保密性————敏感操作使用post,防止Token出现在URL中
注意
如果同域下存在xss的话,除了验证码,其他的方式都无法防御这个问题。
2. 针对XSS的防范,有以下几点要注意:
- 存储型XSS:攻击者在评论区提交恶意脚本(如
<script>sendCookiesToAttacker()</script>),该评论被存储到服务器。其他用户访问该页面时,恶意脚本自动加载并窃取其会话Cookie
<!-- 用户评论内容 -->
<div class="comment">
这篇文章写得真好!<script>sendCookiesToAttacker()</script>
</div>
-
搜索功能——反射型XSS:网站搜索功能未过滤输入参数,攻击者构造恶意链接:
https://example.com/search?q=<script>alert('XSS攻击')</script>,用户点击链接后,服务器返回的页面包含未过滤的恶意脚本 -
单页面应用路由——DOM型XSS:SPA前端路由根据URL参数动态加载内容,但未对参数过滤。攻击者构造链接:example.com/#/profile?u…,用户点击链接,前端脚本将 username 参数直接渲染到页面,触发XSS
防御方法:
- 使用完善且细致的转义库
org.owasp.encoder,要根据项目情况进行过滤,禁止掉 "javascript:" 链接、非法 scheme 等 - 使用
escapeHTML()可以把用户的输入内容进行转义 - 在 cookie 中设置 HttpOnly 属性后,js脚本将无法读取到 cookie 信息
- HTML标签/属性白名单
- 设置请求头: 默认只允许同源资源,禁止嵌入iframe