Cupfighter.net

By Dan Kaminsky (@DaKaMi)

In his talk Dan addressed why web security is hard, but he also tries to to come up with solutions.

One of the solutions explorer is referrer checking. If you think you cannot use them because they can be spoofed? No, referrer tags have been pretty much un-spoofable, however, not each and every call to a website contains a referrer header. One of the problems is that security solutions such as Symatec Internet Security strip referrer headers.

Since we cannot rely on the server site to detect this, maybe we should turst the client. Even if common lore says: “thou shall not trust the browser”.

It appears that the browser is the only one that can actually detect CSRF and XSS. Is it possible for the interpreter to commit suicide if it sees an “evil” request. By using the very definition of javascript to abort the interpreter by keeping it hung up in the first javascript block on the page.

Does this stop XSRF, not because XSRF does not require a return apply, however, the server could actually send a bit of javascript back on the request. It turns out the object.send() method can be overloaded to insert an extra header. So what can we do to use this extra header? There are a lot of methods that don’t work, but what does work?

Unfortunately there does not seem to be a session/domain context variable where we can store our magic cookie.

Another problem Dan tried to address was input validation.

Using regular expressions to do input validation is, the reasons the ha.ckers.org cheatsheet for XSS works is because regular expressions don’t.

Parameterization, Pascal Strings and Tain Checking don’t work.

Mime seems to provide the answer here: Randomzied closing tags, dubbed Tree Locking by Dan. There is however a risk, because of the xml.findAll() method that can be made to return any tag, regardless of which tag it was embedded in.

JSON doesn’t even use named closing tags. One could use comments, but these are not supported by JSON. But, by embedding the data into a base64 string because it cannot be predictable guessed.

It doesn’t just work just work for JSON, it works for XML, SLQ and LDAP as well. It actually adds back type safety in the browser.

Unfortunately Unicode bytes back.0XC0 0×80 is an over wide null character. It is interprited by the Microsoft Crypto API.

Base64 encoding will actually neutralize these unicode attacks. Untimely this code needs to go into the database engines. E.g with a special encapsulation routine.