web application security scanner survey
Paid Advertising
web application security lab

MySQL Truncation Etc…

Stefan Esser has a really good article about how MySQL and SQL truncate columns which can lead to security holes. He uses a good example of a column that has a width of 16 chars but he submits something with 17 chars. Obviously enforcing length is one way to enforce that, even if it almost never happens. But one other thing came to mind.

Harkening back to my days of reading Rain Forrest Puppy’s papers, I realized that often times the code does a straight regex or string matching. Eg: if ($username eq “admin”) { fail(); } but if the $username was “admin    ” it clearly will fail the string match since it’s not an exact match, but it will have the same net effect in the database of passing the check and allowing you to access the admin data. Likewise padding in front of the username will have the same effect in some cases - depending on how the SQL query is constructed (if it’s encapsulated). Anyway, good article, go read it!

14 Responses to “MySQL Truncation Etc…”

  1. Jim Manico Says:

    ESAPI validation functions FORCES a maximum length requirement that would stop these attacks cold.

    Take a look at http://manicode.blogspot.com/2008/08/input-validation-with-esapi.html for a complete explanation/recipe on the proper use of OWASP ESAPI input validation.

    Also, for ESAPI calls like:

    String name = getValidInput(”Name”, form.getName(), “SomeESAPIRegExName1″, 255, false, errorList);

    Take note of the 4′th argument.

  2. RSnake Says:

    It always comes down to implementation issues though, Jim. A great example is someone reading this site looking for help might take your example and copy/paste it, using 255 instead of 16 like they should be in the example above. It’s nice to think that this will solve all problems, but in reality people just mess up code more often than not - implementation is the tough problem to solve.

  3. rvdh Says:

    Just a great affirmation that obviously no-one reads my blog, or at least forgot that I covered it already. ;) pun intended. Anyway i’d like to say that it’s been known for quite some time, especially in regard to T-SQL truncation attacks back in 2006, variables have buffers that can be overflowed if they are truncated by buffer limits. This is true in C, C++ whatever SQL runs on or what have ya, and hence my stressed arguments all the time to check data-size and set new buffers for them in scripting languages like PHP or ASP, before passing it into a SQL query, or a another native function that relies on C(++) buffers. I hope programmers now finally learn not to trust the scripting platform they work on.

    Ah well, so it goes I am glad it gets some more attention now. :p

  4. RSnake Says:

    @rvhd - if I had time to read every blog in the world, I would be all over your site. I just happened across that post today. Sorry if you covered it first. Go beat Stefen up for clearly missing it. Although my post really isn’t about the size issue, it’s just about the padding with spaces issue, so don’t beat me up too! ;)

  5. rvdh Says:

    hehe, just kidding around, I gleamed over the issue before minutely. Stefan does has some nice info regarding MySQL. Stefan spoils all the fun by telling people! ;) But it should be standard practise by now that programmer shouldn’t trust user-data, and that implies data-size also *says the data-size advocate* :D at least that’s on my wishlist for this Christmas.

  6. RSnake Says:

    Okay, if you get to be the data-size guy, I get to be the padding with spaces guy. You’ll be talking sizeof and I’ll be talking about chomp. It’ll be great.

  7. rvdh Says:

    cuze me 4 the double post.

    Ah, yes the space padding. I can remember reading that also, spaces are tricky because they can be represented in different encoding formats also, just like a lot of other low ascii chars too.

  8. RSnake Says:

    Exactly. I would suspect nulls, tabs, carriage returns and newlines (among others) would fit into this.

  9. rvdh Says:

    Those were the days R! :)

  10. rvdh Says:

    The days when http response splitting was called CRLF injection, before all the fancy buzzwords, that kind of time ;)

    bit offtopic: RSnake I thought you had a talk at Blackhat or DefCon? do you have some slides yet?

  11. RSnake Says:

    Ho ho! Now I can accuse you of not reading! ;) http://www.darkreading.com/blog.asp?blog_sectionid=403&doc_id=161389

  12. rvdh Says:

    whoops! eh, I am a whitehat eh? ;)

  13. Rotten Agenda Says:

    Ronald, I believe your website to be one of the most valuable yet under-appreciated sources of information not only in its approach to web application security, but also because of your staunch stance on autonomy, and the truth that many individuals often overlook, or fail to realize: we are all under the control of a select group of “leaders”. That being said both you and RSnake need to continue what you are doing for those of us who do follow your work.

    *P.S. please remove the first comment I posted as I misspelled the URL.

  14. Fanboy Says:

    Hahaha,

    the best thing in esser’s blog is hidden in the “People I read” section.

    http://www.suspekt.org/

    Can you find it?

Respond here or Discuss On the Forums