Securing Your Web Application Against Attacks

In this article we will continue our discussion of authentication and how it helps in securing web applications. You will probably recall from the last article that I mentioned the existence of two methods of authentication and discussed the first one, which is through an HTML form. In this article, the fifth one in an eight-part series, we’ll start with the second method of authentication. We’ll also discuss how attackers may gain access to your system.

More on Authentication

The second method of authentication is called HTTP Authentication. It presents the user with a dialog or password box that requires a username and password to gain access. Some of the benefits of HTTP authentication include:

  • Very little PHP code required.

  • The entered username and password are remembered without the need to use PHP to send cookies or establish sessions.

  • A clean interface that will not interfere with your page design.

I’m also going to give you a list of some of the bad things about HTTP authentication, which may explain why it is not used as much as the method I described in the previous article.

  • Limited usability

  • Does not allow you to establish user groups or specify access levels

  • Does not allow you to set access levels

Authentication: Security Vulnerabilities

A primary cause of access control vulnerabilities is not paying attention to the sections of a web application that are used the least. Administrative features and access control are often an afterthought, and they are written with an authorized user in mind, without considering what an attacker might try to do. We are all guilty of this. An authorized user is trusted more than an anonymous user, but if your administrative features are available via a public URL, they are an inviting target to an attacker. In these cases, negligence is your primary foe.

As with security, access control needs to be integrated into your design. It is not something to be bolted onto an existing application. Although possible, this approach is very error-prone, and errors in your access control are necessarily security vulnerabilities.

So how are these vulnerabilities exploited? There are two very common attacks that are used:

  • Password Sniffing

  • Brute force

{mospagebreak title=Password Sniffing}

Although not specific to access control, when an attacker can sniff traffic between your users and your application, being mindful of data exposure becomes increasingly important, particularly regarding authentication credentials. To sniff out a password, an attacker would use a password sniffer to watch traffic between two or more computers. There is a lot of free password sniffer software available on the Internet that will do the job just fine. This is made particularly easy by developers who use plain text when authenticating their users.

So how do you protect your applications from password sniffing?

You do it by using some form of encryption, which will make it difficult for attackers to read passwords. So, using SSL is an effective way to protect the contents of both HTTP requests and their corresponding responses from exposure. Any request for a resource that uses the https scheme is protected against password sniffing. It is a best practice to always use SSL for sending authentication credentials, and you might consider also using SSL for all requests that contain a session identifier, because this helps protect your users against session hijacking.

To protect a user’s authentication credentials from exposure, use an https scheme for the URL in the form’s action attribute as follows:

<form action="https://localhost/login.php" method="POST">

<p>Username: <input type="text" name="username" /></p>

<p>Password: <input type="password" name="password" /></p>

<p><input type="submit" /></p>

</form>

Although this is all that is required to protect a user’s authentication credentials from exposure, you should also protect the HTML form itself with SSL. There is no technical reason to do so, but users feel more comfortable providing authentication credentials when they see that the form is protected with SSL.

{mospagebreak title=Brute Force}

What is a brute force attack? A brute force attack is an attack in which all available options are exhausted with no intelligence regarding which options are more likely. In other words, the attacker tries to enter your site while not knowing what kind of security measures you have in place or even what username or password you are using, so he or she tries anything and everything. This is more commonly known as an enumeration attack; the attack enumerates through all possibilities.

In terms of access control, brute force attacks typically involve an attacker trying to log in with a very large number of attempts. In most cases, known valid usernames are used, and the password is the only thing being guessed. This can go on and on until the attacker gets to the right password for a particular user name. Of course, the most obvious way to stop this kind of attack is to limit the number of times a user can try to log on or to limit the number of failures at login, but it would be even better to distinguish between a legitimate user and a attacker.

A typical login form would look something like this:


<form action="http://localhost/login.php" method="POST">

<p>Username: <input type="text" name="username" /></p>

<p>Password: <input type="password" name="password" /></p>

<p><input type="submit" /></p>

</form>

What this form would do when submitted, would be to send two very important pieces of information over to the login script (http://localhost/login.php), the username and password. We already discussed how easy it is for a attacker to trick the login script into accepting a username and password that they themselves sent, instead of the form. All that an attacker needs to do is write a script that will repeatedly send a password to the login script.

With such a script, an attacker can add a simple loop to continue trying different passwords, and the HTTP response can be checked after each attempt. When a change in HTTP response is observed, the authentication credentials are expected to be valid. As I stated before, a good way to prevent or stop this kind of attack is to limit the number of failures at login. You can also put a timing limit at login and suspend a user account if a user does not enter the correct login credentials in a given time period. The HTTP requests used in a brute attack are pretty much the same every time, except for the password.

The final type of attack that we are going to look at is called a Replay Attack. A replay attack, sometimes called a presentation attack, is any attack that involves the attacker replaying data sent previously by a legitimate user in order to gain access or other privileges granted to that user. In order to prevent replay attacks, you want to make it very difficult for an attacker to capture any data that can be used to gain access to a protected resource. This primarily requires that you focus on avoiding the following:

  • The use of any data that provides permanent access to a protected resource.

  • The exposure of any data that provides access to a protected resource (even when the data provides only temporary access).

So, to effectively prevent replay attacks, minimize data exposure and also make sure that clear text transmission of usernames and passwords is avoided.

That’s it for authentication.

{mospagebreak title=The Logout script}

The logout script is responsible for logging the user out of a session. It has the following code:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"><!– InstanceBegin template="/primary/Templates/was.dwt.php" codeOutsideHTMLIsLocked="false" –>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<!– InstanceBeginEditable name="doctitle" –>

<title>WebSecure::Logout</title>

<!– InstanceEndEditable –>

<!– InstanceBeginEditable name="head" –>

<!– InstanceEndEditable –>

<link href="Templates/was.css" rel="stylesheet" type="text/css" />

</head>


<body>

<table width="99%" border="1">

<tr>

<td bgcolor="#333333" class="header">Web Secure</td>

</tr>

 

 

<tr>

<td><!– InstanceBeginEditable name="main" –>

<?

session_start();


if($_SESSION["status"]="logged") {

session_unset();

session_destroy();

header( "Location:login.php" );

exit();

}

else{

if ($_SESSION["status"]="not logged") {

//the session variable isn’t registered, the user shouldn’t even be on this page

header( "Location:login.php" );

exit();

}

}

?>



<!– InstanceEndEditable –></td>

</tr>

<tr>

<td class="copy">&copy;2008</td>

</tr>

</table>

</body>

<!– InstanceEnd –></html>


The most important section here, the one that does the job of logging a user out, is the PHP portion. First the session is started:


<?

session_start();

Then we test to see if the status session variable is set and that its value is logged:


if($_SESSION["status"]="logged") {

session_unset();

session_destroy();

If so, we end the session and send the user back to the login page using PHP’s header() function:

header( "Location:login.php" );

exit();

}


If the user is not logged in, then he or she does not belong here and should also be sent to the login page. This is exactly what the script does:


else{

if ($_SESSION["status"]="not logged") {

//the session variable isn’t registered, the user shouldn’t even be on this page

header( "Location:login.php" );

exit();

}

}

?>

Conclusion

In the next article we will focus on database security. We will look at SQL injection and how to prevent it. We will also continue to build the site scripts.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye