前端Web安全介绍及规避。。。

本文转载自：https://jelon.top/posts/web-security/　　　　

如果侵权，请及时告知。

一、跨站脚本攻击 (xss)

1. 反射型跨站脚本攻击

   攻击者会通过社会工程学手段，发送一个 URL 连接给用户打开，在用户打开页面的同时，浏览器会执行页面中嵌入的恶意脚本。

2. 存储型跨站脚本攻击

   攻击者利用 web 应用程序提供的录入或修改数据功能，将数据存储到服务器或用户cookie中，当其他用户浏览展示该数据的页面时，浏览器会执行页面中嵌入的恶意脚本。所有浏览者都会受到攻击。

3. DOM 跨站攻击

   由于 html 页面中，定义了一段 JS，根据用户的输入，显示一段 html 代码，攻击者可以在输入时，插入一段恶意脚本，最终展示时，会执行恶意脚本。

   DOM 跨站和以上两个跨站攻击的差别是，DOM跨站是纯页面脚本的输出，只有规范使用JAVASCRIPT ，才可以防御。

4. HTML/XML 页面输出规范

   1) 在 HTML/XML 中显示“用户可控数据”前，应该进行 html escape 转义。

   2) 在javascript内容中输出的“用户可控数据”，需要做 javascript escape 转义。

   3) 对输出到富文本中的“用户可控数据”，做富文本安全过滤（允许用户输出 HTML 的情况），统一使用 ANTISAMY 过滤框架处理。

   4) 输出在 url 中的数据，做 url 安全输出。

   5) 针对 DOM 跨站的安全策略及加固措施根据实际情况进行过滤。

   6) 在给用户设置认证 COOKIE 时，加入 HTTPONLY。

   7) 在 style 内容中输出的“用户可控数据”，需要做 CSS escape 转义。

二、FLASH 安全

1. 服务端的安全

   由于没有正确的配置域策略文件，导致客户端的 flash 文件能够绕过同源策略的限制跨域获取数据。

2. 客户端安全

   客户端在嵌入 flash 文件的时候没有指定 flash 文件的客户端限制策略，导致嵌入在客户端的 flash 文件可以访问 HTML 页面的 DOM 数或者发起跨域请求。

   Flash配置规范：

   1) Crossdomain.xml的安全配置：

   如果没有 flash 应用，去掉 crossdomian.xml 文件，对有 flash 应用域的根目录下需要配置 crossdomain.xml 策略文件，设置为只允许来自特定域的请求不允许添加 <site-control permitted-cross-domain-policies="by-content-type"/>，这样会导致客户端可能自己加载自定义策略文件。

   2) 客户端嵌入 flash 文件的安全配置：

   ① 禁止设置 flash 的 allowscriptaccess 为 always，必须设置为 never，如果设置为 SameDomain，需要客户可以上传的flash文件要在单独的一个域下。

   ② 设置 allowNetworking 选项为 none。

   ③ 设置 allowfullscreen 选项为 false。

三、跨站请求伪造攻击 (CSRF)

攻击者在用户浏览网页时，利用页面元素（例如 img 的 src），强迫受害者的浏览器向 Web 应用程序发送一个改变用户信息的请求。

由于发生 CSRF 攻击后，攻击者是强迫用户向服务器发送请求，所以会造成用户信息被迫修改，更严重者引发蠕虫攻击。

要防御 CSRF 攻击，必须遵循一下三步：

1. 在用户登录时，设置一个 CSRF 的随机 TOKEN ，同时种植在用户的 cookie 中，当用户浏览器关闭、或用户再次登录、或退出时，清除 token。

2. 在表单中，生成一个隐藏域，它的值就是 COOKIE 中随机 TOKEN。

3. 表单被提交后，就可以在接收用户请求的 web 应用中，判断表单中的 TOKEN 值是否和用户 COOKIE 中的 TOKEN 值一致，如果不一致或没有这个值，就判断为 CSRF 攻击，同时记录攻击日志。

四、URL 跳转攻击

Web 应用程序接收到用户提交的 URL 参数后，没有对参数做 “可信任 URL” 的验证，就向用户浏览器返回跳转到该URL的指令。

为了保证用户所点击的 URL，是从 web 应用程序中生成的URL，所以要做 TOKEN 验证。

1. 当用户访问需要生成跳转URL的页面时，首先生成随机 token，并放入 cookie。

2. 在显示连接的页面上生成 URL，在 URL 参数中加入 token。

这两个方案都可以保证所有在应用中发出的重定向地址，都是可信任的地址。

五、代码注入攻击

web 应用代码中，允许接收用户输入一段代码，之后在 web 应用服务器上执行这段代码，并返回给用户。

执行代码的参数，或文件名，禁止和用户输入相关，只能由开发人员定义代码内容，用户只能提交 “1、2、3” 参数，代表相应代码。

