{card-list-item}
输入验证
{/card-list-item}
{card-list-item}
1、在处理以前，验证所有来自客户端的数据，包括：所有参数、URL、HTTP头信息（比如：cookie名字和数据值），确定包括了来自 JavaScript、Flash 或其他嵌入代码的post 返回信息
2、如果任何潜在的危险字符必须被作为输入，请确保您执行了额外的安全控制，比如：输入转义、输出编码、特定的安全 API等。部分常见的危险字符，包含但不限于： < > " ' % ( ) & + \ \' \"
3、如果您使用的标准验证规则无法验证下面的输入，那么它们需要被单独验证，比如验证空字节 (%00)； 验证换行符 (%0d, %0a, \r, \n)； 验证路径替代字符“点-点-斜杠”（../或 ..\）；如果支持 UTF-8 扩展字符集编码，验证替代字符： %c0%ae%c0%ae/ (使用规范化验证双编码或其他类型的编码)
4、严格验证来自重定向输入的数据（一个攻击者可能向重定向的目标直接提交恶意代码，从而避开应用程序逻辑以及在重定向前执行的任何验证）
{/card-list-item}
{card-list-item}
异常处理
{/card-list-item}
{card-list-item}
1、禁止在异常中泄露敏感信息（敏感数据的范围应该基于应用场景以及产品威胁分析的结果来确定。典型的敏感数据包括口令、银行账号、个人信息、通讯记录、密钥等）
2、禁止在异常中泄露应用服务器的指纹信息（如版本，路径，架构）
3、方法发生异常时要恢复到之前的对象状态（业务操作失败时，进行回滚业务；或者避免去修改对象状态，维持对象状态一致性）
{/card-list-item}
{card-list-item}
身份验证
{/card-list-item}
{card-list-item}
1、除了那些特定设为“公开”的内容以外，对所有的网页和资源都要求进行身份验证，并正确设计身份验证功能
2、所有的身份验证过程必须在服务器后端上执行
3、在任何可能的情况下，建立并使用标准的、已通过安全测试的身份验证服务(比如 C4A)
4、所有的身份验证控制应当安全的处理未成功的身份验证，比如给出错误模糊提示，隐藏敏感信息
5、登录入口应具有防止暴力猜解及撞库猜解（利用已泄漏的密码字典进行批量登录尝试）的措施，超过设定失败次数需要启用锁定或图片随机码进行访问限制
6、采用https post请求方式传输身份验证的凭据信息
7、身份验证的失败提示信息采用模糊处理，比如可以使用“用户名或密码错误”，而不要使用“用户名错误”或者“密码错误”明确提示。
8、涉及敏感信息或功能的外部系统连接应配置身份验证功能，并进行有效身份验证控制
9、在执行关键操作（如个人信息密码修改操作）时，应对用户身份进行再次验证
10、为高度敏感或重要的交易账户使用多因子身份验证机制，如支付密码、短信验证码等
{/card-list-item}
{card-list-item}
短信验证码
{/card-list-item}
{card-list-item}
1、一次一用
2、发送频率控制（建议60s获取一次）
3、验证码有效期（建议60s内有效，发短信时进行友好提示）
4、复杂度（短信验证码建议6位数字）
5、安全提示：是否是个人自己操作等风险提示信息
6、在前端校验（客户端的校验只能作为辅助手段，很容易被绕过），必须使用服务端代码对输入数据进行最终校验
{/card-list-item}
{card-list-item}
图形验证码
{/card-list-item}
{card-list-item}
1、一次一用
2、验证码有效期(10分钟内有效，可根据场景兼容安全和体验灵活设置)
3、复杂度（4位及以上数字、字母交替），根据需要也可采用当下流行的拖拽验证码或计算值的验证方式
4、服务器端进行认证
5、从用户体验和安全角度出发，可设计为当用户输3次错误密码后自动弹出验证码输入框进行验证操作
{/card-list-item}
{card-list-item}
密码管理
{/card-list-item}
{card-list-item}
1、禁止使用私有或者弱加密算法（比如禁止使用DES，SHA1等，推荐使用AES: 128位，RSA: 2048位，DSA: 2048位）
2、采用基于哈希算法和加入盐值（salt）方式安全存储口令信息
3、密码输入框，可设计为显示密码和隐藏密码切换功能
4、密码重设和更改操作，需要进行二次合法身份验证
5、密码重设时，应对注册手机号和邮箱进行有效验证，链接只能发送到预先注册的邮件地址或预先绑定的手机号
6、临时密码和链接应设计一个短暂的有效期（比如5分钟），防止暴力破解
7、当密码重新设置时，应短信通知用户是否是本人在操作，告知安全风险
8、密码复杂度设置：建议8个字符以上，包含字母、数字及特殊字符等
9、密码设置场景中应具有密码复杂度检查功能
10、密码不能输出到日志和控制台
11、数据库连接配置中的用户密码要以加密的形式存储
12、建议设计密码定期修改提醒机制
{/card-list-item}
{card-list-item}
访问控制
{/card-list-item}
{card-list-item}
1、将具有特权的逻辑从其他应用程序代码中隔离开
2、限制只有授权的用户才能访问文件资源
3、限制只有授权的用户才能访问受保护的URL
4、限制只有授权的用户才能访问受保护的功能或服务
5、建议只有授权的用户才能访问直接对象引用
6、限制只有授权的用户才能访问受保护的应用程序数据
7、限制只有授权的用户才能访问与安全相关的配置信息
8、限制只有授权的外部应用程序或接口才能访问受保护的本地程序或资源
9、服务器端执行的访问控制规则和前端实施的访问控制规则必须匹配
10、服务器中创建文件时需指定合理的访问权限（读/写/可执行）
11、当权限重新设置发生变更时，应记录好日志，并短信通知用户是否是本人在操作，告知可能存在的安全风险
{/card-list-item}
{card-list-item}
敏感信息
{/card-list-item}
{card-list-item}
1、临时产生的敏感数据（写入内存或文件），应具有及时清除和释放机制
2、不要在 HTTP GET 请求参数中包含敏感信息，如用户名、密码、卡号、ID等
3、禁止表单中的自动填充功能，因为表单中可能包含敏感信息，包括身份验证信息
4、不要在客户端上以明文形式保存密码或其他敏感信息
5、为所有敏感信息采用SSL加密传输
6、禁止将敏感信息（包含加密秘钥等）硬编码在程序中
7、禁止明文存储用户的密码、身份证号、银行卡号、持卡人姓名等敏感信息
8、不要在日志中保存敏感信息，包含但不限于系统详细信息、会话标识符、密码等
9、禁止在异常中泄露应用服务器的指纹信息，如版本，路径，组件版本等
10、禁止将源码或sql上传到开源平台或社区，如github、开源中国等
11、请求中含有敏感参数（如订单号、ID等），应进行混淆方式处理，防止产生参数遍历获取信息风险
12、敏感信息需要展示在web页面上时，应在后台进行敏感字段脱敏处理
13、请求返回数据不应包含请求之外的业务数据，特别是敏感信息数据
{/card-list-item}
{card-list-item}
密码找回安全
{/card-list-item}
{card-list-item}
1、服务器端要做认证，避免绕过前端控制
2、增加二次认证因子，如验证码
3、涉及登录验证token之类的，不要直接将验证内容直接返回给用户
4、认证凭证加密，推荐强算法（推荐使用AES: 128位，RSA: 2048位，DSA: 2048位）
5、认证凭证中的参数应进行混淆处理
6、在多个验证操作中，要对各验证机制进行排序，以防出现跳过前面验证机制直接到最后一步认证的安全风险
7、手机短信码验证，需同时校验手机号和短信是否对应
8、输入框中，应校验输入数据合法性，防止产生XSS跨站脚本攻击
{/card-list-item}
{card-list-item}
SQL注入
{/card-list-item}
{card-list-item}
1、永远不要信任用户的输入，要对用户的所有输入进行校验，包含SQL语句的过滤和转义
2、永远不要使用动态拼装SQL，可以使用参数化的SQL或者使用存储过程进行数据查询存取
3、永远不要使用管理员权限进行数据库连接，为每个应用使用单独的非特权权限，且配置有限的数据库连接数
4、不要把敏感信息明文存放，采用加密或者哈希、混淆等方式对敏感信息进行脱敏存储
5、应用的异常信息应不带有敏感信息，给出尽可能少的提示；建议使用自定义的错误信息对原始错误信息进行包装，可把异常信息存放在独立的数据库表中
{/card-list-item}
{card-list-item}
XML注入
{/card-list-item}
{card-list-item}
1、不要使用字符串/StringBuffer/StringBuilder/StringFormat组装XML
2、建议对XML元素属性或者内容进行转义
{/card-list-item}
{card-list-item}
XSS跨站脚本攻击
{/card-list-item}
{card-list-item}
1、对输入的数据进行过滤和转义，包含但不限于< >" ' % ( ) & + \ \' \"等危险特殊字符
2、数据添加到html元素属性或者内容中时，对数据进行HTML转义
3、数据添加到script脚本中时，对数据进行script转义
4、数据添加到style中时，对数据进行css转义
{/card-list-item}
{card-list-item}
CSRF跨站请求伪造
{/card-list-item}
{card-list-item}
1、建议在每个关键表单中引入了CSRF Token验证(会话中生成的随机串，提交后校验)
2、在关键表单提交时要求用户进行二次身份验证（录入密码、插KEY、输入图片验证码、短信验证码）
3、对请求refer做验证（比如跨域、系统内部应用）
{/card-list-item}
{card-list-item}
文件上传安全
{/card-list-item}
{card-list-item}
1、上传操作应设计身份验证机制，并进行合法身份校验
2、只允许上传满足业务需要的相关文档类型
3、通过检查文件头信息，比如JPEG (jpg)文件头信息（十六进制）：FFD8FF，验证上传文档是否是所期待的类型
4、不要把文件保存在与应用程序相同的 Web 环境中，建议将文件保存在专用的文档服务器中，单独给文档服务器配置域名访问更好
5、限制上传任意可能被 Web 服务器解析的文件 ，比如jsp、php等
6、上传文件以二进制形式下载，建议不提供直接访问（防止木马文件直接执行）
7、禁止授予上传文件存储目录的可执行权限
{/card-list-item}
