HOW TO SECURE WEBSITE FROM SQLI

HOW TO SECURE WEBSITE FROM SQLI

SQL injection

SQLI also was known as SQL injection is the most common web hacking technique that might destroy your database. It is a code injection technique in which the placement of malicious code in SQL statements, via web page input. This common web attack mechanisms utilized by attackers to steal sensitive data from organizations.  While SQL Injection can affect any data-driven application that uses a SQL database, it is most often used to attack websites.

The hackers insert some malicious SQL statements into input fields for execution by the underlying SQL database.  This technique is made possible because of improper coding of vulnerable web applications. And these flaws happen because the input fields unexpectedly allow SQL statements to go through and query the database directly.

There is an option to prevent such web attacks from hackers. Now explore how to secure website from SQLI. By utilizing some parameterized database queries with bound, typed parameters and careful use of parameterized stored procedures in the database developers can prevent these SQL Injection vulnerabilities in web applications. This can be accomplished in a variety of programming languages including Java, .NET, PHP, and more.

There are many various steps that can be taken by, developers, system administrators, and database administrators to minimize attacks or the impact of successful attacks.

Always Keeps Your Software Up To Date

For all web application software includes some components like libraries, plug-ins, frameworks, web server software, and database server software. Keep these all components up to date with the latest security patches available from vendors.

Utilize The Least Privilege Statements

When the provisioning database accounts used to connect to the SQL database, it is necessary to utilize the principle of least privilege statements.  For example, we do not give the web site’s database connection privilege or queries such as INSERT, UPDATE, or DELETE statement, if a web site only needs to retrieve web content from a database using SELECT statements.  Never allow your web application to connect to the database with Administrator privileges (the “SA” account on Microsoft SQL Server, for instance).

Avoid Shared Databases

Avoid the usage of a shared database. That is, never use the shared database accounts between different web sites or applications.

Validate On Input Fields

If the input fields are set to like drop-down menus or radio buttons then validate user-supplied input for expected data types, not just fields that allow users to type in input. That means allows the user to enter the data according to the rules and prototype specified in the particular entry field.

Right Configuration

The database error messages are never sent to the client web browser. if we properly report and handle the errors on the web server and in the code.  web Attackers always adjust their queries for successful exploitation by leveraging technical details in verbose error messages.

Use HTTPS

HTTPS is a protocol used to provide security over the Internet. HTTPS guarantees that users are talking to the server they expect and that nobody else can intercept or change the content they’re seeing in transit.

It is highly advisable to use the only HTTPS if the users want to deliver any data or information that might want private. Attackers try to steal the logging information stealing and they were able to perfectly imitate a user and take over their login session. To defeat this kind of attacks, you almost always want to use HTTPS for your entire site.

We can get admin access by using these strings.

Username:|' or 1=1 limit 1 -- -+  |

Password:|' or 1=1 limit 1 -- -+  |
We have to find post data directory of username and password.

The easy method is to find post data dir: Goto admin/index.php and note which PHP page you used to post admin data.

Query of form will as: <form method="POST" action="login_check.php" name="form" >

Login_check.php (Might be changed on your own) is form of posting user data.

Now we have to go login_check.php to find dir of user data like username and password.

Query will as :$username=$_POST['username'];


$password=$_POST['password'];

Now it's simple to add little query at post data dir.

