This type of attack is possible by the way the client browser has the ability to interpret scripts embedded within HTML content enabled by default, so if an attacker embeds script tags such
I like this site because <script>alert('Injected!');</script> teaches me a lot
If it works and you can see the message box, the door is opened to the attacker's imagination limits! A common code insertion used to drive navigation to another website is something like this:
<H1> Vulnerability test </H1>
<META HTTP-EQUIV="refresh" CONTENT="1;url=http://www.test.com">
Same within a
<FK STYLE="behavior: url(http://<<Other website>>;">
<TITLE> tag is a common weak point if it's generated dynamically. For example, suppose this situation:
<TITLE><?php echo $_GET['titulo']; ?>
If you build title as '
example </title></head><body><img src=http://myImage.png>', HTML resulting would insert the 'myImage.png' image first of all:
There is another dangerous HTML tag that could exploit a web browser's frames support characteristic:
<IFRAME>. This tag allows (within Sandbox security layer) cross-scripting exploiting using web browser elements (address bar or bookmarks, for example), but this theme is outside the scope of this article.
alert" and "
void". Testing it is very easy, just navigate to whatever site, and type in the web browser's address bar:
This is not a harmful script, as you can see, but suppose you want to get information about the site, for example, if it is using cookies or not, you could type something like this :
If the website is not using cookies, no problem, but else, you could read values like the server session ID, or any user data stored in cookies by the application.
Suppose now that we use the
alert(). This function returns a null value to the web browser, so no recharging page action is executed. We could change the DOM values inside this function and no navigation change state would occur. Imagine you've found a site that stores the PHP session ID in the common cookie '
PHPSESSID'; if we start a new navigation to the same website in another web browser instance, we'll get a new '
PHPSESSID'; we could change the session IDs in both instances by typing:
(The code above was wrapped to avoid scrolling)
You will see in the message box the new session ID assigned to the actual one. This example also shows the possibility of concatenating more than one action in the same line of execution.
By only taking a look at site cookies, you could find some very descriptive ones implementing security features; for example, if you find a site cookie like "logged=no", probably you could go into the logged area simply by changing that cookie value:
<FORM>) for different purposes; in this case, you could change any form field value using the
void() function, too. Imagine a shopping portal with a shopping cart; if the site designer didn't take care of this type of injection, you could fill the cart and pay for it only $1:
These other techniques are named indirect code injection; not only cookies or forms modification are exploited by this technique, any DOM component or HTTP header is exposed.
So, it's very important to keep in mind these code injection techniques when developing web applications to make it a more safe application.
Preventing Code Injection
When developing web applications, it's very recommendable to follow the next considerations to prevent possible code injection:
Suppose you have only one form to store the shopping chart; attackers could modify your bill, simply by changing the price as seen before:
A solution to this situation is just maintaining the shopping chart actions on the server side, and getting the client side refreshed via AJAX, for example.
Don't store sensible data into cookies, because they can be easily modified by an attacker, as seen before. If you need to store data in cookies, store them with a hash signature generated with a server side key.Never use hidden boxes to hold items because they can be hard coded into the code. Otherwise, you should always validate the fields at server side using a secure algorithm, with data received from the client as input:
<TITLE> example above, you better not use dynamic DOM element generation.Take care about dynamic evaluation vulnerabilities (like the
<TITLE> example above). Imagine this piece of code in a PHP page:
$dato = $_GET['formAge'];
eval('$edad = ' . $dato . ';');
If you are developing a web site that allows the user to upload content (forum, guestbook, "contact me", etc.), you may split special HTML chars, so injected tags will be maintained in the website, but will not be executed; you can get this with the
eval() parameters will be processed, so if "
formAge" is set to "5; system('/bin/rm -rf *')", additional code will be executed on the server and will remove all the files. Dangerous, don't you think so?
strip_tags() PHP function,
Ultimately, the best defense to code injection attacks resides on "Best practices" while programming.
Points of Interest
Implementing security features in web applications sometimes takes no care by programmers, and exposes the project to attackers.
- 1.0 - 05/12/2010 - Original version.