Ensuring security is one of the most daunting challenges that web applications are facing nowadays. Authentication and authorization are two main security fields that web applications must consider to be protected against unauthorized accesses. Various approaches that detect well-known vulnerabilities and flaws exist. However, these approaches mainly focus on detecting input validation flaws.
Another kind of flaws that affect web applications are business logic flaws, but they lack of considerations.
The main difference between logic flaws and input validation flaws are their exploits. To exploit an input validation flaw the attackers mainly leverage on coding mistakes, such as a lack of input variables validation, leading to injection of malicious code (SQL Injection, Cross Site Scripting, Command Injection).
On the other hand, a business logic flaw exploit requires the attacker to find out a defect in the way the application makes decisions. We extended the OWASP Foundation’s definition of a logic flaw  to the context of the authentication of the web-based applications, and provide the following definition:
Logic flaws are ways of using the legitimate authentication processing flow of a web-based application in a way that it results with negative impacts either on the users or the organization.
Considering business logic flaws during both the design and the maintenance of authentication procedures of web applications is challenging.
For an existing web application, finding logic flaws are costly and cumbersome for developers since these flaws are inherently linked to the application business logic. There is a need for high level characterization of the logic flaws that can be measured for decisioning.
For a web application under development, developers need guidance during the design of the authentication procedures to prevent logic flaws. The goal is to enforce the security of the design of the authentication procedure by considering human factors and design errors.
To reason about logic flaws associated with authentication and authorization, we would need to correlate usability issues (lost phone, security unawareness) with human behaviors (active session, autocomplete forms).
On this basis, we can provide a set of security and usability requirements developers and architects can use during the early design of the end-user authentication procedure to prevent logic flaws.
Skype is a well-known messaging application powered by Microsoft.In 2012, the blog pixus-ru published a combination of six expected design behaviors that led to an exploit. The flaws allowed changing the password of any Skype account by using the corresponding email address.
The design errors are as follows:
- The application allowed a user to create an account by providing a valid email address. The application, however, did not verify that the given email address exists and belongs to the current user (step in account completion to validate email association)
- The application allowed binding multiple accounts to the same email address.
Due to design error (1) an attacker could create a new Skype account based on the email address of an existing user to then initiate a password reset. Then, because the account’s binding described in the design error (2), the application asked the attacker for the name of the Skype account to reset. Finally, the attacker could change the initial user’s password and grabbed full access to the targeted Skype account.
In this case the flaw is due to the weakness of the recovery phase combined with an insufficient identity verification.
Do business logic flaws put at risk the authentication procedure of web applications?
Finding logic flaws is a complex task as such flaws are intertwined in business logic of the web application.
Listed are requirements to understand and prevent business logic flaws associated with authentication and authorization.
|Class of Logic Flaws||Conditions||Description|
|Improper Identity Management||The application failed to properly manage credential for a given identity.|
|Insufficient Identity Verification||The application does not sufficiently verify and ensure that the given identity information "objectively" exists and pertains to the claimant.|
|Recovery/Reset Deadlock||The way the registration is powered does not provide sufficient information to lately permit recovery or reset credentials.|
|Weak path||The registration phase contains multiple paths with different security level.|
|Inproper control of Interaction Frequency||The authentication mechanism does not support or improperly limits the number of attempts to get authenticated.|
|Insufficient entity authentication and verification||The authentication mechanism does not guaranty the entity’s authenticity and non-repudiation|
|Weak path||The authentication mechanism supports multiple paths with different security level.|
|Weak recovery process||The registration mechanism suffers from a weak credential recovery|
|Insufficient entity authentication||The application does not sufficiently authenticate the current entity while recovering or reseting a credential.|
Blueprint to conduct these checks as a part of CI/CD process
|Class of Logic Flaws||Conditions||Description|
|Credentials Uniqueness checks||The credential uniqueness assurance is not mandatory to the registration phase but highly recommended. It aims at easing the identity management by issuing one credential per identity. Otherwise, in case the registration phase, by design, allows binding multiple credentials to the same identity, it shall provide a mechanism to correctly manage the credential issuance.|
|Identity Verification checks||Web applications mostly rely on asserted identity from a claimant. Ensuring the authenticity of the given identity is vital for identity-based service (i.e., social network, e-commerce, banking). The registration phase shall ensure that the provided identity "objectively" exists and is verified correctly. This means that the entity that is performing the registration is the same entity that the given identity is entitled. For instance, if the registration requires an email, the process shall verify that the provided email exists and belongs to the entity that has provided the email.|
|Credential Recovery/Reset checks||Web applications commonly use identity federations with a separate Providers to ease the enrollment of a user. Afterward, some rely on the given information from the provider and link the relevant data to a local entity’s account, while others do not handle local entity’s account. This usability requirement comes to enforce the procedure by allowing the entity to give sufficient information for future credential reset and recovery (e.g., recovery by e-mail, secret question). The underlying authentication protocols (e.g., Oauth 2.0, OpenID) do not transmit the entity’s original password to the relying party application. So, the recovery or reset credential will fail if it is based on the entity’s password.|
|Path checks||Path equivalence means that every path that leads to a registration should at least match the minimum required security level. In case the registration is delegated to a separate provider, the value of the asserted security level (i.e., Token) from the provider shall at least reach the same level that the required security level. For example, if the system requires a level 2 for its identity proofing, the provider should be at least level 2 or higher. Otherwise, the registration is weakened by the path that supports a lower security level.|
|Interaction frequency limit checks||Limiting the number of attempts in a login form can effectively prevent brute forcing attacks. A malicious entity, however, may abuse that functionality to perform attacks that may affect the user or the organization. This requirement comes to ensure that the authentication process supports a mechanism that "properly" limits the number or frequency that an entity has to claim its identity (e.g., CAPTCHA). This means that such a limitation should neither lead to security issues (e.g., brute force attacks) nor to usability issues (e.g., deny of service of the legitimate user leading to invalidating active sessions, further causing account lockout).|
|Insufficient authentication and verification checks||This requirement gathers all processes that support a mechanism that does not sufficiently authenticate the legitimate entity (e.g., session hijacking, dead URL, cookie stealing). This is also relevant for strong authentication. Remote devices such as a mobile phone can be used as second authentication factor and allows the validation of the authentication procedure remotely. This requirement ensures that the authentication process supports a mechanism that guarantees the authenticity and non-repudiation of the entity during a process that requires an authentication. For instance, when an authentication can be initiated in a web application and remotely validated with a mobile application, the non-repudiation of the entity is engaged (e.g.,the mobile is something it has).The process, however, does not guaranty that the one that initiated the transaction is the one that validated it (e.g., the authenticity of the entity is not guaranteed).|
|Weak path checks||Web applications may use different means to authenticate an entity (e.g., multi-factor authentication, biometrics). Path equivalence means that the security of the authentication process is the minimum security level of the provided means. So that, designers shall fix the required security level and ensure that all other existing paths support at least that minimum security level. Otherwise, a weaker authentication path may exist. It is important to notice that the Path Equivalence Assurance involves the recovery/reset phase. For instance, a recovery phase may push down the authentication phase security level when the identity verification is not well performed.|
|Session Limitation checks||To ease the entity’s authentication, web applications leverage on cookies to keep the legitimate entity’s session active. In an ubiquitous environment, this may be considered as a logic flaw. In fact portable devices (e.g.,laptop, mobile phone) are likely to be lost or stolen. So, they expose the legitimate entity to a possible logic exploit. This requirement enforces the authentication phase by means to limit the lifetime of an active session. For instance, a long active session combining with a misuse of an entity authentication (e.g., cookie stealing) enhances the range of possible exploits that attackers can leverage.|
|Weak recovery process||It comes to ensure that no blocking states are supported by the reset or the recovery phase. In other word, this means that the legitimate user should be always able to update or recover its own credential.|
|Entity authentication checks||Although, the legitimate entity is well authenticated during the authentication phase, sensitive actions such as identity modification shall require an instant authentication. This requirement ensures that, to perform sensitive action such as password reset, the current entity should be instantly re-authenticated to rise the security level and ensure the current entity’s authenticity and non-repudiation.|
Using Ocular to create criteria blueprints
In order to effectively understand the authentication scheme associated with an application, one would need to model a propagation graph — a directed graph that models all information flow in a program. The nodes of a propagation graph are methods and/or code blocks, and edges represent explicit information flow between methods.
A classification of nodes in a propagation graph into sources, sinks and sanitizers is called an information flow specification or, just specification for brevity. Given a propagation graph and a specification, one can easily run a reachability algorithm to check if all paths from sources to sinks pass through a sanitizer.
The specification model should however extend beyond vulnerability discovery (faulty input based) to detect existence of business logic flaws (faulty logic based) as discussed here . Even going further, the specification should be able to extend itself to detect insider attacks and root-kits placed intentionally with malicious intent.
Criteria blueprints can be created as specified in table above (generic based on best practices or specific based on those set by your organization). Such blueprints can be validated in a CI/CD pipeline for every release to ensure that the application architecture is an adherence to the prescribed blueprint.
ShiftLeft's Ocular is a platform built over the foundational Code Property Graph that is uniquely positioned to deliver a specification model to query for vulnerable conditions, business logic flaws and insider attacks that might exist in your application's code base.
To request a free trail and demo , please signup with https://www.shiftleft.io/ocular/