猫说

前端安全

2020/10/23 web安全

详细记录一下前端安全的东西，XSS、CSRF。

1、同源策略

同源策略是不可避免要接触到的协议方面的内容，大致了解一下：

同源策略（Same origin policy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。

同源策略是浏览器的行为，是为了保护本地数据不被JavaScript代码获取回来的数据污染，因此拦截的是客户端发出的请求回来的数据接收，即请求发送了，服务器响应了，但是无法被浏览器接收。

同源指的是：协议相同、域名相同、端口相同。

非同源的话，同源策略限制了：Cookie、LocalStorage 和 IndexDB 无法读取、DOM 无法获得、AJAX 请求不能发送。

2、XSS

2.1 XSS简介

  1. 定义：XSS攻击全称跨站脚本攻击，XSS是一种在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。

  2. XSS的攻击方式：反射型，存储型。 ①反射型：发出请求时，XSS代码出现在URL中，作为输入提交到服务器，服务器解析后响应，XSS代码随响应内容一起传回浏览器，最后浏览器解析执行XSS代码，这个过程就像一次反射，故叫反射型。 ②存储型：存储型XSS和反射型XSS的区别在于，提交的代码会存储在服务器端，下次请求页面时不用再提交XSS代码。

  3. XSS的防范措施：编码、过滤、矫正 ①：编码：对用户输入的数据进行HTML entity编码。 ②：过滤：移除用户上传的DOM属性，如onerror等，移除用户上传的style节点，script节点，iframe节点等。 ③：矫正：避免直接对HTML Entity解码，使用DOM parse转换，矫正不配对的DOM标签。

2.2 XSS成因

  1. 网页劫持、DNS劫持、跳转到假的网站页面，比如本地的hosts文件被恶意修改或者DNS服务器被攻击，导致解析到的IP地址是恶意修改过的。脚本被篡改，比如使用第三方的库、资源不安全。

  2. 缓存投毒：访问A站点时，加载了B站点的通用脚本，缓存时间非常长，再访问B站点时中招。 比如在公共场合连wf，WiFi连接成功跳转到一个页面，然而这个页面偷偷请求了很多常用资源，比如jQuery之类的类库，然后自行篡改后超长时间缓存在你本地，当你请求其他网站，其他网站用到了你本地有缓存的类库的时候，就不发送请求直接使用本地缓存的资源，而本地的资源是被恶意篡改过的，这个时候就触发了攻击。

  3. 文件投毒：在非官方站点下载了某个库；官方下载地址被攻击；网络加速缓存了错误的文件；引用了不可信的第三方cdn上的资源。

  4. 客户端投毒：被安装了恶意插件。

  5. 自身安全漏洞，产生反射性和存储性的XSS。

2.3 XSS使用示例

一个思想，具体操作看具体情况

  1. 毫无限制，HTML解析到div，有input输入框，可以输入<script>alert(1)</script>；
  2. 如果是解析到textarea，textarea会自动把内容转为纯文本，可以提前把标签关闭</textarea><script>alert(1)</script>;
  3. 如果服务器做了尖括号的匹配，比如正则匹配掉了替换成''，我们可以用ES6的字符串模板<script>alert1</script>;
  4. 如果反引号也被匹配了，我们可以使用<svg>标签，svg标签有一个特性就是，他内部的HTML实体代码会被执行： <svg><script>alert&#40;1&#41;</script></svg>,左右括号的HTML实体代码是&#40;,&#41;;
  5. 如果服务器做了处理，我们输入的内容被放到了一个HTML注释里面，如<!-- val -->这种闭合,这种可以通过尝试换种闭合解决，HTML的注释闭合可以使用--!>来闭合
  6. 一些网站会把右括号屏蔽或替换掉，我们可以使用标签的onload之类的属性进行，比如<input onload=alert(1)>
  7. 右括号和标签的事件都被屏蔽掉，我们可以利用HTML标签的属性解析有顺序来尝试，比如一个标签<input type="text">，我们可以通过再写一个标签去重置<input type="image" src type="text">，这样这个标签就变成了image，利用这种规则我们可以挣脱一些限制从而执行我们的脚本。
  8. 可以使用svg不闭合，例如：<svg onload=alert(1)>
  9. 标签可以加无数空格，比如</style>会被匹配到，执行失败，我们可以加空格或者换行来规避</style >
  10. 对于域名匹配，一些服务器限制了资源加载要求www.xx.com的合法域名才可以继续进行，我们没有xx.com这个域名，这个是对方的合法域名，我们可以利用我们的域名，比如我有一个a.com,我们可以配一个子域名www.xx.com.a.com去尝试。
  11. 对于一些单匹配一个script标签的正则，可以使用<scriptscriptscript>alert(1)</scriptscript>来进行绕过。
  12. 对于单行注释，我们可以在插入脚本之前的地方，插入一个换行，然后注释掉后面的东西，中间留我们的脚本,如下 ```js

alert(1) –!> ```

解决方法，没有万能的方案，只能看情况使用，下面列常用的方式

  1. 转码：HTML、URL、js需要转码的都不同， HTML需要转码的字符：&amp;,&#39;,&quot;,&lt;,&gt;,&#x2f，分别是&,单引号 ’ ,双引号 “ ,左尖括号 < ,右尖括号 > ,斜杠 \/ 。比如js全转码大写可以规避很多问题，但是到HTML里面就不好使，HTML不区分大小写，都可以正常执行。
  2. 还是转码，比较XSS就是利用输入做点文章，输入的地方都做了限制就好了。
  3. 不要相信用户输入，不要相信后台返回，cdn资源慎用，都做一下检测。

tip: HTML里面可以加很多换行和空格，很多标签可以不闭合，很多标签可以提前闭合，标签解析顺序可以利用，标签的原生方法，image的src的onerror，svg内部的实体HTML可以正常执行。

2.4 xss防护

  1. html标签、正文的实体字符转译
  2. html onxxx事件，js转译
  3. url转译
  4. 用户输入：后台白名单过滤，使用开源库
  5. 操控dom的地方不要随意插入不可信数据
  6. 配置HTTP安全协议头

3、CSRF

  1. cross-site request forgery 跨站请求伪造
  2. 增删改操作严禁使用GET请求
  3. POST等其他协议同样能被CSRF
  4. 敏感操作一定要判断 请求来源，在cookie之外的地方增加加密串，和请求一同带上，甚至发验证码给用户。

4、SQL注入

  1. 对查询语句中的字符做正确转译
  2. 最小化数据库账户使用权限
  3. 不开放不必要但权力过大的功能
  4. 不要过于信任用户输入的数据，限制输入的字符数，以及对用户输入的数据做潜在指令的检查

Search

    Table of Contents