10.7~8

ch10.md

@@ -362,3 +362,59 @@ OWASP Top 10 的第六名是敏感数据泄露，它发生在应该保护的数
 如果我们在 Apache 服务器的文档根目录（`/var/ www/html/`）储存敏感文档或数据，我们就通过 URL 将这些信息暴露用于下载。所以，最好将它储存到别的地方，并编写特殊的服务端代码来在必要时获取它们，并带有预先的授权检查。
 
 此外，例如 Archive.org、WayBackMachine 或者 Google 缓存页面，可能在缓存含有敏感信息的文件时，以及我们没能在应用的上一个版本有效保护它们时产生安全问题。所以，不允许缓存此类文档非常重要。
+
+## A7 确保功能级别的访问控制
+
+功能级别的访问控制是访问控制的一种，防止匿名者或未授权用户的功能调用。根据 OWASP，缺乏这种控制是 Web 应用中第七大严重的安全问题。
+
+这个秘籍中，我们会看到一些推荐来提升我们的应用在功能级别上的访问控制。
+
+### 操作步骤
+
+1.  确保每一步都正确检查了工作流的权限。
+
+2.  禁止所有默认访问，之后在显示的授权校验之后允许访问。
+
+3.  用户、角色和授权应该在灵活的媒介中储存，例如数据库或者配置文件，不要硬编码它们。
+
+4.  同样，“隐藏式安全”不是很好的策略。
+
+### 工作原理
+
+开发者只在工作流的开始检查授权，并假设下面的步骤都已经对用户授权，这是常见的现象。攻击者可能会尝试调用某个功能，它是工作流的中间步骤，并由于控制缺失而能够访问它。
+
+对于权限，默认禁止所有用户是个最佳时间。如果我们不知道一些用户是否有权访问一些功能，那么它们就不应该执行。将你的权限表转化为授权表。如果某些用户在某些功能上没有显示的授权，则禁止它们的访问。
+
+在为你的应用功能构建或实现访问控制机制的时候，将所有授权储存在数据库中，或者在配置文件中（数据库是最好的选项）。如果用户角色和权限被硬编码，它们就会难以维护、修改或更新。
+
+## A8 防止 CSRF
+
+当 Web 应用没有使用会话层面或者操作层面的标识，如果标识没有正确实现，它们就可能存在跨站请求伪造漏洞，并且攻击者可以强迫授权用户执行非预期的操作。
+
+CSRF 是当今 Web 应用的第八大严重漏洞，根据 OWASP， 并且我们在这个秘籍中会看到如何在应用防止它。
+
+### 操作步骤
+
+1.  第一步也是最实际的 CSRF 解决方案就是实现唯一、操作层面的标识。所以每次用户尝试执行某个操作的时候，会生成新的标识并在服务端校验。
+
+2.  唯一标识应该不能被轻易由攻击者猜测，所以它们不能将其包含在 CSRF 页面中。随机生成是个好的选择。
+
+3.  在每个可能为 CSRF 目标的表单中包含要发送的标识。“添加到购物车”请求、密码修改表单、邮件、联系方式或收货信息管理，以及银行的转账页面都是很好的例子。
+
+4.  标识应该在每次请求中发送给服务器。这可以在 URL 中实现，或者任何其它变量或者隐藏字段，都是推荐的。
+
+5.  验证码的使用也可以防止 CSRF。
+
+6.  同样，在一些关键操作中询问重新授权也是个最佳实践，例如，银行应用中的转账操作。
+
+### 工作原理
+
+防止 CSRF 完全是确保验证过的用户是请求操作的人。由于浏览器和 Web 应用的工作方式，最佳实践是使用标志来验证操作，或者可能的情况下使用验证码来控制。
+
+由于攻击者打算尝试破解标识的生成，或者验证系统，以一种攻击者不能猜测的方式，安全地生成它们非常重要。而且要使它们对每个用户和每个操作都唯一，因为复用它们会偏离它们的目的。
+
+验证码控制和重新授权有时候会非常麻烦，使用户反感。但是如果操作的严重性值得这么做，用户可能愿意接受它们来换取额外的安全级别。
+
+### 另见
+
+有一些编程库有助于实现 CSRF 防护，节省开发者的大量工作。例子之一就是 OWASP 的 CSRF Guard：`https://www.owasp.org/index.php/CSRFGuard`。