Hi webmasters and budding Pen Testers, I hope you read my article about SQL Injection. Our Aim is to provide Security, right? So here is the prevention techniques.
Use Prepared Statements:
Use prepared statements, parameterized queries, or stored procedures. Don't use Dynamic SQL.
- In Java you can use PreparedStatement() with bind variables
- In .NET you can use parameterized queries, such as SqlCommand() or OleDbCommand() with bind variables
- In PHP you can use PDO with strongly typed parameterized queries (using bindParam()).
You can use Stored Procedures also. Unlike prepared statements, stored procedures are kept in the database. Both require first to define the SQL code, and then to pass parameters.
Use Less Privilege Account:
Use less privilege account for database connections. That account should not be able to drop the able or create. Maintain two separate accounts.
Escape user input.
This powerful function rejects the possibility of many clever techniques used by the intruders. php provides escpe string function. Later we will discuss about the syntax.
Assume magic quotes is always off.
When the magic_quotes_gpc variable is off, this can prevent some (but not all) SQL injection attacks. Magic quotes are not an ultimate defense and what is worse - sometimes they are off and you don't know about it. This is why it is necessary to have code for the substitution of quotes with slashes. Here is :
$username = $_POST['username'];if the magic quotes is enabled , the following problem will arise:
$password = $_POST['password'];
if (!get_magic_quotes_gpc()) {
$username = addslashes($username);
$password = addslashes($password);
}
- Not all data that are supplied by the user are intended for insertion into a database. They may be rendered directly to the screen, stored in a session, or previewed before saving. This can result in backslashes being added where they are not wanted and being shown to the end user. This bug often creeps into even widely used software.[7]
- Not all data that are supplied by the user and used in a database query are obtained directly from sources protected by magic quotes. For instance, a user-supplied value might be inserted into a database — protected by magic quotes — and later retrieved from the database and used in a subsequent database operation. The latter use is not protected by magic quotes, and a naive programmer used to relying on them may be unaware of the need to protect it explicitly.
- Magic quotes also use the generic functionality provided by PHP's addslashes() function, which is not Unicode aware and still subject to SQL injection vulnerabilities in some multi-byte character encodings. Database-specific functions such as mysql_real_escape_string() or, where possible, prepared queries with bound parameters are preferred.[8][9]
- While many DBMS support escaping quotes with a backslash, the standard actually calls for using another quote. Magic quotes offer no protection for databases not set up to support escaping quotes with a backslash.
- Portability is an issue if an application is coded with the assumption that magic quotes are enabled and is then moved to a server where they are disabled, or the other way round.
- Adding magic quotes and subsequently removing them where appropriate incurs a small but unnecessary performance overhead.
- Magic quotes do not protect against other common security vulnerabilities such as cross-site scripting attacks or SMTP header injection attacks.
Install patches regularly and timely.
Even if your code doesn't have SQL vulnerabilities, when the database server, the operating system, or the development tools you use have vulnerabilities, this is also risky. This is why you should always install patches, especially SQL vulnerabilities patches, right after they become available.
Use automated test tools for SQL injections.
Even if you follow the above said prevention, there will be some vulnerability. You may not notice it. So check the vulnerability of your web application with some kind of SQLi tools.
Try SQL inject Me tool to test the Vulnerability of your WebSite.
See i just explained theoretically, I didn't explain with code. Don't worry, wait for my next post.
0 Response to "How to Prevent SQL Injection Vulnerability? Website Security"
Post a Comment