前端xss和csrf部分概述

╰半橙微兮° 2022-12-01 12:20 130阅读 0赞

Web安全的两大特性:

*  私密性: 不被非法获取和利用
 *  可靠性: 不丢失不损坏不被篡改

攻击造成的安全问题:

*  用户身份被盗用
 *  用户密码泄露
 *  用户资料被盗取
 *  网站数据库泄露

防范措施:

*  代码层面
 *  架构层面
 *  运维层面

## \------------------------------------ ##

## 前端XSS ##

Cross Site Scripting 跨站脚本攻击  
跨站有的时候并不是指一定要引用一个远程脚本, 更多的攻击和探测的时候会使用一个alert框来确认这个网站有没有xss漏洞

--------------------

## 1. XSS攻击基本原理: ##

程序 + 数据 = 结果  
下面的《script》本身应该属于content， 是数据的， 但是因为是script标签所以有了执行脚本的行为，进行弹窗， 所以这时候script由数据变成了程序  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center]

--------------------

## 2. Scripting能干什么: ##

*  获取页面数据（脚本在页面上，所以可以通过dom方式抓取数据）
 *  获取Cookie（Document.cookie拿到整个网站cookie）
 *  劫持前端逻辑 （所有代码都在前端，当前端注入另外脚本之后，该脚本可以改变逻辑，比如点击按钮本意是要做A动作， 在插入xss脚本之后可以将按钮点击换成B动作）
 *  发送请求 (页面中的脚本可以向服务器发送请求, 那么xss的脚本也可以发送请求, 或图片,form等手段发送到攻击者自己的网站, 这样实现资料的盗取 )
 *  偷取网站数据, 用户资料
 *  获取用户密码和登录态( 因为大部分情况下登录态是保存在cookie中的, 获取了cookie就等于获取了登录态, 只需要将cookie种到攻击者的浏览器中, 攻击者就可以使用用户的身份进行敏感操作)
 *  欺骗用户 (改变一些页面行为)

案例1:  
![案例][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 1]

> 搜索框中换成一段远程脚本, 引入一个js文件, js文件创建了一个图片, 将图片的url地址指向远程php脚本, 同时在php脚本参数上, 赋上当前cookie, 攻击者接收到这个请求之后就可以把cookie获取到, 应用到自己的浏览器上, 就可以获取当前用户的登录态.

案例2: QQ空间日志编辑 富文本添加script  
案例3: 某商城订单附加信息输入脚本, 获取管理员登录态和后台地址

--------------------

## 3. XSS攻击分类: ##

按照攻击代码的来源大致分为两种:

反射型:  
攻击代码由url直接带过来, 也就是本来网站中不存在这种代码, 攻击者通过url带过来然后页面直接显示这样的代码, 导致产生xss攻击  
一般反射型攻击的危害较小, 因为url中带了一串代码, 传播时需要将url发送出去, 用户会看到可能会怀疑, 而存储型隐蔽性好, 危害更大  
因此攻击者url可以改造成短链接

存储型:  
xss代码会被保存到网站的数据库中, 其他用户访问到这条记录时, 比如一篇文章, 一条评论等, 访问的时候会被数据库中读出来, 到达用户

--------------------

## 4. XSS攻击注入点 ##

*  HTML节点内容 ( 如果一个节点内容是动态生成, 里面包含用户输入信息, 有可能输入信息包含脚本, 产生xss )
    
        <div>
          #{ content}
        </div>
        <div>
          <script>
          </script>
        </div>
 *  HTML属性 ( 某一个HTML节点, 某一个属性是由用户输入的数据组成的, 那么可能包含脚本,或者越出属性本身范围 )
    
        // 这个图片src属性来自用户的输入或者数据库存储的用户之前提交的, 有可能src变成下面样子
        <img src="#{image}" />
        <img src="1" onerror="alert(1)" />
 *  JS代码 (代码中存在由后天诸如的变量, 或者里面包含用户输入的信息, 有可能这些信息改变代码逻辑, 导致xss攻击 )
    
        <script>
          var data = "#{data}";
          var data = "hello";alert(1);"";
        </script>
 *  富文本( 也就是一大段html, 所以里面带有格式, 这一段html我们要保留他的格式, 又要去除里面可能造成xss攻击的代码 )
    
        // 富文本要保留html
        // HTML有XSS攻击风险

