一文搞定XSS/CSRF/HTTPS所有知识点

搬砖小方
293 阅读6分钟

一、XSS（跨站脚本）

1、原理

将恶意脚本注入用户当前 html 文档

2、哪些形式

表现

  • 窃取 Cookie
  • 监听用户行为
  • 修改 DOM 伪造表单
  • 在页面中生成浮窗广告

2.1、存储型

将恶意脚本提交到服务器的数据库（如在留言板，评论区提交恶意脚本）

客户端获取数据库信息时，在页面渲染过程中，执行恶意代码

如：将当前网页的 Cookie 发往第三方服务器，达到攻击效果

2.2、反射型

恶意脚本（script 标签）作为网络请求的一部分，作为一个参数传给后端

然后后端返回该参数，浏览器解析为脚本并执行，被攻击

2.1、文档型

攻击不经过服务器，而是作为中间人，在数据传输过程中劫持网络数据包，修改其中的 html 文档

  • WIFI 路由器劫持
  • 本地恶意软件

3、解决措施

  1. 前后端都需要对用户输入进行转码和过滤
    1. 对左右尖括号进行转码
    2. 对 script 标签进行过滤
  2. HTTPOnly
    1. XSS 的一个关键点就是盗取用户 Cookie 信息
    2. 所以可以让 Cookie 无法被 js 脚本获取
  3. CSP
    1. 浏览器的内容安全策略
    2. 服务器决定浏览器加载哪些资源
      1. 限制其他域的资源下载
      2. 进制向其他域提交数据
      3. 提供上报机制

二、CSRF（跨站请求伪造）

1、原理

利用【服务器的验证漏洞】和【用户之前的登录状态（携带 cookie 信息）】发起跨站请求

用户本地有银行网站登录信息，所以浏览器中有可以验证用户登录信息的 Cookie

恶意网站伪造表单诱导用户提交，浏览器会自己带上银行网站 Cookie

这种第三方网站引导发出的 Cookie 称为第三方 Cookie

2、哪些形式

2.1、自动发送 GET 请求

黑客网站利用 img 元素的 src 属性，自动向被攻击网站发送 GET 请求

如果用户本地有被攻击网站的登陆信息，这个请求会自动带上被攻击网站的 Cookie 信息

2.2、自动发送 POST 请求

黑客网站自动发送 form 表单，修改用户数据

2.3、诱导点击发送 GET 请求

诱导用户点击 a 元素，通过 href 属性发送 GET 请求

3、解决措施

  1. 利用 Cookie 的 SameSite 属性，对请求中 Cookie 的携带做限制
    1. Strict：禁止浏览器携带第三方请求的 Cookie
    2. Lax：允许部分第三方请求（导航到目标网址的 GET 请求）携带 Cookie
      • 链接：a 元素的 href
      • 预加载请求：link 元素的 href
      • GET form 表单
    3. None：都可以携带 cookie
  2. CSRF Token
    1. 浏览器访问服务器时，服务器生成 token 并植入到返回的页面中
    2. 浏览器再次访问服务器时需要带上这个 token
    3. 而第三方站点无法获得这个 token
  3. 验证来源站点，请求头中的 Origin 和 Referer
    • Origin：域名信息
    • Referer：URL 路径
    • 但是这二者都可以通过 Ajax 自定义请求头伪造，安全性较差

三、HTTPS

HTTPS

  • HTTP over SSL
  • HTTP over TSL
  • HTTP Secure

1、HTTP 明文传输

客户端和服务器之间进行明文传输，数据很有可能被黑客从中间拦截获取，造成数据泄露

2、只使用对称加密

对称加密需要：

  • 加密算法（一套加密和解密算法）
  • 一个秘钥

通过加密算法，用秘钥给数据加密，可以用同一个秘钥用解密算法进行解密获取原始数据

存在的问题

  • 如果对所有用户用相同的秘钥，则相当于没有加密
  • 服务端也不可能存储所有用户的秘钥
  • 所以每个用户在开启一个会话之前和服务器协商一个秘钥

那么这个秘钥如何协商呢？

如果只是客户端向服务端请求，服务端就给，那么秘钥可能会在传输过程中被黑客盗取。

所以只用对称加密不具有保密性，数据都有丢失的可能。

3、只使用非对称加密

非对称加密：

  • 公钥加密，私钥解密
  • 私钥加密，公钥解密

那么只进行非对称加密呢？

如果要进行非对称加密，首先客户端要从服务器那边拿到公钥，然后客户端有公钥，服务器有私钥，就可以进行数据传输了

存在的问题

这其中也是存在问题的

  • 如果服务器的公钥谁都能要到，那么服务器用私钥加密的数据，谁都能拿到并进行解密

4、对称加密 + 非对称加密

所以，单独的对称加密和非对称加密都不安全，那么将二者结合呢？

先用非对称加密在客户端和服务端协商一个 key，用这个 key 进行后续数据传输的对称加密

中间人问题

第一步，在客户端请求公钥的时候，如果黑客进行拦截，作为一个中间人在客户端和服务端之前传递数据，就会非常危险。

5、引入 CA 机制

目的：保证客户端第一步拿到的公钥是服务器的公钥，而不是中间人黑客的假公钥

5.1、预备阶段

  1. 服务器把自己的身份信息交给 CA 机构，CA 生成一对公私钥作为这个服务器的公私钥，用 CA 私钥对【服务器公钥和身份信息】进行签名，生成证书，把【证书】和【服务器私钥】发还给服务器
  2. 浏览器出厂自带 CA 机构的公钥信息

5.2、通信过程

  1. TCP 三次握手
  2. SSL 握手：对服务器进行身份验证，协商对称加密秘钥
    • 客户端 => 服务器：支持的 SSL 版本，对称加密算法列表，随机数 1
    • 服务器 => 客户端：SSL 版本，对称加密算法，随机数 2，证书
      • 客户端通过 CA 证书
        1. 验证服务器身份
        2. 获取服务器公钥
    • 客户端 => 服务器：随机数 3，hash（随机数1，随机数2）
      • 用服务器的公钥加密
    • 服务端 => 服务器：hash（随机数1，随机数2，随机数3）
      • 服务器用私钥解密
      • 并验证 hash（随机数1，随机数2）是不是等于传过来的值
    • 客户端：验证 hash（随机数1，随机数2，随机数3）是不是等于传过来的值
  3. 正式的数据通信过程，用对称加密

参考资料

sanyuan0704.top/my_blog/

zhuanlan.zhihu.com/p/50692294

www.bilibili.com/video/BV1w4…

avatar
文章
阅读
粉丝