|
|
|
需要对应用程序验证输入内容的方式进行检验，因为很多Web应用程序攻击都故意使用格式错误的输入。SQL注入、跨站点脚本（XSS）、缓冲区溢出、代码注入以及无数其他拒绝服务和特权提升攻击都可利用输入验证中的漏洞。下表中重点列出了常见的输入验证漏洞。
|
|
|
|
|
|
|
|
测试时应考虑下列问题，以帮助发现潜在的输入验证安全问题。
|
|
|
|
|
|
设计指定的输入验证方法是什么？首先，设计必须展示策略。应用程序应对收到的所有输入进行约束、拒绝和净化。约束输入是最佳的方法，因为针对已知有效类型、模式和范围对数据进行验证，要比通过查找已知坏字符来验证数据简单得多。
|
|
|
|
|
|
|
|
确保设计标出了应用程序的入口点，以便跟踪各个输入字段的操作。可考虑Web页输入、输入到组件和Web服务，以及从数据库输入。
|
|
|
|
|
|
如果输入是从信任边界内受信源传递的，并非总要验证输入；但如果输入是从不受信任的源传递的，必须验证输入。
|
|
|
|
|
|
不要将最终用户看作受信任的数据源。确保对正常和隐藏的表单字段、查询字符串和cookie都进行验证。
|
|
|
|
|
|
如果不进行验证，惟一的安全条件就是数据接收自当前信任边界之内。但是，如果使用深层防御策略，则需要使用多层验证。
|
|
|
|
|
|
这种形式的输入也应验证，特别是当其他应用程序也写入该数据库时。不要对其他应用程序的数据验证程度进行假设。
|
|
|
|
|
|
对于相同类型的输入字段类型，检验使用的是否是相同的验证和筛选库，确保一致地执行验证规则。
|
|
|
|
|
|
客户端验证可用于降低到服务器的回程数量，但不能依靠它来维护安全性，因为它很容易被忽略。需要在服务器验证所有的输入。
|
|
|
|
|
|
检查应用程序处理输入的方式，不同类型的处理可能导致不同类型的漏洞。例如，如果在SQL查询中使用输入，应用程序可能易受SQL注入的攻击。
|
|
|
|
|
|
|
|
检查应用程序是否使用基于输入的名称来制定安全决策。例如，应用程序是否接受用户名、文件名或URL。由于名称的表示方法多种多样，以上各项都极易造成规范化错误问题。如果应用程序接受输入作为名称，则应确保对它们进行验证并在处理之前将它们转换为规范的表示法。
|
|
|
|
|
|
密切注意形成SQL数据库查询的所有输入字段。确保对这些字段的类型、格式、长度和范围进行正确的验证。此外，检查查询的生成方式。如果使用参数化的存储过程，输入参数将被当作文本，而不会当作可执行代码。这是降低风险的一种有效措施。
|
|
|
|
|
|
如果在HTML输出流中包括输入字段，可能受到XSS攻击。确保对输入进行验证，并对输出进行编码。密切注意系统对接受一定范围HTML字符的输入字段的处理方法。
|
|
|
