是否可以使用反向代理来防止XSS / CSRF攻击？为简单起见，请考虑一个简单的内部站点，由受信任的用户访问，具有两个端点
/home.html --> basic HTML page
/api/might_be_dangerous?... --> not security-proofed over all possible parameters
home.html只会使用安全参数访问/api/might_be_dangerous，但外部网站可能不会。{/ p>
是否可以使用反向代理
home.html时设置Cookie /api/might_be_dangerous时检查Cookie 以及防止XSS / CSRF攻击所需的其他内容？我想我可能用Flask编写一个，依此类推，看起来通过反向代理暴露它将是一个很好的，可重用的抽象。当然，需要配置哪些端点（在这种情况下为home.html）可以设置cookie，哪些端点需要它，但这似乎不是技术障碍。
答案 0 :(得分：2)
是否可以使用反向代理来阻止XSS / CSRF攻击？
一般情况下没有。解决这些问题需要应用程序的知识。
防止HTML注入（XSS的最常见原因）的正确方法是在创建页面时使用HTML转义输出。代理不能这样做，因为它只获取整个页面而不知道哪些位是需要转义的变量。
防止XSRF的正确方法是要求将秘密值作为与持久性请求数据匹配的非持久性请求数据提交。代理无法做到这一点，因为它不知道客户端将如何创建请求，以及添加秘密数据。
尽管如此，仍有反向代理尝试来阻止CSRF和XSS攻击。这是Web应用程序防火墙（WAF）的典型功能。有时候他们甚至会做一些工作。但是，在他们期望的行为范围之外做任何事情，你就不会被覆盖。
例如，WAF可能会过滤表单数据中提交的<个字符，以防止HTML注入。但是，如果您的应用程序提交的是非形式内容（如JSON），则可能不会被捕获。如果您的应用程序实际上需要能够在输入中接受<个字符，那么它将会中断。无论哪种方式，其他形式的注入（例如HTML属性注入或JS注入）都不会受到影响。
类似地，WAF可能会将<input type="hidden" name="csrftoken" value="..."/>注入到应用程序生成的<form method="POST">元素中，并检查POST中是否提供了csrftoken。但是，当你在客户端使用JS / AJAX做任何聪明的事情时，那是行不通的，如果你忘了将表单设为POST，你就不会受到保护。
因此，尽管诸如WAF之类的反向代理可能在阻止攻击（并且通常更多地用作被动入侵检测器）中有一些用处，但它本身就不可靠，并且通常需要一堆配置和调优才能工作打破你的应用程序，这反过来需要对这些应用程序和威胁的一定程度的理解。此时，您通常最好将应用程序本身的威胁修复程序放在最适合的位置。
答案 1 :(得分：1)
设置和检查Cookie无法防范CSRF，因为如果用户在第一个浏览器标签上打开了您的网站，但被操纵为在第二个标签中打开攻击者的网站，则攻击者网站可以制作对yoursite.com/api/might_be_dangerous的请求将通过您主页上设置的Cookie。在CSRF下，如果在当前用户的上下文中执行，api/might_be_dangerous请求只会是危险的，因此这意味着用户登录到您的站点，并且攻击者的站点导致请求由经过身份验证的用户不情愿地进行。防止这种情况的方法是在由home.html发送并由api/might_be_dangerous代码验证的隐藏字段中包含会话唯一的令牌。请参阅：General Recommendation: Synchronizer Token Pattern
我不确定您的目标是如何使用反向代理来阻止CSRF和XSS。请更新您的答案以解释。感谢。