XSS 与 CSRF 与 SQL注入

一、CSRF(跨站请求伪造)

跨站请求伪造(Cross-site request forgery)，也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF，是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。

如：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

flask 模仿csrf攻击 与 保护:https://www.cnblogs.com/love2000/p/13678360.html

攻击原理及过程

用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
用户未退出网站A之前，在同一个浏览器中，打开一个Tab页访问网站B；
网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。
网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

场景模拟

（1）场景一

假设你正在购物，看重了某个商品，商品 id 是 100 。
同时这个商品的付费接口时 xxx.com/pay?id=100，但是没有任何验证。
这个时候我是攻击者，我看中了一个商品，id 是 200 。
那么，我如何让你来为我付款？
这个时候我像你发送了一封邮件，邮件标题很是吸引人。
但邮件正文隐藏着 <img src = "xxx.com/pay?id=200"> 。
你一查看邮件，一点击，就帮我购买了 id 是 200 的商品。

（2）场景二

要完成一次 CSRF 攻击，受害者必须依次完成两个步骤：
登录受信任网站 A ，并在本地生成 Cookie 。 在不登出 A的情况下，访问危险网站 B 。
看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。
是的，确实如此，但是呢，你可能没办法保证以下情况不会发生哦！
比如：你不能保证你登录了一个网站后，不再打开一个 tab 页面并访问另外的网站。
你不能保证你关闭浏览器了后，你本地的 Cookie会立刻过期，你上次的会话已经结束。
（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了…）
上述中所说的网站，可能是一个存在其他漏洞，但又很受信任的且经常被人访问的网站。

CSRF的特点

攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作，而不是直接窃取数据。 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”

CSRF攻击方式

跨站请求可以用什么方式：

图片 URL 、超链接、 CORS 、 Form 提交等等。
部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。
但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，且这种攻击方式更加危险！

CSRF常见的攻击类型：
（1）GET类型的CSRF

GET 类型的 CSRF 是较为容易攻击的一种方式，只需要一个 HTTP 请求，攻击者一般做出以下操作：
<img src="http://bank.example/withdraw?amount=10000&for=hacker" >
在受害者访问含有这个 img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP 请求。
bank.example 就会收到包含受害者登录信息的一次跨域请求。

（2）POST类型的CSRF

这种类型的 CSRF 攻击通常使用的是一个自动提交的表单，

 如：
	<form action="http://bank.example/withdraw" method=POST> 
		<input> type="hidden" name="account" value="xiaoming" /> 
		<input type="hidden" name="amount" value="10000" /> 
		<input type="hidden" name="for" value="hacker" />
	</form>
	<script> document.forms[0].submit(); </script> 

访问该页面后，表单会自动提交，相当于模拟用户完成了一次 POST 操作。
POST 类型的攻击通常比 GET要求更加严格一点，但仍并不复杂。
任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许 POST上面。

（3）链接类型的CSRF

比起其他两种用户打开页面就中招的情况，链接类型的 CSRF比较不常见，因为这种攻击方式需要用户点击链接才会触发。
这种类型通常是在论坛等平台发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击，例如：<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker"> taget="_blank">1</a>

防范：

（1）验证HTTP Referer字段

	根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。
	通过 Referer Check，可以检查请求是否来自合法的”源”。 
	
	在通常情况下，访问一个安全受限页面的请求来自于同一个网站，
	比如需要访问http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，
	用户必须先登陆bank.example，然后通过点击页面上的按钮来触发转账事件。
	这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的URL，通常是以 bank.example 域名开头的地址。 
	而如果黑客要对银行网站实施 CSRF攻击，他只能在他自己的网站构造请求，
	当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。 
	
	因此，要防御CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，
	如果是以 bank.example开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。
	
	如果 Referer 是其他网站的话，则有可能是黑客的 CSRF攻击，拒绝该请求。然而，这种方法并非万无一失。 
	Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，
	但是每个浏览器对于Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。 
	使用验证 Referer值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。
	
	事实上，对于某些浏览器，比如 IE6 或FF2，目前已经有一些方法可以篡改 Referer 值。 
	如果 bank.example 网站支持 IE6 浏览器，黑客完全可以把用户浏览器的Referer 值设为以 bank.example 域名开头的地址
	这样就可以通过验证，从而进行 CSRF 攻击。
	
	即便是使用最新的浏览器，黑客无法篡改 Referer 值，这种方法仍然有问题。
	因为 Referer值会记录下用户的访问来源，有些用户认为这样会侵犯到他们自己的隐私权，
	特别是有些组织担心 Referer值会把组织内网中的某些信息泄露到外网中。
	
	因此，用户自己可以设置浏览器使其在发送请求时不再提供Referer。
	当他们正常访问银行网站时，网站会因为请求没有 Referer 值而认为是 CSRF 攻击，拒绝合法用户的访问。