--------------------

## 5. 浏览器自带防御: ##

防御的是反射型, 以及参数出现在HTML内容或属性的攻击类型, 但是出现在富文本和JS代码中的无法拦截

浏览器自带防御只适用于反射型的  
HTML内容和HTML属性.

**1. HTML节点内容如何防御:**

用户发表的时候或者显示的时候进行 <> 的转义 &gt &lt
    var escapeHtml = function (str) { 
      str = str.replace	(/</g, '<');
      str = str.replace	(/>/g, '>');
      return str;
    }

**2. HTML属性如何防御:**  
把双引号和单引号和空格进行转义

可以把上面的进行合并
    var escapeHtml = function (str) { 
      if(!str) return '';
      str = str.replace	(/&/g, '&');
      str = str.replace	(/</g, '<');
      str = str.replace	(/>/g, '>');
      str = str.replace	(/"/g, '&quto;');
      str = str.replace	(/'/g, ''');
      
      return str;
    }

**3. JS代码如何防御:**

// 把上面的转义与js这里的进行区分 
    JSON.stringify

**4. 富文本如何防御:**  
1. 白名单方案过滤:  
对富文本过滤一般放在输入时, 因为输入是一次性行为, 过滤会比较耗时影响性能, 所以 输入的时候进行一次过滤对性能影响有限  
按白名单保留部分标签和属性(实现麻烦, 要将html完全解析成数据结构, 对结构进行过 滤, 然后组装成html)

该方案异常繁琐, 因此可以借助插件或库

可以使用cheerio库解析html, 返回类似dom的结构, 特色是使用的类似jquery语法 平时是放到入库之前进行过滤  
jsxss插件

2.黑名单方案过滤

**5. CSP防御:**  
Content Security Policy 内容安全策略  
用于指定哪些内容可执行, 阻止不信任的脚本运行  
它是一个HTTP的头

ctx.get("Content-Security-Policy:'script-src'"

--------------------

## \------------------------------------ ##

## CSRF ##

Cross Site Request Forgy 跨站请求伪造  
在其他网站对目标网站产生影响, 比如在其他网站发送一些请求而这些请求是在用户不知情的情况下完成的  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 2]  
目标网站 a  
攻击者网站 b  
用户在a登录, 输入用户名密码, 发送到网站后台, 验证身份, 验证通过发送一个确认凭证给浏览器(一般是cookie) 保存在浏览器. b网站通过一些手段向a网站后台发送一些数据, 比如表单, 链接, 图片等, 通过这些方式访问a网站后端, 虽然是从b网站发起的请求但是访问的是a网站的后端, 但是它携带了a网站用户的cookie, 也就是说没经过a网站前端, 因此没看到a网站页面, 用户不知情的情况下被b网站用自己的身份发送了一个请求

## 1. CSRF攻击防御 ##

**首先分析攻击的特征:**

*  B网站向A网站请求
 *  带A网站Cookies
 *  不访问A网站前端
 *  refer为B网站

所以根据特征可以做防范

*  禁止第三方网站带cookies

> cookies里的same-sites属性, strict不允许任何cookie, lax稍微宽松比如链接这种可以, ajax不可以

*  不访问A网站前端

> 在前端页面加入验证信息 验证码, token(提交时必须带token信息)  
> 验证码后端如何加: 因为node原生没有图形模块, 借助ccap三方等  
> token放到cookie中和页面的meta中, ajax请求之前通过js把meta中的token取出来一并发到后台, 这样cookie中的值和meta中的一并提交

*  refer为B网站

> 验证refer : refer是http协议中的一个请求头, 包含请求来自哪里. 如果b网站发送的请求, 那么refer为b  
> 有些浏览器允许自己设置refer, 有些业务并没有refer, 那就根据业务需要做不同处理

## \------------------------------------ ##

## 前端Cookies问题 ##

## 1. Cookies特性: ##

*  前端数据存储(浏览器中)
 *  后端通过http头设置
 *  请求时通过http头传给后端(浏览器自动带上符合条件的cookies, http请求和响应中都有cookies)
 *  前端可读写(通过js可以读和修改)
 *  遵守同源策略

> 域名  
> 有效期  
> 路径 (指cookies可以作用于网站的哪一级, 具体就是url上的层级, 可以为不同的url设置不同的cookie, 只有当这个层级的页面被访问时, 这个cookie才可以被使用, 如果其他页面被访问, 那么这个层级的cookie是看不到的 )  
> http-only (指cookie只可以被http协议使用, cookie可以通过请求发送给后端, 后端也可以通过http头来设置)  
> secure (指cookie是否只在https的访问中使用, 当使用http协议时无法使用)  
> same-site是否允许第三方网站使用cookie  
> cookie的删除方法: 设置一个过期的有效期

## 2. Cookies作用: ##

*  存储个性化设置 (该用户上一次停留在什么页面, 皮肤…)
 *  存储未登录时用户唯一标识
 *  存储已登录用户的凭证
 *  存储其他业务数据(做缓存)

**Cookie - 登录用户凭证:**

> 前端提交用户名和密码  
> 后端验证  
> 后端通过http头设置用户凭证(让以后的请求可以识别)  
> 后续访问时后端先验证用户凭证(验票)  
> **有什么样的凭证? :**
> 
> 1.  用户ID + 签名  
>     签名通过crypt模块, sha256算法, 私钥, 相当于把明文的id变成了不可逆密钥形式的
> 2.  sessionID  
>     在cookie中不存储真正的用户数据(比如id, 密码等等), 实际上存储随机的字符串相当于钥匙, 到后台用钥匙验证身份. 这样前端就不存储用户数据, 因此不存在用户数据被盗取和篡改问题. 如何做?  
>     登录时派发一个sessionID, 将用户数据放到内存中, 通过给前端发送一个随机字符串,相当于一个标识, 这时候前端不存储任何数据, 再请求的时候带上这个标识, 就能够在内存中把数据找出来. 但是服务端重启, 数据丢失. 如果使用cookie方案,服务端重启不会丢失数据.  
>     所以希望解决session持久化的问题, 不过一般不会放在内存中, 因为内存容量有限, 用户量增大没法存储所有用户session, 所以一般用外部存储. 再一个项目大, 终端分布多, 造成用户一会访问这一台服务器, 一会访问另一台, 数据不一致, 会造成用户困扰

## 3. Cookies和XSS的关系: ##

xss可能偷取cookies (js可以偷取用户登录态)

如何防止:  
http-only的cookies不会被偷

## 4. Cookies和CSRF的关系: ##

CSRF利用了用户的Cookie  
当用户向目标网站发起请求的时候, 是带上了目标网站的cookie

如何防止:  
虽然CSRF利用了用户cookie, 但是第三方网站无法读写目标网站cookie, 只能让访问的时候带上cookie而已. 所以最好能组织第三方使用cookies(same-site方案, 但是这个兼容性不太好)

## 5. Cookies安全案例: ##

cookies被盗(xss导致或者传输层案例)

案例一:  
某学校(XX大学)教务系统使用了开源CMS, 该CMS使用了username作为用户唯一标识(相当于仅用了id), 该CMS文章作者暴露了username, 可使用任意username登录后台

案例二:  
某论坛使用了某开源ASP BBS程序  
该ASP程序使用用户ID作为唯一标识  
可伪造任意用户登录

## 6. Cookies安全策略: ##

*  加签名防篡改
 *  私有变换(加密)

> 加签名和加密的区别:  
> 签名在于数据仍然是明文, 只是有一个验证数据有没有被修改. 相当于在一份文件上签名, 文件的内容是公开的, 只是验证是否是本人签字. 而加密是把信息隐藏  
> `crypto.createCipher`加密函数 `crypto.createDecipher`解密

*  http-only (防止XSS. 就是只让http请求读写cookie. js是不能读写)
 *  secure (只能在https请求中读写cookie, 防止传输中的窃听, 就是如果有用户登录态的情况下, 用http传输cookie, 有可能被窃取)
 *  same-time (防止csrf攻击, 但是没有副作用, 不过兼容性不好)

## \------------------------------------ ##

## 前端点击劫持 ##

**劫持方案:**  
将目标网站放在页面上, 但是用户操作的是一个iframe, 透明度0

**点击劫持的特征:**

*  用户亲手操作
 *  用户不知情

**如何防御:**

*  JS禁止内嵌(top.loacation 是否等于 window.location). 但是有局限性,比如使用sandbox属性将js禁止掉, 点击劫持仍然存在
 *  X-FRAME-OPTIONS 禁止内嵌 ( 页面加载的时候, 直接制定好关于iframe策略, 就是是否允许内嵌, 当不允许内嵌的时候浏览器禁止内嵌 )
 *  其他辅助手段(比如加入验证码)

## \------------------------------------ ##

## 传输安全 ##

## 1. HTTP窃听 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 3]  
链路是对网络设备的一种统称, 包括路由器, 网关控制设备等等. 也就是浏览器到服务器中间会经过非常多的节点, 中间会有转发的数据, 会有窃听和篡改的可能  
Linux命令`traceroute www.xxx.com`  
![在这里插入图片描述][20200827221544863.png_pic_center]  
案例:  
运营商劫持  
某搜索网站  
访问的时候弹出流量球告知还剩多少流量  
局域网劫持  
公共wifi获取密码

## 2. HTTPS ##

![https][]  
**中间人攻击**:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 4]  
**如何确定服务器身份**:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 5]

