Here is a small description of the issues and how to reproduce them (this really should be a script):
User Signup:
If the user puts in a XSS payload as the username:
an JS error will occur and the payload triggered:
Rename View:
If the user (with Editor privileges) puts in a XSS payload on the 'rename' value, the payload will be triggered on node refresh (only once, and for that user)
Admin Panel: 'Xml Library' and 'Zip Folder' settings
If the admin goes to the 'Control Panel + Admin Tasks', and puts a payload on the 'Xml Library' and 'Zip Folder' values (which can only be set by admins), the payload will be executed on the View Config File' panel (this is an example of DOM XSS)
A payload here:
will work here:
A payload here:
and here:
Note: These issues are tracked as the Issue #110 - User and admin self-exploit XSS issue
jQuery is hard to secure:
The key problem is with jQuery and the challenges that exist in writing secure jQuery code!
This is actually a massive sleeping giant on the web since I don't (and most dev don't) have a real picture of the cases where jQuery will treat a string as a payload (I was able to detect and fix a number of issues, but I'm sure there are still a couple in there)
To get a better idea of the problem, take a look at Unraveling some of the Mysteries around DOM-based XSS presentation (by Dave Wichers) and the Cross-Site Scripting vulnerability with JavaScript and JQuery article.
The cost of fixing these types of XSS Issues (which are not really exploitable) are another example of the Security TAX that developers have to pay.
Note that :
- the app (TM) is working ok without the fix,
- the fixes can introduce side-effects (see double-encoding reference below)
- there is no business-related value added from them (apart from the 'being a bit more secure' one)
On the topic of putting these XSS issues into perceptive, note that the current (3.2) version of TeamMentor is vulnerable by design to XSS payloads added (by editors) to Articles.
Quote from Issue #111 - XSS by design on Articles:
-
"... By default TM allows the use of any HTML in the articles (via the Notepad and WYSIWYG editors).
Although this is an big issue (which would allow a payload to attack an Admin), this is also very common on web apps , for example Sharepoint or Blogger
Note that TM already supports the automatic sanitization of an Article's HTML content (using the AntiXSS library Sanitizer.GetSafeHtmlFragment method) which can be enabled by setting the TM Config SanitizeHtmlContent value true (by default it is false). One of the reasons why SanitizeHtmlContent is disabled is because it broke the formatting of 1000s TM articles.
The current plan is to migrate TM content into WikiText or Markdown (in 3.3) and enable SanitizeHtmlContent by default...."
What I really want to do is to be able to detect (in real-time or via Html/Javascript SAST) the use of malicious JavaScript (which has a complete different pattern and structure from the other Html and JavaScript used). This is where AppSensor like techniques and workflows will really make a difference.
Related posts:
