Authentication and Authorization Security Controls – Code Analysis

Authentication

Applications are running on the server and usually serving browsers. Application authentication is form based and done over HTTP. There are several layers involved in the authentication process and each layer should have their own security protections. There are several different authentication mechanism available on application like NTLM, Basic, Digest, HTML Form based, LDAP, Certificate based etc. Authentication is has two aspects in web based application one is authenticating user and second is making a tunnel or channel for authenticated user since HTTP itself is stateless protocol. Various different authentication controls help in protecting application and if any of the control is missing or poorly written then it opens up severe vulnerability in application. Here is a list of possible issues or vulnerabilities

1.) Authentication disclosing sensitive information
2.) Not having auditing on the authentication
3.) No user lockdown policy in place
4.) Authentication bypass (SQL / LDAP interface)
5.) Password strength is poor
6.) No deployment of CAPTCHA or similar identification product
7.) Credential are not securely transmitted
8.) Credential are stored on client side which can be retrieved
9.) Authentication token or cookies are not well crafted
10.) Single Sign On (SSO) can be abused
11.) Deliberated backdoors are created
12.) Hidden fields and information exposure

Authentication controls are part of application code and it is imperative to analyze full mechanism in detail. This layer of code can help in identifying possible loopholes. Authentication is very critical for sensitive and transaction based sites like banking, trading or mailing system. An attacker can bypass authentication and can take hold of full session, it gets opportunity to advance hacking from there. Over years we have seen popular attack vectors as below

1.) Brutefocing
2.) Cookie theft and replay
3.) Authentication injections with SQL/LDAP
4.) Network eavesdropping and malicious codes
5.) Dictionary attacks
6.) Exploiting backdoors
7.) Hidden data manipulation
8.) Local store and information theft

Above attack vectors can help in exploiting the application and these attacks are easy to carry out using different frameworks. Source code can be written in the most secure fashion to protect against above attacks.

Authorization

Once user gets authenticated next thing is to maintain authorization through out the application. Authorization on the application get maintained using proper access control lists (ACLs). Application runs on HTTP and being a stateless protocol, session tokens are required to maintain authorization. There are several issues which can make entire application weak with authorization perspective and that can lead to exploitable security vulnerability. Here is possible weak area in the application for authorization,

1.) Session tokens are insecure
2.) Weak authorization mechanism
3.) Client side tampering and manipulation possible
4.) Possible data and SQL injections
5.) Access to system level bypass
6.) Single place authorization bypass
7.) URL forcing and manipulation
8.) Guessable resources and access
9.) Role-based bypass exploitation and weakness

Above weakness opens up several different set of vulnerabilities. These vulnerabilities can give access to various resources and opens up larger attack surface. Attacker or hacker can launch various attacks and exploits against target application. Here are list of popular attack vectors,

1.) Elevation of privilege
2.) Confidential data leakage
3.) Data tampering
4.) Session hijacking
5.) Session token exploitation
6.) Authorization injections
7.) URL bruteforcing
8.) Clients side reverse engineering and exploits

Above attacks are very popular against applications with respect to authorization. One needs to analyze logic in detail to detect authorization based vulnerabilities.

Validations and Error Handling – Security Controls

Input Validations

Almost 90% of vulnerabilities arise out of having poor or no input validations at the entry point of the application. There are countless different vulnerabilities of input validation type out there and applications are exploited by attackers. Essentially when developers are not treating each input as evil then it gets consumed directly into the application and exposing business logic with severe payload. These injections can force application to go into vulnerable state. Here are possible set of vulnerabilities arising out of poor input validation in the code.

1.) Various injection vectors (SQL, LDAP, XPATH etc.)
2.) Cross Site Scripting (XSS)
3.) Cross Site Request Forgery (CSRF)
4.) Buffer overflows
5.) Integer and logical boundary overrun
6.) Canonicalization issues
7.) Validation bypass (Client side)
8.) Serialization attacks
9.) Information leakage

