web安全 CSRF漏洞
描述：
跨站点伪装请求 (CSRF) 漏洞会在以下情况下发生：
1. Web 应用程序使用会话 cookie。
2. 应用程序未验证请求是否经过用户同意便处理 HTTP 请求。
Nonce 是随消息一起发送的加密随机值，可防止 replay 攻击。如果该请求未包含证明其来源的 nonce，则处理该请求的代码将易受到 CSRF 攻击（除非它并未更改应用程序的状态）。这意味着使用会话 cookie 的 Web 应用程序必须采取特殊的预防措施，确保攻击者无法诱骗用户提交伪请求。假设有一个 Web 应用程序，它允许管理员通过提交此表单来创建新帐户：
攻击者可能会使用以下内容来建立一个网站：
如果 example.com 网站的管理员在网站上具有活动会话时访问了此恶意页面，则她会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。
大多数 Web 浏览器会随每次请求发送一个名为 referer 的 HTTP 头文件。referer 头文件应该包含参考页面的 URL，但攻击者可以伪造，因此无法利用 referer 头文件确定请求的来源。
如果应用程序通过 URL 传递会话标识符（而不是 cookie），则不会出现 CSRF 问题，因为攻击者无法访问会话标识符，也无法在伪请求中包含会话标识符。
解决方案
使用会话 cookie 的应用程序必须在每个表单发布中包含几条信息，以便后端代码可以用来验证请求的来源。其中一种方法是包含随机请求标识符或 nonce，如下所示：
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
body = addToPost(body, request_id);
rb.sendRequest(body, new NewAccountCallback(callback));
这样，后端逻辑可先验证请求标识符，然后再处理其他表单数据。如果可能，每个服务器请求的请求标识符都应该是唯一的，而不是在特定会话的各个请求之间共享。对于会话标识符而言，攻击者越难猜出请求标识符，则越难成功进行 CSRF 攻击。标记不应能够轻松猜出，它应以保护会话标记相同的方法得到保护，例如使用 SSLv3。
其他缓解技术还包括：
框架保护：大多数现代化的 Web 应用框架都嵌入了 CSRF 保护，它们将自动包含并验证 CSRF 标记。
使用质询-响应控制：强制客户响应由服务器发送的质询是应对 CSRF 的强有力防御方法。可以用于此目的的一些质询如下：CAPTCHA、密码重新身份认证和一次性标记。
检查 HTTP Referer/原始标题：攻击者在执行 CSRF 攻击时无法冒仿这些标题。这使这些标题可以用于预防CSRF 攻击。
再次提交会话 Cookie：除了实际的会话 ID Cookie 外，将会话 ID Cookie 作为隐藏表单值发送是预防 CSRF 攻击的有效防护方法。服务器在处理其余表单数据之前，会先检查这些值，以确保它们完全相同。如果攻击者代表用户提交表单，他将无法根据同源策略修改会话 ID Cookie 值。
限制会话的有效期：当通过 CSRF 攻击访问受保护的资源时，只有当作为攻击一部分发送的会话 ID 在服务器上仍然有效时，攻击才会生效。限制会话的有效期将降低攻击成功的可能性。
这里所描述的技术可以使用 XSS 攻击破解。有效的 CSRF 缓解包括 XSS 缓解技术。
最后欢迎大家访问我的个人网站：1024s