SQL Injection- Web Application Security

Web application security problems are as serious as network security problems. Attackers have begun to focus on web application security problems, and are actively developing tools and techniques for detecting and exploiting them

Here is the web application security Prevention Case 2

SQL injection is a particularly widespread and dangerous form of attack. To exploit a SQL injection flaw, the attacker must find a parameter that the web application passes through to a database. By carefully embedding malicious SQL commands into the content of the parameter, the attacker can trick the web application into forwarding a malicious query to the database. These attacks are not difficult to attempt and more tools are emerging that scan for these flaws. The consequences are particularly damaging, as an attacker can obtain, corrupt, or destroy database contents.

The simplest way to protect against injection is to avoid accessing external interpreters wherever possible. For many shell commands and some system calls, there are language specific libraries that perform the same functions. Using such libraries does not involve the operating system shell interpreter, and therefore avoids a large number of problems with shell commands.

  • Use bind variables where ever possible. If not, escape all user variables which be used in a SQL statement or on the command line.
  • Prepare your statements using variable binding and then pass the parameters when executing the query:
    $cursor = $db->prepare(“DELETE FROM CRITICALTABLE WHERE USER=?”);
  • Use pattern matching to verify user input is an expected value. If input is not what is expected, throw an error. Error messages should be generic.
  • Turn off/control debug messages to avoid giving an attacker potentially useful information.
  • Database level: Limit access to the web account that is accessing the database. Write procedures to insert records and update data rather than give the application direct access to the tables; Limit application to READ-only access where possible – at user level as well as database level.
  • Reuse previously tested code wherever possible.
Posted in:

Leave a Reply