Input validation is very easy to detect since application usually breaks and send abnormal response back to client. This response contains some signature which helps in detecting type of vulnerability. Attacker or tester usually does fuzzing to determine state of validation. This is one of the most important domains for application security.

Data Validations

Application needs place to store and access data from the system. Application may be using various data sources like database, file system, third part application, cross domain calls/APIs, browser memory etc. All these sources can be manipulated by attacker and it can help in stealing information or manipulating behavior of the application. In era of Web 2.0 applications are not running in isolation with single domain, applications are interlinked and share information seamlessly in-between. Application data is no longer restricted to database and dataset, we are seeing data get exchanged in XML, RSS feed, JSON etc. Application need to validate this data before consuming. Here is a list of weak area in the application which can lead to possible vulnerabilities,

1.) Proxy injections from third party stream
2.) XSS injection with RSS feeds
3.) Client side logic bypass
4.) Upload/download stream injections
5.) Remote command/code injection and execution
6.) Callback manipulation in JavaScript

Data validation is becoming equally important like input validation, it is imperative to validate any stream before consuming either on server or client side. We are seeing new ways of hacking and attacking in this area once code is not developed securely.

Error Handling

Error and exception handling is very important aspect of the development process. Many applications are written without having strong and central error handling routine in place. If error is not handled properly then it can lead to information leakage, Denial of Services (DoS) etc. Here is the list of possible security vulnerabilities arising due to poor error handling,

1.) Information leakage
2.) Logic bypass
3.) Internal logic and routine disclosure
4.) Denial of Services (DoS)
5.) Stack trace enumeration

There are several best practices need to be followed in source code for error and exception handling and some of the popular attack vectors to exploit error handling routines are as follows.

1.) Fuzzing and fault code injections
2.) Denial of Services injections

Automated scanners and engines detect vulnerabilities based on error signatures and this information proves very useful for them. Error handling is responsible for over 90% of information leakage.

Business Logic, Session and Crypto – Security Controls

Business Logic Handling

Business logic is core of any application; if any loophole in business logic is identified by an attacker then it can lead to sever set of vulnerabilities. Logical handling with input validation can prove a dangerous cocktail. Business logic vulnerabilities are hard to identify and needs good understanding of source code. Logical decision making blocks are usually suspects for this range of vulnerabilities. Some common logical issues in the source are as follows

1.) Data type bypass
2.) ACLs manipulation
3.) Read/Write access
4.) Privilege escalation on application layer
5.) API abuse
6.) Cross Domain Call and API manipulation
7.) Client Side Logic reverse engineering

We have seen as lower hanging fruits (LHF) are getting exhausted on the application, hackers move on to find something else and logical vulnerabilities is one of the crucial domain they would like to hack in. Lot of secure coding measures is required to protect the application with respect to business logic bugs and vulnerabilities.

Session and Identity Handling

Session management and unique identity handling are very important aspect of web applications. Web applications runs on HTTP protocol and one of the fundamental limitations of this protocol is its non-statefulness. HTTP can not maintain state of network and over period several different mechanisms are developed like URL rewriting or cookie based access. If there is a loophole in session management then it can lead to key vulnerability which can be exploited to gain unauthorized access on the system. Here is a list of possible issues

1.) Session hijacking by eavesdropping
2.) Man in the middle attack
3.) Poor session identifier generation
4.) Browser hacks like XSS to gain cookies
5.) Predictable session identifier
6.) Session bypass and access
7.) Cookie scope and time abuse
8.) Abusing URL rewriting
9.) Local session storing access

Session handling is closely linked to both authentication and authorization layer as well. It can be complex in nature as well when comes to deployment. It is becoming increasingly interesting with Web 2.0 applications and lot of session management required for various different streams as well.

Crypto and secret handling

Cryptographic usage is another important aspect of modern day’s applications. Application needs to keep certain data and information very secret. Many times application data get used by internal users as well and it should not be accessible in clear text either. Application’s crypto usage need to be evaluated thoroughly as well and some of the vulnerabilities or weak area are as follows in this particular domain,

