Safety saves – 3 steps towards a safe web Application

By /

For malicious attackers attempting to compromise your web application, the network is no longer the path of least resistance. A simple configuration error or a little carelessness and sometimes not being aware can give an attacker direct illegal access to your database or sections that require aunthentication. In this post we present you some simple yet strong steps towards making your endeavour more secure. We are sure they will surely tighten your seatbelts or prove or be your helmet. And we beleive that Safety does matter when it involves your hard work.

SQL injection

SQL injection is a code injection technique and is basically due to input data validation flaw. Let us assume that you ask user to input username and password to access certain section of your application. And your query is something like:

SELECT * FROM user_table WHERE user=”.$username.” and pass=”.$password.”;

here,

$password = $_POST[‘password’];

$username = $_POST[‘username];

In this case, all malicious user has to do to gain access to your application is enter in either of the field ( say password ) some string of the type – “ or “1” = “1 – Hence your query now becomes

  SELECT * FROM user_table WHERE user=”some known username” and pass=”“or “1” = “1”;

Since “1” = “1” is always true, therefore he gains access to that particular section with the power of “some known username”.

You can prevent it by following two very simple approaches:

1. Using addslashes() method

   $username = addslashes($_POST["username"]);   
   $password = addslashes($_POST["password"]);

2. Using mysql_real_escape_string() method

$sql_query = sprintf(“SELECT * FROM user_table WHERE user = ‘%s’ AND pass = ‘%s’ ”, mysql_real_escape_string($user), mysql_real_escape_string($password));

.

DoS Attacks

DoS (Denial of Service) attack is an attempt to engage your resource and make it unavailable to its intended users.

Test size limits of user input before using or storing it. There are two ways to limit the file size that can be uploaded. As explained below:

php.ini Settings

1. Adjust the upload_max_filesize setting:
The default value is 2MB. A second restriction affecting the total size of form submissions, is marked by the post_max_size setting in php.ini. Its default value is 8MB. So you can alter it as you want.

2. HTML Form setting:
But changing php.ini setting in shared web Servers becomes an issue. In that case, include a hidden input field in your form with the name MAX_FILE_SIZE, and the maximum file size you want to accept with this form as its value. But, this value can’t exceed the upload_max_filesize setting in your php.ini. Anyway you can accept different maximum sizes on different pages and avoiding unnecessary engagement of your server.

.htacess Settings
If you find in your log file that some particular IP address (say xxx.xxx.xxx.xxx) is making enormous requests to your application and keeping it engaged. This can be an automated program or a bot or some guy with ill intentions. You can simply deny the requests from that particular IP Address by adding below code to your .htacess file

      Deny from xxx.xxx.xxx.xxx

Put size safeguards on database queries. For example, before you display query results in an PHP Web page, be sure that there are not an unreasonable number of records.

.

Sessions

Sessions are the methods by which we can “maintain state” from one page to the next and identify specific users across multiple page requests. Below are some practices that you might find of some help. It might not be very close to give bullet-proof security. However, they can be some simple extra steps that can be taken to help keep hackers out

A session assigns a unique identifier to a user. To make it difficult for someone to guess, or for a program to find quickly, to help avoid hacking, a session identifier should be at least 32 random alpha-numeric characters or longer.
In order to protect your session from hacker, you need to find as many unique aspects of the user’s computer as you can find, and verify that they stay the same across all page requests.

I would advise to store IP Address and User Agent (UA). It is possible that a hacker could be spoof IP or using same UA, but it is more unlikely.

Store the last access time in the session variable. And in case it is inactive for more than 20 minutes (say), end the session.

An illustration:
Scroll to Top