Web Application Security Basics — Introduction

When taking about web application security we often come across the term “untrusted data” . So what is it? Untrusted data is not limited to the data we receive as user inputs.

Any data that enters your web application from an outside source, be it input typed in by users, uploaded files, third-party cloud services, even databases and other applications within your own organization, should be treated as untrusted.

By using an intercepting web proxy which is common to all the web browsers a hacker can intercept and record the requests made by a client. By using a proxy tool like the Burp Suite or ZAP individual requests can be intercepted and modified. Not only can attackers modify fields that contain user-entered input,they can also add, modify, or delete headers, cookies, the HTTP verb (GET,POST, and so on), or any other aspect of the HTTP request.

Since the majority of web traffic generated by web applications is HTTP it is worth to understand the basics of HTTP.

HTTP, or Hypertext Transfer Protocol, is a simple, stateless, request and response protocol that drives the vast majority of web traffic.

Hyper Text Transport Protocol Secure provides variety of encryption services to protect data in transit over a network. HTTPS allows for

• confidentiality (to protect your data from being seen)
• integrity (to protect your data from being changed
• authenticity (to assure you that the domain you are visiting is really the real version of that domain).

HTTP/S Request types

The HTTP request consists of several basic components. These include the

GET http://www.oracle.com/index.html?locale=US&lang=en HTTP/1.1

• HTTP verb,
• the resource requested,
• the version of HTTP
• the headers
• parameters

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0)
Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Host: http://www.oracle.com

In the preceding example,

• the HTTP verb is “GET”
• the resource being requested is “http://www.oracle.com/index.html"
• the version is “HTTP/1.1”

The HTTP request headers include User-Agent , Accept ,Accept-Language , Connection , and Host .

In a GET request, the parameters are appended to the URL after a question mark and separated by an ampersand ( & ). The parameters in this request are locale , with the value US , and lang with the value en .

The HTTP POST request is a more secure way to transport sensitive data. The following POST has three properties that allow for the secure transport of sensitive data:

POST https://www.codemagi.com/user/login HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; Accept-Language: en-US,en;q=0.5 Referer: https://www.codemagi.com/ Cookie: JSESSIONID=39189CF28FC2D37C95EAE82B1E808F68; __utma=193591103.2028319770.1398918959.1398918959.1398918959.1; __utmb=193591103.2.10.1398918959; __utmc=193591103; __utmz=193591103.1398918959.1.1.utmcsr=(direct)|utmccn=(direct) Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 59 Host: http://www.codemagi.com action=login&start_in=&username=August&password=FluffyBunny1

• The request is an HTTPS request
• the HTTPS verb is POST
• the sensitive data is in the body of the request instead of the URL.

The most important thing to notice here is that sensitive data is sent in the request body unlike in the HTTP GET. But this does not guarantee the security of an attacker being able to access these data during transit unless it’s sent through a secure channel. That is HTTPS.

HTTP/S Response

When an HTTP server receives a request, it will return an HTTP response,which includes the HTTP version and response code, headers, and the response body. The response body is typically HTML, but it can also be XML,
JSON, or a binary file such as an image or document. A typical HTTP response will look similar to the following:
HTTP/1.1 200 OK
Date: Thu, 01 May 2014 04:00:32 GMT
Server: Apache
Content-Type: text/html;charset=UTF-8
Set-Cookie: JSESSIONID=37701355FAA6576DC3FD8C2E97E340E4;
Path=/; Secure; HttpOnly
Vary: Accept-Encoding
Strict-Transport-Security: max-age=31536000
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

… lots more HTML …

HTTP/S Response Headers

HTTP response headers is a simple and easy control mechanism to be adopted by developers when developing secure web applications. Some of the useful response headers are listed and described below.

Cache-Control HTTP Response Header

no-cache : The browser should re-validate the data with every request.

no-store: None of the content of the request or response should be stored in the browser

must-revalidate: The browser should not serve stale content.

Expires: tells the browser when to expire the content and setting this to a negative value will expire content immediately.

Strict-Transport-Security: max-age=31536000

Strict Transport Security HTTPS Response Header

This response header will force the browser to use HTTPS for the next 31536000 seconds. This should be delivered via HTTPS to take effect and the site will be contacted with HTTPS including all sub domains.

Building secure web applications is not an easy task. Several things should be considered through the entire software development life cycle to minimize vulnerabilities. Identifying anti-patterns and refrain from using them using positive patterns and security controls and input validation are goo measures that should be adopted in building secure web applications.

Originally published at http://neatrick.wordpress.com on September 24, 2015.