Mindoo Blog - Cutting edge technologies - About Java, Lotus Notes and iPhone

• • Lotus Notes 9
  • Webdev
  • XPages

  XSS security fix in Domino R9 HTTP server may break existing web applications

  Karsten Lehmann  3 June 2013 21:56:04

  Last week we noticed that two of our web applications did not work as expected after upgrading our servers to Domino R9.
  We tracked down the issue and found the problem: In one REST API call, we have a query string parameter that contains a Domino fulltext query to filter the entries of a Notes view.
  Domino now reported that the query syntax was wrong. The same code had worked in 8.5.3.
  
  The reason is that the Domino R9 HTTP server contains a security fix to prevent applications from being vulnerable to cross site scripting attacks (XSS).
  IBM picked the brute force solution here: All occurences of "<" and ">" in the url automatically get replaced. "<" becomes "-lt" and ">" becomes "-gt".
  
  Let's take the following simple XPage as an example:
  
  <?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
Content of query parameter param1:<xp:br></xp:br>
        <xp:inputTextarea id="inputTextarea1"
                style="width:600.0px;height:200.0px" value="#{javascript:param.param1}">
        </xp:inputTextarea>
</xp:view>
  
  When I call this XPage with a URL like
  
  http://localhost/urltest.nsf/params.xsp?param1=[date]%3E%3D01.01.2008%20AND%20[date]%3C%3D31.12.2008
  
  we get the following result in Domino 8.5.3:
  
  Content of query parameter param1:
[date]>=01.01.2008 AND [date]<=31.12.2008
  
  With Domino R9, we get this instead:
  
  Content of query parameter param1:
[date]-gt=01.01.2008 AND [date]-lt=31.12.2008
  
  You can see that the operators "<" and ">" got replaced and the ft query is no longer valid.
  
  The big surprise here was that the Domino server even replaces these characters if they are correctly escaped as hex codes like %3C and %3E.
  This way, IBM wants to prevent web developers from writing the query string content as part of a HTML page without properly escaping "dangerous" characters, e.g. to tell the user that a passed search query
  
  "<script type='text/javascript'>alert('it works!');</script>"
  
  is not understandable, which would immediately execute the script block in the browser and could cause a lot worse effects than just a simple alert box.
  
  And this is not a theoretical threat. It has been done before.
  
  Workarounds / solutions
  We asked IBM if the current implementation, which also replaces the hex encoded characters, is working as designed and they confirmed. They said they had seen too many XSS attacks in different areas of the product and customer applications, so they picked the "big hammer" as a solution. It's unlikely that this behavior will change anytime soon, but if somebody has a better idea, they are open for discussion.
  
  Here are a few things that you might try to make your application work again, if you've got the same issues:
  
  1. Change the URL parameters
  In our sample, we could change the query parameters so that we only pass the min and max dates as query string arguments. The whole FT query can then get computed on the server side. Depending on the kind of query string parameter, replacing "-lt" and "-gt" with the correct values also could be an option. But this might lead into trouble if someone wants to send "-lt" or "-gt" as part of a query string parameter on purpose.
  
  2. Use POST instead of GET
  If you put the ft query in the payload of a POST request, the parameters do not get replaced.
  
  3. Disable the XSS fix (not recommended)
  IBM dev told us that the XSS security fix can be disabled by setting the Notes.ini variable
  
  HTTP_QUERY_STRING_SCRUB=0
  
  Of course, then the server will be more vulnerable to XSS attacks. So use it at your own risk and try to find a better solution.
  
  

  • Comments [2]