Tuesday, May 8, 2007


I just read 29 Happiness Hacks to Feel Better Now, and the tip I really liked is tip Eighteen:

Hack Eighteen: Silence

Listen to the quiet. Turn off every sound possible so you can actually hear what silence sounds like. It might require a drive to a more secluded location, or turning off appliances in your house but near absolute silence is so rare it is amazing how beautiful it is when you can hear it.

However it can be so hard to find a silent place nowadays. In my room I always hear music of neighbours (not that hard that it is annoying, but i still hear it), my computer, and several other small sounds.

Even when I go for a walk outside the city it still hard to get silence. Recently I took a walk along the Paterswoldse Meer, and though it's nice and relatively quiet there at night, you still hear the cars from the nearby highway.

I remember skiing down a closed black piste with a friend of mine, and since it was closed (meaning you're not insured if you get an accident) and black (meaning it's comparatively hard) there was no-one there. And as the piste went around a mountain, at some point you could see neither hear the other pistes. Shocked by the silence I first comfirmed that "Ezel" was indeed the mayor of "Wezel".

We decided to lie down for a moment and to listen to the silence. And it was right there I discovered I haven't heared silence for a long time. This was really a weird discovery, because you're in enough "silent" situations; when in the library, while making an exam, etc. However, it's only when you hear perfect silence you realise you actually never experience real silence.

When was the last time you experienced silence?

Monday, May 7, 2007

Jonathan Swift on Security Theater

Recently I stumbled upon a passage in Gulliver's Travels where Gulliver visits the Academy of Projectors. In this Academy, projectors invent great projects, however there seem to be some practical downsides (aka, the plans don't work). After visiting a professor extracting sunbeams out of cucumbers, a professor who tried to restore the original food from human excrements, a professor who decided it was better to build buildings top-down, since that was how spiders built them and several others, he came into the political department. Here he met another professor:

Another professor showed me a large paper of instructions for discovering plots and conspiracies against the government. He advised great statesmen to examine into the diet of all suspected persons; their times of eating; upon which side they lay in bed; with which hand they wipe their posteriors; take a strict view of their excrements, and, from the colour, the odour, the taste, the consistence, the crudeness or maturity of digestion, form a judgment of their thoughts and designs; because men are never so serious, thoughtful, and intent, as when they are at stool, which he found by frequent experiment; for, in such conjunctures, when he used, merely as a trial, to consider which was the best way of murdering the king, his ordure would have a tincture of green; but quite different, when he thought only of raising an insurrection, or burning the metropolis.

Which reminded me of a lot of posts on Security Theater and profiling in the aviation industry which I read on Schneiers blog recently, however, it reminded me the most on the report of the development of a new technology which registers wether someone on board of a plane is a terrorist by watching how they act. Maybe they should put technology in the toilets instead ;). I really like how a 300-year old satire still is so uptodate.

Saturday, April 14, 2007

Month of Myspace Bugs, Yuss!

After the month of the browser bugs, the month of the kernel bugs, the month of the apple bugs and the month of the php bugs this month is the month of the myspace bugs. While this initiave takes itself a bit less serious and also parodies the other month-of's it's still interesting. They show a lot of nice application level exploits and explain wether they are hard or not and why. So check it out if you're into XSS, phishing, etc. Also make sure you check their recent post on operational security

Thursday, April 12, 2007

XSS defense in depth measures

Last night i was thinking about defense in depth against XSS. It is not always an option to rewrite big parts of an application (since it's a commercial package for instance). So I am searching for methods which could be implemented easily using for instance one (server-side) include at the start of each page. These are the options I thought of. If anyone has additional defense in depth methods I'd really like to hear.

  1. Referrer checking
    If some page should only be called from your own site, you shouldn't allow other sites. Of course this is no real protection since people use (stupid) firewalls which block the referrer. Also, it does not stop attacks from the same site (using XSS for example).
  2. Disallow certain characters in parameters
    This might not be able for every site but if it is it might help. You can of course forbid certain characters like <. This might not prevent all attacks but it might keep a few out of the door. Of course this is only possible if your site doesn't need to accept less than signs.
  3. HTTPOnly cookies
    While this doesn't help preventing XSS it helps against one of the standard exploits. If you use HTTPOnly cookies MSIE and Firefox 3 users can't have their cookies (=sessions) stolen. This prevents a remote takeover from a session. However, one can still put a script in the payload which already does nasty stuff, or hijack the session using some sort of XSS shell.
  4. Advanced referrrer checking
    You could improve on referrer checking by defining a graph of pages. In this graph you'd need to mention all allowed steps from one page to the next, and only allow those. Of course this is rather labour intensive. Alternatively you could `record' steps taken for a month or so and base your graph upon that.
  5. Parameter checking
    If the parameters are well-defined you could add an extra kind of software firewall in front off the application which checks wether the values contain ``valid'' values (for instance, wether id's are integers). Again this is labour intensive, and again it might be possible to automate this by recording currently used values and doing some smart heuristics on them.
  6. Crippling Javascript
    This won't help against XSS either, but like HTTPOnly cookies it will reduce the impact. For instance you could overwrite the XMLHttpRequest object if you're not using it, so it can't be used in any exploit
So now it's your turn, do you have any simple methods which can improve the security? (I'm aware that the only solution is to code secure applications)

Friday, January 12, 2007

XSS in Blogspot

Yesterday RSnake posted about a ``XSS'' hole in Blogger. I don't really think it's XSS if you can only inject on your own blog, but whatever. It didn't sound too interesting that it was safari-only either, so I decided to extend the exploit to MSIE and Firefox, so here it is:


For the exploit I use that Firefox actually parses comments correctly and that MSIE has support for conditional comments.

Kudos to Jose Avila for the original exploit.

Friday, January 5, 2007

Month of the Apple Bugs

I have a few hippie friends who use a Mac. They used to claim their OS was safer, but now they can't anymore ;). It's the Month of the Apple Bugs. But since I like my RSS reader I decided to make a feed, enjoy!

Friday, December 22, 2006

Why don't people take XSS seriously?

Recently RSnake wrote an article on the seriousness of XSS, because a lot of people are asking him what the worst thing is XSS can do. He goes on about how it can be used to do sophisticated cross-domain exponential attacks, but he doesn't touch too much upon the underlying problem. Why are people asking this question?

In my experience people don't see XSS as a problem. This is since the people who should care about it are system administrators and/or programmers. They're the same people who think Linux is safe because each user can only fuck up his own files. And this is the fundamental problem! Sure, a user can only fuck up his own files, but those are the only important files to the user. The user couldn't care less if the systems emacs binary becomes crippled. Because It is easy to replace everything in the system, but not the user files.

It's the same with XSS versus SQL injection. SQL injection is seen as a serious problem since you can attack the system. But you don't need to attack the system, attacking the client is enough. Let's say I want to hack a bank, because of a lack of money. Of course if I could do SQL injection (let's say this bank uses a mysql database ;) ) and change some of the amounts and end up with a lot more money.

However, I don't really need 5 million euro's and I'll settle for a few thousand. If I can just hack one account and make one user do a deposit to my account, wouldn't that be enough? Similarly, if I'm a student and I want to change my grades, I only need to hack the teachers account. And these are typically the kind of attacks most easily done by XSS. You only need to find one XSS exploit somewhere on the site and then need to social engineer someone to click on a link (which doesn't even have to be to the site, but can be a redirect) or if you're lucky you can even use persistent XSS. And almost all sites I know of are full of XSS, while fewer and fewer have SQL injection leaks.

So what can you do with XSS? Anything the person you are hacking can do.