Posts Tagged ‘HTML’

Skills shortage leaves Australian Computer Society open to attack.

Friday, January 22nd, 2010

According to the Australian Computer Society and DIAC (The department for immigration) there is a massive shortage in Australia of “Computing Professionals specialising in Network Security/Firewall/Internet Security”.

No surprise there, whats more of a shocker is that the very people who assess the skills of would be migrants to Australia can’t even secure their own website against the most basic types of Injection attacks – namely cross site scripting (I’m guessing its down to the skills shortage)

Security flaw

Security flaw

The ACS however don’t seem to be concerned – I’ve emailed them twice at the beginning of the week about the fault and they’ve yet to reply to my email or even fix it. The carefully crafted link below will generate the above screen shot.

http://www.acs.org.au/index.cfm?action=load&temID=search&searchtxt="><h1>hello</h1><script>alert(document.cookie);</script><input type="hidden"&pageno=1&display=1&searchbtn.x=53&searchbtn.y=16

The code is not malicious, the above script will just output the current cookie to the screen. With security flaws like this lets hope the ACS aren’t “shaping our future”…

Update 27th January It appears that someone at the ACS has fixed the issue, but only to the extent of filtering the <script></script> tags from the input string… HTML injection is still possible, wouldn’t it have been easier just to use html_entities() or similar asp.net function to sanitize the string before displaying it? HTML injection is still a big security risk.

How not to advertise for a PHP programming job

Wednesday, October 28th, 2009

So I got an email today for a job in Tower Hill (thats central london). The job came with a simple programming test to write a script that parsed a tab separated file and produced a batch script as the output. They kindly provided a working copy of their solution on their website so you could validate the output of your code.

If I was going to advertise a job in a company and provide an online example of my own code I’d make darn sure that, unless the sole purpose of my online code was to find someone who knew what an XSS flaw was, that the link to the script I sent a prospective employee to wasnt vunerable to Cross Site Scripting attacks. Eeek. Worse still as their script seemed to accept either GET or POST variables as inputs (they were probably checking $_REQUEST rather than $_POST or $_GET in their code) it was possible to format a link that injected HTML code straight into their website.

Screenshot of the flaw with 'Cheese!!' being injected.

Screenshot of the flaw

You can mitigate the threat from these types of attacks by properly sanitizing your variables before they are displayed. If this is on a HTML page and you are expecting an integer value then intval might be a good function to use, if its a text field you might try htmlentities. If any data is going into a database then you need to be using mysql_escape_string on all of your variables.

As I’ve not alerted the company to the flaw I wont post the URL to the exploit. Luckily the page in question can’t be found within googles’ indexes. I wonder if anyone else will notice…

Disable google translate

Friday, September 25th, 2009

Got a problem with dodgy users from obscure countries causing havoc on your website? I recently noticed a huge number of people using Google translate to access a website. If you want to prevent people using Google translate on your website you can use.

<meta name=”google” value=”notranslate” />

In your HTML page inside the head section. Users don’t seem to get an error message from Google, it just gives them a blank screen instead of their translated page.

Caching wordpress as static HTML using APC

Monday, August 17th, 2009

While trying to speed up my wordpress installation I noticed that there seemed to be a lot of plugins that generate a static home page – they all used complex methods to store the files, checking the last modified times and implementing complex checking methods to see if the content has changed.

It struck me as strange that no one had suggested using APC cache – I don’t know if this is because its not available on all commercial hosting packages (such as dreamhost) or if its just due to lack of knowledge about the apc_store and apc_fetch commands. APC doesn’t just cache PHP opcode, it can cache user defined PHP variables as well.

I’ve come up with a small script that is capable of caching my PHP pages generated by wordpress. It uses the APC cache to store and manage the page data and it guarantees that the page will never be more than a specified number of seconds out of date.

In order to use this plugin you only have to make 2 changes go index.php in the wordpress root. Firstly you place this code at the top of your index.php


<? 
   
if (empty($_POST)) {

        $cache_key md5($_SERVER['REQUEST_URI'] .serialize($_GET));
        
$cache_data apc_fetch($cache_key$cache_result);

        if ($cache_result == true) {
            echo(
$cache_data);
            die;
        }

        ob_start();

    } 
?>

And then place this code at the base of index.php


<?
   
if (empty($_POST)) {
    
$cache_data ob_get_clean();
    
apc_store($cache_key$cache_data300);
    echo(
$cache_data);
   } 
?>

The code works by creating a MD5 hash of the URL and the GET request – this is important as it means that pages that take variables as arguments, such as search, will create their own cached pages. We don’t use the cache if there are POST variables present as we can probably assume that the output of the page is very dynamic. If you don’t want to cache pages that use a GET request as well you could use something like this

