Category: Uncategorized

Without trying to repeat too much others may have already, this afternoon on the #PHPWM IRC channel one resident seemed to be having a ‘lolwut’ competition, well – posting links which showed ‘lolwut’s (In english: highlighting security problems in web sites).

Sure, you might think, so what ? There will always be a website somewhere with a security flaw…. Except the websites in ‘todays’ list were from the top 10-15 google results when searching for ‘PHP Development UK’. The sites returned should reflect companies or individuals who are offering (one would assume) professional PHP development, and should therefore be clueful about such issues….

We came across someone claiming 6 years of professional web development experience – who was vulnerable to an XSS attack (subsequently fixed as I write this post, so there’s little point in me including a screenshot).

Of course, Akrabat then chipped in with a “I hope my work site isn’t vulnerable” type comment – so obviously we had to have a go at breaking it, just to put his mind at rest … and we nearly succeeded – I found an error message in an error page which outputted mostly unescaped input – it seemed to have some filtering in place, but we worked around this by inputting %3D type characters, converting IP addresses to integers and so on – which was an amusing experience.

The rest of us seem to be running WordPress, and as funny as this may sound, I suspect it’s more secure (at least out of the box) due to the fact more people have tried poking and breaking it. Unless your hosting is with 123-reg …. in which case it seems you’re going to be in trouble.

<rant>

If you want to avoid Cross Site Scripting (XSS) holes – make sure you escape or filter what you’re writing out – using either something like htmlentities or strip_tags or htmlpurifier. This must include error messages – if they contain any user supplied data. Every code base we have audited for third parties have contained Cross Site Scripting or SQL Injection vulnerabilities. This sucks. I’ve blogged in the past (although this was probably on my old drupal based website) about how easy this is to fix from an architecture point of view, if you’re writing something bespoke (which the sites in question seemed to be) – follow the MVC design pattern and when assigning data to the ‘view’ make it so that it is escaped by default (e.g. override Smarty::assign()). To avoid SQL Injection’s either use prepared statements everywhere, or use an ORM layer like Propel.

</rant>

(For the record – all sites were informed ….)

One vaguely interesting outcome from the above is that it seems obvious to me that I need to re-do the Pale Purple website – as it’s not really changed in 2-3 years now… which is perhaps not good. This time I think I’ll use WordPress, as it’ll mean I can stop supporting Drupal