Awesome Application Security Checklist

很棒的应用 - 安全检查清单

如果您要牢记使用安全性设计，创建，测试您的Web/移动应用程序，则此反测量清单可能是一个很好的起点

身份验证系统（注册/签名/2因子/密码重置）

• 到处使用HTTP。
• 使用Bcrypt存储密码哈希（无需盐 - Bcrypt为您提供）。
• logout后破坏会话标识符。
• 在重置密码上销毁所有主动会议（或提供）。
• 必须在OAuth2中具有state参数。
• 成功登录后或任何其他中间重定向后，没有开放的重定向。
• 解析注册/登录输入时，为JavaScript：// andialsize data：//，crlf字符。
• 设置安全的，httponly cookie。
• 在基于移动OTP移动验证中，当generate OTP或Resend OTP API时，请勿将OTP发送回响应中。
• 限制尝试Login ， Verify OTP ， Resend OTP并为特定用户generate OTP API。有一个指数的向后集或/和/和/和类似基于验证码的挑战。
• 在电子邮件或SMS中检查重置密码令牌的随机性。
• 在合理的期间设置重置密码令牌的到期。
• 成功使用重置令牌后到期。

用户数据和授权

• 任何资源访问，例如my cart ， my history都应使用会话ID检查用户对资源的所有权。
• 应避免串行峰值资源ID。使用/me/orders代替/user/37153/orders 。如果您忘了检查授权令牌，这是一种理智检查。
• Edit email/phone number功能应随附给帐户所有者的验证电子邮件。
• 任何上传功能都应消毒用户提供的文件名。另外，由于通常原因，除了安全性外，还将上传到S3（以及使用Lambda的后处理），而不是您自己的服务器能够执行代码。
• Profile photo upload功能也应消毒所有EXIF标签（如果不需要）。
• 对于用户ID和其他ID，请使用符合RFC的UUID而不是整数。您可以在GitHub上找到用于您的语言的实现。
• JWT很棒。如果需要，请使用单页应用程序/API。

数据库

• 使用加密来识别用户和敏感数据，例如访问令牌，电子邮件地址或计费详细信息。
• 如果您的数据库支持REST（例如AWS Aurora）的低成本加密，则可以使其在磁盘上保护数据。确保所有备份也被存储了加密。
• 为数据库访问用户帐户使用最小特权。不要使用数据库根帐户。
• 使用为该目的设计的密钥商店存储和分发秘密。不要在您的应用程序中硬代码。
• 仅通过使用SQL准备的语句完全防止SQL注入。例如：如果使用NPM，请勿使用NPM-MYSQL，请使用支持准备的语句的NPM-MYSQL2。

Android / iOS应用程序

• 付款网关中的salt不应进行硬编码。
• 第三方SDK的secret / auth token不应进行硬编码。
• 旨在完成server to server API调用不应从应用程序中完成。
• 在Android中，应仔细评估所有授予的权限。
• 在iOS上，在系统键链中存储敏感信息（身份验证令牌，API密钥等）。请勿将此信息存储在用户默认值中。
• 强烈建议固定证书。

安全标头和配置

• Add CSP标头以减轻XSS和数据注入攻击。这很重要。
• Add CSRF标头以防止跨站点请求伪造。还要在cookie上添加samesite属性。
• Add HST标题以防止SSL剥离攻击。
• 将您的域Add到HSTS预加载列表
• Add X框架选项以防止点击夹克。
• Add X-XSS保护标头以减轻XSS攻击。
• 更新DNS记录以添加SPF记录以减轻垃圾邮件和网络钓鱼攻击。
• 添加子资源完整性检查是否从第三方CDN加载JavaScript库。为了获得额外的安全性，请添加要求SRI-FOR CSP指导性，以免加载没有SRI SAT的资源。
• 使用随机的CSRF代币并将业务逻辑API作为HTTP POST请求。例如，在初始请求升级阶段中，请勿通过HTTP公开CSRF令牌。
• 请勿在获取请求参数中使用关键数据或令牌。服务器日志的暴露或计算机/堆栈处理它们会依次曝光用户数据。

输入的消毒