if ((empty($_POST)) && (empty($_GET)) {

It would be unwise to cache separate pages for each set of POST data as POST data is generally much larger than data sent via GET.

We use the MD5 of the URI and GET parameters to act as a key for our storage, if we find the key in memory and it hasn’t expired, we can use the data retrieved from the key to display the page – this bypasses all the MySQL and other PHP that was needed to create the original page.

Wordpress Static vs Dynamic benchmarks

If we now look at some benchmarks of before and after we can see the difference. I’ve use ab (that comes with apache) to perform the tests

Without the caching

Requests per second: 8.52 [#/sec] (mean)
Time per request: 1173.343 [ms] (mean)
Time per request: 117.334 [ms] (mean, across all concurrent requests)
Transfer rate: 212.85 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 579 1161 104.4 1158 1464
Waiting: 234 465 82.6 449 756
Total: 579 1161 104.4 1158 1464
Percentage of the requests served within a certain time (ms)
50% 1158
66% 1186
75% 1225
80% 1238
90% 1289
95% 1315
98% 1407
99% 1413
100% 1464 (longest request)

With caching (tests done on non primed cache)

Requests per second: 136.07 [#/sec] (mean)
Time per request: 73.490 [ms] (mean)
Time per request: 7.349 [ms] (mean, across all concurrent requests)
Transfer rate: 3391.63 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.6 0 4
Processing: 10 72 32.2 77 202
Waiting: 5 32 25.0 26 196
Total: 11 72 32.2 77 202
Percentage of the requests served within a certain time (ms)
50% 77
66% 89
75% 93
80% 98
90% 109
95% 120
98% 136
99% 142
100% 202 (longest request)

You can see that without the caching that the server can serve 10 requests per second and after the caching it can serve 136 requests per second. That’s a 13 times increase in speed. Not bad for a server with only 256mb of RAM and a single core CPU. I’m pretty sure the server could handle even more load but at this point the upstream connection became saturated.

There are however some pitfalls with caching. Currently when users are logged in we cache their page, we need to add a condition to prevent this caching. Its not a problem on my server however as I am the only personal allowed to blog. Other pitfalls are the freshness of data, we can set this to whatever we want (from 1 second to infinity) but its never going to be as “fresh” as a page that isn’t cached.

Caching isn’t for everyone but if you do want your site to run faster, can afford to have some slight inconsistencies in your data and don’t mind waiting a few minutes for a comment to appear then you can achieve some really good results.

Cross Site Request Forgery attacks

Thursday, November 6th, 2008

Cross site request forgery attacks in one of their simplest forms are a hidden iframe in which an html form is hidden and who’s submit action is triggered on-load. CSRF attacks have been becoming increasingly common – they have the distinct advantage over other attacks (such as SQL injection – it is possible to combine both types of attack for devastating consequences) as they leave virtually no trace of the real attacker.

A CSRF attack works by secretly tricking your browser into posting data to another site via HTML/JavaScript. The user is often unaware of this and the the content of the post and its actions can vary. Some CSRF attacks simply abuse affiliate schemes in the hope that you will eventually visit the website you unknowingly posted to and purchase one of their products. Others can be far more malicious stealing personal information, posting entries in a blog or granting users additional access rights to your CMS.

Even if your website is password protected it could still be vulnerable to a CSRF attack. Since session data is shared amongst all windows a hidden iframe that posts data would be no exception. This would give an attacker the potential to POST to the password protected section of your website (such as a CMS or Control Panel). You might be totally unaware of this until someone mentioned a strange post that you had made. That’s right – the CSRF attack would appear to come from your account. Below is some HTML and JavaScript demonstrating how easy it is to craft a CSRF attack.

exploit.html

<iframe src=”postme.html” style=”display: none;” border=”0″ height=”0″ width=”0″></iframe>

postme.html

<form id=”send_me” name=”send_me” method=”post” action=”http://www.example.com/post_form.php”>
<input name=”title” value=”Teehee” type=”hidden”>
<input name=”content” value=”Woot” type=”hidden”>
<script>
document.send_me.submit();
</script>
</form>

In the above example the code in exploit.html would be pasted into a page, it would then post to example.com/post-form.php when you visited the page. If the website used GET instead of POST it would be possible to craft an even simpler attack

<img src=”http://www.example.com/post_form.php?title=Teehee&content=Woot>


CSRF + DDOS

If the script that you post to is vulnerable to SQL injection you could further compound the CSRF attack and create a Distributed Denial of Service attack on your given domain – every time someone visited your website with the embedded CSRF code in you could cause them to inject an additional SQL statement into an SQL query. If this was a command like BENCHMARK it could very well cripple the target server. Once again it would be very hard to trace the initial perpetrator of this type of attack.

Defending against CSRF

Tokens tend to be the most common way to defend against such attacks. Here the server sets a variable which is stored in a HTTP session. It then inserts a hidden item in the form which contains this value. When the form is posted to the server it checks the HTTP session value against the value sent by the form. If they don’t match, you reject the post.

A potential attacker would be unable to guess this token and as a result it would be very hard if not impossible to craft a CSRF attack.

As you can probably see CSRF attacks are certainly something you need to defend against – in case you don’t believe me here are some examples of CSRF in the news, the latter by David Airey makes very good reading.

http://www.webappsec.org/

http://www.davidairey.co.uk/