Following on from yesterday's discussion about users editing hidden fields I want to discuss another danger and the reason I was thinking about the problem in the first place.
Let's forget about the consequence of the actual change to the field for a moment. Even if changing it has no adverse effect on the system itself there is another, potentially dangerous, problem. Cross-Site Scripting or XSS.
Maybe you've heard of XSS but dismissed it as something not worthy of attention. You really shouldn't dismiss it too easily though. What if I were to say I could easily use XSS to login to your server as an administrator or any other user for that matter!? It's really easy to do!!
Let's assume you have a form that allows user-entered HTML. This can be either because you want them to (TinyMCE on top of a Rich Text field, for example) or because you don't strip HTML from fields where you don't want or expect it (the Title for example). Either way, if the user can enter HTML, they can then have a good go at hacking you.
As an example imagine a user enters the following HTML in to a field:
Or even the following (which works in IE6) seemingly harmless-looking HTML:
If either of the above (or the 1,000s of similar hacks) aren't properly filtered out then you could be in trouble!
If the above code was stored in a document and you opened it while logged in you'd reveal your authentication cookie's value to the hacker. They could also see your IP address and the URL you were logged in to.
To prove it works I actually tested it out. In the example above the form on the other server looked like this:
Note that the user would only see this if the <img> hack was used from two I showed above. If the <script> hack was used the user wouldn't see this and would be completely unaware of the problem.
Even if they are aware there's not much they can do. Even if they panic and close the browser it's too late. Although closing the browser logs them off, the session still exists on the server and if the hacker reproduces a cookie called DomAuthSessId with the value they now know the hacker will be logged in as you! Your only hope is that the user has the wherewithal to ring and tell somebody who can quit the HTTP task on the server and not start it again until they've fixed the huge security hole.
To test it out I made it so that the LogCookie Form (see the above screenshot) would run a WebQueryOpen agent to email me the cookie value and the URL they were logged in to. Then all I did was:
- [Hacker]: Post one of the above snippets of HTML to a website where I knew (or hoped if I were an actual hacker) there was no filtering.
- [User]: Visit the site while logged in as an Administrator who knows nothing of the attack.
- [Hacker]: Wait at the other end for the email(s) to arrive.
- [Hacker]: Take one of the emails and click the link in it which points to the URL (HTTP_Referer) of the hacked page.
- The link opens Firefox at the problem Domino website. Imagine the first thing you see is a login screen (like below).
- Even if I don't have a login for the site it doesn't matter. I can now bypass the login by adding a cookie (see above) using the Web Developer plugin.
- All I need to do is add a cookie called DomAuthSessId (case sensitive!) with the same value as the one that was emailed to me, like so, being sure to tick "Session cookie":
- After pressing OK all I need to do is refresh the page and it will send the cookie to the server, which will then think I'm logged in as the user who just opened the hacked page. Instead of seeing the login page I'll see the application itself and be able to do everything that user is allowed to (including changing their password!).
- Even if the user has since logged out it doesn't matter, just as long as the hacker receives the email and creates the cookie before the session times-out on the server!
Scarily easy! Note that I tested this from different servers and PCs. The server logging the cookie was different to the one hacked. The PC I logged in to with the stolen cookie was not the one I used to log in to when I visited the bad page and, so, had a different IP address. This is as real world a test as I could conjure up. Real enough to prove it's possible.
So then. This isn't one of my digs at Domino. This is a problem that affects all web server environments that user cookie-based authentication. I'm only showing how easy it is in the hope it will make you sit up and take notice of how serious XSS vulnerabilities can be.