声明：本文由Bypass整理并翻译，仅用于安全研究和学习之用。
文章来源：https://medium.com/bugbountywriteup/how-to-write-secure-code-d4823bc2e86d
如何编写安全代码？保护自己免受破碎的身份验证和会话管理！
需要安全代码？
我一直致力于安全编码实践，并试图尽可能多地学习基本要点。在过去的几年里，我已经意识到一个小小的漏洞在普通人的生活中可能造成的伤害。像WannaCry和Petya勒索软件这样的网络攻击在几个遭受其原因的人心目中是相当新鲜的。
研究人员仍然可以在网络应用程序和其他领域中发现另一个非常严重的错误。除非程序员自己意识到他们正在编写的代码，否则这种趋势不会下降。代码不仅应该能够执行它应该执行的预期工作，而且还能够抵御任何恶意负载和攻击场景。实现这一目标的最佳方式是能够在编码和安全社区之间建立协同作用，并相互帮助。
我们来挖掘吧！
那么，这篇特别的文章“如何编写安全代码？”专注于身份验证和会话管理问题。
身份验证和会话管理相关的应用程序功能存在安全缺陷，允许攻击者破坏密码，密钥，会话令牌或利用其他实现缺陷来承担其他用户的身份。
在本文中，我将介绍几种不同类型的攻击和方法，您可以使用它们来防止它们： -
1.硬编码登录凭据
硬编码登录凭据是程序员可以犯的最大错误之一，因为它与在银盘上为黑客提供凭证一样好。敏感数据永远不应该是硬编码的。
不安全的代码 - 硬编码的信用卡
上面的代码是其中一个示例，其中登录凭证在程序员编写的代码中进行了硬编码。
虽然下面的代码是一个示例，其中凭证在程序中没有硬编码，使得它比信用卡硬编码的指数更加安全。
安全代码 - 信用证不是硬编码的
这种小差异会对应用程序的安全性产生巨大影响。
2. Cookie操作
随着越来越多的身份验证过程通过检查用户提供的cookie细节来执行，Cookie操作正在成为当今最危险的攻击之一。
攻击者正在寻找方法来打破并弄清楚网络应用程序如何分配cookie，以便他们可以操纵它们并像其他用户进行帐户接管一样构成。
让我演示攻击者如何利用分配给用户的弱cookie或者cookie保持不变。
这边的图像是一个登录门户，我们将进行攻击并显示弱cookie实现的问题。
一旦我们登录到应用程序，我们就会拦截Burp-Suite中的流量，以查看它以及传递给用户身份验证我们的cookie。
Cookie细节
上图显示了我们尝试登录时分配的四个“Set-Cookie”参数。这四个不同的cookie登录，PHPSESSID，显示提示，用户名和uid。我们怀疑uid对每个用户都是唯一的。所以我们继续篡改uid以检查我们是否可以访问其他人的帐户。
修改cookie
要捕获cookie的值，我们使用浏览器中存在的Cookie Manager扩展，然后传递请求。我们将“uid”从24改为12，如下所示。
修改过的cookie
一旦我们修改了cookie值，我们就可以看到，当我们访问其他用户的帐户时，我们已经执行了帐户接管攻击。
这次攻击经历的原因是，在用户登录之前和之后，PHPSESSID根本没有被修改，因此“uid”是识别哪个用户刚刚登录到他们帐户的唯一决定因素。正如我们上面所看到的那样，很容易被操纵，允许帐户接管。
为了避免这种情况发生，我们需要在登录尝试后重新分配cookie，我们需要记住，cookie也必须是唯一的。以下是如何执行以下操作的想法。
//问题是正在使用相同的会话对象，因此获取当前会话 HttpSession before_login = request.getSession（）; //使该会话无效 before_login.invalidate（）; //生成一个新会话，新的JSESSIONID HttpSession after_login = request .getSession（true）;
上面的代码用于在登录前后更改SESSIONID cookie。
3.通过Web服务进行用户枚举
枚举问题非常严重，因为它可以让攻击者弄清楚应用程序中存在的用户的用户名/电子邮件ID，以下细节可以在以后用于暴力攻击。
我们使用Widsler扩展并利用它的“getuser”功能对Burp-Suite进行此攻击。因此，当我们输入有效的用户名时，我们尝试从系统收集响应，然后我们输入一个不是用户名的随机字符串，然后检查响应。我们可以在下面的图像中看到相应的响应。
用户不存在
上面的图像是我们在具有特定用户名的用户不存在时收到的请求和响应。我们在转发器中发送了请求查询以检查响应。
用户确实存在
上面的图像是我们收到的用户确实存在的条件的请求和响应。我们在转发器中发送了请求查询以检查响应，并在此次获得了不同的响应。这给了我们一个想法，我们可以根据我们收到的响应来枚举用户。
因此，我们在入侵者选项卡中传递请求，然后执行蛮力来检查使用该应用程序的各个用户。
枚举的用户名
这里的主要问题是开发人员实际上在响应查询中放了太多细节。正如在这次攻击中我们可以清楚地看到，由于响应中的信息太多，我们可以弄清楚哪些用户具有相应的用户名，哪些用户没有。我们需要制作一些标准化的消息，以便攻击者不能仅仅使用一些简单的枚举技术。
4.暴力攻击
这是攻击者通过前一种方法枚举用户及其用户名后执行的下一阶段攻击。
旁边的图像显示我们已经枚举用户的登录页面，需要执行暴力攻击才能知道这些用户的登录凭据。
因此，当我们尝试登录时，我们拦截Burp-Suite中的流量并捕获请求数据包并将其发送给入侵者。
请求查询
现在，我们已经枚举了用户名，我们执行命中和尝试，暴力攻击。我们从互联网上获取一组常用密码并运行我们的攻击以找出相应的密码。
通过Burp-Suite进行蛮力攻击
在任何情况下都绝不允许暴力进攻。应始终存在帐户锁定功能，因为它可以使应用程序免于暴力破解并喷出用户凭据。蛮力也可以通过允许用户不使用字典单词，使用一定长度的密码更好地要求他们使用密码来抵消。在存储之前，应始终对用户的密码进行哈希处理，使用带哈希值的盐也非常重要。
安全防御
我们可以采取以下预防措施，并在尝试与身份验证和会话管理问题作斗争时保留这些心理记录。
认证失败
- 提示错误/成功消息
- 永远不要硬编码凭证
- 密码策略执行（成熟，强度，盐的哈希）
会话管理
- 令牌的不可预测性（即安全随机性）
- 到期策略，登录/注销重置
- 使用强加密
- 复杂的Cookie安全性