Automatic Cross Site Scripting detection
Ariadne has always had a focus on security-by-default and in-depth security. It has been immune to SQL injection attacks from day one, because its internal query language has no capability to modify anything. It has had a capabilities-based authentication system which guards against authenticated users gaining more access than they should. Even programmers who build applications or sites in Ariadne cannot bypass the security system, since their PHP code is sandboxed.
All this security is on by default, without the need to configure anything. The only major attack vector that a programmer in Ariadne needed to keep track of his- or herself has been Cross Site Scripting or XSS. Untill now.
The latest release of Ariadne, 2.7.7, automatically prevents hackers abusing poorly written code.
A typical XSS attack abuses a form on a webpage where input from the form is included in the resulting page after submitting the form without change. This allows the attacker to add his own html code to this page and he can hide this in a hyperlink so the user never has to see the form or press submit, just follow a link, e.g:
http://www.ariadne-cms.org/docs/search/?searchstring=xss%22%3E%3CH1%3EXSS%3C%2FH1%3E
When the input variable searchstring is not filtered and/or changed before outputting it, the normal layout of the page will be changed and an extra H1 heading saying 'XSS' will be added.
The problem with XSS attacks is that it is very easy for a programmer to forget to filter an input. And you won't know about it untill someone abuses it, because for allmost all normal uses the site or application works fine. The harm that an XSS attack can do also seems rather limited, untill you see the attack as part of a larger attack, like one last year where an XSS attack was used to gain the users trust while presenting them with a spoofed website.
Ariadne 2.7.7. automatically detects a potential XSS attack and will buffer the output and check that the XSS attack did not succeed before sending the output to the client. If it finds the malformed input without change in the output, Ariadne assumes its a potential XSS attack and returns an error page 'Bad request'.
As a programmer you have the option to change this behaviour by writing your own anti-xss handler, called 'user.xss.html'. It will be called whenever Ariadne thinks something fishy is going on, with the following arguments:
arRequestedArgs |
All the original arguments to this request. |
arRequestedTemplate |
The original template requested. |
arSuspectedArgs |
The arguments containing suspected values. |
arResultOutput |
The full html (or other) output which would otherwise be sent. |
So now you have the option to either simply pass on the output anyway, making you vulnerable to an XSS attack, although you could log the problem and check it later. Or you could try to filter the output again or create your own error page.
Whatever you choose, it is now a known problem and by default the xss attack will fail.
This is ofcourse a rather brute force kind of protection, it is not designed to be depended upon. As always the programmer is responsible for parsing input correctly. Ariadne has an alternative system to make this easy, called 'tainting'. Whenever you request input variables using ar::getvar() or ar('http')->getvar() they are automatically tainted. If you echo them or otherwise convert them to strings, they will be filtered automatically. This is a behaviour which is easily controlled on variable by variable basis, using the ar::untaint() and ar::taint() methods. The automatic XSS protection has been added only as a last line of defense and as a blanket protection for legacy code.
PS. The limitation of the detection system is that it only detects input that has been included as-is in the output. If any attempt at filtering or rewriting the input has been made, but that attempt is incomplete, than the XSS attack will succeed without detection. This means that it is up to you as a programmer to get filtering variables right. PHP has good support for filtering, see filter_var for one option, but when you allow some kinds of html in your input, including things like bb-code, then it is up to you to get the filtering right.
PPS. One other thing, the detection and prevention is limited to output with a text/* mimetype.