Hacking Domino: XSS-Safe Form - Can You Hack It?
After spending way longer than I'd hoped on it (what a can of worms!) I have a Domino form that I believe to be XSS-safe. So sure was I that I put a message on there about a (nominal) monetary reward for the first user to hack the form. Then I had a scary vision of loads of you doing it and me being out of pocket big time, so I took the message off. I'll put it back on after the "first pass" of testing in the wild.
I've tested the form against all the hacks listed here and it seemed to stand up to them well. I also tested it using the XSS Me Firefox plugin, which it passed with flying colours. Please only use XSS Me on your own local applications. DO NOT point it at codestore.net or any other website you don't own for that matter!
So, if you have some time to spare and fancy yourself as something of a hacker then see if you can get your own JavaScript code to run on this form.
Disclaimer: Last week Dragon Cotterill pointed out that I could be committing and offence by describing how to hack a webpage. I said I wouldn't lose sleep over it, but Chris Linfoot then suggested I should. Whatever your outlook I guess what I'm asking you to do is in fact to commit a criminal offence by attempting to hack the above webpage. If you don't feel comfortable doing so then I suggest you don't. Although it goes without saying that I won't press charges.
Skip to the 
You can subscribe to an individual
Commit an offence? Only if you get caught. :p
Not stopped me in the past. But then I have my own servers to hack against. So I guess I ought to complain to myself about my hacking. The law is too fuzzy. In actual fact it could be interpreted that "hacking" your own servers is illegal.
Nice stuff with the XSS-safe form Jake. I'll certainly give it a thorough going over and let you know what I find out.
Well your "computed" field fails at the first hurdle Link , but the xss stuff seems pretty sound. I'll try some of my harsh code when I get home (I'm in the office at the moment.)
That was never a hurdle though Dragon. The computed field is hackable, as you proved, but did you manage to run any JavaScript because of that? ;o)
The form is only equipped to prevent XSS attacks against it. I didn't say it would prevent users from changing the value of fields they shouldn't. That's not the aim here.
Yup. I realise that. Thats why I'm giving it my best shot. But unfortunately most of my best stuff is on my home machines. Wait till tonight and I'll see what I can do for you. (^_^)
Now, I'm not a lawyer, but since XSS is nothing new, are you really breaking any laws by just talking about things that are already pretty much common knowledge?
And if that doesn't work, just fall back on the words of the great Martin Luther King Jr.: "One has a moral responsibility to disobey unjust laws." :P
Plus, I thought the law would only be enforced if the "victim" decided he wanted it to be. For example, you could assault me in the street, but if I decided not to press charges then you'd get away with it. What do I know though...
@MD & Jake,
As the law stand at present, no you are not breaking the (UK) law by talking about it. However, as I said last week, there is an adjustment to the Police and Criminal Justice Act going through at the moment where talking about it *is* breaking the law.
Jake, true if the victim doesn't want to press charges then you get away with it... except for additional evidence. If you were filmed on CCTV doing the act then the victim doesn't need to press charges the CPS can do it automatically on the victim's behalf and indeed in some cases against the victim's wishes. In this case, if your provider gave log to the CPS to prove I (or others) willfully attacked your servers then the CPS could go ahead with a prosecution. Admitidly the likelyhood of such events is extremely remote, but the law allows for it.
Back to the task in hand. I think I can give your XSS protection a thumbs up. In fact I went back through your database to find old document which didn't have the protection, embedded the javascript, then tried standard Domino hacking to change the form type to "demos.xss.filtering" in an attempt to bypass your protection. That failed too.
Phew. I might put the $50 prize back in place now then ;o)
Hopefully that will offer the incentive for people to test it a little more aggressively. I get the impression people haven't done so thus far because - although they want or need the solution - they don't necessarily understand the underlying problem in the detail needed to fully test the solution itself. If that makes sense.
Changing the Form field only didn't work as I don't normally add the field called "Form" to the Form itself. Otherwise your hack might have worked. Although that would have been cheating as it's not what you're supposed to be testing. I admit the other forms in dext.nsf are still vulnerable. Once this form is fully tested and retro-fit it to *all* forms on this server (including codestore's).
Thanks for helping Dragon! If you get chance could you share your methods with me (offline if you prefer).
"as I don't normally add the field called "Form" to the Form itself."
You'll be surprised how many people do though. The moment a Form field is available, it can be changed. I have a whole load of different techniques that i have been gathering over the years for attacking Domino databases... so I can make sure my own are safe.
If I actually started telling people how to hack Domino directly, it could get very interesting, because there are a lot (and I mean a LOT) of websites which are very vulnerable. It's just that Domino is a little more obscure than most so hackers tend to stick with what they know (SQL Injection, PHP command etc.) which fail dismally on Domino. A different set of techniques is needed.
I'll drop you an email or three and we can start talking about compiling a list of attack vectors if you wish. I'm sure the Domino community would like it. I'm just worried that the Hacking community would like it even better.
Look forward to seeing your methods. I agree that sharing online would need to be considered carefully. Especially if it is (or will become) illegal to do so. Although this site it hosted in the US, so wouldn't that means it falls outside UK law?
Domino Security Reviews is maybe a niche market Rockall/yourself/us could tap in to!
Hmmmm.
Just spotted a rather nasty side effect. Try pasting some Formula code in there.
@if(Date1<Date2; "Younger"; "Older")
"Although this site it hosted in the US, so wouldn't that means it falls outside UK law?"
Can of worms dear chap.
You now need to be aware of (and comply with) US law because the US authorities can actually seize your equipment without telling you. There is a very nasty law passed over there called the DMCA which is the bane of many a hoster. A US competitor could ask your provider (via a nicely drafted solictor/lawyer) to pull the plug on your server. And you know what? You can't do anything about it. You have NO legal jurisdiction on US soil.
Thats why I run my own server (hosted with rackspace at Heathrow), to which they (RS) have no access to the onboard software. The databases are encrypted and replicated to my home server. Now UK law says that if requested by teh authorities I must hand over the encryption keys. Oh gee. I appear to have "forgotton" them. Guess it's jail time for me then.
Side effect being?
I find the best way to deal with the legal side of it all is ignorance ;o)
The "side-effect" is that the sanitiser (can it be called that?) strips everything after the < symbol in the belief that it is the start of an HTML tag.
I've been trying allsorts of ways to inject something executable in there. Most of the time my tags vanish. I've tried css style injection - it strips any url() style imports - All <div>s turn to <span>s (and I still can't embed things in them) any mention of the word script or any derivative vanishes into the aether and it strips a lot of things which are harmless, and all that is malicious. The only downside is that it errs on the side of caution. Hence the above @formula code cannot be used.
Ignorance is no defence in the eyes of the law. Of course the best option is not to fall foul of the law in the first place.
Ah. I see what you mean. In a "real world" situation I'd expect this server-side code to be used in conjunction with an client-side "editor", such as TinyMCE. In that case, if a formula were pasted in (or anything else with angle brackets), then it would be sent to the server as < or whatever and so the parser/sanitiser wouldn't treat it in the same way you're seeing.
If a plain field were being used to accept HTML then I'd expect that user to be of the "power user" type and to know not to type in an unclosed < without it causing problems.
The "sanitiser" works on a whitelist of allowed tags/attributes. There are harmless tags removed, but when a user is creating content you really need to hammer down what they can use. For example, I only usually allow h4, h5 and h6. H1/2/3 are usually reserved for the actual design of the page in which their content will sit.
Weird, but I had your RSS Feed on my iGoogle home page. Starting this morning (~10AM US) everytime I loaded my iGoogle home page I was getting endless alerts that said "XSS" only in IE. I didn't have time to find the source, but as soon as I removed your feed the problem went away.
Have the same problem as Neil R describes.
Weird indeed guys.
You mean the RSS feed from DEXT.nsf, right?
The default title of documents people create when testing the XSS form is <script>alert('XSS')</script>. The stored value doesn't contain < or > though it just contains < and >. It is NOT stored as HTML. The fact that Google's feed reader renders it as HTML is worrying, to say the least.
Does it just happen on iGoogle homepage or in the Google Reader too? I looked in both (using Ie6) and can't see the problem. I just see the "html" rendered as text, as I'd expect it to be.
Could one of you send a screen grab of the problem? I just can't reproduce it. Even if I add the dext feed on to the google homepage as an feed in its own right. Tried in Ie6 and 7.
It's an javascript alert saying "XSS". I think it's on this channel:
Link
The only thing to get around it is to shutdown the IE-task.
In my case it applies to IE7.
/l
Aha. I see what you mean now. I managed to reproduce it and I too had to terminate IE.
If you look at this post Link you'll see an example of a naughty HTML IMG tag about 2/3 the way down. This isn't stored as HTML and the XML for the feed doesn't contain any HTML for an image with an expression used for the style (IE only).
My guess is that Google is "encoding" the HTML for transit and then "decoding" it for display. The img tag in my example must somehow get decoded as HTML as they haven't double-encoded the & of the < that is stored. Only a guess though. I'd have to look in to it more but can't afford the time as I don't see it as an issue with my content.
It is worrying though! If I were you I wouldn't use feeds on iGoogle as that seems like a massive hole in the security to me. If you subscribe to this site's comment feed then you're open to attack by any of the readers who post, as they too could execute code on your browser (and steal your google session!?) by posting naughty HTML on my site. Although I protect the site and readers by replacing any < with a < it looks like Google is converting them back again.
I might look in to this some more if I get chance...
Jake
Interesting.... [verybigevilgrin]