转载 | 身份管理的15个安全开发实践

本文主要是介绍转载 | 身份管理的15个安全开发实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

应用或服务的安全编码很重要，但若事关处理个人数据的系统，那就不仅仅是重要，而是至关重要了。

软件分析公司CAST分析了1380个软件应用，在代码中发现了惊人的130万个漏洞。

有点网络安全常识的人都知道，软件漏洞就是向网络罪犯敞开的大门。

身份管理可以说是所有技术门类中风险最大的服务。身份盗窃事件常伴我们左右。咨询公司 Javelin Research 从事身份盗窃事件研究多年，其《2018身份欺诈》报告将2017年身份盗窃统计数据描述为“历史新高”，揭示身份盗窃继续困扰着这个行业。

身份管理中我们常会谈及所谓“武器化身份”的概念，也就是强化系统中的接入点和用户与服务交互的位置。然而，武器化过程需分层实施，而其中一层就是代码层。

身份管理安全编码

数字身份平台可能会非常复杂，因为这些平台往往得依赖外部数据源，并与第三方API集成。消费级身份与访问管理(IAM)甚至更为复杂。这类平台需要扩展功能来上传、存储和共享文档与图片。很多身份服务还融入移动设备App，或者说完全基于移动App。依靠身份生态系统各组件间通信所用协议的固有安全是不够的。此类生态系统的底层代码必须尽可能安全，同时又不能对其功能造成影响。

开发身份平台时可以采用如下几种最佳安全编码实践：

1. 使用良好资源

从安全编码入门经典资源开始。开放网络应用安全计划(OWASP)是安全编码实际上的入门资源。其安全编码“快速参考指南”是个极好的起始点，可作为开发过程中的复核工具使用。放心充分利用他们的资源。

2. 采用防御性编程技巧

这么做可以一定程度上避免出现可利用漏洞。其中一招是等价比较：把常量放到比较语句的前端。常量前置的话，如果不小心把比较操作符(两个等号“==”)误敲成赋值操作符(一个等号“=”)，在编译或运行时阶段就会报错。举个例子：

不良编码习惯：变量在前

if ($result == ‘SUCCESS’) {

更好些的编码习惯：常量在前——如果 “==” 误敲成 “=” 会导致运行时错误或编译错误

if (‘SUCCESS’ == $result) {

3. 清洗数据

数字身份，尤其是消费级数字身份系统，往往会调用外部数据源。来自外部源或由用户提供的所有数据都应该被当成不可信的。对Web客户端来说，这些数据包括从查询字符串或散列参数、cookie、本地存储等等获取的数据；对服务器端应用来说，这些数据包含通过POST、GET、cookie等等提交的数据。原生应用常会读取配置文件，而这些配置文件有可能被故意篡改。

无论如何，第一道防线都是数据清洗：确保数据中仅含有经允许的字符/格式。其中一个重点是检查最大数据域长度，避免缓冲区溢出攻击。

数字身份平台安全检查的另一个重要领域是图片上传。随着证件照片的存储和共享越来越广泛，IAM和CIAM服务也变得越来越重要。用户上传照片之类的文件上传行为可能会特别危险，必须严格检查以确保文件真的只是单纯的图片而没有隐藏的可执行内容。

4. 筛查

文档和其他文件存储是数字身份生态系统的重要部分。放到存储中的所有数据都必须经过可执行内容筛查。筛查过程无关底层数据库技术。比如说，虽然非SQL数据库对SQL注入攻击免疫，但仍有自身弱点，仍然要经过筛查。

5. 过滤

类似的，不应直接接受外部命令字符串。应设置过滤器，总是检查命令是否有效且适用于相应上下文。

6. 防止未经验证的代码执行

避免使用eval()类函数，因为此类函数允许未经验证的代码执行。内嵌eval()函数的函数也不应采用，比如JavaScript的SetTimer()。

7. 弹性为王

开发面向消费者的数字身份服务往往意味着需要覆盖大量用户。你得允许各种各样的值。应用开发编程的时候要考虑弹性，这样才能在外部数据值超出预期范围或类型时不会发生故障或允许代码注入。良好的单元测试或功能测试通常能检测出此类问题。

8. 谨慎使用开源代码

产品中引入最新版开源代码有可能同时引入了恶意软件。使用开源代码包时，最好在包管理器中设置特定版本号，以免误用未经验证的版本。编译过程应包含对所有外部文件的散列检查。

9. 错误响应

错误响应是数字身份服务的关键部分，因为可以告知用户问题点并改善可用性。然而，这一功能也可能被恶意黑客用于摸清系统行为。要确保错误响应动作不会向攻击者泄露信息。客户端-服务器错误响应应仅包含知会用户的最少信息，而不是协助攻击者窥探应用。

10. 审计日志

如果攻击确实发生了，你会想要知道到底结果如何以及确保攻击事件可以复现。但日志记录需有效，用无意义的审计数据填充日志可能会适得其反。

11. 数字签名

尽可能采用数字签名来验证数据完整性。散列消息验证码(HMAC)是经济实惠且有效的验证方式。类似的，如果数据十分敏感，比如包含PII，那么需要确保数据存储和传输过程中加密。通过公共或私人网络传送任何东西都应使用TLS。

12. 使用令牌进行安全通信

进程间通信可以考虑使用令牌而不是口令进行身份验证。

13. 移动应用

移动设备应用越来越多地被用于数字身份证明和交易。最好假定设备是可以被越狱的。仔细检查你处理的数据并评估所涉风险。在可能的情况下引入越狱检测代码。

14. 漏洞检查

每次新升级完成都要做漏洞检查。有很多专业公司提供这项服务。CheckMarx或CAST之类的公司提供独立源代码分析器服务。此类解决方案是安全编码实践的重要组成部分，尽管它们不应被当做人工代码检查的替代品，而应作为附加检查完成。

15. 最重要的

紧跟最新漏洞。严重漏洞总会出现在 CVE Details 上。必须注意到新威胁并采取行动，确保自己的代码中不存在这些漏洞。

应用或服务的安全编码很重要，但若事关处理个人数据的系统，那就不仅仅是重要，而是至关重要了。如果你设计或开发数字身份系统，安全和可用性总会成为难以平衡的两难选择。但良好的安全编码习惯可助你在管理网络攻击威胁的同时确保消费者身份系统的复杂功能不受影响。

CAST软件应用分析报告：

https://www.castsoftware.com/news-events/press-release/press-releases/download/cast-research-on-the-state-of-software-security-reveals-riskiest-applications

Javelin《2018身份欺诈》报告：

https://www.javelinstrategy.com/coverage-area/2018-identity-fraud-fraud-enters-new-era-complexity

OWASP《安全编码实践快速参考指南》：

https://www.owasp.org/index.php/OWASPSecureCodingPractices-QuickReference_Guide

CVE Details：

https://www.cvedetails.com/browse-by-date.php

什么是 Authing？

Authing 提供专业的身份认证和授权服务。
我们为开发者和企业提供用以保证应用程序安全所需的认证模块，这让开发人员无需成为安全专家。
你可以将任意平台的应用接入到 Authing（无论是新开发的应用还是老应用都可以），同时你还可以自定义应用程序的登录方式（如：邮箱/密码、短信/验证码、扫码登录等）。
你可以根据你使用的技术，来选择我们的 SDK 或调用相关 API 来接入你的应用。当用户发起授权请求时，Authing 会帮助你认证他们的身份和返回必要的用户信息到你的应用中。