A few lines on cross site scripting issues
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
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\”>”;
String data = session.getAttribute(“checkbox_value”).toString();
var checkbox_selection = “<%=data%>”;
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.
var checkbox_selection = “<%=data%>”; would become
var checkbox_selection = “54321”;alert(‘XSS issue’)//733
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.
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.
Now as is expected,the alert pops up with the message “XSS issue” on the final jsp.
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 >
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.