Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

The SQL phrase looks like this,

"SELECT * from XX where id = '" + id + "'"

The id variable comes directly from the GET parameter named id.

And the Java web app explicitly disallowed single quote. If a single quote was found in that parameter, the server stop processing it immediately and returns an error.

So, is this still exploitable? With postgresql and tomcat environment.

share|improve this question
1  
Well - why not do it properly instead of wondering whether or not it's exploitable? –  user1615903 Jun 20 '13 at 5:06
    
Also - yes it is: websec.wordpress.com/2010/03/19/… –  user1615903 Jun 20 '13 at 5:14
    
@user1615903 it's a different situation where $id is not surrounded by single quote, am I wrong about it? –  warl0ck Jun 20 '13 at 5:45
    
What language? Is it a strongly typed language where id is guaranteed to be a valid integer, or a dynamic language where id could be a String or anything? –  GlenPeterson Jun 20 '13 at 12:35
add comment

3 Answers

You may want to take a look at this paper (wayback machine link). It details some methods of bypassing such filters.

For example, some SQL filters replace all single quotes with a pair of single quotes. However, feeding them an input containing \' can bypass this.

Also, there is Unicode smuggling, where you use a Unicode character that Java (PHP/Ruby/Python/whatever) understands as being different from a quote, but the database doesn't.

Unless you have a really, really good reason, I recommend you use the built-in escaping.

share|improve this answer
3  
Or parameterised queries / prepared statements. –  Polynomial Jun 20 '13 at 15:22
1  
Wow, that paper is brilliant! ;-) –  AviD Apr 4 at 8:19
    
@manishearth the link doesn't work.. –  Shurmajee Apr 4 at 17:33
    
@Shurmajee added an alternate link –  Manishearth Apr 4 at 20:08
add comment

You are talking about "prevent known bad" which only works until someone thinks of a new bad thing. As @Manishearth says, \' is one technique. For a URL, %27 is another. In HTML, you can have ', ', ', ', ' are others. What does your server do if these techniques are combined as in, %40%230039%3B (' url encoded) or %5C%27 (\' url encoded) or \\\\'?

Prevent Known Bad is always a risky proposition. Allow Known Good is always better when it is an option. Thus, converting to an integer type will always provide more safety than trying to prevent specific strings. Prepared Statements provide an excellent layer of protection.

Check out the Wikipedia article about SQL Injection Mitigation.

share|improve this answer
add comment

Assuming that GET parameter 'id' in digits-only, the best thing to do is to check if ID really contains digits only, by for example converting it into an INT (and catch the exception if any), and not some nasty things like quotes/slashes/encoded chars/etc.

In general I prefer having a real integer variable as I perfectly know it contains only digits, rather than an escaped string which might contains some strange characters..

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.