Fix XSS vulnerability for sidebar

[mshtawythug]

An XSS attack is possible using the trestle:sidebar cookie value.

Proof of concept is setting the cookie value to <IMG """><SCRIPT>alert("XSS")</SCRIPT>"\>

Performance or security impact

Client-side scripts are used extensively by modern web applications. They perform from simple functions (such as the formatting of text) up to full manipulation of client-side data and Operating System interaction.

Cross Site Scripting (XSS) allows clients to inject scripts into a request and have the server return the script to the client in the response. This occurs because the application is taking untrusted data (in this example, from the client) and reusing it without performing any validation or sanitisation.

If the injected script is returned immediately this is known as reflected XSS. If the injected script is stored by the server and returned to any client visiting the affected page, then this is known as persistent XSS (also stored XSS).

Scanner has discovered that it is possible to insert content directly into an HTML tag. For example <INJECTION_HERE href=.......etc> where INJECTION_HERE represents the location where the scanner payload was detected.

Solution

To remedy XSS vulnerabilities, it is important to never use untrusted or unfiltered data within the code of a HTML page.
Untrusted data can originate not only form the client but potentially a third party or previously uploaded file etc.
Filtering of untrusted data typically involves converting special characters to their HTML entity encoded counterparts (however, other methods do exist, see references). These special characters include:

& * < * > * ' * ' * /
An example of HTML entity encoding is converting < to &lt;.
Although it is possible to filter untrusted input, there are five locations within an HTML page where untrusted input (even if it has been filtered) should never be placed:

Directly in a script. 2. Inside an HTML comment. 3. In an attribute name. 4. In a tag name. 5. Directly in CSS.
Each of these locations have their own form of escaping and filtering.
Because many browsers attempt to implement XSS protection, any manual verification of this finding should be conducted using multiple different browsers and browser versions.

See Also
http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

fixes #341

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coveralls]

Coverage remained the same at 91.579% when pulling b603f51 on vericred:v0.9.4-master into 2313ea1 on TrestleAdmin:master.

[spohlenz]

Fixed in 568924b.