Web application flaws are attractive fruits for hackers and Web is a best place to find the web application flaws. Web application development has grown very tricky courtesy of smart attackers who can spot flaws in this application-and you cannot imagine the outcome of such a flaw! This article dissects some of prime application logic flaws that a developer should know and most importantly be wary of.
What are Application Logic Flaws?
First things first, if you are a newbie in web application development then it is colossal to understand the basic concepts before you dive into the technical aspects. In simple terms, application logic flaws are loopholes in the logical flow of application execution that can be exploited by hackers. To get a good picture of the concept, you should first understand that application logic is basically the series of steps defined by a programmer that needed for the application user to complete a particular action. Take an example of an application that requires a user to add some products into a cart before making a purchase. Application logic should however not be thought of as the whole web server functionality, but as the specified operations undertaken by the application.
Now that you have the basic understanding of the concepts, let us look at 10 most common web application logic flaws that you need to understand.
- Denial of Service Attack:
Web applications usually have difficulty distinguishing between genuine traffic and traffic related to an attack. This can be explained by the fact that it is quite tough to point the originality of an HTTP request. It is known that servers can handle hundreds of users using a given application concurrently, but an attacker can consume resources that can deny legitimate users time in the system. Some of the resources that usually targeted are: databases, bandwidth, storage, CPU, memory, application specific resources among others. The best way to solve this is to provide some security measures at the application layer and test the application against a threat model.
- Potency of Change in User privileges:
This form of flaw occurs when an application’s user gets access to the rights and privileges that he or she should not be afforded in an application. There are two main escalations happen, when such a scenario occurs, vertical escalation-an attacker gets privileges allowed to high-level users, e.g. admin and horizontal escalation-when an attacker gets privileges similar to his/her legally configured accounts. Such a flaw can be tested using privilege-testing techniques that involve checking every portion of the application where a user has a privilege to write information for any flaws.
- Potential Abuse of cookies:
Cookies are normally used to maintain an application state in an HTTP communication. Developers are not only using session cookies but integrate it with variable sessions. Cookies can be reverse engineered and some have values that can be easily guessed-this can create loopholes in the application. The best measure against this is to check on the cookie values in a bid to know if it is vulnerable or not. This is usually done by analyzing the cookies-delivered during profiling.
- Web Parameters imperfection:
HTTP uses GET and POST methods to make requests to the application and they are usually accompanied by parameters that can be easily manipulated. Parameters include JSON, XML and name/value pairs that can be easily guessed and you will need to test the parameters for vulnerability.
- Lightweight Directory Access Protocol flaw vulnerability:
LDAP is a standard that allows development and access to directory information over an IP. LDAP statements may be constructed based on the user input. If not properly sanitized, the input LDAP may be modified using a local proxy. The result of this is a possibility that an application can grant access to unauthorized users. LDAP tests can be used to prevent or rather reduce chances of such an attack.
- Business constraints defects:
The key to designing a web application is to follow a set of rules and constraints, but some hackers are smart enough to build spiders that crawl through the hidden fields and exploit them. To counter such exploitations, it is advisable to test the hidden values that could be manipulated. It is especially important to test those parts, which are core to the application for probable exploitation.
- Identity profiling weaknesses:
Web applications usually take advantage of the session and other tokens to maintain identity. If a web application is not properly designed, an attacker may misuse the values and parameters of these tokens. Things can get bitter if the tokens that control profiles can be easily guessed and may be used in system wide attacks. A way to prevent this is to test the token parameters and check if they can be deciphered.
- Errors in Business Flow:
Web applications are designed to include flows that are usually controlled by page transfers and redirects. This flow may be bypassed leading to an error or even worse a leakage in information. An attacker that uses this technique can use the information to identify the application’s core functionality. As a countermeasure, it is important to cross check the web application functionality to ensure that important parameters cannot be misused.
- Client Side Routines flaws:
It is common these days for web applications, integrating Internet applications that interface to JavaScript, Silverlight, and Flash. In most cases, these applications are on the client side. This presents a potential loophole given that they can be reverse engineered to expose the logic of the application. Think of it as a potential tunnel towards the access of encryption algorithms, storage of credentials, and management of privileges among other things that could lead to exploits. To deal with this, it is important to check the DOM (Document Object Model) for values, which could be exploited.
- Logical inadequacies in URL Access/Extraction of business information:
In web applications that involve exportation of documents, critical information is usually exported in the form of PDF, CSV, or XLSX. Implementing such functionality careless could prove detrimental in case of asset leakage. You will need to check on call functionalities on the basis of parameters like dir, doc, and files to see the potentially vulnerable areas. You can then perform a brute-force test to see if you can access files from another user.
In summary, web application development is more than just getting a functioning application in place in that you need to find techniques of checking these apps against attacks. What is clear though is that web security to get even tougher in the future as more and more attackers venture into the web.
