Filtering Out Cross-Site Scripting Attacks in Domino

The other day I saw a signature in a forum that said something along the lines of:

Just because you're not paranoid it doesn't mean somebody isn't out to get you.

No matter how desirable or what the outcome is of hacking your site, somebody will probably have a go at doing so. Even if there's nothing in it for them financially it can often be the challenge. Sometimes it might simply be to inform you of your site's shortcomings. Whatever the intention and no matter how important you think it is for your site or your customer's application to be completely secure it's well worth getting in there first and saving face and sleepless nights.

One major area of concern is Cross-Site Scripting (XSS) — users injecting nasty bits of executable code in to the content of a site.

XSS is of particular concern for any site where the user actually creates the content, as is often the case with Domino applications, and when there's little or no approval process. If you have a document with a rich text field on it (or any other fields for that matter) then you need the Form's WQS agent to make sure the content is safe to display to other unsuspecting users.

Stripping all HTML out of plain text fields is easy enough - a simple @ReplaceSubstring in the Input Translation does the trick. It gets trickier when you want to allow HTML in a rich text field (through the use of WYSIWYG editors) but want to filter out unwanted HTML.

So, I'm looking to see how people do this. What's the best way to strip all the nastiness out of a large rich text field and what exactly do we need to strip? In short — how do we avoid XSS issues with user-driven Domino content? Is a simple LotusScript Replace() call enough? If so what are the arrays of strings to look for?

