详解XSS攻击、SQL注入攻击、CSRF攻击

1、xss攻击

1.1 什么是xss攻击

XSS全称cross-site scripting（跨站点脚本），是当前 web 应用中最危险和最普遍的漏洞之一。攻击者向网页中注入恶意脚本，当用户浏览网页时，脚本就会执行，进而影响用户，比如关不完的网站、盗取用户的 cookie 信息从而伪装成用户去操作，携带木马等等。

1.2 xss分类

1. 反射型XSS（非持久性跨站攻击）
2. 存储型XSS（持久性跨站攻击）
3. DOM Based XSS（基于 dom 的跨站点脚本攻击）

1.2.1 反射型XSS（非持久性跨站攻击）

利用网站某些页面会直接输出请求参数的特性，通过在url的请求参数包含恶意脚本,诱使用户点击嵌入恶意脚本的url链接执行恶意脚本以达到攻击的目的。目前有很多攻击者利用论坛、微博发布含有恶意脚本的URL就属于这种方式。

1.2.2 存储型XSS（持久性跨站攻击）

通过表单输入（比如发布文章、回复评论等功能中）插入一些恶意脚本，并且提交到被攻击网站的服务器数据库中。当用户浏览指定网页时，恶意脚本从数据库中被加载到页面执行，QQ邮箱的早期版本就曾经被利用作为持久型跨站脚本攻击的平台。

与反射型 XSS 相比，该类的攻击更具有危害性，因为它影响的不只是一个用户，而是大量用户，而且该种类型还可进行蠕虫传播。

1.2.3 DOM Based XSS（基于 dom 的跨站点脚本攻击）

通过前面两种类型的方式，注入的脚本是通过改变 DOM 来进行攻击的。采用该种方式有一个好处就是从源代码中不易被发现。

1.3 防范xss攻击

1.3.1 xss攻击漏洞产生的原因

产生xss攻击漏洞主要是因为服务器没有对用户输入进行编码和过滤。

另一个原因是，这种攻击方法有很多变体，攻击的手法却不断翻新，要设计出一个能完全防御的XSS过滤器是非常困难的。

1.3.2 xss攻击防护防范

防范xss攻击的原则就是不相信用户输入的数据，我们可以从俩分泌入手：

1. 消毒（对危险字符进行转义）
2. HttpOnly（防范XSS攻击者窃取Cookie数据）。

消毒

• 对数据进行转义，比如<转义成<,这样脚本就运行不了了。
• 录入数据设置白名单，比如javaWeb项目，设置过滤器过滤特殊字符
• 前端页面限制用户输入数据类型，比如用户输入完年龄后验证输入内容只能是数字。
• 过滤JS事件的标签，比如onclick、load等

HttpOnly

将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了

2、SQL注入攻击

2.1 什么是SQL注入

SQL注入，顾名思义就是通过注入SQL命令来进行攻击，更确切地说攻击者把SQL命令插入到web表单或请求参数的查询字符串里面提交给服务器，从而让服务器执行执行的该SQL。

SQL 注入漏洞产生的原因

既然SQL注入是通过让服务器执行了恶意的SQL命令从而进行攻击的，那么主要问题就出在于服务器是如何生成 SQL语句的。绝大多数拥有SQL注入漏洞的Web系统，在生成SQL语句的时候，采用的是拼接字符串的方式，并且没有对要组装成SQL语句的参数进行检验和过滤。另外Mybatis框架的占位符用的$而不是#也存在被注入的风险。

2.2 SQL注入攻击防范

SQL注入攻击的防护与xss攻击的有点类似，也可以采用消毒的方式，过滤特殊操作字符来避免大部分的注入攻击。

3、CSRF攻击

3.1 定义

CSRF攻击，全程Cross Site Request Forgery（跨站请求伪造），攻击者通过跨站请求，以合法的用户身份进行非法操作（如转账或发帖等）。CSRF的原理是利用浏览器的Cookie或服务器的Session，盗取用户身份，从而进行操作。

3.2 CSRF漏洞产生的原因

CSRF漏洞产生的原因是服务器端没有对请求的发起源进行合理的检验，不加分析地认为请求者一定是正常的用户，响应请求给非法分子。

3.3 防范

CSRF 攻击是一种请求伪造的攻击方式，它利用的是服务器不能识别用户的类型从而盗取用户的信息来攻击。因此要防御该种攻击，因为从服务器端着手，增强服务器的识别能力，设计良好的防御机制。
主要有以下几种方式：

1. 请求头中的Referer验证（不推荐）
2. 请求令牌验证（token验证）

3.3.1 请求头中的Referer验证

HTTP的头部有一个Referer信息的字段，它记录着该次HTTP请求的来源地址（即它从哪里来的）,既然CSRF攻击是伪造请求是从服务器发送过来的，那么我们就禁止跨域访问，在服务器端增加验证，过滤掉那些不是从本服务器发出的请求，这样可以在一定程度上避免CSRF攻击。 但是这也有缺点，比如如果是从搜索引擎所搜结果调整过来，请求也会被认为是跨域请求。

