CODEWITHSUNDEEP
javaregexxsssql-injection
arya
arya

Reputation: 235

Ways to prevent SQL Injection Attack & XSS in Java Web Application

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.

Upvotes: 12

Views: 21658

Answers (6)

duffymo
duffymo

Reputation: 308878

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.

Upvotes: 2

drscroogemcduck
drscroogemcduck

Reputation:

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.

Upvotes: 1

Ryan Anderson
Ryan Anderson

Reputation: 502

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.

Upvotes: 0

rmeador
rmeador

Reputation: 25694

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.

Upvotes: 3

Loki
Loki

Reputation: 30940

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)

Upvotes: 1

James McMahon
James McMahon

Reputation: 49639

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.

Upvotes: 7

Related Questions