Cross-Site Scripting vulnerability in Websense Data Security block page

Abstract

It was discovered that the Websense Data Security block page processes user-controllable data insecurely, rendering the block page is vulnerable to Cross-Site Scripting. Cross-Site Scripting allows an attacker to perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.

Tested versions

This issue was discovered on Websense Triton v7.8.3 and Websense appliance modules V-Series v7.7. Other versions may be affected as well.

Fix

This issue is resolved in TRITON APX Version 8.0. More information about the fixed can be found at the following location: https://support.forcepoint.com/KBArticle?id=Vulnerabilities-resolved-in-TRITON-APX-Version-8-0

Introduction

Websense Data Security Suite contains three modules - Data Security Gateway, Data Discover, and Data Endpoint - that can help manage the risk of losing your data to malicious users or accidental misuse.

When Data Security DLP policies block a website, a block page is displayed in the client's browser. The message presented to the user is send back to the server using Base64 encoding. This message contains user related information such as the IP address of the client. The message is not properly encoded when used in the block page. Consequently, the block page is vulnerable to Cross-Site Scripting.

Details

In order to exploit this vulnerability a valid ws-session is required. The payload has to be Base64 encoded, submitted to the block page via the ws-encdata URL parameter. For example, the following parameters can be submitted to the block page.

ws-session=18446744072585574752&**ws-userip**=1.2.3.4**--><iframe>**0&ws-cat=76&ws-reason=1029

The above parameters must then be encoded with Base64 and appended to the following URL:

http://:15871/cgi-bin/moreBlockInfo.cgi?ws-encdata=

An attacker must trick victims into opening the attacker's specially crafted link. This is for example possible by sending a victim a link in an email or instant message. Once a victim opens the specially crafted link, arbitrary client-side scripting code will be executed in the victim's browser. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session tokens or login credentials, performing arbitrary actions on their behalf, logging their keystrokes.

Vragen of feedback?