Michaela Merz's personal blog site

No pain – no gain.

Secumundo now supports “Content Security Policy” to protect against malicious cross-site-scripting. The art of developing web environments in an evolving world. Always a challenge, sometimes a PITA.

germany_netI feel like a dinosaur sometimes. Or better: a stone-age woman forced to soldier through the evolution of mankind on fast forward. I started developing web-applications at a time, where we had no apache, no mysql, no PHP or any other web scripting language (not even javascript), no variables in HTML – heck I remember the day Mosaic introduced the „align“ tag to allow text to float around images.

So – I wrote my own HTML server. It was able to parse variables within the HTML context to allow something like

<H1>HELLO $firstname, welcome to $server.</H1>

My own server became the basis for the third largest online-services in Germany and it served well over half a million users. It supported chats, online-payments, travel reservations, e-mail and a lot more. But that was back in the nineties. A lot of things have happened since then. And I had to adapt.

So I went through the transitions, accepted CSS and all the different HTML versions, switched from plain “C” to PHP (for web development only), learned to love Javascript and Ajax, concentrated on the threats of SQL-Injection and other malicious attempts to hack sites – I accepted all the new and sometimes weird facts of web developing.

The new “Content security policy” is another mechanism I had to adapt to. Let me give you a brief description about CSP: If the Content-Security-Policy header is present in the server response, a compliant client enforces a more strict execution mode for JavaScript in order to prevent certain cross-site scripting attacks.

In other words: You can not include any CSS and/or Javascript within the HTML (or PHP) content of your web-applications.

 <a style=”color:red” href=”#” onclick=”doSomething()”>Clickme</a>

is no longer allowed. It includes inline-styles and inline-script. Styles should go into CSS files and any JavaScript script will only be executed if explicitly loaded from a trustworthy site.

Well – I know there are some of you out there who would argue, that this is bad style programming in the first place. And I agree. But I am a dinosaur. I am used to do stuff like that. It’s fast, it’s easy (especially in dynamically created pages) and it is flexible. But it is no longer feasible for modern and secure sites. So – I had to adapt.

secumundo_shotMy new Secumundo service is my first comprehensive web-environment supporting CSP. Well – not thoroughly – as I am still using and allowing inline-styles. But all those pesky little styles will be moved into appropriate CSS files with every new round of code cleaning (they call it re-factoring nowadays).

So – the 1000 dollar question is: Was it worth the work and the adjustment? I can’t really say. It sure feels good to know that simple xss-attacks won’t work anymore. That doesn’t mean of course, that I can rest easy. Attackers will try to find other ways to inject malicious stuff into the site or the database. It’s always a rat race and we will have to stay sharp to protect the integrity of our web environments. But the time for easy XSS is over with CSP. And that is important.

Leave a Reply

Your email address will not be published.