Preventing XSS and CSRF vulnerabilities in WSO2 ESB
In this article I will explain you how to prevent Cross Site Scripting and Cross-Site Request Forgery (CSRF) attacks in WSO2 ESB. First let me explain you what are those vulnerabilities.
What is XSS
Cross Site Scripting (XSS) is a client side code injection attack where an attacker can execute malicious scripts into a legitimate website or web application. XSS is a very common vulnerability exists in web applications and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates. For an example an attacker can inject a malicious script into an input textfield of your web application, and once the form is submitted that malicious script get executed, leading to catastrophic consequences.
What is Cross-Site Request Forgery (CSRF)
CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user's session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim. CSRF attacks target functionality that causes a state change on the server, such as changing the victim's email address or password, or purchasing something .
For an instance consider an online banking system where users carrying out their transactions such as paying bills, fund transfer etc. Suppose the victim has logged in, and his session is there with all the necessary credentials. An attacking web application running on victim's machine can make use of these information to send a POST request to the banking endpoint with these credentials if the required parameters are known priory.
Exploiting XSS Vulnerability
Now let us try to exploit XSS vulnerability in WSO2 ESB. I am going to use ESB 4.7.0 version which can be downloaded from . Unzip the ESB 4.7.0 and start it by running following command.
Login to the ESB admin web console using the following url.
Go to configure tab, under users and roles click on the Users link and enter the following script into the search text box and click on the search button.
It searches users with the injected script. Moreover you can create a user by giving above script as password. An attacker can easily use this to inject a malicious script into our administrative web console and exploit vulnerabilities.
How to Prevent the vulnerabilities
To prevent those vulnerabilities we need to unzip and apply the patch (named as patch0450)  to our ESB. To apply the patch merely unzip and copy the given patch directory into the ESB_HOME/repository/components/patches directory.
Then locate the catalina-server.xml file under the $ESB_HOME/repository/conf/tomcat directory and add the following elements under <Host> element.
Then locate the carbon.xml file under the <ESB_HOME>/repository/conf/ directory and add the following configuration under the <Security> element.
Now start the ESB instance. Once started try to access the ESB administrative web console using the following url.
You may get the following error when you login to the admin web console.
ERROR - CompositeValve Could not handle request: /carbon/admin/images/menu_header.gif
javax.servlet.ServletException: Possible CSRF attack. Refer header : https://10.100.5.120:9443/carbon/styles/css/main.css
This is similar to CSRF attack which is going to connect to our ESB. If you are pretty much sure about this request url and really need to allow this you need to add this url into <WhiteList> element resides inside the <CSRFPreventionConfig> element. For that first shut down the ESB instance and add the following element into the <WhiteList> element of the <CSRFPreventionConfig> element.
Now start the ESB again and now you should be able to access the admin web console via the above url since we have added that to our whitelist, which instructs the security framework that we are going to trust this as a legitimate request.
Now as we did above move into the Users and Roles under Configure menu and try to search for users giving the following string value.
You may get an error and ended up with a blank white screen. Now you can not inject scripts as you did before any more. Hurrah, we have secured our ESB now!
Next let us go ahead and create a Proxy service with script mediator which contains a simple java script.
Click on update, you may end up with a white blank screen and notice the following error in ESB console.
javax.servlet.ServletException: Possible XSS Attack. Suspicious code : <script>alert('XSS')</script>
After applying our security patch and necessary configuration changes it suspects this as a potential XSS attack. But this is not an XSS attack and we should be able to add scripts inside script mediators within our Proxy services, APIs etc. Therefore we need to allow this. For that we need to shut down the ESB and add this pattern under the <Patterns> element of the <XSSPreventionConfig> element. I have already added them but they are commented at the moment, hence you are getting this error. So you merely go ahead and uncomment those patterns under the <Patterns> element of the <XSSPreventionConfig> element. Then start the ESB again and try to create a Proxy service with a script mediator which consists of a simple java script as above. Now you should be able to create it without any errors.
In this article I have walked you through XSS and CSRF vulnerabilities in WSO2 ESB. First I gave a brief introduction to XSS and CSRF vulnerabilities. Then we exploited XSS and CSRF vulnerabilities with a fresh ESB 4.7.0 pack. Then I discussed about how to prevent those XSS and CSRF vulnerabilities in WSO2 ESB and gave you necessary configurations. Then I have proven you that after applying these patches and configurations, the XSS and CSRF vulnerabilities were avoided by using few sample use cases.