## \------------------------------------ ##

## 密码安全 ##

## 1. 密码的泄露渠道 ##

*  数据库被偷
 *  服务器被入侵(比如从缓存中读取)
 *  通讯被窃听
 *  内部人员泄露
 *  其他网站撞库

**防护措施:**

*  严禁明文存储
 *  单向变换
 *  变换复杂度(防猜解)
 *  密码复杂度(防猜解)
 *  加盐(防猜解)

**密码-哈希算法**:  
明文-密文 一一对应  
雪崩效应(哪怕一点点不一样, 密文完全不一样)  
密文-明文 无法反推  
密文固定长度 一般32位字符串  
常见哈希算法 md5, sha1, sha256

单向密码彩虹表

## 2. 密码传输安全 ##

*  https传输
 *  频率限制防止猜解
 *  前端加密意义有限(虽然明文变化后, 但是攻击者也可以使用变换后的密码进行登录, 所以仅仅能明文密码不被获取)

> 前端密码加密如何做:  
> js-md5模块 + 加盐  
> 后端如何做  
> 与前端算法保持一致

## \------------------------------------ ##

## 接入层注入问题 ##

## 1. 关系型数据库和SQL介绍 ##

*  存放结构化数据
 *  可高效操作大量数据
 *  方便处理数据之间的关联关系(比如一个表存用户信息, 一个是评论信息的表, 希望查询用户的评论就涉及到关联查询)
 *  常见的 : access / sqlite(多用于嵌入式设备) / mysql / mssql / server

