绕过Web应用程序输入验证

Question

恶意用户可以使用Bas-64或其他编码方案绕过web应用程序输入验证或绕过某些外部Web应用程序防火墙。由于这些编码方案是无限的，我们如何使这些输入有限来验证每一个输入字符串。

Answer 1

攻击者无法选择哪些编码可能有效。如果应用程序端没有base64 64解码器，执行base64编码将一无所获。

如果在应用程序端存在base64解码步骤，则应用程序应该在解码完成后执行输入验证。

对于处于中间的WAF，它不知道应用程序可能在做什么解码，您是对的--它们不可靠。

有些工具只应用协议标准解码(例如URL -URL参数解码)，并且在使用特殊方案编码的攻击上会出现假阴性；有些工具尝试选择编码和可选的编码组合，试图识别攻击签名，这可能导致错误的阳性，因为无害的文本永远不会被base64 64解码，被误解为可能是攻击的东西的base64 64编码。

所以是的，像WAF这样运行在应用层之上的补丁是不可靠的，但这并不是什么新鲜事。任何人都不应该仅仅依靠WAF来获得安全性；它们很好地检测一般攻击，并在应用程序修复可用之前对已知的漏洞采取临时的自定义解决办法，但它们永远不会是一个水密的输入过滤器。

Answer 2

您不需要在抽象中验证输入字符串。为特定目的验证字符串。

当恶意用户使用Base64绕过验证系统时，这意味着验证系统和使用该值的系统不一致。验证系统不了解Base64，但是底层系统将很高兴地将Base64解码应用于输入。这是错误的验证。

我们可以说，当在单独的系统(例如前端)中完成时，“输入验证”或多或少是注定要失败的，因为两个独立维护的软件部件在任何时候都不能保持完全同步。这是mysql_real_escape_string()上下文中的通用问题: PHP+MySQL函数必须充分了解底层MySQL实现将如何解释输入字符串的所有细节，并且这些细节随着产品版本的不同而不同。

Answer 3

我同意@Thomas关于输入验证的文章，但值得指出的是(RE: OP)，编码方案的数量并不多。有很多，但这不是一个没完没了的系统。在保护应用程序时，重要的是研究系统所支持的编码方案，并根据系统的需要调整安全性，而不是试图为每个潜在的安全问题映射每个已知的代码集。不幸的是，没有“金锤”来解决不安全的数据获取或管理问题，因此，应有的注意和尽职调查是至关重要的。

祝你工作顺利。