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.