Security concerns with the HTML Calculated Column

The HTML Calculated Column is certainly my most popular technique. It is mainly used to color code calendars, but its scope is much larger than that. The technique is especially useful when you… actually do calculations, for example in these progress bars with color gradients. You can see some other examples in this live demo, and in many other live demos and posts in this blog. Any html tag could be added using this technique.

For the record, the original post is outdated (and so are the hundreds of articles that copied it). You’ll need to read the more recent ones for updates on SP 2007 and SP 2010.

Did I just say any html tag? mmm… so how about script tags? Does it mean that a user could push a malicious script to your computer? Well, the short answer is yes. This is something I have already discussed in the past, in private or in forums, but I never posted a detailed explanation on this blog – until today.

The question was actually raised in a recent project I worked on. I accidentally stumbled upon an experiment that the IT team ran behind my back (well, to be fair, maybe they just didn’t know I was the author of the code). Let me tell you the story.

For the sake of simplicity, I’ll use these short snippets instead of the actual code:

  • our malicious script: alert(“Boo!”)
    The script simply opens a pop-up that says Boo!, be prepared to be scared…
  • our calculated column: =”<div style=’font-weight:bold;’>”&Title&”</div>”
    This will render the Title in bold. It is actually the example used in the original post from September 2008.

For example if Title is Chandler, the value of the calculated column will be
“<div style=’font-weight:bold;’>Chandler</div>”
and the page will render it as Chandler.

Now, here is what the IT team tested: in the Title column, they entered:
<script>alert(“Boo!”);</script>

In this case, the calculated column returns:
“<div style=’font-weight:bold;’><script>alert(“Boo!”);</script></div>”

What happens when you use my technique? You might expect to get a “Boo!” alert, but in practice… nothing! The code simply doesn’t execute. This is due to the technique I use in the HTML Calculated Column: script tags are added (just like other tags), but do not run.

I guess IT was satisfied with the test, as they agreed to leave my code on the page.

What they overlooked is that there are actually other ways than script tags to add code to the page. Imagine for example that you enter the following string in the Title field:
<img src=”/_layouts/images/blank.gif” onload=”alert(‘Boo!’)” />

This time, when you use my technique the above code loads the image (blank.gif), and once it’s loaded it triggers the code in the onload event. Wicked!

As I said, there’s nothing new here. I even have a blog post from 2009 that explains it:
https://blog.pathtosharepoint.com/2009/02/26/using-calculated-columns-to-write-scripts/

So is there really a security risk here? In theory, yes. In practice, only people who have contributor access will be able to inject code, so in collaborative environments the risk should be very low. Also, you’ll be very limited in the amount of code you can put (a text column like Title only accepts up to 255 characters). However, I would advise against using the HTML Calculated Column in open environments, for example if anonymous users have write access or if your list is mail enabled (and by the way in such cases you’ll have other concerns, not just with the HTML Calculated Column).

In the next few weeks, I’ll publish two techniques that avoid the security risk described in this post.

7 thoughts on “Security concerns with the HTML Calculated Column

  1. Hi Christophe,

    As ever an interesting ‘find’ that may well come in handy at some point in my work. Thanks for posting the information.

    Regards,

    David

  2. We came across a very similar issue with our Custom Field Type version of your HTMLCC. In the end the best resolution was to warn the users when using text/note fields.

    It was an exceedingly unpleasant realisation to make just a few hours after the initial release!

      • I totally forgot that you flagged this issue to us! Sorry about that and thanks again.

        I should give Andrey Markeev a mention too, since he flagged it separately, at pretty much the same time.

  3. Pingback: Trick or Treat? Text to html, the wicked no-code way (Part II) « Path to SharePoint

  4. Pingback: HTML Calculated Column + Client-Side Rendering | Path to SharePoint

Comments are closed.