Application Security - Being Secure and Feeling Secure are two different things

This post aims to help you refresh your knowledge for Application Security Job Interviews.
The content is taken from various sources and my own notes and I claim no novelty for the content presented here.

What are the main causes of Application Security Issues?

Trusting the User - A security Issue

The main cause of application security problems is that - "User can submit arbitrary input to the application".

The user input, and any parameter that can be manipulated by the user, whether directly or indirectly, should be treated as "Malicious".

User can interfere between any piece of information that is transmitted between the client and the server. The following can be modified by the user

•  URL Parameters
•  Cookies
•  HTTP Headers
•  Client Side Security Controls  ( All client side controls can be circumvented)
•  The sequence in which requests are sent
•  The rate at which requests are made 
•  Parameters may be submitted at a different stage / may not be submitted at all / may be submitted more than once.

Any kind of assumption about "how a user will interacts with the application" has the potential of  being violated. A user may not even use a browser to interact with the application.

Lack of Awareness  - A Security Issue

A developer often uses multiple "third party packages" together. Each of these third party package is designed to abstract the underlying technology. It is common to meet experienced developers who make major assumptions about the security provided by their programming frameworks. This lack of awareness about security issues as well as assumptions about the security capabilities of third party packages are an important security issue.

Resources and Project Deadline Constraints 

Most projects are subject to strict constraints of money and time. Employing dedicated security expert  to help in the design and development is mostly infeasible, thus security testing is left until the very end in the project life cycle.  Since Security is a less tangible issue compared to producing a stable and functional application, the economics of time and money often override security considerations.

Quick penetration tests often find "easy to find vulnerabilities" but are not sufficient, and may miss subtle vulnerabilities that require time and patience.

Greater Attack Surface

Modern applications provide more functionality than older static web pages. Each new feature in modern applications adds to the attack surface and has the potential of being misused for carrying out an attack. For example - The password recovery feature in a modern website has the potential of being misused.

The Security Perimeter has shifted

Earlier - Organization's efforts to protect themselves from attacks were largely focused on the Network Perimeter. Defending the network perimeter entailed
-  hardening & patching the services that were needed to be exposed
-  putting all other services behind firewall to control access.

Now - Web applications now occupy significant part of the security perimeter.

The Databases, financial and logical systems lie behind several network level defenses. These resources are accessible to a normal user, in a controlled manner, through the web application. If there exists a vulnerability in the web application's security controls, then none of the network security defenses can protect the system as the "attack data" sails past the network security defenses just like "normal data".  A significant part of security perimeter is now occupied by the organization's web application.

Ways in which an application receives user data and passes it to back-end systems has increased manifold, thus the attack surface has increased.

Third party widgets, and other cross domain integration in web applications - shifts the "server side security perimeter" beyond the walls of the organization itself. Trust is placed in external applications and services and these services may not be entirely secure.

Another way in which security perimeter has changed - A vulnerable web application can be used to attack unsuspecting users. Client side attack surface has also increased considerably because of browser extensions and plugins, thus allowing more ways in which a user might be attacked .If the user is located in an internal corporate network, then the attacker can use the external web application's vulnerability to launch an attack on the internal network, from the position of a trusted internal user. Thus using external vulnerable websites in an internal corporate network also changes the security perimeter.

Security Perimeter has partly moved to the client side, through the use of "Email" , "Phone" as authentication mechanisms, through the use of "forgot password" functionality.

What is SQL Injection ?

SQL Injection is a high risk vulnerability caused by - "Malicious user input being interpreted as a real database query, usually due to inadequate data validation from the web tier"

Hackers are able to get to the database through.

1.  URL Parameters
2.  Forms ( including hidden forms)
3.  Areas which allows user input, through which data could get to the database.
4. Cookies

Modern web applications are broken down into three tiers

1. Web Tier
2. App Tier
3. Database Tier

The App Tier sits between and doesn't allow direct interaction between Web Tier and Database Tier.

The SQL Injection will originate from Web Tier, through user input methods ( URL, Forms and other means) and travel to Database Tier if the Application Tier does not properly sanitize or validate the user input.

Visible error messages indicate that the application is vulnerable to SQL Injection. They also help the attacker build a successful SQLi Query.

What is Blind SQL Injection?

Blind SQL injection is just like SQL Injection except that the attacker does not get any help from an error message (though you might get a generic error message), hence it is called Blind SQL Injection. The attacker only relies on the website load mannerism to identify whether his attack succeeded or not. For example, the presence or absence of a "picture" on the page might suggest whether the query returned a "True" or "False". A series of specially crafted queries which return a "true" or "false" as result, can be used to get all the information you want. This attack is slightly more difficult to do, but that has never been a deterrent for a determined hacker.

Causes of SQL & BLIND SQL Injection

1. SQL code is allowed to be entered on the web tier, and travels to the database tier due to improper validation.
2. Error messages make it easy to exploit SQL Injection vulnerability.

Defence against SQL Injection