• Sanitize所有用户输入或暴露于用户的任何输入参数以防止XSS。
• 始终使用参数化查询来防止SQL注入。
• 如果直接将其用于CSV导入等功能，则对用户输入进行消毒。
• 为特殊情况（例如robots.txt）作为配置文件的用户输入Sanitize以防您使用coolcorp.io/username之类的URL模式。
• 无论对象有多小，都不要通过字符串串联来手动代码或构建JSON。使用您的语言定义的库或框架。
• 消毒输入，这些输入需要某种URL来防止SSRF。
• 在向用户显示之前对输出进行消毒。

拒绝服务保护

• 确保对API的DOS攻击不会削弱您的网站。至少在较慢的API路径（例如登录和令牌生成程序）上具有速率限制。考虑前端API上的CAPTCHA，以保护后端服务免受DOS的影响。
• 对用户提交的数据和请求的大小和结构进行理智限制。
• 使用分布式拒绝服务（DDOS）缓解通过CloudFlare等全球缓存代理服务。如果您遭受DDOS攻击并作为DNS查找功能，则可以打开此功能。

运营

• 如果您很小且经验不足，请使用AWS ElasticBeanstalk或PAAS来评估您的代码。
• 使用一个体面的配置脚本在云中创建VM。
• 检查有不必要的公开open ports的机器。
• 检查databases中的不/默认密码，尤其是MongoDB和Redis。
• 使用SSH访问您的机器；不要设置密码，而是使用基于SSH的基于SSH的身份验证。
• 及时安装更新以对零日漏洞（如Heartbleed，Shellshock）采取行动。
• 修改服务器配置以将TLS 1.2用于HTTPS并禁用所有其他方案。 （权衡很好。）
• 请勿继续调试模式。在某些框架中，调试模式可以提供访问成熟的补充或外壳，或在错误消息stackTraces中揭示关键数据。
• 为不良演员和DDOS做好准备 - 使用具有DDOS减轻的托管服务。
• 为您的系统设置监视，并记录物品（使用新的遗物或类似的东西）。
• 如果为企业客户开发，请遵守合规要求。如果AWS S3，请考虑使用该功能加密数据。如果使用AWS EC2，请考虑使用该功能使用加密量（现在也可以加密启动量）。

云配置

• 确保所有服务都有最低端口。尽管通过晦涩难懂的安全性没有保护，但使用非标准端口将使攻击者更难。
• 在任何公共网络上都不可见的私人VPC上的主机后端数据库和服务。配置AWS安全组和凝视VPC时，请非常小心，这些VPC可以无意间使公众可见。
• 在单独的VPC和PEER VPC中隔离逻辑服务，以提供服务间通信。
• 确保所有服务仅接受最小的IP地址集中的数据。
• 限制即将发出的IP和端口流量，以最大程度地减少APT和“腐烂”。
• 始终使用AWS IAM角色而不是根凭证。
• 为所有OP和开发人员使用最小的访问权限。
• 根据时间表定期旋转密码并访问键。

CI和CD通过单位/集成测试覆盖范围审核您的设计和实施。使用代码审核过程并无视自我批准。确保您的服务的所有组件在推入生产之前，都由AV软件静态扫描，包括供应商库和其他依赖关系。设计用于部署的回滚解决方案。

人们

• 设置电子邮件（例如[email protected]）和一个页面供安全研究人员报告漏洞。
• 根据您的制作，请限制对用户数据库的访问。
• 对错误记者有礼貌。
• 从安全的编码角度来完成您的代码审查。 （更多眼睛）
• 如果发生黑客攻击或数据泄露，请检查以前的日志以获取数据访问，请人们更改密码。您可能需要根据您合并的位置进行外部机构进行审核。

基础设施

• 确保您可以在不停机的情况下进行升级。确保您可以以完全自动化的方式快速更新软件。
• 使用Terraform等工具而不是通过云控制台创建所有基础架构。基础架构应定义为“代码”，并可以按按钮重新创建。对于云中创建的任何资源的零公差 - Terraform然后可以审核您的配置。
• 将集中列表用于所有服务。您永远不应需要SSH来访问或检索日志。
• 除了一次性诊断外，不要进入服务。定期使用SSH，通常意味着您没有自动化一项重要的任务。
• 不要永久对任何AWS服务组的端口22打开。而是考虑仅允许授权的IPS在框中进行SSH。
• 创建不变的主机，而不是您修补和升级的长寿命服务器。 （请参阅不变的基础架构更安全）。
• 使用Sensedeep或服务等入侵检测系统来最大程度地减少APT。