（2）token验证

	在请求地址中添加token并验证，可以在 HTTP 请求中以参数的形式加入一个随机产生的token，
	并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，
	则认为可能是CSRF 攻击而拒绝该请求。 
	这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session之中，
	然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对。 

（3）在 HTTP 头中自定义属性并验证

	这种方法也是使用 token 并进行验证，和上一种方法不同的是，
	这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到HTTP 头中自定义的属性里。
	通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP头属性，并把 token 值放入其中。

方案：

1）验证码 增加验证，例如密码、短信验证码、指纹等等，强制用户必须与应用进行交互，才能完成最终请求。
这种方式能很好的遏制 csrf，但是用户体验相对会比较差。

2）Referer check referer 代表请求的来源，不可以伪造。
后端可以通过写一个过滤器来检查请求的 headers 中的referer ，检验是不是本网站的请求。
但缺点是浏览器可以关闭 referer ，且低版本的浏览器会存在伪造 Referer 的风险。
referer 和 origin 的区别，只有 post 请求会携带 origin 请求头，而 referer 不论何种情况下都带。

3）token 是最普遍的一种防御方法，后端先生成一个 token，将此放在数据库中并发送给前端
那么前端发送请求时就会携带这个 token ，后端通过校验这个 token 和数据库中的 token是否一致，以此来判断是否是本网站的请求。
示例： 用户登录输入账号密码，请求登录接口，后端在用户登录信息正确的情况下将 token放到数据库中，
并返回 token 给前端，前端把 token 存放在 localstorage 中，之后再发送请求都会将 token 放到header 中。
后端写一个过滤器，拦截 POST 请求，注意忽略掉不需要 token 的请求，
比如登录接口，获取 token 的接口，以免还没有获取 token 就开始检验 token 。
校验原则：数据库中的 token 和前端 header 中的 token一致的 post 请求，则说明校验成功，给客户端放行。

什么是csrf？（cross-site request forgery）简称跨站请求伪造，它是一种什么行为？伪造你的请求的行为。

简单来说就是:

你访问了信任网站A,然后A会用保存你的个人信息并返回给你的浏览器一个cookie
然后呢，在cookie的过期时间之内，你去访问了恶意网站B，它给你返回一些恶意<br>请求代码，要求你去访问网站A，
而你的浏览器在收到这个恶意请求之后，在你不知情的情况下，会带上保存在本地浏览器的cookie信息去访问网站A，
然后网站A误以为是用户本身的<br>操作，导致来自恶意网站C的攻击代码会被执行：
发邮件，发消息，修改你的密码，购物，转账，偷窥你的个人信息，导致私人信息泄漏和账户财产安全受到威胁。

如何解决？在post请求时，form表单或ajax里添加csrf_token（实际项目代码里就是如此简单）

解决原理：

添加csrf_token值后，web框架会在响应中自动帮我们生成cookie信息，返回给浏览器，同时在前端代码会生成一个csrf_token值
然后当你post提交信息时，web框架会自动比对cookie里和前端form表单或ajax提交上来的csrf_token值，两者一致
说明是当前浏览器发起的正常请求并处理业务逻辑返回响应
那么第三方网站拿到你的cookie值为什么不能通过验证呢，因为他没你前端的那个随机生成的token值啊，
他总不能跑到你电脑面前查看你的浏览器前端页面自动随机生成的token值吧。

注意：

你打开浏览器访问某个url（页面），默认是get请求
也就是说，你只要访问了url，对应的视图函数里只要不是if xx ==post的逻辑就会执行
所以你打开页面，他会先生成cookie（token）值，返回给浏览器
然后你提交表单，或者发ajax请求时会将浏览器的cookie信息（token值）发送给服务器进行token比对
这个过程相对于你发起了两次请求，第一次是get，第二次才是post
搞清楚这个，你才能明白csrf_token是怎么比对

