SQL injection and Quote escaping

Viewing 4 reply threads
  • Author
    • #8821

      considering that it is part of a wordpress app (which mean quotes are being escaped)
      so stuff like this will not wok – Page.php?name=’; drop table table;
      (php and mysql)

      $name = $_GET
      Select * from table where name = ‘{$name}’

      Is there any way to exploit this kind of code,

      I read about a vulnerability only on GBK charset – let say it uses a different charset.
      Does it mean that it is completely safe – can any one exploit it?

    • #54190

      With ONLY that code snippet, I can’t say for certain if there are other exploits.

      For example, depending on exactly what is in play on the site, here’s an example of where the built-in cleansing / sanitizing in wordpress isn’t always prohibitive of exploitation:


      Perhaps different character encoding could bypass sanitization, as well. (Never hurts to try some other options, in the event you find yourself a new 0-day, depending on the plugins in use, or even some new found vuln in the main wordpress.)

    • #54191

      Quick followup… If you’re at all interested in web application pentesting, it’d be well worth a look at eLearnSecurity’s courses. Don will be posting my review here on EH-net, in the next few days, of their WAPTX (Web Application Penetration Testing Extreme) course. I just submitted the writeup to him, last night. They cover a lot of SQLi stuff in there as well as, I’m sure, in the WAPTv2 course they just released, in the past week.


    • #54192

      I realize that parameterized SQL queries is the optimal way to sanitize user input when building queries that contain user input, but I’m wondering what is wrong with taking user input and escaping any single quotes and surrounding the whole string with single quotes.

      Any single-quote the user enters is replaced with double single-quotes, which eliminates the users ability to end the string, so anything else they may type, such as semicolons, percent signs, etc, will all be part of the string and not actually executed as part of the command. We are using Microsoft SQL Server 2000, for which I believe the single-quote is the only string delimiter and the only way to escape the string delimiter, so there is no way to execute anything the user types in.

      I don’t see any way to launch an SQL injection attack against this, but I realize that if this were as bulletproof as it seems to me someone else would have thought of it already and it would be common practice. My question is this: what’s wrong with this code? Does anybody know a way to get an SQL injection attack past this sanitization technique? Sample user input that exploits this technique would be very helpful.

    • #54193

      “SQL Injection” is subset of the an unverified/unsanitized user input vulnerability (“buffer overflows” are a different subset), and the idea is to convince the application to run SQL code that was not intended. If the application is creating SQL strings naively on the fly and then running them, it’s straightforward to create some real surprises.

      We’ll note that this was a somewhat winding road with more than one wrong turn, and others with more experience will certainly have different — and better — approaches. But the fact that we were successful does suggest that we were not entirely misguided.

      There have been other papers on SQL injection, including some that are much more detailed, but this one shows the rationale of discovery as much as the process of exploitation.

Viewing 4 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?