1. 常见开发场景安全

1.1 敏感信息使用场景

敏感信息指用户的身份证号、银行卡号、手机号等身份信息。重要敏感信息的脱敏规范如下。

敏感信息类型	展示规范
身份证	显示前 1 位 + (实际位数) + 后 1 位，如： 3***************3
银行卡	显示前 6 位 + (实际位数) + 后 4 位，如：622575*****1496
手机号	显示前 3 位 + ** + 后 4 位，如：137**9050

1.1.1 敏感信息用于展示的场景

原则：敏感信息的展示请严格按照脱敏规范进行脱敏
- 说明：脱敏的逻辑必须在服务端完成，不能使用 Javascript 在客户端进行脱敏，包括代码注释、隐藏域、url 参数、cookies 等处的数据也必须脱敏。
- 说明：不能使用可逆的编码/加密方式，如 base64 编码等代替脱敏规范。
- 说明：若敏感信息明文展示在应用中，没有按照脱敏规范完成脱敏。支付宝开放平台将有权暂停敏感数据相关接口的开放。

1.1.2 敏感信息用于身份校验的场景

原则：不要直接将敏感信息的明文信息在客户端与服务端之间传递
- 说明：可以将敏感信息在服务端关联到用户标识 ID，在客户端保存用户标识 ID 并提交到服务端，服务端根据 ID 取出对应信息后进行校验。
- 说明：如果服务端没有用户标识 ID 的机制，同时也必须在客户端与服务端之间传递敏感信息，请使用 AES128 对称加密算法进行加密后传输，并且不能将解密密钥传输给用户端。

1.2. HTML 页面渲染

原则：所有在页面渲染的敏感数据 (身份证、银行卡号、手机号) 必须进行脱敏
- 说明：参考章节 1.1.1. 敏感信息用于展示的场景
原则：禁止在 Cookie 中明文写入敏感数据
- 说明：参考章节 1.1.2. 敏感信息用于用于身份校验的场景
原则：禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据
- 说明：用户数据不仅仅包括用户正常数据，同时包括攻击者可修改，伪造的其他数据。
- 说明：参考章节 2.2 跨站脚本（XSS）漏洞
原则：HTML 页面动态输出 JSON、JavaScript 必须对其中的字符串值做 XSS 防御处理
- 说明：参考章节 2.2 跨站脚本（XSS）漏洞
原则：默认设置 HTTP Header 中的 HttpOnly 属性为 true
- 说明：设置 HttpOnly 为 true，将可以禁止 JavaScript 读取页面 Cookie 信息，一定程度上防范 XSS 攻击。
- 说明：参考章节 2.2 跨站脚本（XSS）漏洞
原则：如果网站使用 HTTPS 协议，默认设置 HTTP Header 中的 secure 属性为 true
- 说明：设置 secure 为 true，Cookie 信息将不会在 HTTP 连接中传输，一定程度上防范 XSS 攻击。
- 说明：参考章节 2.2 跨站脚本（XSS）漏洞

1.3. 接口调用操作

原则：AJAX 接口必须执行 CSRF 过滤
- 说明：参考章节 2.6 CSRF 漏洞
原则：AJAX 接口输出 JSON 字符串禁止通过字符串拼接构造，且输出的 JSON 需要经过安全过滤
- 说明：参考章节 2.2 跨站脚本（XSS）漏洞
原则：AJAX 接口返回头必须设置 Content-Type 为 application/json;charset=utf-8

1.4. 表单提交操作

原则：统一使用 POST 方式提交表单
- 说明：Get 请求可以通过构造 img 等标签发起，造成 CSRF
- 说明：参考章节 2.6 CSRF 漏洞
原则：Form 表单提交必须执行 CSRF 过滤
- 说明：参考章节2.6 CSRF 漏洞
原则：用户输入的富文本浏览器展示之前必须由服务器端做安全过滤
- 说明：参考章节 2.2 跨站脚本（XSS）漏洞

1.5. 数据库操作

原则：编写的 SQL 必须预编译，不允许通过字符串拼接的方式合成
- 说明：部分特殊场景，必须通过拼接合成，则拼接的变量必须经过处理，只允许 [a-zA-Z0-9_-.]＋字符。
- 说明：参考章节 2.5 SQL 注入漏洞