Whatever I learn here I'll put in to a downloadable NSF for all to use. I'll also put it online so that the wannabe hackers amongst us can take their best shot at it and we can make sure we've got something truly secure.


    • avatar
    • Ferdy
    • Tue 6 Nov 2007 05:24 AM


    Interesting initiative. My approach is to "disable, unless". I essentially block all html tags except a few that I specifiy explicitly, i.e. p,u,li,b,i. This seems obvious, but I have seen designs that do things the other way around: filtering everything potentially dangerous, leading to large exclusion lists.

    Furthermore, it is of course important to disable script tags, along with every other syntax that allows the insertion of javascript, Flash, and the like.

    A final thing which comes to mind, that I have not checked yet, is to see if other representations of a tag are filtered correctly. For example, the script tag can be written as <script>, but also using escape chars, Unicode chars, or combinations of the above. Will your filter script block all variations?

    Oh, and do run the filter on all sorts of input, not just fields. Do not forget your querystrings for example.

    Not a perfect fit example, but hopefully some useful pointers?

    PS: In both PHP and .NET there are ready-made/built-in protection methods for these kind of things. Not to dismiss Domino, just to provide information :)

    • avatar
    • Jake Howlett
    • Tue 6 Nov 2007 05:39 AM

    That's what I was thinking Ferdy (also wishing Domino had this built in!) but I am stuck knowing where to start as I don't know the best methods to apply the rules. Can LotusScript's replace do it or do we need more powerful string manipulation methods in a Java agent instead I wonder...

  1. Remember that you need to strip javascript from an elements event attributes too. e.g. in p tags onmouseover attribute.

    Also some browsers allow img tags src attribute to contain javascript.

    • avatar
    • veer
    • Tue 6 Nov 2007 07:10 AM

    First thing would be to convert all "&" to "& amp;", "<" to "& lt ;" to ">" and so on.

    Have a document which will have the list of all allowable tags. Comeback and make another replace on the allowable tags. Only, instead of looking for tags look for a sequence of "& lt ; p & gt ;" for the paragraph tag.

    This should probably cover all malicious scripts.

    I don't see why Lotusscript can't handle this.

  2. Remember, attackers can also insert the malicious script using hex. The Wikipedia entry on this topic is pretty comprehensive.


    To do the filtering in LotusScript is definitely possible, but the approach would need to be layered.

  3. My only issue like this was that automated porn spammers kept making forum posts with links to their sites in them. I solved that problem by adding a "quarantine" field to the forum form, and having a WQS agent set the field to "True" if the string "http:" was found. Then I changed the view selection properties to exclude any documents with that field set to true. Finally, I set up a new view that ONLY showed documents flagged as having links, and set up a way for reviewers to clear the quarantine field if the document was legitimate. So documents without links showed up right away, legitimate documents showed up after a reviewer could look them over, and spam got flushed without the public seeing it at all.

    I did something similar for documents with script tags in them, but in practice, no one has ever attempted to include script in a forum post.

  4. @Jake

    If I were you, I'd contact Steve Castledine or Declan Lynch to see how they are handling it in their blogging templates.

    • avatar
    • Richard C
    • Tue 6 Nov 2007 12:32 PM

    @Sean Peters,

    I had a similar problem with the discussion forum that was put on a couple of websites - the owners insisted on not having people logging in .. I did warn them of spam. Before you know it, the spammers found the forums and spammed it all day long ...

    So, being a sneaky bloke, I added some spam detection code ...

    if content contains bb-code, spam_value = 99

    if content has one word, spam_value = 98

    if telephone has a value, but no numbers, spam_value = 97

    Suprisingly, the above three rules have eliminated all spam ...

    • avatar
    • Tufty
    • Tue 6 Nov 2007 12:51 PM

    When it comes to small fields, @ReplaceSubString is just fine. If you use a WYSIWYG editor on the web, any decent implementation should let you determine what HTML you allow. For example, TINYMCE has an init parameter called "invalid_elements" in which you can define a list of html tags to disallow -- there is also a parameter for "whitelisting" some tags too.

    With regards using vanilla Domino, what we really need is a decent regex implementation in Lotusscript or formula. Failing that, @ReplaceSubString doesn't do a bad job of scaling, and people like Mr. Robichaux have already done some exhaustive tests of the Java equivalents (if you don't want to use regex).

    • avatar
    • Jake Howlett
    • Tue 6 Nov 2007 04:20 PM

    Yeah, I might take a look at the blog templates and see how they do it. Although I'd be surprised if the comments area on them is a rich text field. And there's no need to do it on the blog documents as you wouldn't expect the blog owner to hack themselves.

    Tufty. The editors do allow you to strip out nasty HTML, but any junior hacker would know how to turn this off, if they didn't just disable the editor in the first place. The filtering has to happen server-side.


  5. I would do a 2 level approach:

    - run what comes back through jTidy (wrap it into Ls2J): result: parsable HTML.

    Use a XSLT transformation to wipe out what you don't want. Got some code somewhere...

    Ping me if u want it

    :-) stw

  6. in addition to Stephan's post you could also use the LS NotesSAXParser parser to process all of the tags and attribute values, rather than XSLT. It might be better for larger XML documents than @replacesubstring.

  7. I've posted a lss of a NotesSAXParser class on my website (link above) for those interested.

    • avatar
    • Tufty
    • Wed 7 Nov 2007 06:00 AM

    Re server-side filtering, no argument from me, but I always do both sides. To address Jake's other concern around JS, we don't allow content to be submitted if it isn't coming via the editor. This check isn't bulletproof, but it discourages the less persistent kiddies, and the server validation / translation sorts out the rest.

    (We don't deal with submissions so big that simple formula text manipulation can't deal with them).

    • avatar
    • yuval
    • Wed 7 Nov 2007 07:58 AM

    Download the domino wiki template from the open NTF and see how does he handling it.

    As mention in previous comment here, he is stripping everything and then check for allowed tags to re-add.

    nice and simple.

    • avatar
    • Jake Howlett
    • Wed 7 Nov 2007 08:25 AM

    It looks like the Wiki template uses a normal text field, rather than RT. Maybe there's something in there that will help, but I'm guessing the methods of applying the rules will be different.


    • avatar
    • Alastair Grant
    • Wed 7 Nov 2007 09:45 AM

    Some tips on :


    • avatar
    • mark
    • Thu 8 Nov 2007 10:28 AM

    There are lots of ways to encode a < character (see below) - which means there are a similar number of ways to encode _every_character. Also - some browsers accept keywords like Javascript when they contain other characters such as line feed. As you noted in another thread // will be interpreted as {Link} in some circumstances. So pattern matching can be very, very difficult

    At the same time I don't want to limit the vast majority of our users who just want to provide interesting looking material, including embedding movies & flash on occasion.

    Something I've been doing recently is aggressive removal of suspicious characters from short text fields and forcing documents with suspicious textarea fields to remain in draft mode until they're no longer suspicious - obviously that only works if the application has a draft mode for submissions. The checking is done in formula language in field translation events.

    There is one thing that's very important to watch out for but I don't really want to explain that in detail here!

    Codes for < - not sure what this will look like when submitted...

    "<": "<": "%3C": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "<": "x3c": "x3C": "u003c": "u003C"

    • avatar
    • mark
    • Thu 8 Nov 2007 10:29 AM

    Ha - thought so. (replace @ with &)

    "@lt": "@LT": "%3C": "@LT;": "@#60": "@#060": "@#0060": "@#00060": "@#000060": "@#0000060": "@#60;": "@#060;": "@#0060;": "@#00060;": "@#000060;": "@#0000060;": "@#x3c": "@#x03c": "@#x003c": "@#x0003c": "@#x00003c": "@#x000003c": "@#x3c;": "@#x03c;": "@#x003c;": "@#x0003c;": "@#x00003c;": "@#x000003c;": "@#X3c": "@#X03c": "@#X003c": "@#X0003c": "@#X00003c": "@#X000003c": "@#X3c;": "@#X03c;": "@#X003c;": "@#X0003c;": "@#X00003c;": "@#X000003c;": "@#x3C": "@#x03C": "@#x003C": "@#x0003C": "@#x00003C": "@#x000003C": "@#x3C;": "@#x03C;": "@#x003C;": "@#x0003C;": "@#x00003C;": "@#x000003C;": "@#X3C": "@#X03C": "@#X003C": "@#X0003C": "@#X00003C": "@#X000003C": "@#X3C;": "@#X03C;": "@#X003C;": "@#X0003C;": "@#X00003C;": "@#X000003C;": "x3c": "x3C": "u003c": "u003C"

    • avatar
    • mark
    • Thu 8 Nov 2007 10:42 AM

    Domino web access has a built in parser of HTML that I think is used to sanitise HTML emails before they are displayed in DWA. It would be fantastic to be able to use that for web applications too - anyone know how?

    • avatar
    • yuval
    • Thu 8 Nov 2007 11:04 AM

    Other then using UnformattedText and not getitemvalue in your WQS, What is difference between text and richtext?

    • avatar
    • Jake Howlett
    • Fri 9 Nov 2007 03:23 AM

    I knew DWA did something like this, as I'd found an article on a security advisor website talking about a vulnerability in DWA and the subsequent fix.

    I don't know much about DWA though (is that what used to be iNotes?). Is it hackable - can we get to the code?


    • avatar
    • Jas
    • Fri 9 Nov 2007 05:20 AM

    The DWA code is hackable to an extent. I have modified the DWA template in the past and have been successful to an extent.

    Good Luck hacking !!!

Your Comments


About This Page

Written by Jake Howlett on Tue 6 Nov 2007

Share This Page

# ( ) '


The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social

About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content