Quer is : mysql_real_escape_string(htmlspecialchars(      ----(For username)

mysql_real_escape_string(htmlspecialchars(md5(  ----(For password)


After adding query to data dir script will as :

$username = mysql_real_escape_string(htmlspecialchars($_POST['username']));

$password = mysql_real_escape_string(htmlspecialchars(md5($_POST['password'])));


After adding this little query admin page can't bypass. Page will give you an error message.

Error: Please enter correct detail!  (Might Be Your's Own)

Parameterized Statements

Programming languages talk to SQL databases using database drivers. A driver allows an application to construct and run SQL statements against a database, extracting and manipulating data as needed. Parameterized statements make sure that the parameters (i.e. inputs) passed into SQL statements are treated in a safe manner.

For example, a secure way of running a SQL query in JDBC using a parameterized statement would be:

// Define which user we want to find.
String email = "user@email.com";

// Connect to the database.
Connection conn = DriverManager.getConnection(URL, USER, PASS);
Statement stmt = conn.createStatement();

// Construct the SQL statement we want to run, specifying the parameter.
String sql = "SELECT * FROM users WHERE email = ?";

// Run the query, passing the 'email' parameter value...
ResultSet results = stmt.executeQuery(sql, email);

while (results.next()) {
  // ...do something with the data returned.
}

Contrast this to explicit construction of the SQL string, which is very, very dangerous:

// The user we want to find.
String email = "user@email.com";

// Connect to the database.
Connection conn = DriverManager.getConnection(URL, USER, PASS);
Statement stmt = conn.createStatement();

// Bad, bad news! Don't construct the query with string concatenation.
String sql = "SELECT * FROM users WHERE email = '" + email + "'";

// I have a bad feeling about this...
ResultSet results = stmt.executeQuery(sql);

while (results.next()) {
  // ...oh look, we got hacked.
}

The key difference is the data being passed to the executeQuery(...) method. In the first case, the parameterized string and the parameters are passed to the database separately, which allows the driver to correctly interpret them. In the second case, the full SQL statement is constructed before the driver is invoked, meaning we are vulnerable to maliciously crafted parameters.

You should always use parameterized statements where available, they are your number one protection against SQL injection.

Object Relational Mapping

Many development teams prefer to use Object Relational Mapping (ORM) frameworks to make the translation of SQL result sets into code objects more seamless. ORM tools often mean developers will rarely have to write SQL statements in their code – and these tools thankfully use parameterized statements under the hood.

The most well-known ORM is probably Ruby on Rails’ Active Record framework. Fetching data from the database using Active Record looks like this:

def current_user(email)
  # The 'User' object is an Active Record object, that has find methods 
  # auto-magically generated by Rails.
  User.find_by_email(email)
end

Code like this is safe from SQL Injection attacks.

Using an ORM does not automatically make you immune to SQL injection, however. Many ORM frameworks allow you to construct SQL statements, or fragments of SQL statements when more complex operations need to be performed on the database. For example, the following Ruby code is vulnerable to injection attacks:

def current_user(email)
  # This code would be vulnerable to a maliciously crafted email parameter.
  User.where("email = '" + email + "'")
end

As a general rule of thumb: if you find yourself writing SQL statements by concatenating strings, think very carefully about what you are doing.

Escaping Inputs

If you are unable to use parameterized statements or a library that writes SQL for you, the next best approach is to ensure proper escaping of special string characters in input parameters.

Injection attacks often rely on the attacker being able to craft an input that will prematurely close the argument string in which they appear in the SQL statement. (This is why you will often see ' or " characters in attempted SQL injection attacks.)

Programming languages have standard ways to describe strings containing quotes within them – SQL is no different in this respect. Typically, doubling up the quote character – replacing ' with '' – means “treat this quote as part of the string, not the end of the string”.

Escaping symbol characters is a simple way to protect against most SQL injection attacks, and many languages have standard functions to achieve this. There are a couple of drawbacks to this approach, however:

• You need to be very careful to escape characters everywhere in your codebase where an SQL statement is constructed.
• Not all injection attacks rely on abuse of quote characters. For example, when a numeric ID is expected in a SQL statement, quote characters are not required. The following code is still vulnerable to injection attacks, no matter how much you play around with quote characters:

def current_user(id)
  User.where("id = " + id)
end

Sanitizing Inputs

Sanitizing inputs is a good practice for all applications. In our example hack, the user supplied a password as ' or 1=1--, which looks pretty suspicious as a password choice