Mantis Bug Tracker

Work is well underway towards modernising the user interface of MantisBT. The first step being taken towards this goal is to ensure that MantisBT 1.3.x produces XHTML strict page output. Bug #12545 tracks progress towards removing deprecated HTML 4 (and earlier) features from MantisBT page output and replacing them with modern equivalents. For instance, the old <font>, <b>, <u>, <i>, etc elements of HTML 4 are very much deprecated. This bug report also tracks progress towards ensuring that MantisBT page outputs produce well formed XHTML (so that pages can be parsed using XML tools).

Note that the 1.3.x branch now uses the application/xhtml+xml MIME type where the browser supports rendering XML documents. The XML specifications state that if malformed XML is detected during the parsing of an XML document, a critical error should be produced and the parsing immediately terminated. This will make it much easier for errors in the output XHTML markup to be detected and fixed (both in the core and within plugins).

User interface breakages are expected in the 1.3.x branch while the user interface is being modernised. We’re trying to create semantic output from MantisBT complete with class and ID attributes to allow for precise CSS styling of page outputs. Ultimately this will allow us to remove the dedicated “print” pages from MantisBT and instead just use separate on-screen and print stylesheets. This is easier for users, easier for MantisBT developers, easier for plugin authors and less prone to errors and discrepancies.

If you would like to assist with modernising the MantisBT interface we’d very much like to hear from you. Experience with XHTML and CSS are required – as well as a good understanding of how to write semantic and meaningful markup. There is a lot of work to complete and it generally has to be performed by hand on a page-by-page basis.

In November of 2010 I provided a progress update on work performed to ensure MantisBT 1.3.x fully supports the X-Content-Security-Policy feature of Firefox 4. At the time, MantisBT was only providing partial support of X-Content-Security-Policy due to a large amount of inline JavaScript contained within pages MantisBT was returning to clients. I am pleased to report that as of late December 2010, MantisBT no longer produces inline JavaScript in page outputs. This means that the following HTML output is no longer permitted in any part of MantisBT’s XHTML page output: onchange=”…” attributes, <script…>some_code();</script> and <a href=”javascript:some_code()”…

Browsers supporting X-Content-Security-Policy will not be at risk of having malicious JavaScript code execute as a result of Cross Site Scripting (XSS) vulnerabilities discovered in MantisBT core or any MantisBT plugins. Attackers looking to exploit XSS vulnerabilities are therefore severely restricted in what they can accomplish. For the most part, a XSS vulnerability in MantisBT will only lead to partial page defacements – an annoyance rather than a major security concern. The remaining risk is that attackers could trick a user into clicking on an innocent looking hyperlink to launch an external web site that aims to attack their browser. To counter this risk it is recommended that you use NoScript (or similar) to control which domains have the ability to execute JavaScript within your browser. Because MantisBT 1.2.0 (since July 2009) and all later versions fully implement Cross Site Request Forgery (CSRF) the malicious hyperlinks placed in a hypothetical XSS attack on MantisBT can not be used to maliciously perform actions on behalf of the user (even if the user has clicked on a maliciously placed hyperlink).

There is a some work remaining on the X-Content-Security-Policy implementation (and by extension, the implementation of X-Frame-Options) to make it easier for plugin developers to allow remote scripts on other domains to be executed. Further to that point we need to make it easier for users to allow their MantisBT instance to be loaded within an iframe from a list of domains they trust for that purpose.

In my November 2010 progress update I mentioned that MantisBT is one of very few web applications implementing X-Content-Security-Policy. This is still the case and we hope that other web application developers (and browser vendors) will jump on the bandwagon to provide this additional security layer to their users.

MantisBT 1.2.1 introduced anti-clickjacking features in the form of both X-Content-Security Policy and X-Frame-Options HTTP headers. SHODAN is a search engine that allows the searching of HTTP server fingerprints obtained from internet facing hosts. If we search for X-Frame-Options in SHODAN’s database, just over 7000 results are returned. Performing the same check for the X-Content-Security-Policy header returns just over 90 results. Interestingly, the great majority of search results for X-Content-Security-Policy are MantisBT installations. It therefore appears that other web applications (and websites) have yet to implement X-Content-Security-Policy in readiness for the stable release of Firefox 4.

As Firefox 4 has been pushed back to early 2011 we have more time to finish off the implementation of X-Content-Security-Policy within MantisBT. A fair amount of progress has already been achieved towards removing inline JavaScript from within MantisBT pages. Once this process is complete we can switch on CSP’s ability to block inline JavaScript from being executed. This will severely limit the impact of XSS vulnerabilities on MantisBT. At the same time there is also a push towards reimplementing the output handling of MantisBT to use a templating system that automatically escapes user supplied data before printing it into HTML output. This approach would help prevent mistakes from occurring, especially with respect to third party plugins that may not undergo as much scrutiny as the MantisBT core.