安全编码实践之三：身份验证和会话管理防护

声明：本文由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安全性