So this morning I get an email from the US Department of Defence. Seems one of our computers was being used as a launching pad to exploit some DOD systems. Found the computer, pulled it off the net and proceeded to do a post-mortem. My co-workers were offering all kinds of suggestions about how to go about this, what to look for, etc. All wrong of course. I've done this before. Found the payload in about 3 minutes. Hidden away in "/var/tmp/.. " - note the space at the end. Clever yes, but this is an old trick. I pulled off the payload files to have a look. Lessee, a streaming media server, thirty different denial of service attack generators, and one old root kit from 2001. 

My co-workers were instantly preparing to format the disk. Rootkit, bad. Re-format. Nah, these guys weren't after root, and they didn't get it. They got what they were after - another zombie to join their network of DoS slaves. If they really wanted to get root access, they would've used a modern rootkit.  The poor kid who uses this box has his entire PhD on it, and the last thing I want to do is erase his life's work. No need to. Just reset the password, get rid of the zombie net and put the machine back in service. 

Incidentally, this is just one of a growing number of incidents coming out of Romania. There were Romanian 'fingerprints' all over this particular exploit. FYI. In year's past we've seen involvement by Germany, Russia, China and others. This one is Romanian for what it's worth. Somebody there is funding an effort (or being funded) to stage denial of service attacks on a global scale. Interesting. 

I've been working on all kinds of different ways to completely stop XSS (and potentially the related CSRF) and provide a much better authentication framework for web applications. 

The problem:

The HTTP protocol is completely stateless. On the server side each and very page access starts with zero knowledge of who is at the other end of the connection. In order to provide what were once considered 'sessions' in the pre-web computing days, the client is able to store a 'cookie' which is sent from the server, which is sent to every page within that domain. The server can look at this cookie and use it to bind a particular person who has presumably passed authentication so they don't have to re-authenticate.

But cookie storage has some serious flaws. If somebody who isn't the specified logged-in person can read the cookie, they can become that person. IP address checks can help to provide extra verification but in a world containing proxies this information can be spoofed.

Cross Site Scripting is a method whereby a malicious person who is allowed to post HTML on a page can inject javascript code which is then executed on a registered user's session and the cookie is leaked or sent elsewhere - allowing the malicious person to impersonate the registered person.

A possible solution:

I'm still working out the details so please let me know if this is flawed, but I think I've got a way to prevent XSS and still allow registered members to post full HTML, CSS, whatever - including javascript.  It relies on the fact that cookies are stored and used per-domain. Different domains are unable to see cookies from another domain. 

We'll also assume SSL connections since anything else can leak everything (cookies, passwords, everything) to a port sniffer.

We'll start with a normal website at https://example.com - which we'll assume is a multi-user website where XSS could be a problem. If somebody on this site can inject javascript onto a page, they can steal the cookies of a logged-in user. There are hundreds of ways to do this that are beyond the scope of this discussion.

But we'll also create another domain - say https://private.example.com - which processes logins and does not serve content. This will have a different cookie than example.com. Perhaps we'll let it serve the website banner image just so that it is accessed on every page of the site. Since there is no active content allowed, it is immune to XSS eploits.

It is allowed to process login requests and send cookies, and one image. That's it. 

What this means from an attacker's viewpoint is that he/she now needs to steal two cookies to impersonate somebody else.  It may be easy to steal the cookie on the main site, but there's no way to get at the cookies for the private.example.com site since it isn't allowed to host active content.

The main site uses out-of-band methods (not involving HTTP) to communicate between the two domains and establish that the session is valid and authenticated. They're both hosted in the same place after all. It can check a file or database to see that the logged in session was authenticated by the other site. Both keys (cookies) have to match or the authentication is denied.

Anybody see a flaw in this? Granted I still haven't thought it through completely and haven't yet tested it, but I don't see any glaring problems on the surface. Some variation of this concept will probably work and both prevent XSS as well as provide a better way of doing web authentication that is much more resistant to intrusion.   

Again assuming https to prevent snooping, the only way I can see to steal both cookies and impersonate a logged-in user is to have access to the target person's desktop and browser. 

It also allows a site to completely separate the authentication mechanism from the content server allowing the authentication code to be small, simple, self-contained, and verifiable.