I'm supposed to test a web application for SQL injections. I'm new to this type of security testing and I'd like to get some tips on the matter. Are there any best practices or do I simply search on the Internet for the most common SQL injections and try them out on my application?

I hope some guidance would be profitable for other newbies like me, so please, help me complete the following lists:

  1. List of "places" in the application to be tested:

    • username
    • password(s)
    • e-mail
    • search field
    • text fields
    • any other fields that are available to the user
  2. List of tests to be performed:

    • ...?



4 Answers 4


From Application level you need to check how does the code handle parameters. Are there any validations done on these parameters (Length, Datatype checks)?

Best Practices:

  • Use of parameterized queries
  • Use Procedures
  • Grant only execute permission for SP. No DDL operations for users

Alternative I would suggest you look at how code is written.

You can check on


This kind of testing can be incredibly fun and can expose a wide variety of defects outside of its core focus; making sure you can't destroy data. I'm no expert but I do have a few tips I hope you'll find helpful.

There are a variety of ways to try and inject SQL queries and commands into the web application; text input fields are the most obvious but depending on how your site works, you may be able to manipulate URLs to transmit injection attacks. If you can upload to your web application, don't forget to try setting file names as injection attacks.

Some familiarity with the database in question is a must; if it's not terribly complex ask the designer for an ERD ( Entity Relationship Diagram ). If it's very complex ( lots of tables, views and indexes ) then ask for some guidance on crucial fields.

The kinds of attacks I generally try consist of trying to delete tables, trying to delete or change entities, or trying to hit the database with complex queries in rapid succession to try and overtax the database server. You'll need an introduction to SQL syntax in the environment you're using ( MySQL vs MS SQL ).

Lastly, I tend to use a variety of ways to outsmart filters that might be on the text boxes; after vanilla SQL syntax is tried, using HTML or UTF encoding instead of character literals can reveal a ton of bugs. Something like this:


As opposed to using literals:


This can sometimes trick the application server into converting otherwise innocuous characters into a dangerous string.

As mentioned before, this kind of testing will often find bugs that have nothing to do with your database. For example, I once uploaded a file with an encoded "drop table" query that broke the page so that my upload history could not be shown.

Hope this helps.


I think this question is more suited at http://security.stackexchange.com . The following questions has been answered over there which are similar to your question:

  • I disagree with your assessment, security testing is (or should be) a major part of QA. Also, why an answer and not a comment?
    – Paul Muir
    Commented May 30, 2014 at 12:27

I must say, I loved BrMcMullin's answer. This is an area where using tools can teach you a lot. There are plenty of good open source and free one's, however, I'm not familiar with most of them (company shelled out for some nice vulnerability management software). You could always check out a site like penTestIT for some recommendations. Personally, since I have it at my disposal, I normally do an automated in the background while I'm doing some of my other tests. Since it shows you what it's doing, helps beautifully.

After this, I do exactly what BrMcMullin stated. In this area, all that I keep open is my browser, fiddler, and some good music.

As for your second question, about where to test, far too many people limit themselves to textfields. Take a look at where your query is getting it's information. Often, select boxes, and radio button's are also used, the data from those inputs are not checked anywhere near as much as the text fields.

I can almost guarantee that after you find you're first sql injection bug, that you will have a ton of new idea's for testing it, as you'll want to keep on going. It's fun and a great way to get your creative juices flowing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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