的。

二、XSS（跨站脚本攻击）

不需要你做任何的登录认证，它会通过合法的操作（比如在 url 中输入、在评论框中输入），向你的页面注入脚本（可能是 js、hmtl
代码块等）。

共分为三种：

非持久型跨站（也叫反射型）
持久型跨站（也叫存储型）
DOM跨站

（1）非持久型跨站（反射型）

①攻击步骤

攻击者构造出特殊的 URL ，其中包含恶意代码。 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL
中取出，拼接在HTML中返回给浏览器。 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

②攻击场景

反射型 XSS (也被称为非持久性 XSS )漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

③攻击方式

由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。
POST 的内容也可以触发反射型XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。

（2）持久型跨站（存储型）

①攻击步骤

攻击者将恶意代码提交到目标网站的数据库中。
用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在HTML中返回给浏览器。
用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

②攻击场景

存储型 XSS 攻击 (也被称为持久型 XSS )常见于带有用户保存数据功能的网站，如论坛发帖、商品评论、用户私信等。

③危害

它是最危险的一种跨站脚本，相比反射型 XSS 和 DOM 型 XSS 具有更高的隐蔽性，危害更大，因为它不需要用户手动触发。
任何允许用户存储数据的 web 程序都可能存在存储型 XSS 漏洞，当攻击者提交一段 XSS
代码后，被服务器端接收并存储，当所有浏览者访问某个页面时都会被 XSS 。

（3）DOM跨站

①攻击步骤

攻击者构造出特殊的 URL ，其中包含恶意代码。 用户打开带有恶意代码的 URL 。
用户浏览器接收到响应后解析执行，前端JavaScript 取出 URL 中的恶意代码并执行。
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

②危害

DOM通常表示 html、xhtml和xml中的对象，使用 DOM可以允许程序和脚本动态的访问和更新文档的内容、结构和样式。
它不需要服务器解析响应的直接参与，触发 XSS 依靠的是浏览器端的DOM解析 。

对以上三种xss的攻击类型进行一个小结

反射型跟存储型的区别是：

存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
DOM 型跟前两种区别是： DOM 型 XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

三者的对比：

类型存储区插入点反射型 XSSURLHTML存储型 XSS后端数据库HTMLDOM 型 XSS后端数据库/前端存储/URL前端 JavaScript
防范：

只要有输入数据的地方，就可能存在 XSS 危险。
1.编码： 对于用户输入进行编码；
2.过滤： 移除用户输入和事件相关的属性；(过滤 script、style、iframe 等节点)；
3.校正： 使用 DOM Parse 转换，校正不配对的 DOM 标签；
4.设置HttpOnly 在 cookie 中设置 HttpOnly 属性后，js 脚本(document.cookie)将无法读取到 cookie 信息。
5.CSP(内容安全策略): CSP 的实质就是白名单策略，预先设定好哪些资源能被加载执行而哪些不能，为了防止跨域脚本攻击而制定。

实现方式一：通过 HTTP 头信息的 Content-Security-Policy 的字段；
实现方式二：通过页面标签；

防范：

php防止XSS跨站脚本攻击的方法:是针对非法的HTML代码包括单双引号等
使用htmlspecialchars(string,quotestyle,character-set)函数。
需注意第二个参数, 直接用htmlspecialchars($string)的话,第二个参数默认是ENT_COMPAT,函数默认只是转化双引号(“), 不对单引号(‘)做转义

两者区别：

CSRF： 需要用户先登录网站 A，获取 cookie。
XSS： 不需要登录。

CSRF： 是利用网站 A 本身的漏洞，去请求网站 A 的 api。
XSS： 是向网站 A 注入 JS 代码，然后执行 JS里的代码，篡改网站 A 的内容。

	通常来说 CSRF 是由 XSS 实现的，CSRF 时常也被称为 XSRF（CSRF 实现的方式还可以是直接通过命令行发起请求等）。
	本质上讲，XSS 是代码注入问题，CSRF 是 HTTP 问题。 
	XSS 是内容没有过滤导致浏览器将攻击者的输入当代码执行，CSRF 则是浏览器在发送 HTTP 请求时候进行。

三、SQL注入

这篇博客写的非常详细
https://blog.csdn.net/lady_killer9/article/details/107300079