Showing posts with label Methodology. Show all posts
Showing posts with label Methodology. Show all posts

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.

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.