views:

5726

answers:

6

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:

  1. What all special characters and character patterns (for example <>, ., --, <=, ==,>=) should be blocked so that injection attack could be prevented.
  2. Is there any existing regex pattern which I could use as is?
  3. 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.

+5  A: 

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.

James McMahon
Thanks nemo. But my application is an old application and it will take lot of effort to convert all the Statements to PreparedStatements and that's the reason we have chosen to use alternate methods. Any further information on that is greatly appreciated.
arya
I actually have alot of experience updating older apps to use PreparedStatements, it is fairly easy except if you are using alot of dynamic statements. Still this process is time consuming, so I can understand not wanting to spend the time. Hopefully that IBM article is helpful to you. Best of luck.
James McMahon
@arya: There is no substitute for PreparedStatements. Everything else is a bug waiting to happen. If you don't have time now to update everything, I'd recommend making it a priority to update every SQL statement in every file you are editing. Clean up the code as you go along.
Mr. Shiny and New
+1  A: 

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)

Loki
For encoding, do I use a URLEncoder class? Then where do I decode?
arya
A: 

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.

duffymo
+3  A: 

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.

rmeador
A: 
Ryan Anderson
+1  A: 

don't filter or block values.

  1. you should ensure that when combining bits of text you do the proper type conversions :) ie: if you have a piece a string which is type HTML and a string which is type TEXT you should convert TEXT to HTML instead of blindly concatenating them. in haskell you can conveniently enforce this with the type system.

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 :)

  1. if you take strings of type HTML from users you should sanitize it with a library to remove all not-good tags/attributes. there are lots of good whitelist html filters out there.
  2. you should always use parameterized queries. ALWAYS! if you have to build up queries dynamically then build them up dynamically with parameters. don't ever combine non-SQL typed strings with SQL typed strings.