3.3.2 请求令牌验证（token验证）

token验证是一种比较广泛使用的防止CSRF攻击的手段，当用户通过正常渠道访问服务器时，服务器会生成一个随机的字符串保存在session中，并作为令牌（token）返回给客户端，以隐藏的形式保存在客户端中，客户端每次请求都会带着这个token，服务器根据该token判断该请求是否合法

Token可以放在cookie中，在HTTP请求时，可以在form表单中加上一项，提交给后台校验提交的token是否和cookie中的token一致。

CSRF的源站是获取不到cookie里的token的，所以它没办法模拟这样一个POST请求。至于httponly，实际上是用于防止XSS了，一般来讲跟CSRF关系不大。

参考：https://segmentfault.com/q/1010000004869663/a-1020000004870005

转：https://blog.csdn.net/q649381130/article/details/79571574

关于token：

转自：https://blog.csdn.net/qq_35246620/article/details/55049812

基于 Token 的身份验证方法：

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

1. 客户端使用用户名跟密码请求登录；
2. 服务端收到请求，去验证用户名与密码；
3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端；
4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token；
6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

JWT：

实施 Token 验证的方法挺多的，还有一些标准方法，比如 JWT，读作：jot ，表示：JSON Web Tokens 。JWT 标准的 Token 有三个部分：

• header
• payload
• signature

中间用点分隔开，并且都会使用 Base64 编码，所以真正的 Token 看起来像这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

1. Header

Header 部分主要是两部分内容，一个是 Token 的类型，另一个是使用的算法，比如下面类型就是 JWT，使用的算法是 HS256。

{
    "typ" : "JWT",
    "alg" : "HS256"
}

 上面的内容要用 Base64 的形式编码一下，所以就变成这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

2. Payload

Payload 里面是 Token 的具体内容，这些内容里面有一些是标准字段，你也可以添加其它需要的内容。下面是标准字段：

• iss：Issuer，发行者
• sub：Subject，主题
• aud：Audience，观众
• exp：Expiration time，过期时间
• nbf：Not before
• iat：Issued at，发行时间
• jti：JWT ID

比如下面这个 Payload，用到了 iss 发行人，exp 过期时间，另外还有两个自定义的字段，一个是 name ，还有一个是 admin 。

使用 Base64 编码以后就变成了这个样子：

eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ

3. Signature

JWT 的最后一部分是 Signature ，这部分内容有三个部分，先是用 Base64 编码的 header 和 payload ，再用加密算法加密一下，加密的时候要放进去一个 Secret ，这个相当于是一个密码，这个密码秘密地存储在服务端。

• header
• payload
• secret

处理完成以后看起来像这样：

SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

 最后这个在服务端生成并且要发送给客户端的 Token 看起来像这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

 客户端收到这个 Token 以后把它存储下来，下回向服务端发送请求的时候就带着这个 Token 。服务端收到这个 Token ，然后进行验证，通过以后就会返回给客户端想要的资源

Web安全:

 

Token，我们称之为“令牌”，其最大的特点就是随机性，不可预测。一般黑客或软件无法猜测出来。那么，Token 有什么作用？又是什么原理呢？

Token 一般用在两个地方:

• 防止表单重复提交；
• Anti CSRF 攻击（跨站点请求伪造）。

两者在原理上都是通过 session token 来实现的。当客户端请求页面时，服务器会生成一个随机数 Token，并且将 Token 放置到 session 当中，然后将 Token 发给客户端（一般通过构造 hidden 表单）。下次客户端提交请求时，Token 会随着表单一起提交到服务器端。

然后，如果应用于“Anti CSRF攻击”，则服务器端会对 Token 值进行验证，判断是否和session中的Token值相等，若相等，则可以证明请求有效，不是伪造的。不过，如果应用于“防止表单重复提交”，服务器端第一次验证相同过后，会将 session 中的 Token 值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的 Token 没变，但服务器端 session 中 Token 已经改变了。

上面的 session 应用相对安全，但也叫繁琐，同时当多页面多请求时，必须采用多 Token 同时生成的方法，这样占用更多资源，执行效率会降低。因此，也可用 cookie 存储验证信息的方法来代替 session Token。比如，应对“重复提交”时，当第一次提交后便把已经提交的信息写到 cookie 中，当第二次提交时，由于 cookie 已经有提交记录，因此第二次提交会失败。不过，cookie 存储有个致命弱点，如果 cookie 被劫持（XSS 攻击很容易得到用户 cookie），那么又一次 game over，黑客将直接实现 CSRF 攻击。所以，安全和高效相对的，具体问题具体分析吧！

此外，要避免“加 token 但不进行校验”的情况，在 session 中增加了 token，但服务端没有对 token 进行验证，这样根本起不到防范的作用。还需注意的是，对数据库有改动的增、删、改操作，需要加 token 验证，对于查询操作，一定不要加 token，防止攻击者通过查询操作获取 token 进行 CSRF攻击。但并不是这样攻击者就无法获得 token，只是增大攻击成本而已。