## 2. SQL语言 ##

`show table`  
`select * from table where id = 1` 查询  
`insert into`  
`set`  
`delete`  
标准化  
类似自然语言的描述性语言  
用于关系型数据库

## 3. SQL注入 ##

**SQL注入危害:**

*  猜解密码
 *  获取数据
 *  删库删表
 *  拖库

**SQL注入防御:**

*  关闭错误输出
 *  检查数据类型
 *  对数据进行转义
 *  使用参数化查询
 *  使用ORM(对象关系映射)

## \------------------------------------ ##

## 接入层上传问题 ##

**上传问题**

1.  上传文件 (比如头像)
2.  再次访问上传的文件
3.  上传的文件被当成程序解析 会产生问题

**上传问题防御**

1.  限制上传后缀 (extname)
2.  文件类型检查(file.type)
3.  文件内容检查(fs.readFileSync(file.path)读出来buffer数据对象, 根据前几位判断文件内容)
4.  node通过fs.readFileSync(file.path)读出来直接放body里, 不给文件执行的机会. 这样会影响性能, 因为把文件读到内存中, 然后输出给浏览器, 中间有一层读和写的过程. 折衷的办法是: 程序知道我要去访问哪个文件, 然后我可能直接输出一个指令给到前端服务器, 然后服务器直接读给它, 性能损耗少一些
5.  权限控制 - 可写可执行互斥(意思是因为脚本之所以可以正常工作, 是因为能执行. 那么上传文件就给目录写入的权限, 如果目录不可写上传也不会成功, 给目录只给可写的权限或者只给执行的权限)

