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
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
No comments:
Post a Comment