Thursday, March 17, 2016

Fixing XSS

Respect XSS had a nice blog post on an XSS vulnerability that existed a while back on the Mozilla Add-Ons website. This was a stored XSS. Stored XSS is where the XSS attack was stored server-side likely in a database table and is loaded over and over from the database every time any user goes to a particular page. The issue was with the Name field, so if you entered html / javascript into the Name field, it was actually getting stored into a database table probably in a name column, and then on the next page, the name column was pulled out, still unsanitized, and displayed as the Title of the next page. So an attacker could Name their collection with javascript instead of a real name, and anytime a person when to that collection the javascript would execute. Thus classic XSS. This could lead to session or cookie theft, keylogger, malware installation, browser hijacking, or much more. XSS is bad, and as that blog says "Respect" it.

What I thought was worth discussing a bit further though was 2 other XSS fixes (albiet simple) that the same blogger found and mentioned at the bottom of the post. There were 2 github checkins worth looking at

1.) forms.js fix


The above change is in the populateErrors function, and it's looping thru each error message and printing out the error. This appears to be related to user input validation, and if user input was incorrect then an error would display, and when an error was displayed, the error display field bwas actually vulnerable to XSS and javascript could be executed. Thus to prevent that it was very simple, any output that is controllable by a user in any way should first be escaped/sanitized. This project is using the _.escape function to escape or sanitize the user input before displaying.

2.) mobile-search-results.html fix


The above change is to fix an issue where the search keyword was being displaying in the search results page unsanitized thus it was vulnerable to XSS. This project uses Swig javascript templates, thus the reason you see all the curly braces and modulus symbols {%. Then it's basically taking the doc.url (or current url) and encoding it with the encodeUri() javascript function. This strips out the malicious characters that enable the XSS from the search keyword prior to displaying it.

It's just good sometimes to see how simple it is to fix XSS and thus you should take time and make time to remediate quickly if you find one.

u>More about neonprimetime


Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru


Top Github Contributions
  1. Qualys Scantronitor 2.0


Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

No comments:

Post a Comment