1.6. 跨域操作

1.6.1. JSONP 跨域

原则：JSONP 接口 Callback 必须验证有效性
原则：JSONP 接口输出 JSON 字符串禁止通过字符串拼接构造，且输出的 JSON 需要经过安全过滤
- 说明：参考章节 2.2 跨站脚本（XSS）漏洞
原则：JSONP 接口必须对 Referer 进行白名单校验，或执行 CSRF 检查
原则：JSONP 接口返回头必须正确设置 Content-Type 为 application/javascript;charset=utf-8

1.6.2. CORS 跨域

原则：支持 CORS 跨域的接口，返回头 Access-Control-Allow-Origin 必须使用白名单验证，禁止直接返回*

1.7 文件上传与下载

原则：限制可下载文件所在的目录为预期范围，并通过指定文件编号的方式来定位待下载文件
- 说明：参考章节 2.4 目录遍历漏洞
- 说明：参考章节文件下载漏洞
原则：保存上传文件的目录不提供直接访问
原则：对上传文件的大小和类型进行校验，定义上传文件类型白名单
- 说明：参考章节文件上传漏洞

2. 常见安全漏洞及修复方案

2.1 源代码仓库安全

源代码泄露也不是个新的话题了。但前段时间的“B站工程源码泄露”又把源代码泄露推上了热搜。

那么问题来了，源代码是怎么被泄露的怎么能预防呢？

源代码的泄露大部分都是在 源代码仓库，内部泄露和线上项目文件权限设置问题，接下来我们来重点讲解一下 源代码仓库 这种。这种方式最为普遍，危险程度也是最高的。

在源代码仓库泄露代码也分为很多种密码被破解、仓库权限设置错误、宿主机漏洞、Web 程序漏洞、SSH 漏洞等等。

我们拿仓库权限举个栗子：

挖掘

利用搜索引擎的高级搜索来搜索一些gitlab私服，这里我提供了以下几种关键字可以去搜索gitlab私服：

谷歌：allinurl:cn + /explore/projects

谷歌：浏览项目,群组和代码片段。与他人分享您的项目

百度：项目· 探索· GitLab - 登录· GitLab

搜索结果大概如下：

我们发现了很多gitlab私服，我们随便点击几个就发现了很多权限设置为公开的项目，这些项目我们分分钟都可以同步回本地，这些仓库都带了全部的代码提交以及操作记录。

利用案例

这里随便搜集了几个私服地址：

http://gitlab.gongwuyun.cn/explore/projects

http://git.neweservice.com/explore/projects

http://www.shenjia.net/explore/projects

代码泄露还不是最危险的。最危险的是代码里面的各种硬编码、密钥以及证书！！！

防范方式

使用强密码降低被破解的风险，开启双重身份验证，使用SSH密钥等……
定期更新系统安全补丁，升级应用版本。
项目权限设置：管理中心 > 通用 > 可见性与访问控制
定期检查开放的项目 管理中心 > 项目 > 公开

2.2 跨站脚本攻击—XSS

漏洞描述

跨站脚本攻击(Cross Site Scripting, XSS)发生在客户端，可被用于进行窃取隐私、钓鱼欺骗、偷取密码、传播恶意代码等攻击行为。 XSS 攻击，==一般是指攻击者通过在网页中注入恶意脚本，当用户浏览网页时，恶意脚本执行，控制用户浏览器行为的一种攻击方式==。

XSS 攻击类型一般分为两类：

==Reflected XSS（反射型的 XSS 攻击）==
==Stored XSS（存储型的 XSS 攻击）==

==两类下有分为若干种方式（例：DOM-based、JSONP XSS）==。

反射型 XSS 和 DOM 型 XSS 算是 非持久型 XSS 攻击，而 存储型 XSS 算是 持久型 XSS 攻击。

2.2.1 Reflected XSS（反射型的 XSS 攻击）

反射型XSS，非持久化，用户通过Web客户端提交给服务端的数据，立刻用于解析和显示该用户的结果页面(数据没有在服务端存储)

漏洞描述

