检查所有参数以防止注入攻击是一种好习惯吗?
Is it a good practice to check all the parameters for preventing injection attacks?
背景
- 应用程序基于:Spring MVC
- Java8
- 主要使用拦截器过滤掉请求。
问题
我测试了我的应用程序,每个用户输入都容易受到 HTML/Script 注入攻击。我正在使用某些方法在我的客户端阻止它们,但是如果我在将它们发布到服务器之前操纵了表单值,则注入成功并破坏了我的网站。因此,我的首要任务是在服务器端也采用相同的检测方法。我应该早点做这个,但无论如何都有一些原因......
我在想什么
是检查拦截器中的每个参数。拦截器将在页面提供用户输入和要提交的表单的任何地方验证所有参数。
像这样
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>
所以..我想问的是.."IS IT A GOOD IDEA TO DO SOMETHING LIKE ABOVE?"
试图逃脱或以其他方式拒绝 cross-site scripting (XSS) 提交尝试不是一个好主意。这种方法存在一些问题:
- 转义用户输入的正确方法取决于您要将其注入的位置。使用未正确转义的内容可能会导致显示问题——用户看到垃圾——或意外的 XSS 漏洞。
- 因为你的用户内容已经被转义显示,所以你必须避免再次转义。这意味着您必须在模板中以不同方式处理来自数据库的用户输入和来自其他来源的用户输入,否则您将遇到与上述相同的问题。
- 如果您不想将数据库中的转义内容用于显示,则需要对其进行特殊处理,因为您需要将其取消转义。这会添加不必要的样板代码,降低互操作性,并可能导致错误。
- 很难区分合法的 XSS 攻击和无害地使用保留字符,如 <、>、" 或 '。标签剥离(即删除所有看起来像 HTML 标签的方法)会破坏用户内容.
相反,您应该适当地转义您的内容一旦显示。这里有一个 pretty good writeup 详细说明了为什么在输入时转义不是一个好主意。
Spring 支持的模板框架具有转义内容的快捷方式。
就我个人而言,我建议使用 Thymeleaf:默认情况下它会转义 HTML 内容和属性的用户输入 — 否则需要使用 specific Thymeleaf attribute — and it has shortcuts for escaping input 用于 JavaScript 或 JSON 嵌入页面(见底部)。
如果您使用的是其他模板框架(或 JSP),请查阅其文档以了解如何对显示的内容进行转义。请注意,某些模板框架默认不转义 and/or 不提供不同的转义方法。前者忘记在某处转义输入时会导致XSS漏洞,后者的后果上面已经描述了。
背景
- 应用程序基于:Spring MVC
- Java8
- 主要使用拦截器过滤掉请求。
问题
我测试了我的应用程序,每个用户输入都容易受到 HTML/Script 注入攻击。我正在使用某些方法在我的客户端阻止它们,但是如果我在将它们发布到服务器之前操纵了表单值,则注入成功并破坏了我的网站。因此,我的首要任务是在服务器端也采用相同的检测方法。我应该早点做这个,但无论如何都有一些原因......
我在想什么
是检查拦截器中的每个参数。拦截器将在页面提供用户输入和要提交的表单的任何地方验证所有参数。
像这样
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>
所以..我想问的是.."IS IT A GOOD IDEA TO DO SOMETHING LIKE ABOVE?"
试图逃脱或以其他方式拒绝 cross-site scripting (XSS) 提交尝试不是一个好主意。这种方法存在一些问题:
- 转义用户输入的正确方法取决于您要将其注入的位置。使用未正确转义的内容可能会导致显示问题——用户看到垃圾——或意外的 XSS 漏洞。
- 因为你的用户内容已经被转义显示,所以你必须避免再次转义。这意味着您必须在模板中以不同方式处理来自数据库的用户输入和来自其他来源的用户输入,否则您将遇到与上述相同的问题。
- 如果您不想将数据库中的转义内容用于显示,则需要对其进行特殊处理,因为您需要将其取消转义。这会添加不必要的样板代码,降低互操作性,并可能导致错误。
- 很难区分合法的 XSS 攻击和无害地使用保留字符,如 <、>、" 或 '。标签剥离(即删除所有看起来像 HTML 标签的方法)会破坏用户内容.
相反,您应该适当地转义您的内容一旦显示。这里有一个 pretty good writeup 详细说明了为什么在输入时转义不是一个好主意。
Spring 支持的模板框架具有转义内容的快捷方式。
就我个人而言,我建议使用 Thymeleaf:默认情况下它会转义 HTML 内容和属性的用户输入 — 否则需要使用 specific Thymeleaf attribute — and it has shortcuts for escaping input 用于 JavaScript 或 JSON 嵌入页面(见底部)。
如果您使用的是其他模板框架(或 JSP),请查阅其文档以了解如何对显示的内容进行转义。请注意,某些模板框架默认不转义 and/or 不提供不同的转义方法。前者忘记在某处转义输入时会导致XSS漏洞,后者的后果上面已经描述了。