10.2

ch10.md

@@ -96,3 +96,79 @@ https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
 +   http://www.regular-expressions.info 它包含教程和实例来了解如何使用正则表达式。它也有一份实用的参考，关于主流语言和工具的特定实现。
 
 +   http://www.princeton.edu/~mlovett/reference/Regular-Expressions.pdf （Jan Goyvaerts 编写的《Regular Expressions, The Complete Tutorial》）就像它的标题所说，它是个正则表达式的非常完备的脚本，包含许多语言的示例。
+
+## A2 构建合理的身份验证和会话管理
+
+带有缺陷的身份验证和会话管理是当今 Web 应用中的第二大关键的漏洞。
+
+身份验证是用户证明它们是它们所说的人的过程。这通常通过用户名和密码来完成。一些该领域的常见缺陷是宽松的密码策略，以及隐藏式的安全（隐藏资源缺乏身份验证）。
+
+会话管理是登录用户的会话标识符的处理。在 Web 服务器中，这可以通过实现会话 Cookie 和标识来完成。这些标识符可以植入、盗取，或者由攻击者使用社会工程、XSS 或 CSRF 来“劫持”。所以，开发者必须特别注意如何管理这些信息。
+
+这个秘籍中，我们会设计到一些实现用户名/密码身份验证，以及管理登录用户的会话标识符的最佳实践。
+
+### 操作步骤
+
+1.  如果应用中存在只能由授权用户查看的页面、表单或者任何信息片段，确保在展示它们之前存在合理的身份验证。
+
+2.  确保用户名、ID、密码和所有其它身份验证数据是大小写敏感的，并且对每个用户唯一。
+
+3.  建立强密码策略，强迫用户创建至少满足下列条件的密码：
+
+    +   对于 8 个字符，推荐 10 个。
+    +   使用大写和小写字母。
+    +   至少使用一个数字。
+    +   至少使用一个特殊字符（空格、` !`、`&`、`#`、`%`，以及其它）。
+    +   禁止用户名、站点名称、公司名称或者它们的变体（大小写转换、l33t、它们的片段）用于密码。
+    +   禁止使用“常见密码”列表中的密码：https://www.teamsid.com/worst-passwords-2015/ 。
+    +   永远不要显示用户是否存在或者信息格式是否正确的错误信息。对不正确的登录请求、不存在的用户、名称或密码不匹配模式、以及所有可能的登录错误使用相同的泛化信息。这种信息类似于：
+    
+        登录数据不正确。
+        
+        用户名或密码无效。
+        
+        访问禁止。
+        
+4.  密码不能以纯文本格式储存在数据库中。使用强哈希算法，例如 SHA-2、scrypt、或者 bcrypt，它们特别为难以使用 GPU 破解而设计。
+
+5.  在对比用户输入和密码时，计算输入的哈希之后比较哈希之后的字符串。永远不要解密密码来使用纯文本用户输入来比较。
+
+6.  避免基本的 HTML 身份验证。
+
+7.  可能的话，使用多因素验证（MFA），这意味着使用不止一个身份验证因素来登录：
+
+    +   一些你知道的（账户信息或密码）
+    
+    +   一些你拥有的（标识或手机号）
+    
+    +   一些你的特征（生物计量）
+    
+8.  如果可能的话，实现证书、预共享密钥、或其它无需密码的身份校验协议（OAuth2、OpenID、SAML、或者 FIDO）。
+
+9.  对于会话管理，推荐使用语言内建的会话管理系统，Java、ASP.NET和 PHP。它们并不完美，但是能够确保提供设计良好和广泛测试的机制，而且比起开发团队在时间紧迫情况下的自制版本，它们更易于实现。
+
+0.  始终为登录和登录后的页面使用 HTTPS -- 显然，要防止只接受 SSL 和 TLS v1.1 连接。
+
+1.  为了确保 HTTPS 能够生效，可以使用 HSTS。它是由 Web 应用指定的双向选择的特性。通过 Strict-Transport-Security 协议头，它在 `http://`存在于 URL 的情况下会重定向到安全的选项，并防止“无效证书”信息的覆写。例如使用 Burp Suite 的时候会出现的情况。更多信息请见： https://www.owasp.org/index.php/HTTP_Strict_Transport_Security 。
+
+2.  始终设置 HTTPOnly 和安全的 Cookie 属性。
+
+3.  设置最少但实际的会话过期时间。确保正常用户离开之后，攻击者不能复用会话，并且用户能够执行应用打算执行的操作。
+
+### 工作原理
+
+身份校验机制通常在 Web 应用中简化为用户名/密码登录页面。虽然并不是最安全的选择，但它对于用户和开发者最简单，以及当密码被盗取时，最重要的层面就是它们的强度。
+
+我们可以从这本书看到，密码强度由破解难度决定，通过爆破、字典或猜测。这个秘籍的第一个提示是为了使密码更难以通过建立最小长度的混合字符集来破解，难以通过排除更直觉的方案（用户名、常见密码、公司名称）来猜测，并且通过使用强哈希或加密储存，难以在泄露之后破解。
+
+对于会话管理来说，过期时间、唯一性和会话 ID 的强度（已经在语言内建机制中实现），以及 COokie 设置中的安全都是关键的考虑因素。
+
+谈论身份校验安全的最重要的层面是，如果消息可以通过中间人攻击拦截或者服务，没有任何安全配置、控制或强密码是足够安全的。所以，合理配置的加密通信频道的使用，例如 TLS，对保护我们的用户身份数据来说极其重要。
+
+### 另见
+
+OWASP 拥有一些非常好的页面，关于身份校验和会话管理。我们推荐你在构建和配置 Web 应用时阅读并仔细考虑它们。
+
++   https://www.owasp.org/index.php/Authentication_Cheat_Sheet
++   https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
+