攻击者诱导用户访问一个带有恶意代码的URL后，服务器端接收数据后处理，然后把带有恶意代码的数据发送到浏览器端，浏览器端解析这段带有 XSS 代码的数据后当做脚本执行，最终完成 XSS 攻击。因为这个过程就像一次反射，故称为反射型 XSS。

攻击步骤：

攻击构造出特殊的 URL ，其中包含恶意代码。
用户被诱导打开带有恶意代码的 URL，服务器端将恶意代码从 URL 中取出当做参数处理，然后返回给用户带有恶意代码的数据。
用户浏览器接收到响应解析执行，混在其中的恶意代码也被执行。
恶意代码窃取用户敏感数据发送给攻击者，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

举个栗子：

我们接收一个Name的参数然后把它显示在界面。

下面是一个正常的流程

http://127.0.0.1:888/ReflectedXSS?name=User

显示效果正常。

因为这里没有对用户输入的数据做处理，所以我们构造这样一个链接：

http://127.0.0.1:888/ReflectedXSS?name=%3Cscript%3Ealert(%22xss%22)%3C/script%3E

然后诱导他人点击这个链接，就可以完成一次反射型 XSS 攻击。

==假如客户认识XSS，看见链接有js代码不访问了怎么办？我们还可以伪装伪装，转为短网址或者二维码==。

短网址：http://i6q.cn/4YSo03

也许你觉得只是一个弹框而已，问题不大，但如果我们把攻击代码变为加载一个第三方的 js 文件呢？变为用 document.cookie 盗取 cookie 的代码呢？总之如果是真的攻击的话，就不会只是一个弹框这么简单了。

2.2.2 Stored XSS（存储型的 XSS 攻击）

存储型XSS，持久化，用户通过Web客户端提交给服务端的数据，由服务端保存，然后永久显示在其他用户的页面上。

漏洞描述

存储型 XSS 跟反射型 XSS 的区别是：==存储型 XSS 的恶意代码存在服务器上，反射型 XSS 的恶意代码存在 URL 里==。

存储型 XSS 攻击时恶意脚本会存储在目标服务器上。当浏览器请求数据时，脚本从服务器传回并执行。它是最危险的一种跨站脚本，比反射性 XSS 和 DOM 型 XSS 都更有隐蔽性，因为它不需要用户手动触发。任何允许用户存储数据的 Web 程序都可能存在存储型 XSS 漏洞。若某个页面遭受存储型 XSS 攻击，所有访问该页面的用户都会被 XSS 攻击。

基于存储的 XSS 攻击，是通过提交带有恶意脚本的内容存储在服务器上，当其他人看到这些内容时发起 Web 攻击。一般提交的内容都是通过一些富文本编辑器编辑的，很容易插入危险代码。

攻击步骤：

攻击者把恶意代码提交到目标网站的服务器中。
用户打开目标网站，网站服务器端把带有恶意代码的数据取出，当做正常数据返回给用户。
用户浏览器接收到响应解析执行，混在其中的恶意代码也被执行。
恶意代码窃取用户敏感数据发送给攻击者，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

举个栗子：

https://www.kkkk1000.com/xss/Stored/index.html

但是，评论的内容是没有处理过的，所以我们如果输入这样的内容： <script>alert("xss")</script> 同样是可以作为评论的。

我们用这样的内容作为评论后，所有打开这篇文章的用户都会遭到存储型 XSS 攻击。

XSS 防御

1. 浏览器自带防御（X-XSS-Protection）

HTTP X-XSS-Protection 响应头是 Internet Explorer，Chrome 和 Safari 的一个功能，当检测到跨站脚本攻击(XSS)时，浏览器将停止加载页面。他可以设置4个值： X-XSS-Protection: 0
禁止XSS过滤。

X-XSS-Protection: 1 启用XSS过滤（通常浏览器是默认的）。如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）。

X-XSS-Protection: 1; mode=block
启用XSS过滤。如果检测到攻击，浏览器将不会清除页面，而是阻止页面加载。

