Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Few Web Application Security Vulnerabilities and Countermeasures

In year 2015 we fixed some of the Web vulnerabilities in our Supply Chain Finance application and I would like to share a few of the Application findings which represent issues arising from how the application is developed or configured.

Issues in this section describe instances where the application implementation deviates from best practices.

1. Cross-Site Scripting — XSS Attacks

Persistent XSS occurs when the application is capable enough to store every possible input given by the user. An attacker can abuse this functionality by inserting malicious code block or by convincing a user to perform an action on the specially crafted link that submits the user action. The malicious JavaScript is then executed on that page until the data is properly escaped or encoded.

Likelihood of attack “High”. XSS can be used to run attacker supplied JavaScript in the user’s browser and force the user to perform arbitrary actions.

Countermeasures — There can many possible “defense strategy” to mitigate XSS vulnerabilities. The main motive is to avoid execution of scripts which got introduced in the application. While there are a huge number of XSS attack vectors, following a few simple rules which can completely defend against this serious attack.

#Rule 1  HTML Escape Before Inserting Untrusted Data

Escape the following characters with HTML entity encoding to prevent switching into any execution context.

However, html escaping didn’t proved to be sufficient enough because HTML entity encoding doesn’t work if attacker has launched the untrusted data inside a <script> tag anywhere, or in any kind of event handler such as onmouseover.

#Rule 2 Attribute Escaping and JavaScript Escaping

Attribute Escaping — Untrusted data can be configured into typical attribute values like width, name, value, etc.

<div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>content</div>     inside UNquoted attribute

<div attr='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'>content</div> inside single quoted attribute

JavaScript Escaping — dynamically generated JavaScript code — both script blocks and event-handler attributes.

<script>alert('...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...')</script>     inside a quoted string

<script>x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'</script> one side of a quoted expression

As Supply Chain Finance application is a Spring based application so attribute escaping and java script escaping was easily achieved using spring:message.We escaped all characters less than 256 with the xHH format to prevent switching out of the data value into the script context or into another attribute.

<spring:message javaScriptEscape="true" htmlEscape="true" code="label" />

#Rule 3URL Escaping was done and HTTPOnly cookie flag was used

URL Escaping — For URL Escaping certain pattern was taken care and XSSFilterWrapper was written to escape certain pattern.

HTTPOnly cookie — Cookies are usually created by a server, passed to the browser and then passed back. Now it is possible to create and manipulate Cookies using JavaScript which can be helpful but can also be a security hole. So an HttpOnly Cookie is only accessible by the server, which clearly indicates it is not accessible from client side JavaScript which protects your site from some forms of XSS attacks.

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Set-Cookie: SessionId=ig2fac55; path=/; HttpOnly
Set-Cookie: user=t=bfabf0b1c1133a822; path=/; HttpOnly

#Rule 4White listing and Blacklisting the character set

In our application we validated input parameters to reject dangerous characters which are responsible enough for script execution (Blacklisting the character set).
Or there exists an even better approach is to accept only the characters that are relevant for each particular field (White listing the character set).

Additionally, we have added the header X-Content-Type-Options: nosniff to block content sniffing and avoid transforming of non-executable MIME types into executable MIME types.

For additional information follow the XSS Prevention OWASP CheatSheet.

2. Unrestricted File Upload

Uploading files in an application represent a significant risk to applications. The first step to initiate attack in the system is to introduce the malicious code block to the system to be attacked. Then attack only needs to find a way to get the code executed. Using file up-loader helps the attacker to initiate the first process to introduce the malicious code block to the system.

Likelihood of attack  “Medium”. Attacker may require additional set of knowledge of the system.

The consequences of unrestricted file upload can include:

  1. Overloaded database
  2. Complete takeover the back-end system by executing a web-shell which can run commands
  3. Uploaded files might trigger vulnerabilities in broken libraries/applications on the client side initiating client-side attack.

Countermeasures — For uploaded file content, validate that the data content matches the expected types for all allowed types and reject attempts for all those file extensions that can be executed on the server side or can be dangerous on the client side. Assign a system-generated filename to any uploaded file and do not incorporate any portion of the original filename. Do not serve or process the user uploaded files from web server directories that may have script mappings enabled.

For more information follow the OWASP Unrestricted File Upload CheatSheet.

3. SQL Injection

SQL injection attacks allow attackers to spoof identity, tamper with existing data, voiding transactions and user’s balance, allow the complete disclosure of all data on the system which otherwise should only be accessible to administrator user of the database.

Likelihood of attack — “Medium”. Attacker may require additional set of knowledge of the system.

Countermeasures —Low privilege connections to the database server, passwords, bank account details, credit card information, bank routing number all such information should be redacted. Such information should be encrypted before storing them to the database to avoid identity theft.

For more information follow the OWASP SQL Injection Cheat-sheet.

4. Click-jacking Defense Mechanism

UI redressing is a technique that tricks users into revealing confidential information after clicking on an apparently anodyne area of a web page.<frame> or <iframe> elements are put into use to make certain attacks successful.

Likelihood of attack — “Low”. Attacker may require additional set of knowledge of the system.

Countermeasures — The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>.

X-Frame-Options Header Types:

  1. DENY, which prevents any domain from framing the content.
  2. SAMEORIGIN, which only allows the current site to frame the content.
  3. ALLOW-FROM uri, which permits the specified ‘uri’ to frame this page.

For more information follow the OWASP Clickjacking Defense Cheat Sheet.

5. Cross-Site Request Forgery

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.

CSRF attacks ensure to introduce the state change for stateless servers, theft of data is not involved as getting request would fetch the response to the victim not to the attacker, as the victim is authorized to. There are no means that attacker can see the response to the forged request.

CSRF attack can bring the change in the state of the server but can’t see their results, it is forced to act blindly.

Let’s say, CSRF attack can tell the victim browser to request victim bank account balance, but the attacker can’t see that balance. This is obviously a pointless attack.

But it is not pointless if, the attacker asks the victim browser to perform transfer of money from victim account to the attacker’s account. The success or failure page for the transfer is inaccessible to the attacking script. The attacker is not concerned about the response of success or failure​, his main concern lies there should exists a successful transfer of money in his account.

Assume that your bank’s website provides a form that allows transferring money from the currently logged in user to another bank account. For example, the HTTP request might look like:

POST /transfer HTTP/1.1
Cookie: JSESSIONID=randomid;; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded


Likelihood of attack — “High”

Countermeasures — Configure CSRF Protection

Modify form submissions to include CSRF token:

<c:url var="logoutUrl" value="/logout"/>
<form action="${logoutUrl}"
<input type="submit"
value="Log out" />
<input type="hidden"

Modify AJAX and JSON Request:

<meta name="_csrf" content="${_csrf.token}"/>
<!-- default header name is X-CSRF-TOKEN -->
<meta name="_csrf_header" content="${_csrf.headerName}"/>
<!-- ... -->
$(function () {
var token = $("meta[name='_csrf']").attr("content");
var header = $("meta[name='_csrf_header']").attr("content");
$(document).ajaxSend(function(e, xhr, options) {
xhr.setRequestHeader(header, token);

CSRF is a huge, impossible-to-guess random number that an application will include in their own web page when they serve it to your server. It is different each time they serve any page to anybody. The attacker is not able to guess the token, is not able to convince your web browser to surrender it and so the attacker will not be able to create a valid request.

For more information follow the OWASP CSRF Cheat Sheet.

I was mentoring two of the people who were newcomers to web developments and techniques. Realized small article might help all those people who are new to web development or new to bring security to their web application.