Web应用开发规范

Web应用十大安全风险

1. 注入

注入漏洞（如SQL， OS和LDAP注入）。

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

与身份认证和会话管理相关的应用程序功能往往没有正确的实现， 导致攻击者破坏口令或密钥， 会话令牌或其他的漏洞来冒充用户身份。

3. 跨站脚本（XSS）

当应用程序收到含有不可信的数据， 在没有进行适当的检验和转义的情况下， 就将它发送给web浏览器， 这就会产生跨站脚本攻击（简称XSS）， XSS允许攻击者在受害者的浏览器上执行脚本， 从而劫持用户会话， 危害网站， 或者将用户转向恶意网站。

4. 不安全的直接对象引用

当开发人员暴露一个对内部实现对象的引用时， 例如： 一个文件，目录或数据库密钥， 就会产生一个不安全的直接引用对象。 在没有访问控制检测或其他保护时， 攻击者会操控这些引用去访问未授权数据。

5. 安全配置错误

好的安全需要对应用程序， 框架，应用服务器， web服务器， 数据库服务器和平台， 定义和执行安全配置。 由于许多配置的默认值是不安全的， 因此， 必须定义，实施和维护所有这些配置。 这包括了对所有的软件保持及时地更新， 包括所有应用程序的库文件。

6. 敏感数据泄露

许多的web应用程序没有正确保护敏感数据， 如信用卡， 税务登记号码， 身份验证凭据。 攻击者可能会窃取或修改这些弱保护的数据进行身份盗窃、 信用卡诈骗罪或其他犯罪。

敏感数据应该得到额外的保护， 如在存储或传输时加密， 以及当与浏览器进行交换时， 做特殊的预防措施（如用HTTPS）。

7. 缺少功能级别的访问控制

几乎所有的web应用都检验功能级别的访问权限， 然后再使功能在界面可见。 然而， 当每个功能被访问时， 应用需要在服务器端进行相同的访问控制检查。 否则， 攻击者就能够伪造请求访问未授权的功能。

8. 跨站请求伪造（CSRF）

一个跨站请求伪造攻击迫使登录用户的浏览器将伪造的HTTP请求， 包括用户的会话和cookie和其他认证信息， 发送给一个存在漏洞的web应用程序， 这就允许了攻击者迫使用户浏览器向存在漏洞的应用程序发送请求， 而这些请求会被应用程序认为是合法的用户请求。

9. 使用存在已知漏洞的组件

有漏洞的组件（例如： 库， 框架和其他软件模块）几乎是全权限运行。 所以， 一旦漏洞被利用， 可能导致敏感数据泄露或服务器被攻击者接管， 使用这些脆弱组件应用程序可能会破坏他们的防御， 并使一系列的攻击或影响成为可能。

10. 未验证的重定向或转发

web应用程序经常将用户重定向和跳转到其他网页或网站， 并且利用不可信的数据来确定目的页面。 如果没有得到适当的验证， 攻击者可以重定向到受害用户到钓鱼网站或恶意网站， 或者使用转发去访问未授权的页面。

web应用程序缺陷和由于设计可能导致的问题

• 身份验证： 身份伪造， 口令破解， 权限提升和未授权访问
• 权限管理： 访问机密或受限数据， 篡改和执行未授权访问。
• 会话管理： 通过捕获导致会话劫持和会话伪造
• 输入检验： XSS， SQL注入等
• 参数操作： 路径遍历， 命令执行等
• 敏感数据： 机密信息泄露和数据篡改
• 加密技术： 未授权访问机密数据或帐号信息
• 异常管理： 拒绝服务和敏感的系统级详细信息泄露
• 安全审计： 未识别入侵征兆、无法证明用户操作， 以及在问题诊断中存在困难
• 配置管理： 未授权访问管理界面、更新配置数据、访问用户帐号和帐号配置文件

主要安全性原则

• 攻击面最小化
• 默认安全
• 最小权限原则
• 深度防御原则
• 安全地失败
• 外部系统是不安全的
• 职责分离
• 不依赖隐晦的安全
• 简单
• 正确地修改安全问题
• 客户端的输入是不可信的

认证

用户口令

• 用户名/用户ID必须唯一
• 设置/修改口令时默认进行口令复杂度检查
• 口令输入框不能明文显示或copy
• 用户修改旧口令时， 必须验证旧口令， 同时对新口令确认
• 强制用户在首次登录系统时修改系统为其设置的口令
• 强制特权用户的口令每隔一定周期必须进行修改， 周期可配置
• 在网络传输口令必须采用安全协议（如HTTPS）
• 不要以任何形式发送口令哈希或口令给用户
• 口令存储前使用带hash的算法加密
• 系统支持口令修改最短时间间隔以及口令历史记录， 并支持可配置
• web应用不应该实现“记住我”功能
• 关闭登录窗体菜单的自动填充功能
• 应提供安全口令重置功能（邮件/手机短信验证码）

认证要求

• 对用户的最终认证处理过程必须在服务器端进行
• 网页上的登录和验证表单必须加入验证码
• 所有登录页面的认证处理模块必须统一
• 认证失败， 不能给用户详细的、明确的错误原因， 只能给出一般性的提示， 同时记录日志信息
• 禁止在系统中预留任何未公开的帐号和特殊的访问机制
• 对于重要的管理事务或重要的交易事务要进行重新认证或二次认证
• 对安全性要求高的web应用实施多因素认证
• 同一客户端在多次连续尝试登录失败后， 服务端需要进行用户帐号或客户端所在机器的IP地址的锁定策略， 且该锁定策略必须设置解锁时长， 超时自动解锁
• 认证通过后， 给当前用户显示访问历史记录数据

