Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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:

    • ...?

Thanks!

share|improve this question
2  
I did a Google search for "SQL injection testing" and found this helpful link: owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005) –  user246 Aug 1 '11 at 13:50
    
OWASP has all very knowledgeable informations. –  Balaji Kothandaraman Aug 18 '11 at 11:08
add comment

5 Answers 5

up vote 3 down vote accepted

From Application level you need to check how does the code handle parameters. Are there any validations done on this 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 sqlmap - automatic SQL injection and database takeover tool. http://sqlmap.sourceforge.net/

Microsoft Source Code Analyzer for SQL Injection (CTP July 2008) - http://blogs.msdn.com/b/benjones/archive/2008/07/19/microsoft-source-code-analyzer-for-sql-injection-ctp-july-2008.aspx

share|improve this answer
add comment

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:

&#60alert"!xss!</&#60

As opposed to using literals:

<alert>"xss"</alert>

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.

share|improve this answer
1  
+1 for some great ideas! –  Todd Bumbarger Aug 2 '11 at 15:16
add comment

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:

share|improve this answer
    
I disagree with your assessment, security testing is (or should be) a major part of QA. Also, why an answer and not a comment? –  PaulDonny May 30 at 12:27
add comment

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.

share|improve this answer
add comment

Check this out, I've shared an article on XSS attack, SQL injections and cheat sheet for scripts http://www.cygnet-infotech.com/is-your-website-safe-against-cross-site-scripting-attacks

share|improve this answer
1  
The question is about SQL injection, the linked article does not mention SQL at all, its only about XSS. –  Niels van Reijmersdal May 30 at 12:56
    
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. –  Kate Paulk May 30 at 13:30
1  
Prashant, two minor things. First, if this is original content, it should be clear that this is your own material (otherwise it would look like you're just trying to get more hits on your site). It could be that's what you meant by "I've shared" but we should try to remove ambiguity when we can. =) Second, as Kate mentioned, it's much better to include the key points as they apply to the OP, and then provide a link for further reading if they get hungrier. Thanks! –  corsiKa May 31 at 2:42
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.