## \------------------------------------ ##

## 社会工程学和信息泄露 ##

**信息泄露的途径**

*  错误信息失控
 *  SQL注入
 *  水平权限控制不当
 *  XSS/CSRF

**OAuth思想**

*  一切行为由用户授权
 *  授权行为不泄露敏感信息(虽然完成授权, 但只拿到token, 并没有拿到密码)
 *  授权会过期  
    ![OAuth][]

**利用OAuth思想防止资料泄露**

*  用户授权读取资料
 *  无授权的资料不可读取
 *  不允许批量获取数据
 *  数据接口可风控审计 (sdk.login(data.username, data.password) 业务部门不可以操作sdk,拿到票据, 请求sdk)  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 6]

## \------------------------------------ ##

## 其他安全问题 ##

## 1. 拒绝服务攻击DOS ##

模拟正常用户 大量占用服务器资源 无法服务正常用户

**攻击方式:**

1.  TCP半连接( 攻击者只发送一半请求, 服务器尝试打开一个连接, 告诉对方我已经准备好, 请你过来连接, 这时攻击者不再进行连接, 服务器产生等待, 影响后续请求 )
2.  HTTP连接
3.  DNS ( 如果发现上面两种攻击力度不够, 或者防御能力很强, 会转而攻击DNS )

## 2. 大规模分布式拒绝服务攻击DDOS ##

流量可达几十到上百G  
分布式

**DOS攻击防御:**  
交换机  
流量清洗  
高防IP

**预防措施**  
避免重逻辑业务(快速解决用户业务需求, 重逻辑需求拆分)  
快速失败快速返回 ( 负载很高的时候, 减少重试请求 )  
防止雪崩机制 (清楚了解能承载多少请求, 当快要到达极限的时候先拦截请求, 对系统进行保护 )  
有损服务 (允许部分服务异常, 不影响其他服务)  
CDN(主要针对静态文件, 减少服务器负载)

## 3. 重放攻击 ##

请求被窃听或记录  
再次发起相同的请求, 产生意外的结果

**产生后果:**  
用户被多次消费  
用户登录态被盗取  
多次抽奖, 投票

**防御:**  
加密HTTPS  
请求加时间戳  
token(session)  
nonce (类似token, 后端生成字符串并记录, 表示这一次请求被用过, 下一次请求再用相同nonce就拒绝, 但是这个可以被篡改, 涉及到篡改就涉及签名 )  
不管时间戳还是nonce都需要签名

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/3300c98e185745678cd1d0444b8ec11f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/f1089ec916f64833a369eefab945a565.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/f90efca7f89a40db81e8ec212519c8df.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/685a7ecfb96f46e6b6838af0a7a5505f.png
[20200827221544863.png_pic_center]: /images/20221123/0e2cd9406d114c9e9ed11534ed80a440.png
[https]: /images/20221123/f44ec8b65c4b4644a428a4ca36ca87c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/8dea337bb4254161bcd112e3d12f6a40.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/63dcee3394a745b49eb106730869d66c.png
[OAuth]: /images/20221123/f2daccc187fe487fb769d25f2187490f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzQ4NDQ2NTQy_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/dac8e676dc54405b8a169f3d91084a2a.png