安全的Web编程 - 验证用户的最佳实践

时间:2014-01-09 03:56:45

标签: security authentication encryption https

进入网络开发,并希望善于建立安全的网站。任何下面的任何一般类型/答案将不胜感激。

因此在身份验证方面得到了一些问题:

  1. 如何在客户端上键入密码并将其发送到服务器 - 假设https已在使用中?我听说有人建议只为安全发送哈希值,例如。应该加密客户端 - 如何?
    1.  
    2. 类似但在服务器端。应该如何保存密码。实际,哈希等?他们应该加密 - 怎么样?
      此外,是否有一种架构可以保护密码,如果一个密码被泄露,不是其他人的密码?例如,如果所有密码都存储在一个文件中,则只访问这一个文件会危及系统上的每个用户。
    3. 如果只需要存储哈希 - 如何处理冲突?
  2. 经过身份验证后,您是否应该依赖会话ID来维护整个身份验证状态?我已阅读有关减少会话劫持的提示,因此想知道这是否是一个好主意/首先是保持用户身份验证的唯一想法。
  3. 有没有一种安全的方法来提供autoLogIn功能,以便浏览器记住密码 - 类似于社交网络/网络电子邮件客户端?
  4. ------------- 额外预防攻击  
    1. 是否有任何工具,甚至只是一些必须应用于提供的用户名/密码条目以防止注入或任何其他类型攻击的常见做法?
    2. 如果我使用Java开发环境(使用PlayFrameWork btw),一般来说攻击者可能在任何表单条目中包含任何类型的有害代码片段的可能性有多大?
    3.  

    PS 如上所述,我可能会使用Java PlayFrameWork对网站进行编码 - 你能否提出我应该考虑的任何内容?
    出于安全考虑,必须遵循的设计模式的任何提示都会有所帮助。

    非常感谢 PPS 您可以建议将工作交给专家,但如果可能的话,我希望自己有一些编码经验。我希望这是一个可行的选择吗? 可能想建立一个电子商务系统FYI。

1 个答案:

答案 0 :(得分:2)

  

假设https已在使用中,如何对客户端上输入的密码进行编码并发送到服务器?我听说有人建议只为安全发送哈希值,例如。它应该加密客户端 - 如何?

不应以可以恢复的方式将其发送到服务器。 SSL / TLS和PKI的问题是{username,password}(或{username,hash(password)})几乎呈现给任何使用证书回答的服务器。该服务器可能好坏。

这里的问题是频道设置与用户身份验证不相交,然后Web开发人员和服务器管理员会做一些愚蠢的事情,例如在basic_auth方案中将纯文本密码放在线路上。

最好将SSL / TLS通道设置与身份验证相集成。那叫做通道绑定。它提供了相互身份验证,并且不会做愚蠢的事情,比如将{username,password}放在线路上,这样就可以轻松恢复。

SSL / TLS提供了近80个密码套件,它们不会在线路上执行愚蠢的{用户名,密码}。它们是预共享密钥(PSK)和安全远程密码(SRP)。即使一个坏人回答(即控制服务器),攻击者也无法学习密码,因为它没有放在线上进行恢复。相反,他将不得不打破AES(PSK)或解决离散日志问题(针对SRP)。

所有这一切都在彼得古特曼的Engineering Security书中详细介绍。

  

类似但在服务器端。应该如何保存密码。实际,哈希等?他们应该加密 - 怎么样?

请参阅约翰史蒂文为OWASP写的Secure Password Storage Cheat SheetSecure Password Storage paper。它将引导您完成整个威胁模型,并解释为什么事情以特定方式完成。

  

一旦经过身份验证,您是否应该依赖会话ID来维护整个身份验证状态?

是的,但授权与身份验证不同。

身份验证是一种“粗粒度”权利。它提出了一个问题,“用户可以使用此应用程序吗?”。授权是一种“细粒度”授权。它回答了一个问题,“用户可以访问此资源吗?”。

  

是否有一种安全的方式来提供autoLogIn功能,以便浏览器记住密码 - 类似于社交网络/网络电子邮件客户端

这取决于您认为安全的内容以及威胁模型中的内容。如果您的威胁模型不包括对用户的计算机或设备具有物理访问权限的攻击者,那么大多数标准都可能“安全”。

如果攻击者可以访问计算机或设备,并且用户没有使用密码或密码保护它,则可能不会将其视为“安全”。

  

是否有任何工具,甚至只是一些必须应用于提供的用户名/密码条目以防止注射或任何其他类型攻击的常见做法?

是的,用户登录遭受注入。因此,您可以在路上执行某些过滤,但必须在输出上执行HTML编码。

它不仅仅是用户名/密码和登录。几乎所有东西都应该有一些输入过滤;并且它必须具有输出编码以防恶意。

你绝对应该花时间在OWASP web site上。如果您有本地章节,您甚至可以考虑参加会议。你会学到很多东西,并会遇到很多很棒的人。

  

如果我使用Java开发环境(使用PlayFrameWork btw),一般来说攻击者可能在任何表单条目中包含任何类型的有害代码片段的可能性有多大?

Java是黑客的喜悦。自Oracle从Sun收购以来,质量和安全性确实下降了。更偏执(安全意识?)的人建议签署任何Java代码,因为沙箱是如此破碎。这使合法的应用程序保持适当的沙盒。来自http://threatpost.com/javas-losing-security-legacy

  

...   “沙盒对甲骨文来说是一个巨大的问题,”Jongerius告诉Threatpost。   “每个人都在闯入。他们的解决方案是代码签名并退出   沙箱但是,您拥有该机器的完全权限。它   没有意义。“

糟糕的是坏人没有收到备忘录。他们将自己的代码签名为恶意软件,然后突破沙箱。

  

出于安全考虑,必须遵循的设计模式的任何提示都会有所帮助。

您还拥有Web服务器配置,例如HTTPS OnlySecure Cookie,HTTP严格传输安全(HSTS)和内容安全策略(CSP),Suhosin(强化PHP),SSL / TLS算法等等。

它有很多,你需要找到适当的强化指南。