六、XML/XXE 注入安全攻击

和 SQL 注入原理一样，XML 是存储数据的地方，如果在查询或修改时，如果没有做转义，直接输入或输出数据，都将导致XML注入漏洞。攻击者可以修改XML数据格式，增加新的 XML 节点，对数据处理流程产生影响。

XXE 外部实体注入攻击，当允许引用外部实体时，通过构造恶意内容，可导致读取任意文件、执行系统命令、探测内网端口、攻击内网网站等危害。

在XML保存和展示前，对数据部分，单独做 xml escape。

按照以下列表做转义

1 2 3 4 5

& --> &amp; < --> &lt; > --> &gt; " --> &quot; ' --> &#39;

方案一、使用开发语言提供的禁用外部实体的方法

1 2 3

// JAVA: DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance(); dbf.setExpandEntityReferences(false);

方案二、过滤用户提交的 XML 数据

关键词：<!DOCTYPE 和 <!ENTITY，或者，SYSTEM 和 PUBLIC。

七、任意文件上传攻击

Web 应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，就把文件保存在服务器上，导致恶意用户可以上传任意文件，甚至上传脚本木马到 web 服务器上，直接控制 web 服务器。

处理用户上传文件，要做以下检查：

1. 检查上传文件扩展名白名单，不属于白名单内，不允许上传。

2. 上传文件的目录必须是 http 请求无法直接访问到的。如果需要访问的，必须上传到其他（和 web 服务器不同的）域名下，并设置该目录为不解析 jsp 等脚本语言的目录。

3. 上传文件要保存的文件名和目录名由系统根据时间生成，不允许用户自定义。

4. 图片上传，要通过处理（缩略图、水印等），无异常后才能保存到服务器。

5. 上传文件需要做日志记录。

八、任意文件下载攻击和目录遍历攻击

处理用户请求下载文件时，允许用户提交任意文件路径，并把服务器上对应的文件直接发送给用户，这将造成任意文件下载威胁。如果让用户提交文件目录地址，就把目录下的文件列表发给用户，会造成目录遍历安全威胁。

恶意用户会变换目录或文件地址，下载服务器上的敏感文件、数据库链接配置文件、网站源代码等。

对文件操作功能，做到以下几点：

1. 要下载的文件地址保存至数据库中。

2. 文件路径保存至数据库，让用户提交文件对应 ID 下载文件。

3. 下载文件之前做权限判断。

4. 文件放在web无法直接访问的目录下。

5. 记录文件下载日志（内容见日志章节）。

6. 不允许提供目录遍历服务。

九、垂直/水平权限提升攻击

垂直权限安全攻击（权限提升攻击），由于 web 应用程序没有做权限控制，或仅仅在菜单上做了权限控制，导致的恶意用户只要猜测其他管理页面的 URL ，就可以访问或控制其他角色拥有的数据或页面，达到权限提升目的。

这个威胁可能导致普通用户变成管理员权限。

访问控制攻击(水平权限安全攻击)

Web应用程序接收到用户请求，修改某条数据时，没有判断数据的所属人，或判断数据所属人时，从用户提交的 request 参数（用户可控数据）中，获取了数据所属人 id，导致恶意攻击者可以通过变换数据 ID ，或变换所属人 id ，修改不属于自己的数据。

恶意用户可以删除或修改其他人数据。

在打开管理页面URL时，首先判断当前用户是否拥有该页面的权限，如果没有权限，就判定为“权限提升”攻击，同时记录安全日志。从用户的加密认证 cookie 中，获取当前用户的 id ，并且需要在执行的 SQL 语句中，加入当前用户 id 作为条件语句。由于是web应用控制的加密算法，所以恶意用户无法修改加密信息。

十、Cookie安全

1. Cookie httponly 安全

   Cookie http only，是设置 COOKIE 时，可以设置的一个属性，如果 COOKIE 没有设置这个属性，该 COOKIE 值可以被页面脚本读取。

   设置 cookie 时，加入 http only 属性后， 该 COOKIE 将不可被前端脚本读取。

2. Cookie Secure 安全

   Cookie Secure，是设置 COOKIE 时，可以设置的一个属性，设置了这个属性后，只有在https 访问时，浏览器才会发送该 COOKIE。

   在设置认证 COOKIE 时，加入 Secure。

3. Session 有效期安全攻击

   由于 Session 没有在 web 应用中设置强制超时时间，攻击者一旦曾经获取过用户的Session，就可以一直使用。

   在设置认证 cookie 中，加入两个时间，一个是“即使一直在活动，也要失效”的时间，一个是“长时间不活动的失效时间”。并在 web 应用中，首先判断两个时间是否已超时，再执行其他操作。