SQL Injection

1. SQL Injection

Description:
Hackers manipulate a web application in an attempt to inject their own SQL commands into those issued by the database.

Prevention
Some steps that you can take to protect your applications against SQL Injection attacks include:
1. Implement parameter checking on all applications. For example, if you're asking someone to enter a customer number, make sure the input is numeric before executing the query.
2. Limit the permissions of the account that executes SQL queries. The rule of least privilege applies. If the account used to execute the query doesn't have permission to execute it, it will not succeed!
3. Use stored procedures (or similar techniques) to prevent users from directly interacting with SQL code.

Testing Inputs:
1. Look for sites that have query string values (example: search for URLs with "id=" in the URL)
2. Send a request to the sites identified as dynamic with an altered id= statement that adds an extra quote to attempt to cancel the SQL statement (example: id=6')
3. Parse the response sent back to look for words like "SQL" and "query" - which typically indicate that the app is often sending back detailed error messages (also bad)
4. Review whether the error message indicates that the parameter sent to SQL wasn't encoded correctly (in which case the site is open to SQL Injection Attacks)
5. Enters invalid data or garbage values or pass (special) characters for “Username” and “Password” and try to break the SQL query.
2. "ALL" validation needs to be checked on the server side too
Description:
Some times validations are done only on the presentation side and not to the server side.
Prevention:
Make sure while coding the validations are set on server side also.
Testing Inputs:
Test all the fields for validations by entering different format values, garbage values, special characters, spaces etc.





3. CRLF Injection



Description:
The term CRLF stands for Carriage Return (CR, ASCII 13, \r) Line Feed (LF, ASCII 10, \n). A CRLF Injection attack occurs when a hacker manages to inject CRLF Commands into the system. This kind of attack is not a technological security hole in the Operating System or server software, but rather it depends on the way that a website is developed. Some developers are unaware of this kind of attack and leave open doors when developing web applications, allowing hackers to inject CRLF Commands.
Here is a sample basic log file:
Date UserName Message
25/07/2005-14:23:47 GoodSurfer I perfectly agree!
This log file is perfectly normal, however if a user had to input something like: I also agree with you...\n25/07/2005-15:00:00 Another Surfer What are you talking about!? The log file would then look like this:
Date UserName Message
25/07/2005-14:23:47 GoodSurfer I perfectly agree!
25/07/2005-14:42:19 BadSurfer I also agree with you..
25/07/2005-15:00:00 AnotherSurfer What are you talking about!?
In this case, since the input is not being properly filtered from the CR and LF characters, the user created a fake entry in the log file.
Prevention: The best way to defend against CRLF attacks it to filter extensively any input that a user can give. One should "remove everything but the known good data" and filter meta characters from the user input. This will ensure that only what should be entered in the field will be submitted to the server.
Testing Inputs:
Check for the filtration of user inputs are done or not and if not then Enter carriage return (\r) and line feed (\n) in text fields and check for the affected area.