DotNetNuke (DDN) Persistent Cross-Site Scripting (XSS) / HTML injection
03 May 2013
17 May 2013
Amir Azam of ProCheckUp Ltd (www.procheckup.com)
'Vendors.aspx' page's input fields and also 'Upload File' under 'Tools' options are vulnerable to this XSS issue. ('http://target-domain.foo/Admin/FileManager/tabid/99/ctl/Edit/mid/99/ftype/File/rtab/99/Default.aspx') does not ensure that all data originating from a client request is adequately filtered and HTML encoded.
Successfully tested on:
Affected DNN Enterprise version: 07.00.05
Vendor has agreed that this is a valid vulnerability; however it is considered to be as a low risk issue, since DotNetNuke (DNN) vendor does not create a separate administrative level account on the fresh install (by default). In order to compromise this issue, an attacker needs to create the admin level role which has access to ‘vendor.aspx’ page, where the hacker has an ability to exploit cross site scripting attack. Nevertheless vendor has agreed to look into this issue and releasing patch respectively.
Proof of concept:
Proof of concept 1:
Step1: go to http://target-domain.foo/Admin/Vendors.aspx
Step2: Click on 'Add New Vendor'
step3: enter the following XSS payload into any of fields on the vendor page:
setp4: click on 'Update' to store the information
Step5: return to http://target-domain.foo/Admin/Vendors.aspx page to see executed XSS alert box(s)
Few examples of unfiltered parameters:
Proof of concept 2:
Upload html page with XSS payload e.g.
Step1: Go to 'Tools' and click on 'Upload File'
step2: upload an html page with following code:
XSS test page
<P>This is XSS HTML test page.</P>
An attacker may be able to cause execution of scripting code within the browser of a victim user who clicks on a malicious link. Such code would run within the context of the target domain. This type of attack can result in non-persistent defacement of the target site, or the redirection of confidential information (i.e.: session IDs or passwords) to unauthorised third parties.
How to fix:
Update DNN to 7.1.1 or ensure all data originating from a client request is adequately filtered and HTML encoded.
Follow a white-list input validation approach where possible to allow only necessary characters, and restrict the length of parameter values. For further information please refer to the OWASP XSS Prevention Cheat Sheet:
Copyright 2013 ProCheckUp Ltd. All rights reserved.
Permission is granted for copying and circulating this Bulletin to the Internet community for the purpose of alerting them to problems, if and only if, the Bulletin is not edited or changed in any way, is attributed to ProCheckUp, and provided such reproduction and/or distribution is performed for non-commercial purposes.
Any other use of this information is prohibited. ProCheckUp is not liable for any misuse of this information by any third party.