1.) Poor key generation
2.) Database fields are not well encrypted (password, social security number etc.)
3.) Poor encryption (customized)
4.) Checksum spoofing
5.) Some secrets in source code itself
6.) Configuration file containing secrets
7.) Secret getting revealed in error message or some other means

Source code assessment can help in identifying any weak area in crypto and managing secret. This domain is another very critical area of application.

Input validation – First line of defense

Input validation is one of the most critical parts of application with security perspective. Most of the common issues like SQL injection or XSS come into existence with not having proper validation at the input layer. We have seen there are several entry points to the application over HTTP and each of these entry points need proper validation before consuming the value into the business logic. By having strong input validation can help in reducing severe threats and protect logic as well.

An attacker tries to induce faults in the application by doing fuzzing on HTTP inputs and if validations are not in place then application breaks giving vital clue and information out. There are several different types of validations required and based on the validation application works. Here is a list of popular validations

1.) Size and length validation
2.) Data type validation
3.) Meta character validation
4.) File type validation
5.) Data ranges

HTTP protocol is all string and there are no bifurcations for type of data. Hence, it is up to developer to validate the content before consuming in the application. If at design level central validation control is not designed then developer would take input and process in the business logic. Not having right input validation can lead to logical bypass and several other issues and vulnerabilities get injected. Input validation is one of the most fundamental requirements for the application and it acts as first line of defense in the source code.

There is range of different possible injections which can help in disrupting the logic.

1.) SQL injection
2.) File system access injection
3.) Remote command execution
4.) XML poisoning
5.) Source code injection
6.) LDAP etc.

Here are the characters which can cause this type of injections in the application if code is not validating it.

Attack vector	Possible characters or string
XML poisoning	Recursive same pattern as part of attacks
Parameter tampering (Characters)	double quotes (“), single quote (‘), ampersand (&), percentage (%)
Parameter tampering (Data type)	Data type mismatch.
Parameter tampering (Abnormal values)	Large or negative value causing EOF/BOF
SQL injection	single quote (‘), double quotes (“), hyphen (-) , “or 1=1”.
XPATH injection	slash (/), double slash (//), dot(.), double dot (..), @, =, <, >, *, “’ or 1=1 or ”=’” as attack strings
LDAP injection	bracket (“(“) and *
Directory traversal and File system access	Dot dot slash (../), “../../../etc/passwd”, ../../../autoexec.bat.
Operating System command execution	Pipe (|)
Brute forcing	Multiple requests from the same IP address
Buffer overflow	Large-sized buffer injection.

All above characters can help an attacker to bypass the logic and craft an exploit. Successful injection can be damaging for the application and an attacker can gain rights and access to confidential information to full system as well.

Solution to protect application

There are two broad approaches to protect application against this sort of attack vector.

1.) Applying validation across application – each parameter needs to be validated before consuming into application layer. Set of checks like length, data type, character filters etc. needs to be made before using inside the application. One needs to identify each and every entry point to the application and then apply secure coding across it.

2.) Another approach is putting a module in the application at HTTP layer for validation and it is also known as web application firewall. We are interested in filtering capabilities of it to protect our inputs. This has overhead to the application but getting some momentum in the industry in last few years.

One of the best approaches is to provide protection at the source code level itself so no dependent on any external checks and lock down.

For example here is a simple way of adding rule on .NET framework using built in form capability.

<%@ language="C#" %>

<form id="form1" runat="server"> <asp:TextBox ID="txtName" runat="server"/> <asp:Button ID="btnSubmit" runat="server" Text="Submit" /> <asp:RegularExpressionValidator ID="regexpName" runat="server" ErrorMessage="Valication failed." ControlToValidate="txtName" ValidationExpression="^[a-zA-Z'.\s]{1,40}$" /> </form>