授权

广义上的授权， 包括授权和鉴权两部分

• 对于用户请求的URL需要先标准化后进行鉴权， 避免鉴权被绕过
• 对于受保护资源的访问， 必须检查用户是否拥有访问该资源的权限， 如果没有则拒绝访问并记录日志
• 采用基于角色的访问机制， 授权用户角色数据必须存放在服务端， 不能存放在客户端， 鉴权处理也必须在服务端完成
• 一个帐号只能拥有必须的权限和角色， 一个组只能拥有必需的角色和必须的权限， 一个角色只能拥有必需的权限。
• 帐号默认没有角色和权限， 也就是说， 角色刚创建后没有任何权限。
• 对于运行应用程序的操作系统帐号不应使用"root", "administrator", "supervisor"等特权帐号或高级别帐号， 应该尽可能地使用低级别的权限的操作系统帐号。
• 对于应用程序连接数据库服务器的数据库帐号， 在满足业务需求的前提下， 必须使用最低级别权限的数据库帐号
• 对于应用程序连接Web Server或者中间件的帐号， 在满足业务需求的前提下， 必须使用最低级别权限的帐号， 禁止使用admin等超级帐号
• 若使用web框架， 优先使用web框架自带的授权机制。 若web框架提供的机制无法满足需求时， 需要自己开发集中的授权模块时， 应该完全覆盖受保护的资源和功能， 且当授权发生异常时， 强制用户退出。
• 当授权变更、终止、或失效时， 应支持禁用帐号和终止会话的能力
• 限制单个用户或设备可以在一个给定的时间内执行的交易数量

会话管理

• 使用web开发框架自身提供的会话管理功能
• 会话cookie的属性要设置为HttpOnly
• 用户名和口令认证通过后， 必须更换会话标识
• 任何重新认证或二次认证都需要重新生成新的会话标识
• 会话过程不允许修改的信息， 必须作为会话状态的一部分在服务器端存储和维护
• 必须设置会话超时机制， 在超时后必须清除该会话信息
• 所有登录后才能访问的页面都必须有明显的”注销“的按钮或菜单。 如果该按钮或菜单被点击， 则必须使对应的会话立即失效。
• 在服务端对业务流程进行必要的流程安全控制， 保证流程衔接正确， 防止关键鉴别步骤被绕过、重复、乱序。
• 当web应用跟踪到非法会话， 则必须记录日志， 清除会话并返回认证界面。
• 如果产品无法使用web容器， 只能自己实现web服务， 那么必须自己实现会话管理。
• 为包含会话标志的cookie设置适当的限制domain和path
• 当服务端检测到用户的IP，UserAgent等信息发生变化， 应该强制销毁当前会话， 并要求用户重新登录。
• 防止并发登录。
• 为cookie设置secure标志。

输入检验

• 对所有来自不可信数据源的数据进行校验， 拒绝任何没有通过校验的数据
• 通过集中的输入校验程序， 对输入进行校验
• 禁止将HTTP头中的未加密信息作为安全决策依据
• 不能依赖于客户端校验， 必须使用服务端代码对输入数据进行最终校验
• 处理web的请求/响应的编码方式必须统一
• 对于具有相同含义却存在多种描述方式的外部输入数据， 必须先进行标准化再进行校验
• 校验输入数据的类型或格式
• 校验输入数据的长度
• 校验输入数据的范围
• 确保输入数据只包含允许的字符集， 不包含不合法和危险的字符， 尽可能采取”白名单“方式进行输入检验

Web Storage

1. 禁止在LocalStorage和SessionStorage中存储敏感数据

说明： LocalStorage和SessionStorage本身无防XSS的机制， 数据容易被窃取， 即使对敏感数据加密， 一旦密钥泄露， 也将导致敏感数据泄露。 客户端上有本地访问权限的操作系统用户或程序都能访问LocalStorage， 容易泄露。

2. 如果数据权需要临时存储在客户端， 使用会话cookie或者SessionStorage而不是LocalStorage。

说明： LocalStorage是持久性的（没有时间限制）的数据存储。 数据永远不会过期， 除非主动删除数据。 不应该用于存储临时数据， 否则会导致数据长期存储， 增加数据泄漏的风险。 同时， 浪费客户端的磁盘空间， 而存储于会话cookie或SessionStorage中的数据会被及时清除。

3. 如果在同一个origin上部署多个应用， 则禁止应用使用LocalStorage对象存储数据。

说明： 不像cookie的path属性可以限制只能被特定的路径访问， LocalStorage对象会被同源的所有应用访问（读、写、删除）。 应避免同一个源上部署多个应用（使用不同的子域代替）。 否则， 就禁止应用使用LocalStorage对象存储数据。

Web SQL DataBase和Indexed DataBase

1. 访问Web SQL DataBase数据库时， 使用参数绑定SQL语句（防止SQL注入）。
2. 禁止在Web SQL DataBase和Indexed DataBase数据库中存储敏感数据。

说明： Web SQL DataBase和Indexed DataBase存储的数据是明文的， 客户端上有本地访问权限的操作系统用户都能访问， 容易泄露。 而且， 利用XSS漏洞， 攻击者可以构造脚本对Web SQL DataBase和Indexed DataBase数据库进行操纵， 数据容易被窃取， 即使对敏感数据加密， 一旦密钥泄露， 也将导致敏感数据泄露。 因此， 禁止在Web SQL DataBase和Indexed DataBase数据库中存储敏感数据。