X-XSS-Protection: 1; report=
启用XSS过滤。如果检测到跨站脚本攻击，浏览器将清除页面并使用CSP report-uri指令的功能发送违规报告。
复制代码这种浏览器自带的防御功能只对反射型 XSS 有一定的防御力，其原理是检查 URL 和 DOM 中元素的相关性，但这并不能完全防止反射型 XSS，而且也并不是所有浏览器都支持 X-XSS-Protection。

2. 转义

在 XSS 攻击中，攻击者主要是通过构造特殊字符来注入脚本，所以对用户的输入进行检测就很有必要，并且需要在客户端与服务端都进行输入检测，然后对用户输入的数据进行转义。主要就是对输入所包含的特殊字符进行转义，如 <，>，&，"，'，来防止 XSS 攻击。下面是一个用于转义的方法：

function escapeHTML(str) {
    if (!str) return '';
    str = str.replace(/&/g, "&amp;");
    str = str..replace(/</g, "&lt;");
    str = str..replace(/>/g, "&gt;");
    str = str..replace(/"/g, "&quot;");
    str = str..replace(/'/g, "&#39;");
    return str;
};

3. 过滤

在富文本中因为需要保留 HTML ，所以我们不能使用转义的方法防御 XSS 攻击，这里使用过滤的方式防御 XSS 攻击，也就是通过只使用白名单允许的 HTML 标记及其属性，来防御攻击。这里推荐一个名为 ==XSS== 的组件，这就是一个根据白名单过滤 HTML，防止 XSS 攻击的组件。

4. 内容安全策略（CSP）

内容安全策略（Content Security Policy，CSP），实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，大大增强了网页的安全性。

两种方法可以启用 CSP。

一种是通过 HTTP 头信息的 Content-Security-Policy 的字段。

Content-Security-Policy: script-src 'self'; 
                         object-src 'none';
                         style-src cdn.example.org third-party.org; 
                         child-src https:

另一种是通过网页的标签。

<meta http-equiv="Content-Security-Policy"
      content="script-src 'self';
               object-src 'none';
               style-src cdn.example.org third-party.org;
               child-src https:"
>

上面代码中，CSP 做了如下配置。

脚本：只信任当前域名
标签：不信任任何 URL，即不加载任何资源
样式表：只信任 cdn.example.org 和 third-party.org
页面子内容，如、<iframe>：必须使用HTTPS协议加载
其他资源：没有限制

启用后，不符合 CSP 的外部资源就会被阻止加载。

Chrome 的报错信息。

更多资料访问这里：http://www.ruanyifeng.com/blog/2016/09/csp.html

总结

XSS 攻击的本质就是输入的内容被当做程序执行了，所以我们对于用户输入的内容不能完全的信任，需要考虑如何避免其被当做程序执行。

2.3 JSONP XSS

先说 JSONP。通过 JavaScript 调用，被调用域名和当前页面域名不一致，就需要用到 JSONP。

浏览器为了保证跨域访问的安全性，会默认发一个 callback 参数到后台，接口拿到这个参数之后，需要将返回的 JSON 数据外面包上 callback 参数。一般而言，利用跨站脚本攻击，攻击者可窃会话 Cookie 从而窃取网站用户的隐私。

JSONP 的 callback 参数非常危险，他有两种风险可能导致 XSS

1、callback 参数意外截断js代码，特殊字符单引号双引号，换行符均存在风险。

2、callback 参数恶意添加标签（如 <script> ），造成 XSS 漏洞。

参考 JSONP 安全攻防

攻击步骤：

攻击构造出特殊的 URL ，其中包含恶意代码。
用户被诱导打开带有恶意代码的 URL，服务器端将恶意代码从 URL 中取出当做参数处理，然后返回给用户带有恶意代码的数据。
用户浏览器接收到响应解析执行，混在其中的恶意代码也被执行。
恶意代码窃取用户敏感数据发送给攻击者，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

已经在网站 “A” 登录了。网站 “A”有JSONP XSS。我们在网站 “B” 加载含XSS的链接，攻击成功。

http://127.0.0.1:888/jsonpHtml

举个栗子：

在网站 “192.168.3.4:888” 登录设置了Cookie。

http://192.168.3.4:888/jsonp/login

然后在其他地方打开包括有恶意代码的链接。

http://192.168.3.4:888/jsonp/xss?callback=aaaaaaaaa%3C/script%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

网站“192.168.3.4:888”直接执行了恶意代码。

防御内容：

callback 函数名只允许 [, ], a-zA-Z0123456789_, $, .，防止一般的 XSS，utf-7 XSS等攻击。
后端定义返回头类型

2.4 目录遍历漏洞

漏洞描述

攻击者向 Web 服务器发送请求，通过在 URL 中或在有特殊意义的目录中附加 ../、或者附加 ../ 的一些变形（如 ..\ 或 ..// 甚至其编码），导致攻击者能够访问未授权的目录，以及在 Web 服务器的根目录以外执行命令。

解决方案

严格检查文件路径参数，限制在指定的范围。
严格限制文件路径参数，不允许用户控制文件路径相关的参数，限定文件路径范围。

业务漏洞

一般业务漏洞是跟具体的应用程序相关，比如参数篡改（连续编号 ID / 订单、1 元支付）、重放攻击（伪装支付）、权限控制（越权操作）等。

2.5 SQL 注入

漏洞描述

SQL 注入攻击(SQL Injection)，被广泛用于非法获取网站控制权，是发生在应用程序的数据库层上的安全漏洞。在设计不良的程序当中，忽略了对输入字符串中夹带的 SQL 指令的检查，那么这些夹带进去的指令就会被数据库误认为是正常的 SQL 指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。

解决方案

所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中。
对进入数据库的特殊字符 '"<>&*; 等进行转义处理，或编码转换。
确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为 int 型。
数据长度应该严格规定，能在一定程度上防止比较长的 SQL 注入语句无法正确执行。
网站每个数据层的编码统一，建议全部使用 UTF-8 编码，上下层编码不一致有可能导致一些过滤模型被绕过。
严格限制网站所用数据库账号的权限，给此用户仅提供能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
避免网站显示 SQL 错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。

2.6 CSRF 跨站请求伪造

漏洞描述

CSRF（Cross-site request forgery）跨站请求伪造：也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

跨站请求伪造(Cross-Site Request Forgery, CSRF)，恶意网站通过脚本向当前用户浏览器打开的其它页面的 URL 发起恶意请求，由于同一浏览器进程下 Cookie 可见性，导致用户身份被盗用，完成恶意网站脚本中指定的操作。

解决方案

CSRF漏洞修复方案主要思路有两类：

验证请求是信任页面发起，这类修复方案有：
- 在表单中填充一次性随机的 csrf token 防止攻击者伪造 form 表单进行 CSRF。同时将此串 token 置入 session，在后端再进行一次一致性校验。
- referer 验证。
验证请求是合法用户发起，这类修复方案有：
- 验证码
- 密码验证
- OTP 验证

https://xss-game.appspot.com/level1

1. 常见开发场景安全

1.1 敏感信息使用场景

1.1.1 敏感信息用于展示的场景

1.1.2 敏感信息用于身份校验的场景

1.2. HTML 页面渲染

1.3. 接口调用操作

1.4. 表单提交操作

1.5. 数据库操作

1.6. 跨域操作

1.6.1. JSONP 跨域

1.6.2. CORS 跨域

1.7 文件上传与下载

2. 常见安全漏洞及修复方案

2.1 源代码仓库安全

挖掘

利用案例

防范方式

2.2 跨站脚本攻击—XSS

漏洞描述

2.2.1 Reflected XSS（反射型的 XSS 攻击）

漏洞描述

攻击步骤：

举个栗子：

2.2.2 Stored XSS（存储型的 XSS 攻击）

漏洞描述

攻击步骤：

举个栗子：

XSS 防御

1. 浏览器自带防御 （X-XSS-Protection）

2. 转义

3. 过滤

4. 内容安全策略（CSP）

总结

2.3 JSONP XSS

攻击步骤：

举个栗子：

2.4 目录遍历漏洞

漏洞描述

解决方案

业务漏洞

2.5 SQL 注入

漏洞描述

解决方案

2.6 CSRF 跨站请求伪造

漏洞描述

解决方案

About

1. 浏览器自带防御（X-XSS-Protection）