Above code will compare against regular expression shown below.

 ^[a-zA-Z'.\s]{1,40}$

It will take values from a to z and A to Z with maximum length of 40. This way full protection can be applied to the parameter “txtName”.

Similar result can be achieved by applying at source code execution and code is shown below.

 Regex reg = new Regex(@"^[a-zA-Z'.]{1,40}$"); Response.Write(reg.IsMatch(txtName.Text));

 if (!Regex.IsMatch(txtName.Text, @"^[a-zA-Z'.]{1,40}$")) { // Validation failed }

Hence, there are various different ways validation can be achieved at application layer. Objective is not to allow certain values to the application layer.

Bug vs. Vulnerability

In last few years it is discovered that 9 out of 10 sites are vulnerable to possible security breach and some of them are easily exploitable as well. We are seeing rise in attack patterns on application layer accessible over HTTP (Hyper Text Transfer Protocol) using port 80 and 443. It is observed that 70% of cyber-attacks are happening over web ports and almost 95% companies are hacked through these ports in reported breaches. It is amazing to see more and more attacks are targeted to web ports and application layer. Fundamental reasons behind attacking these ports are obvious, one is availability of ports and second it is running with high value information which can be leveraged by an attacker.

We need to analyze top vulnerabilities pointed by different bodies to identify its root cause. At this point SQL injection and Cross Site Scripting (XSS) are top two vulnerabilities getting discovered on online sites or applications along with other vulnerabilities like path traversal, server side injections, information leakage or HTTP response splitting. The root cause of both SQL injection and XSS is insecure source written by developer. This poorly written source code gets exploited by an attacker to fulfill its malicious intent. Insecure code can range from having poor or no input validation to erroneous exception handling. Hence, one can conclude that insecure application code gives rise to vulnerability and an opportunity for an attacker to compromise an application. It is a rising threat for corporate world wide and needs better response to nail down these sorts of application layer vulnerabilities.

It is practically impossible to write an application without any bug. Bug is a developer’s mistake which gives rise to unexpected result or behavior in the application.

Figure 1 – Bug vs. Vulnerability

Bugs can be of different types like feature misbehavior, data access errors, logical issue etc. All bugs are not related with security but some of them are. These bugs which are related with security become root cause for vulnerability as shown in figure 1. As shown in the figure we have application layer security control in place but bug in application asset opens up a control and that gives rise to vulnerability. This vulnerability gets leveraged by an attack agent by crafting an exploit which eventually compromise the application and related assets in the corporate.

For example as shown in figure 2, developer has created a data access component in your enterprise application where he/she expected that input which is going to be passed by end user is going to be integer or number value always. Developer has provided exception handler for value falling into A to Z character set but no precaution is taken for meta-characters or any other special characters. This value is passed to database with a SQL query.

Figure 2 – State diagram for vulnerable application

Now this assumption itself has a defect in thinking and that generates a bug in the application routine. If an attack agent sends non integer/number value using special characters as input then application is going to behave in unintended fashion and leads to vulnerable state. This is when bug gets converted into vulnerability. This vulnerability can be exploited by an attacker to get unauthorized access by doing SQL injection.

Hence, bug and vulnerability are siblings in the source code and it brings risk into your application layer. Here is a list of important bug layers which gets converted into exploitable vulnerabilities:

Design and Architect layer bug – These bugs are very hard to fix and it comes into existence when at architecture or design layer some bad decisions are made. For example, authentication and authorization strategies are not designed in right fashion and it has a flaw which can be exploited by an attacker or cryptographic issues on the application layer.

Validation layer bug – This layer of bugs are at development layer when an input taken and consumed by application without any sanitizations then it has potential to break application and leads to a state where exploitation is possible either by various different means like information leakage or access escalation.

Logical layer bug – Logical bugs are very interesting to find and fix, these bugs come into existence when an actual implementation of the application is having logical coding error. It can leads to access level issue or flaw in business logic itself. It can cause devastation at application layer. These bugs are usually discovered while doing manual assessment.