Java 检查所有参数以防止注入攻击是否是一种良好的做法？

背景

• 基于springmvc的应用程序
• 爪哇8
• 大多数情况下，使用拦截器过滤请求

问题

我测试了我的应用程序，每个用户输入都容易受到HTML/脚本注入攻击。我在客户端使用某种方法来阻止它们，但是如果我在表单值发布到服务器之前对表单值进行了操作，则注入成功并损坏了我的网站。所以，我的首要任务是在服务器端使用相同的检测方法。我早就应该这么做了，但还是有原因的

我在想什么

检查拦截器中的每个参数。拦截器将在页面提供用户输入和提交表单的地方验证所有参数

类似这样的东西

public class ParameterFilteringInterceptor {
     // 1. get all request parameters..
     // 2. check every values..
     // 3. if illegal characters exist in one of them, 
     //    converting or escaping them will start and change them to acceptable values.

     // Getting and setting on request parameters is going to occur frequently.

     // If good to go, return true
     // Or return false with a proper error message.
}

    <interceptor>
        <mapping path="/addform" />
        <mapping path="/editform" />
        <mapping path="/post" />
        <mapping path="/newarticle" />
        <mapping path="/newcomment" />
            .
            .
            .
            <!-- Depend on the volume of a web application,
            these mapping paths could be sooooooooo many. -->
        <beans:bean class="com.company.web.interceptor.AuthenticatingInterceptor"></beans:bean>         
    </interceptor>

这样设置

public class ParameterFilteringInterceptor {
     // 1. get all request parameters..
     // 2. check every values..
     // 3. if illegal characters exist in one of them, 
     //    converting or escaping them will start and change them to acceptable values.

     // Getting and setting on request parameters is going to occur frequently.

     // If good to go, return true
     // Or return false with a proper error message.
}

    <interceptor>
        <mapping path="/addform" />
        <mapping path="/editform" />
        <mapping path="/post" />
        <mapping path="/newarticle" />
        <mapping path="/newcomment" />
            .
            .
            .
            <!-- Depend on the volume of a web application,
            these mapping paths could be sooooooooo many. -->
        <beans:bean class="com.company.web.interceptor.AuthenticatingInterceptor"></beans:bean>         
    </interceptor>

.
.
.

---

---

所以。。我想问的是“这样做好吗？”

试图逃避或拒绝提交尝试不是一个好主意。这种方法存在一些问题：

• 转义用户输入的正确方法取决于要将其注入的位置。使用未正确转义的内容可能会导致显示问题（用户看到垃圾）或意外的XSS漏洞
• 因为您的用户内容将被转义以供显示，所以您必须避免再次转义。这意味着您必须在模板中以不同的方式处理来自数据库的用户输入和来自其他来源的用户输入，否则您将遇到与上述问题相同的问题
• 当您不想将数据库中转义的内容用于显示时，需要对其进行特殊处理，因为您需要取消转义。这会添加不必要的样板代码，降低互操作性，并可能导致错误
• 很难区分合法的XSS攻击和诸如“或”之类的保留字符的无害使用。标记剥离（即删除所有看起来像HTML标记的内容）等方法可能会破坏用户内容

相反，您应该在内容显示后立即对其进行适当的转义

Spring支持的模板框架具有转义内容的快捷方式

就我个人而言，我建议使用Thymeleaf：默认情况下，它会逃避用户对HTML内容和属性的输入，否则需要使用a，并且它可以在页面上嵌入的JavaScript或JSON中使用（见下图）

---

如果您正在使用另一个模板框架（或JSP），请参阅其文档以了解如何转义显示的内容。请注意，某些模板框架在默认情况下不会转义和/或不提供不同的转义方法。前者可能会导致XSS漏洞，当您忘记转义某处的输入时，后者的后果已在上文中描述。

作为实践事项tice，是的，您应该验证请求中的每个参数，因为不能假设请求通过已验证的UI来自人类。您可以使用经验证的框架，如HDIV，而不是使用自定义验证。为什么不通过JSR303注释验证模型中的所有输入。您必须编写更少的代码。如果使用Spring表单标记时，输入数据直接进入模型，在模型中进行验证，然后在控制器方法中进行验证。如果有错误，则重新显示表单页面。如果没有错误，则输入过程完成。对每个参数执行此操作，而不管参数的含义如何，通常可能是错误的。它可能适用于简单的情况，但通常，您应该根据输入的语义对其进行清理。如果您的输入内容显示在HTML页面上，则您希望剥离

+1。输入筛选（删除您不需要的字符，如控制字符）和验证（确保输入符合业务规则的预期格式）有很好的用途，但输入阶段不是考虑转义/注入问题的地方。