XSS攻击、CSRF攻击

XSS攻击

XSS，全称跨站脚本(Cross Site Scripting)，为避免与层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故缩写为XSS。这是一种将任意 Javascript 代码插入到其他Web用户页面里执行以达到攻击目的的漏洞。

攻击原理

主要原因是程序对输入和输出的控制不够严格，导致“精心构造”的恶意脚本输入后，在输到前端时被浏览器当作有效代码解析执行从而产生危害。

XSS会造成那些危害？

1、网络钓鱼，包括获取各类用户账号
2、窃取用户cookies资料，从而获取用户隐私信息，或利用用户身份进一步对网站执行操作；
3、劫持用户（浏览器）会话，从而执行任意操作，例如非法转账、强制发表日志、电子邮件等
4、强制弹出广告页面、刷流量等
5、网页挂马；
6、进行恶意操作，如任意篡改页面信息、删除文章等
7、进行大量的客户端攻击，如ddos等
8、获取客户端信息，如用户的浏览历史、真实p、开放端口等
9、控制受害者机器向其他网站发起攻击；
10、结合其他漏洞，如csrf，实施进步危害；
11、提升用户权限，包括进一步渗透网站
12、传播跨站脚本蠕虫等
验证方法：一般可采用script标签来手动检测（比如在搜索框中输入alert）

XSS的防御

形成XSS漏洞的主要原因是程序对输入和输出的控制不够严格，导致“精心构造”的脚本输入后，在输到前端时被浏览器当作有效代码解析执行从而产生危害。

因此在XSS漏洞的防范上，一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理: 输入过滤：对输入进行过滤，不允许可能导致XSS攻击的字符输入; 输出转义：根据输出点的位置对输出到前端的内容进行适当转义;

XSS常见出现的地方

1、数据交互的地方
get、post、cookies、headers
反馈与浏览
富文本编辑器
各类标签插入和自定义
2、数据输出的地方
用户资料
关键词、标签、说明
文件上传

XSS分类：

反射型

又称非持久型XSS，这种攻击方式往往具有一次性，只在用户单击时触发。跨站代码一般存在链接中，当受害者请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码通常不存储服务端

常见注入点:
网站的搜索栏、用户登录入口、输入表单等地方，常用来窃取客户端cookies或钓鱼欺骗。

漏洞产生原因一般是网站只是简单地将用户输入的数据直接或未经过完善的安全过滤就在浏览器中进行输岀，导致输岀的欻据中存在可被浏览器执行的代码数据

攻击方式
攻击者通过电子邮件等方式将包含XSS代码的恶意链接发送给目标用户。当目标用户访问该链接时，服务器接受该目标用户的请求并进行处理，然后服务器把带有XSS的代码发送给目标用户的浏览器，浏览器解析这段带有XSS代码的恶意脚本后，就会触发XSS漏洞。

由于此种类型的跨站代码存在于URL中，所以黑客通常需要通过诱骗或加密变形等方式将存在恶意代码的链接发给用户，只有用户点击以后才能使得攻击成功实施。

反射型XSS攻击的流程如下：

1.攻击者寻找具有漏洞的网站
2.攻击者给用户发了一个带有恶意字符串的链接
3.用户点击了该链接
4.服务器返回HTML文档，此时该文档已经包含了那个恶意字符串
5.客户端执行了植入的恶意脚本，XSS攻击就发生
例如：在有XSS漏洞的搜索框栏中输入此时我们会发现cookie已经被弹窗显示出来了，但是只会在受害者的浏览器中弹出，我们最终是无法获取到的，这个时候我们可以联想到SQL注入，将受我们控制的域名一同写入SQL语句中，然后通过查看服务器访问日志来获得我们想要的数据。同样的，在反射型XSS中，我们也可以在XSS中写入受我们控制的域名，然后通过查看该域名服务器的请求日志来获得cookie。

储存型

存储型XSS（ Stored xss Attacks），也是持久型XSS，比反射型XSS更具有威胁性。。攻击脚本将被永久的存放在目标服务器的数据库或文件中。这是利用起来最方便的跨站类型，跨站代码存储于服务端（比如数据库中）

常见注入点
论坛、博客、留言板、网站的留言、评论、日志等交互处。

造成漏洞原因一般是由于Web应用程序对用户输入数据的不严格，导致Web应用程序将黑客输入的恶意跨站攻击数据信息保存在服务端的数据库或其他文件形式中。

攻击方式
攻击者在发帖或留言的过程中，将恶意脚本连同正常信息一起注入到发布内容中。随着发布内容被服务器存储下来，恶意脚本也将永久的存放到服务器的后端存储器中。当其他用户浏览这个被注入了
恶意脚本的帖子时，恶意脚本就会在用户的浏览器中得到执行。

存储型ⅩSS攻击的流程如下
1.用户提交了一条包含XSS代码的留言到数据库
2.当目标用户查询留言时，那些留言的内容会从服务器解析之后加载出来
3.浏览器发现有XSS代码，就当做正常的HTML和JS解析执行

DOM型

DoM是文档对象模型（ Document Object Model）的缩写。它是HTML文档的对象表示，同时也是外部内容（例如 JavaScript）与HTML元素之间的接口。解析树的根节点是“ Document"对象。DOM（ Document object model），使用DOM能够使程序和脚本能够动态访问和更新文档的内容、结构和样式。

