XSS跨站脚本攻击 与 CSRF跨站请求伪造

目录

XSS跨站脚本攻击

1.什么是XSS（Cross Site Scripting）？

2.XSS可以达到什么目的？

3.XSS的分类和实现方法？

4.如何预防XSS？

CSRF跨站请求伪造

1.什么是CSRF（Cross-site Request Forgery）？

2.CSRF可以达到什么目的？

3.如何预防CSRF

---

XSS跨站脚本攻击

 

1.什么是XSS（Cross Site Scripting）？

hacker利用网页漏洞，将恶意代码植入网页中，使用户加载并执行这段恶意代码，达到攻击的目的。

 

2.XSS可以达到什么目的？

恶意代码通常是JavaScript，js能做什么事情就代表xss也能做什么事情。

①获取用户cookie

cookie代表用户的身份令牌，可想而知，一旦cookie被hacker获取，hacker就可以登录网站，假冒用户做他想做的事情，盗取用户信息。

②劫持流量进行恶意跳转

例如我们在网页中插入一段代码

<script> window.location.href="http://www.huangse.com"; </script>

用户正常访问网站，便会跳转到第三方网站。仔细想一下，日常生活中是不是出现过类似的情况，我们访问一个正常网站，突然跳到一个黄色网站或赌博网站去了。真是吓死人了。当然这种跳转还容易察觉，那如果是跳到一个hacker伪造的克隆网站，用户不曾察觉，在上面进行正常操作，信息就被泄露啦，可怕。

③篡改、删除页面信息

恶意脚本可以任意修改页面信息。例如，你是某网站的付费会员，恶意脚本可以修改页面信息，将你显示为过期会员，提醒你扫码续费，再将续费通道引导至hacker控制下的网站，神不知鬼不觉。

④配合CSRF实施下一步攻击

⑤……

 

3.XSS的分类和实现方法？

根据xss实现方法的不同，xss又分为持久型攻击/非持久型攻击/DOM型攻击

①持久型攻击，又称为存储型攻击。hacker注入的恶意脚本被存储在正常网站的数据库中，当用户访问到执行这段代码的页面时便会受到攻击，这种攻击类型影响人群范围大，时间广，危害也是最直接的。

举个例子，有一个论坛存在漏洞，hacker利用漏洞，提交了一段评论（评论就是恶意脚本），评论被存储在论坛的服务器中（数据库中）。当其他用户访问这个论坛的时候，加载评论，加载到这个hacker提交的评论，然后网站又没有做安全处理，那就GG了，这段伪装成评论的恶意代码就在客户端执行了，又是hacker为所欲为的一天。

②非持久型攻击，又称为反射型攻击。一般是hacker将恶意代码包装在网页链接上，引诱用户去点击这个链接，达到执行恶意代码的目的。之所以叫反射型，是因为服务器没有处理这段代码，直接将代码“反射”回给用户。

举个例子，这是正常的访问链接 https://www.normal.com/detail?params=cc 如果服务端没有对params进行安全过滤，直接将params=cc反射回客户端，那么hacker抓住了这个漏洞。就可以这么做：https://www.normal.com/detail?params=<script>alert(1)</script> 将恶意代码包装在params上，通过电子邮件或短信伪装分发这个链接，引诱无辜人群点击，又是hacker为所欲为的一天。

因为这种攻击只针对特定用户且是一次性的，所以危害程度相对持久型攻击低。

③DOM型攻击。这种攻击一般是通过修改DOM树实现的，所以叫DOM型攻击，DOM型攻击不经后端。容易造成DOM型攻击的方法有document.write、innerHTML等。

 

根据XSS类型可以总结出，在以下2种情况下，容易发生 XSS 攻击：

1. 从一个不可靠的链接进入到一个 Web 应用程序。
2. 没有过滤掉恶意代码的动态内容被发送给 Web 用户。

 

4.如何预防XSS？

防范XSS攻击是前后端的共同责任。一句话亦可总结：永远不要相信用户输入的内容。

①对用户端输入提交的数据进行充分转义。开发人员可自行处理转义或用现成的转义工具。现在有很多过滤xss的开源工具，例如https://www.npmjs.com/package/xss

②针对cookie的盗取，可以对cookie做http-only限制，使cookie不可读取

③“永远不要相信前端传递的数据”这句话说给后端听。后端开发者需要对各个接口的提交的数据需要做数据格式校验和长度过滤，不达到条件的一律过滤掉。遇到过后端没有充分校验前端传递的数据，一个特殊参数拿去数据库那里跑，把数据库跑崩了……

④前端慎用document.innerTHML、document.write等

⑤启用内容安全策略（CSP），不允许网站加载来历不明的脚本

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

 

 

CSRF跨站请求伪造

 

1.什么是CSRF（Cross-site Request Forgery）？

hacker引诱用户进入恶意网站，在恶意网站上向被攻击网站发起跨站请求。与XSS相比，XSS利用的是用户对网站的信任（网站被植入了恶意代码）；CSRF利用的是服务器对用户的信任（发起请求的并不是真正的用户而是hacker）。

CSRF的原理是，用户登录了a.com网站，并保留了登录凭证cookie。此时，hacker引诱用户访问b.com，b.com向a.com发起了请求，浏览器默认携带上了a.com的cookie。a.com的服务器通过cookie去校验用户成功，并执行了请求的相关操作。

 

2.CSRF可以达到什么目的？

根据网站的业务不同，hacker可以冒用用户身份做不同的操作达到不用的目的

例如

① 商城类：通过调用下单接口冒用用户身份伪造订单；

② 金钱类：通过调用转账相关接口达到转账目的，将用户的钱转到hacker的账户；

③ 邮箱/信息类：通过信息转发相关接口将用户的信息转发给hacker的账户，盗取用户信息，比如获取到用户邮箱里某些应用的验证码。

④……

 

3.如何预防CSRF

①因为CSRF攻击来自第三方网站，后端可以通过HTTP请求头的Referer字段查明请求是否来自同一域名，如果不是，一些敏感信息操作后端应该慎重。

② 利用token校验。由于cookie会随浏览器默认请求头携带，可以转换校验方式，采用token校验，那么跨站网站就无法取到token冒用用户身份发起请求了。

③利用Cookie的Samesite属性。 

POST /transfer HTTP/1.1
Host: www.a-bank.com
Cookie: JSESSIONID=randomid;SameSite=Strict;

将Samesite设置为Strict严格模式，任何跨域请求都不会携带cookie。设置为Lax宽松模式，大部分跨站的请求也不会带上Cookie，但是一些导航的Get请求会带上Cookie