防止SQL注入攻击的方法 Java Web 应用程序中的 XSS
我正在编写一个 java 类，该类将由 servlet 过滤器调用，并检查基于 Struts 的 java web 应用程序的注入攻击尝试和 XSS。 InjectionAttackChecker 类使用正则表达式 & java.util.regex.Pattern 类，用于根据正则表达式中指定的模式验证输入。
话虽如此，我有以下问题：
- 应该阻止哪些所有特殊字符和字符模式（例如 <>、.、--、<=、==、>=）从而可以防止注入攻击。
- 是否有我可以按原样使用的现有正则表达式模式？
- 在某些特定情况下，我必须允许使用一些特殊字符模式，一些示例值（允许）是（使用“管道”|字符作为不同值的分隔符）*Atlanta | #654，8号楼#501 | 单纯疱疹：慢性溃疡（持续时间>1个月）或支气管炎、肺炎或食管炎| 功能与功能 COMP（date_cmp），“NDI＆MALKP＆HARS_IN（icd10，是）”。 我应该采取什么策略才能防止注入攻击和 XSS，但仍然允许这些字符模式。
我希望我已经清楚地提到了这个问题。 但如果我没有，我很抱歉，因为这只是我的第二个问题。 如果需要任何说明，请告诉我。
I'm writing a java class which would be invoked by a servlet filter and which checks for injection attack attempts and XSS for a java web application based on Struts. The InjectionAttackChecker class uses regex & java.util.regex.Pattern class to validate the input against the patterns specified in regex.
With that said, I have following questions:
- What all special characters and character patterns (for example <>, ., --, <=, ==,>=) should be blocked so that injection attack could be prevented.
- Is there any existing regex pattern which I could use as is?
- I have to allow some of the special character patterns in some specific cases, some example values (to be allowed) are (used 'pipe' | character as a separator of different values) *Atlanta | #654,BLDG 8 #501 | Herpes simplex: chronic ulcer(s) (>1 mo. duration) or bronchitis, pneumonitis, or esophagitis | FUNC & COMP(date_cmp), "NDI & MALKP & HARS_IN(icd10, yes)" . What strategy should I adopt so that injection attack and XSS could be prevented but still allowing these character patterns.
I hope I have mentioned the question clearly. But if I didn't, I apologize as its just my 2nd question. Please let me know if any clarification is needed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
根据您的问题，我假设您正在尝试过滤不良值。 我个人认为这种方法很快就会变得非常复杂，并且建议将编码值作为替代方法。 这是一篇关于该主题的 IBM 文章，列出了两种方法的优缺点，http://www.ibm.com/developerworks/tivoli/library/s-csscript/。
为了避免 SQL 注入攻击，只需使用准备好的语句而不是创建 SQL 字符串。
Based on your questions I am assuming you are attempting to filtering bad values. I personally feel that this method can get very complex very quickly and would recommend encoding values as an alternate method. Here is an IBM article on the subject that lays out the pros and cons of both methods, http://www.ibm.com/developerworks/tivoli/library/s-csscript/.
To avoid SQL injection attacks just use prepared statements instead of creating SQL strings.
如果您尝试清理输入的所有数据，您将会遇到非常困难的时期。 有大量涉及字符编码的技巧，可以让人们绕过您的过滤器。 这个令人印象深刻的列表只是可以完成的无数事情中的一部分SQL注入。 您还必须防止 HTML 注入、JS 注入以及其他可能的注入。 执行此操作的唯一可靠方法是对应用程序中使用的数据进行编码。 对写入网站的所有输出进行编码，对所有 SQL 参数进行编码。 对于后者要特别小心，因为正常编码不适用于非字符串 SQL 参数，如该链接中所述。 使用参数化查询是完全安全的。 另请注意，理论上您可以在用户输入数据时对数据进行编码并将其编码存储在数据库中，但这仅在您始终以使用该类型编码（即 HTML如果它只与 HTML 一起使用，则编码；如果它在 SQL 中使用，则不会受到保护）。 这就是为什么经验法则是永远不要将编码数据存储在数据库中并且始终在使用时进行编码的部分原因。
If you attempt to sanitize all the data on input, you're going to have a very difficult time of it. There are tons of tricks involving character encoding and such that will allow people to circumvent your filters. This impressive list is only some of the myriad things that can be done as SQL injections. You've also got to prevent HTML injection, JS injection, and potentially others. The only sure way of doing this is to encode the data where it is used in your application. Encode all the output you write to your web site, encode all of your SQL parameters. Be especially careful with the latter, as normal encoding will not work for non-string SQL parameters, as explained in that link. Use parameterized queries to be completely safe. Also note that you could theoretically encode your data at the time the user enters it and store it encoded in the database, but that only works if you're always going to be using the data in ways that use that type of encoding (i.e. HTML encoding if it will only ever be used with HTML; if it's used in SQL, you're not going to be protected). This is partially why the rule of thumb is to never store encoded data in the database and always encode on use.
验证和绑定所有数据是必须的。 同时执行客户端和服务器端验证，因为 10% 的人在浏览器中关闭 JavaScript。
Jeff Atwood 有一个关于该主题的不错的博客，为您提供了因其复杂性而具有风味。
Validating and binding all data is a must. Perform both client-side and server-side validatation, because 10% of people turn off JavaScript in their browsers.
Jeff Atwood has a nice blog about the topic that gives you a flavor for its complexity.
这是一篇关于该主题的相当广泛的文章。
但我不认为你会在这里拥有圣杯。 我还建议尝试以一些标准方式对接收到的文本进行编码/解码（uuencode、base64）
Here's a pretty extensive article on that very subject.
I don't think you'll have a holy grail here though. I would also suggest trying to encode/decode the received text in some standard ways (uuencode, base64)
不要过滤或阻止值。
好的 html 模板语言会默认转义。 如果您要生成 XML/HTML，那么有时使用 DOM 工具比模板语言更好。 如果您使用 DOM 工具，那么它可以消除很多此类问题。 不幸的是，与模板相比，DOM 工具通常很糟糕:)
don't filter or block values.
good html templating languages will escape by default. if you are generating XML/HTML then sometimes it is better to use DOM tools than a templating language. if you use a DOM tool then it removes a lot of these issues. unfortunately, DOM tool is usually crap compared to templating :)
查看 AntiSamy 项目 [www.owasp.org]。 我认为这正是您想要的； 您可以设置过滤器来阻止某些标签。 他们还提供策略模板，斜线策略将是一个好的开始，然后添加您需要的标签。
此外，www.osasp.org 网站上还有大量有关保护您的应用程序的知识。
用户“nemo”所说的有关使用准备好的语句和编码的内容也应该执行。
Take a look at the AntiSamy project [www.owasp.org]. I think it is exactly what you want; you can setup a filter to block certain tags. They also supply policy templates, the slashdot policy would be a good start, then add on the tags you require.
Also, there is a wealth of knowledge on the www.osasp.org website about securing your application.
What user 'nemo' says about using prepared statements and encoding should also be performed.