1

是否可以使用反向代理来防止 XSS/CSRF 攻击？为简单起见，考虑一个简单的内部站点，由受信任的用户访问，具有两个端点，

/home.html --> basic HTML page
/api/might_be_dangerous?... --> not security-proofed over all possible parameters

home.html只会/api/might_be_dangerous使用安全参数访问，但外部站点可能不会。

是否可以使用反向代理

  1. home.html访问时设置 cookie
  2. /api/might_be_dangerous访问时检查 cookie

以及防止 XSS/CSRF 攻击的其他必要措施？我想我可能可以使用 Flask 等编写一个，似乎通过反向代理公开它是一个不错的、可重用的抽象。当然，需要配置哪些端点（home.html在这种情况下）可以设置 cookie，以及哪些需要它，但这似乎不是技术障碍。

4

2 回答 2

4

是否可以使用反向代理来防止 XSS/CSRF 攻击？

在一般情况下没有。解决这些问题需要应用程序的知识。

防止 HTML 注入（XSS 的最常见原因）的正确方法是在创建页面时对输出进行 HTML 转义。代理不能这样做，因为它只获取完整的页面而不知道哪些位是需要转义的变量。

防止 XSRF 的正确方法是要求将秘密值作为与持久请求数据匹配的非持久请求数据提交。代理不能这样做，因为它不知道客户端将如何创建请求，将秘密数据添加到其中。

尽管如此，还是有一些反向代理试图阻止 CSRF 和 XSS 攻击。这是 Web 应用程序防火墙 (WAF) 的典型功能。有时他们甚至有点工作。但是做任何超出他们期望的行为范围的事情，你就不会被覆盖。

例如，WAF 可能会过滤<表单数据中提交的字符，以防止 HTML 注入。但是，如果您的应用程序正在提交非表单内容，例如 JSON，那么这可能不会被捕获。如果您的应用程序确实需要能够接受<输入中的字符，它就会中断。无论哪种方式，其他形式的注入（例如 HTML 属性注入或 JS 注入）都不会受到影响。

类似地，WAF 可能会将 a 注入<input type="hidden" name="csrftoken" value="..."/>应用<form method="POST">程序生成的元素中，并检查 acsrftoken是否在从该应用程序返回的 POST 中提供。但是当你在客户端用 JS/AJAX 做任何聪明的事情时，那是行不通的，如果你忘记将表单设置为 POST-only，你将不会受到保护。

因此，尽管诸如 WAF 之类的反向代理可能在阻止攻击方面有一些用处（并且通常更多地用于充当被动入侵检测器），但它本质上是不可靠的，并且通常需要大量配置和调整才能在不破坏您的应用程序的情况下工作，这反过来又需要对这些应用程序和所面临的威胁有一定程度的了解。在这一点上，您通常最好将这些威胁的修复程序放在应用程序本身更适合的地方。

于 2013-10-01T14:23:16.703 回答
1

设置和检查 cookie 并不能防止CSRF，因为如果用户在他们的第一个浏览器选项卡上打开了您的网站，但被操纵在第二个选项卡中打开攻击者的站点，则攻击者站点可以发出请求yoursite.com/api/might_be_dangerous并设置 cookie您的主页将通过。在 CSRF 下，您的api/might_be_dangerous请求只有在当前用户的上下文中执行才会是危险的，因此这意味着用户已登录到您的站点，并且攻击者的站点会导致经过身份验证的用户不情愿地发出请求。防止这种情况的方法是将会话唯一的令牌包含在由代码发送home.html和验证的隐藏字段中。api/might_be_dangerous请参阅：一般建议：同步器令牌模式

我不确定您打算如何使用反向代理来防止 CSRF 和XSS 。请更新您的答案以进行解释。谢谢。

于 2013-10-01T09:24:33.300 回答