Skip to Content

Introduction

In this blog I shall describe my experience in addressing a simple cross site script issue reported on a portal application as part of security testing and the tools that came in handy in this endeavour.

     Generally security testing is performed by using specially developed tools that scan the application and try to find and exploit security vulnerabilities.The tool also generates reports and also provide fix recommendations.Examples include IBM Appscan,Burp suite from PortSwigger Ltd etc.


I had to investigate a reflected cross site script(XSS) issue reported on a customized portal application.There is lot of literature available on the Internet about cross site scripting.This page from help.sap.com provides a lucid explanation.And a great resource on this topic is the the Open Web Application Security Project at https://www.owasp.org/index.php/XSS

Issue Description

In a custom portal application there is a HTML form inside a JSP page which contains username and password fields along with a checkbox.Upon user submission,this form is posted to an abstract portal component.The values entered in the form are retrived from the request(IPortalComponentRequest) object and are stored in IPortalComponentContext object.After the necessary business logic, the abstract portal component is redirected to irj/portal URL.On the server side,the values entered by the user are retrieved from the IPortalComponentContext object.Here the value of the checkbox field is stored in a java variable.In a javascript block inside the $(document).ready function,this value is further copied to a javascript variable.


The above scenario is implemented in JSPs on Apache tomcat server for demo purpose.Below is the pseudocode for the initial login.html

<input id=”user” type=”text” name=”user” ….>

<input id=”password” type=”password” name=”password” –>

<input type=”checkbox” id=”mycheck” name=”mycheck” …>

The values submitted are posted to intermediate jsp(NewFile.jsp) where the checkbox selection is stored in a JSP session.A HTML form in this JSP posts to the final JSP page.

<%

String text = request.getParameter(“mycheck”);

session.setAttribute( “checkbox_value”, text );

……


String redirectURL = “<form id=\”redirectedform\” method=\”post\” action=\”final.jsp\”>”;

……

%>

In the final JSP page,the value stored in the session is retrieved and later copied to a javascript variable as below.

<%

String data = session.getAttribute(“checkbox_value”).toString();

….

%>

…..

<script language=”javascript”>

$(document).ready(function()  {

var checkbox_selection = “<%=data%>”;

});

</script>


The above code is vulnerable because the value entered in the checkbox field is not encoded when it is being stored in the session object.The tool used for

security testing sent a string such as 54321″;alert(‘XSS issue’)//733  as the value for the checkbox.This value flowed till the final JSP and echoed in the response.

This is possible because the string is crafted in such a manner,as to make it a valid javascript statement in the runtime

var checkbox_selection = “<%=data%>”; would become

var checkbox_selection = “54321”;alert(‘XSS issue’)//733

The double quotation mark after 54321 and the following (;) character would neatly close the statement,following which is a javascript alert() statement.The

javascript single line comment indicator(//) would render the rest of the code non executable.


Now that the issue is reported by the security testing tool we need to test and validate if the issue actually occurs and the code is vulnerable.After all not all issued reported by such tools  turn out to be potential vulnerabilities.


How to validate:

This issue escaped unit testing because of the apparent difficulty in passing any text value for a checkbox field.From the HTML page rendered by the browser,a checkbox can either be selected or unselected.So we need to use a tool that can alter/tamper HTTP requests. “TamperData” plugin for Mozilla Firefox browser is one such tool offering this functionality.The tool can be installed as browser add on.


/wp-content/uploads/2014/10/screenshot1_557894.png


We need select this addon from Tools and select click on select Start Tamper button before submitting the request. After checking to tamper the request,

A popup box opens  that lists all the fields used in the form to edit. As can be seen from the below screenshot,the value 54321″;alert(‘XSS issue’)//733 is entered for the field mycheck and click on Ok button./wp-content/uploads/2014/10/screenshot3_557896.png


Now as is expected,the alert pops up with the message “XSS issue” on the final jsp.


/wp-content/uploads/2014/10/screenshot5_557929.png

Solution


Since the existence of the issue is now confirmed,a solution is to be provided,In the above simple scenario,as mentioned earlier,the issue exists because the value of the checkbox is not  HTML encoded before being stored in the session.Encoding the output before before displaying it is a good practice and it need to be done for every input. HTML encoding ensures harmful symbols and HTML tags are converted to their harmless HTML representation,

Eg: ‘>‘ is converted to &gt;

The class com.sap.security.core.util.taglib.EncodeHtmlTag contains the required methods for HTML encoding/decoding on EP 7.0 In the latest versions of NW portal,the class com.sap.security.core.server.csi.XSSEncoder provides similar functionality.For complete information on various encoding functions offered by SAP, please refer this help page.



To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply