1. 安全问题

1.1. 系统违规并不总是涉及数据获取，有时会出现植入假数据，例如假身份或假运输文件

1.2. 必须在整个开发过程中持续地把安全内建到系统里，而不是把安全像胡椒面那样在出锅前才撒到系统上

2. OWASP

2.1. Open Web Application Security Project

2.2. 开放式Web应用程序安全项目

2.3. 从2001年开始，OWASP基金会开始对应用程序的安全事故和漏洞进行编目

3. 注入

3.1. 当解析器或解释器需要依赖用户提供的输入内容时，注入攻击就有机可乘

3.2. “来自用户”并不仅仅意味着刚刚从HTTP请求中获得的用户输入，从数据库中获取的数据也可能源自用户

3.3. SQL注入

3.3.1. 埋下SQL注入攻击隐患是绝对不允许的

3.3.2. 存在SQL注入漏洞

String query = "SELECT * FROM STUDENT WHERE NAME = '" + name + "'; "

3.3.3. 更好的写法

String query = "SELECT * FROM STUDENT WHERE NAME = ? ; "
PreparedStatement stmt = connection.prepareStatement(query);
stmt.setString(1, name);
ResultSet results = stmt.executeQuery();

3.4. 常见的用于注入攻击的媒介是XML

3.4.1. XML外部实体（XXE）注入是一种基于XML的攻击

3.4.2. 大多数XML解析器在默认情况下容易受到XXE注入的攻击

3.4.3. 绝不能用正则表达式自行解析XML

3.5. 格式化字符串攻击

3.6. Eval注入

3.7. XPATH注入

4. 失效的身份验证和会话管理

4.1. 人们常在URL和超链接上使用查询参数携带会话ID

4.2. 会话ID不仅对每台交换机、路由器和代理服务器可见，也对所有人可见

4.3. 会话劫持

4.4. 会话固定攻击是会话劫持的变体

4.5. 如果会话ID是在任意可预测的过程中生成的，那么服务也容易受到“会话预测”攻击

4.5.1. 基于用户自己的数据生成会话ID肯定有风险，按顺序生成会话ID绝对是最差的选择，虽然会话ID看起来像是随机的，但这并不意味着它就是随机生成的

4.6. 处理会话ID准则

4.6.1. 使用熵较大且字符数量较多的会话ID

4.6.2. 使用具有良好加密属性的伪随机数生成器来生成会话ID

4.6.2.1. 编程语言内置的rand（)函数可能并不是这种生成器

4.6.3. 防范XSS攻击，从而避免执行那些会显示会话ID的脚本

4.6.4. 当用户进行身份验证时生成新的会话ID

4.6.4.1. 发生会话固定攻击，攻击者将无法访问用户账户

4.6.5. 使用平台内置的会话管理功能

4.6.5.1. 做了相关的强化来抵御绝大多数这类攻击

4.6.5.2. 要及时更新平台的安全补丁和版本

4.6.6. 使用cookie交换会话ID，不要通过其他机制接受会话ID

4.6.6.1. 有些服务器虽然使用cookie发出会话ID，但仍然能通过查询参数接收会话ID，要禁用该功能

4.7. 密码注意事项

4.7.1. 不要将密码保存在数据库中

4.7.2. 在处理“忘记密码”操作时，绝对不要用电子邮件向用户发送密码

4.7.3. 将强大的散列算法应用于密码，并给密码“加盐”

4.7.3.1. 给密码添加一些随机数据，加大字典攻击的难度

4.7.4. 允许用户输入过长的密码

4.7.5. 允许用户将密码粘贴到图形用户界面中以便于用户使用密码管理工具生产和使用密码

4.7.6. 计划在未来某个时候用散列算法重置密码，而且必须不断增加散列算法的强度，同时也确保可以更换加盐值

4.7.7. 禁止无限制地尝试身份验证

4.7.8. Kerberos、NTLM和OAuth都是第三方身份验证系统

5. 跨站脚本攻击

5.1. 一些注入攻击者会将“枪口”对准日志查看者，通过将恶意数据放入日志字符串中来搞破坏

5.1.1. 如果日志查看器不能很好地转义HTML字符，那么它将借助日志查看器用户（通常是管理员）的系统访问特权，执行这些恶意代码

5.2. 防范XSS攻击的第一条底线是永远不要对输入内容抱有信任态度

5.3. 不要用拼接字符串的形式构建结构化数据

5.4. 找一个能生成HTML的程序库，自动转义所有内容，并且在做不安全的事情前必须多次确认

6. 失效的访问控制

6.1. 攻击者可以通过应用程序访问到不应访问的数据

6.2. 让URL探测令人望而却步

6.2.1. 降低URL探测的价值

6.2.1.1. 切忌使用数据库ID作为URL的标识符

6.2.1.2. URL中使用的标识符应该是唯一但非连续生成的

6.2.1.2.1. 攻击者可以探测ID空间，但发现有趣结果的可能性会变得很低

6.2.2. 使用会话敏感的通用URL

6.2.2.1. 不要使用http://www.example.com/users/1023

6.2.2.2. 使用http://www.example.com/users/me

6.2.3. 使用特定会话从随机ID到真实ID的映射也会有帮助

6.2.3.1. 使用更多的内存，但避免了随机ID所需的额外的存储空间

6.2.3.2. 该服务必须为所有响应的URL随机分配标识符

6.2.3.3. 当跨越不同的会话时，链接就不再有效，而这违反了REST原则

6.2.3.4. 缺点

6.3. 检查对象最初的授权信息

6.3.1. 服务混淆“拥有URL”和“允许访问资源”是对象访问出现问题的根本原因

6.3.2. 如果资源只应给已授权的调用方使用，那么所有请求都应进行服务鉴权

6.3.3. 假设当调用方请求一个不存在的资源时，服务会响应404 Not Found

6.3.3.1. 404的意思是“没有听说过这个人”

6.3.4. 当请求一个存在却未被授权的资源时，服务会响应403 Authentication Required

6.3.4.1. 403意味着“是的，那是我的顾客”

6.3.5. 服务会泄露资源是否存在的信息

6.3.5.1. 如果调用方未被授权查看某个资源的内容，那么得到的响应是“该资源根本不存在”

6.3.5.2. 假设该资源是按ID进行标识的顾客，那么攻击者就可以通过请求顾客1、2、3等找出系统到底有多少顾客

6.3.5.3. 当响应从403变为404时，他们就发现了顾客群的规模

6.3.5.4. 接下来每个月都能看到这个数字的变化

7. 唯一安全处理文件上传的方法

7.1. 将客户端的文件名内容视为纯粹的字符串存储到数据库字段

7.2. 不要用请求中的文件名构建文件访问路径

7.3. 为真实的文件名随机生成唯一键

7.4. 将其连接到数据库中用户指定的文件名

7.5. 文件系统中的文件名将受服务控制，不会包含任何外部输入内容