它是基于DoM文档对象的一种漏洞，并且DOM型XSS是基于JS上的，并不需要与服务器进行交互。

其通过修改页面DOM节点数据信息而形成的ⅩSS跨站脚本攻击。不同于反射型XSS和存储型XSS，基于DOM的XSS跨站脚本攻击往往需要针对具体的 Javascript DOM代码进行分析，并根据实际情况进行XSS跨站脚本攻击的利用。

一种基于DOM的跨站，这是客户端脚本本身解析不正确导致的安全问题

注入点
通过js脚本对对文档对象进行编辑，从而修改页面的元素。也就是说，客户端的脚本程序可以DOM动态修改页面的内容，从客户端获取DOM中的数据并在本地执行。由于DOM是在客户端修改节点的，所
以基于DOM型的XSS漏洞不需要与服务器端交互，它只发生在客户端处理数据的阶段。

攻击方式
用户请求一个经过专门设计的URL，它由攻击者提供，而且其中包含XSS代码。服务器的响应不会以任何形式包含攻击者的脚本，当用户的浏览器处理这个响应时，DOM对象就会处理XSS代码，导致存
在XSS漏洞。

它的流程是这样的：
1.攻击者寻找具有漏洞的网站
2.攻击者给用户发了一个带有恶意字符串的链接
3.用户点击了该链接
4.服务器返回HTML文档，但是该文档此时不包含那个恶意字符串
5.客户端执行了该HTML文档里的脚本，然后把恶意脚本植入了页面
6.客服端执行了植入的恶意脚本，XSS攻击就发生了

反射型XSS与DOM型区别：

1、反射型XSS攻击中，服务器在返回HTML文档的时候，就已经包含了恶意的脚本;

2、DOM型ⅩSS攻击中，服务器在返回HTML文档的时候，是不包含恶意脚本的；恶意脚本是在其执行了非恶意脚本后，被注入到文档里的

通过JS脚本对对文档对象进行编辑，从而修改页面的元素。也就是说，客户端的脚本程序可以DOM动态修改页面的内容，从客户端获取DOM中的数据并在本地执行。由于DOM是在客户端修改节点的，所以基于DOM型的XSS漏洞不需要与服务器端交互，它只发生在客户端处理数据的阶段。

预防XSS

（1）cookie的secure属性（只允许在https协议下传输）、httpOnly属性（cookie无法被js获取到）
（2）加强对用户输入的过滤
（3）尽量避免使用DOM中的内联事件、a标签的href等，因为他们都能运行恶意代码

CSRF攻击

CSRF，跨站点请求伪造(Cross—Site Request Forgery)

攻击原理

网站是通过cookie来实现登录功能的。而cookie只要存在浏览器中，那么浏览器在访问这个cookie的服务器的时候，就会自动的携带cookie信息到服务器上去。那么这时候就存在一个漏洞了，如果你访问了一个别有用心或病毒网站，这个网站可以在网页源代码中插入js代码，使用js代码给其他服务器发送请求（比如ICBC的转账请求）。那么因为在发送请求的时候，浏览器会自动的把cookie发送给对应的服务器，这时候相应的服务器（比如ICBC网站），就不知道这个请求是伪造的，就被欺骗过去了。从而达到在用户不知情的情况下，给某个服务器发送了一个请求（比如转账）。
注意：
首先，这种攻击方式是跨域的，所以攻击者在第三方网站是获取不到用户cookie的（浏览器的同源策略规定 不允许获取 跨域cookie、localStorage、sessionStorage等信息），但浏览器会为该请求自动携带上对应域的cookie。
也就是说，攻击者并不需要获取到用户cookie，只需利用 浏览器的默认行为（即 cookie策略）即可实施攻击。

CSRF的防御

CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。

CSRF有两个特点：

CSRF（通常）发生在第三方域名。

CSRF攻击者不能获取到Cookie等信息，只是使用。

因此，针对以上两点，我们可以从以下两个方面来进行防御：
1、阻止不明外域的访问
同源检测，即直接禁止外域（或者不受信任的域名）对我们发起请求。Cookie的SameSite 属性就可以解决这个问题，SameSite属性可以设置三个值：Strict、Lax、None。
Strict：严格，完全禁止第三方获取cookie，跨站点时，任何情况下都不会发送cookie；只有当前网页的 URL 与请求目标一致，才会带上 Cookie。
Lax：防范跨站，大多数情况下禁止获取cookie，除非导航到目标网址的GET请求（链接、预加载、GET表单）；设置了Strict或Lax以后，基本就杜绝了 CSRF 攻击。当然，前提是用户浏览器支持 SameSite 属性。

None：没有限制。但是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。
2、增加token验证机制
Token被用户端放在Cookie中（不设置HttpOnly），同源页面每次发请求都在请求头或者参数中加入Cookie中读取的Token来完成验证。CSRF只能通过浏览器自己带上Cookie，不能操作Cookie来获取到Token并加到http请求的参数中。
所以CSRF本质原因是“重要操作的所有参数都是可以被攻击者猜测到的”，Token加密后通过Cookie储存，只有同源页面可以读取，把Token作为重要操作的参数，CSRF无法获取Token放在参数中，也无法仿造出正确的Token，就被防止掉了。