The primary defense is to use  "Parameterized Queries". When we use parameterized queries, then the meaning of a query gets fixed, and no matter what command we enter in the "Name" field, it will be considered a part of the input and will not be interpreted as a command.

INSERT INTO CustomerTable (Name, Email) VALUES (?, ?)


What is Cross Site Scripting (XSS) ?

• A type of Injection Attack
• Attacker sends and executes a malicious Javascript code, in another user's browser, through a VULNERABLE web application.
• Vulnerability exists when, untrusted user input, is used to construct the web application output without Input validation & Output Encoding it.
• Occurs because Browser has no way of differentiating between "Trusted" & "Untrusted" scripts

Harmful effects of XSS

Malicious script executed through XSS can

• Access cookies, session tokens & other confidential information and send it to an external server
• Change the contents of the HTML page
• Perform unintended operations on behalf of the user.

Different Types of XSS ( Based on how the Injected Script is delivered)

Stored XSS ( TYPE 1 XSS)

• Script is sent to the user as a part of the requested resource. 
• Injected Script is permanently stored on the target server in database message / forum / visitor log / comment field

Reflected XSS ( Non Persistent, Type-2 XSS)

• The user is tricked into clicking a malicious link to submit a specially crafted form to a vulnerable website
• Malicious Script Injected through the "crafted form" will reflect back & execute in user's browser
• Injected script is included in server response which includes part of the user-input

DOM-Based XSS ( Type-0 XSS)

• The server's response does not change in case of DOM based XSS
• If a        Crafted URL        (or)     URI Fragment               (or)  Form submission data       contain attacker supplied Malicious script and if these are used to update a page's content by the "CLIENT SIDE JAVASCRIPT" then the Malicious script will get executed.
• The Client Side Javascript can access the DOM elements ( like URL, URI fragment) and use those to update the contents of the Page.
• An attacker can trick a user into clicking a "Specially crafted URL" or submit  a Form containing malicious script to exploit this vulnerability.
• The part of "URI Fragment" is never submitted to the server & hence cannot be detected

XSS Prevention Steps (for DOM Based XSS)

• Avoid using client side scripts to process DOM Data and render it to the page
• If it is unavoidable to use client-side scripts to process DOM Data, then we should

Validate Input on Client Side

• Validate on "Client Side" that data being inserted in the document contains only allowed characters.
• Validate the URL data on the "SERVER SIDE" to detect malicious exploits for DOM based XSS.
• Validate the "URI Fragment" part on the "CLIENT SIDE"

Validate Output on Server Side

• Do Context appropriate output encoding on using the Client Side Script

XSS Prevention Steps ( for Stored & Persistent XSS )

Never insert Untrusted data in the following locations

• - in a script tag
• - in an HTML comment
• -in an attribute name
• -in a tag name
• -in CSS style tag

In the following contexts, take the corresponding steps

1. HTML Element Context - HTML Escape before inserting in

• body
• div
• p 
• b 
• td

2. HTML "Common ATTRIBUTE" Context - Attribute escape before inserting in

• width
• name
• value

NOT FOR - complex attributes like - href, src, style

3. JAVASCRIPT Context

• Only Safe place to insert data is inside a "quoted data value".
• JavaScript escape before inserting untrusted data in Javascript "Quoted DATA" values.
• Including untrusted data in any other context is dangerous, as its easy to switch into execution context
• some functions like "window.setinterval(' ')" can NEVER Safely use Untrusted data, even within Quotes
• Except for Alphabets & Numbers escape all characters less than 256 with \xHH
• Do not use \ as an escape character because it is vuln to "escape-the-escape (\\)" attack
• Unquotes attributes can be broken out of using space % * + , - + ; < = > ^ |
• A </script> tag will close a script block EVEN if it is INSIDE a QUOTED string.      REASON- HTML parser runs before JAVASCRIPT parser

4. CSS Escape & Strictly Validate Before Inserting untrusted data in a CSS "style PROPERTY Values"

• CSS can be used for numerous attacks
• CSS ESCAPE & Use untrusted data Only in "Property Values" & NOT ANYWHERE ELSE
• Except for Alphabets & Numbers escape all characters less than 256 with \xHH
• Do not use \ as an escape character because it is vuln to "escape-the-escape (\\)" attack
• Quoted attribute requires a corresponding Quote
• Unquoted attributes can be broken out of using space % * + , - + ; < = > ^ |
• A </script> tag will close a script block EVEN if it is INSIDE a QUOTED string.      REASON- HTML parser runs before JAVASCRIPT parser

5. URL Escape before Inserting Untrusted Data in HTML URL Parameter Values

• "URL should not be allowed in HTML Parameter values - No foolproof way to prevent switching out of the URL
• Entity encoding (&lt, &gt) is useless in this context

Additional XSS Prevention Mechanisms

1. Use HTTPOnly Cookie flag

• Prevents a cookie from being accessed by client-side JavaScript

2. User Content Security Policy

• A complex solution
• Allows creation of source white-list for client side resources of the web application
• Will disallow any scripts from external sources
• Also has the option to disallow any inline scripts.