Core Defences Mechanism in Web Applications (original) (raw)

Last Updated : 30 Sep, 2022

We divide core defences in web applications into three areas: Handling User Access, Handling User Input, and Handling Attackers. These are explained as following below.**1. Handling User Access:**First task is to handle access according to user (admin user, anonymous user, normal user). Most web applications handle access using a trio (I named it as ASA) of interrelated security mechanisms: Authentication, Session management, and Access control are as explained below.

1. **Authentication -**Username and password mechanism to check validity of user or anonymous user is the basic one. Nowadays, even more advanced mechanisms like two step verification are also implemented. So, hackers are always check these mechanism to defects.Brute force is the most common one. Limitations and input validations must be applied to these inputs to protect the basic functionality of the application.

2. **Session management -**After, user passed the first step of authentication it may have to manage and provide access management, which is mostly done by token mechanism. The main areas of vulnerability arise from defects in how tokens are generated, enabling an attacker to guess the tokens issued to other users, and defects in how tokens are handled, enabling an attacker to capture other users’ tokens. So, programmer can implement token validity time check and difficult encrypted tokens which are not easily guessed by an attacker .

3. **Access Control -**On the basis of received credentials application decided the level of access and due to complex nature these mechanism are often defective. Developers often make ? awed assumptions about how users will interact with the application and frequently make oversights by omitting access control checks from some application functions. So, provide proper mechanism.

**2. Handling User Input:**Mostly flaws are found in input handling of an application. Any unwanted input may even lead to data breach by SQL injection or Token loose by stored XSS and many more attacks may in play and harm your application. So, it becomes very necessary to make these mechanism strong. User input can be user-name, comments, search, forms, sometimes cookies are also used.**Approaches to handle User Input -**We can not guess user mind or methodology while inputting. So, we should use approach will "RKB" method which is "Reject Known Bad".

• **Reject Known Bad -**This, method consists of a blacklist according to which characters are blocked. In general, this is regarded as the least effective approach to validating user input, for two main reasons. First, a vulnerability in a web application can be exploited using a wide variety of input, and second, techniques for exploitation are at a constant change. Black-list filters can be bypassed as:

1. If SELECT is blocked, try SeLeCt
2. If or 1=1-- is blocked, try or 2=2--
3. If alert(‘xss’) is blocked, try prompt(‘xss’)
   Filters designed to block specific keywords can be bypassed by using nonstandard characters between expressions to disrupt the tokenizing performed by the application. For example:
   SELECT/foo/username, password/foo/FROM/foo/users
   NULL byte bypassing example. For example:
   %00alert(1)

• **Accepts known Good (AKG) -**This approach is reciprocal of "RKB" approach in which we can not reject the bad inputs. Instead, we can create a white-list. So, application can only accept only listed inputs and all other inputs are rejected by the applications. This approach is more secured than the reject bad known scheme.

• **Sanitization -**In this approach data received must be sanitized. Malicious characters may be removed from the data, only safe characters are left, or they may be suitably encoded or “escaped” before further processing is performed. For example, the usual defence against cross-site scripting attacks is to HTML-encode dangerous characters before these are embedded into pages of the application.But it may be bypassed if attacker understand the sanitization mechanism.

• **Safe Data Handling -**Most of web application vulnerabilities arise because user-supplied data is processed in unsafe ways. Vulnerabilities often can be ignored not by validating the input itself but by ensuring that the processing that is performed on it is safe. In some conditions, safe programming methods are available that avoid common problems. For an instance, SQL injection attacks can be prevented through the correct use of parameterized queries for database access.

• **Semantic Checks -**However, with some vulnerabilities the input supplied by the attacker is similar to the input that an ordinary, non-malicious user may submit. The thing makes it malicious is the different circumstances under which it is submitted. For an instance, an attacker might seek to gain access to another user’s bank account by changing an account number transmitted in a hidden form field. No amount of syntactic validation will distinguish between the user’s data and the attacker’s. To avoid unauthorized access, the application needs to validate that the account number submitted belongs to the user who has submitted it.

• **Multi-step Verification -**We all are using many secure services these days like gmail etc, which provides us two step or we can say multi-step verification. But all these verification is for user identification rather than data verification.

**3. Handling Attackers:**We must consider these points while handling errors: Handling errors, Maintaining audit logs, Alerting administrators, and Reacting to attacks are explained as following below.

1. **Handling Error -**In short term attackers first trying to collect information about application. So, all the error mechanisms in application must not provide any descriptive, i.e., it must not leak any information about databases, system architecture, or path details etc.

2. **Maintaining Audit -**Audit logs are important while investigate events such an incident, effective audit logs should enable the application’s owners to understand exactly what has taken place, which vulnerabilities were exploited, whether the attacker gained unwanted access to data or performed any unauthorized actions, and, as far as possible, provide evidence of the intruder’s identity. All events relating to the authentication functionality, Key transactions, Any requests containing known attack strings that indicate overtly malicious intentions.

3. **Alerting administration -**There may be some mechanism which may alert admin of the applications, about any unusual activity in the application like high ping request from a particular IP.

4. **Reacting to Attack -**Many security-critical applications contain built-in mechanisms to react defensively to users who are identified as potentially malicious. Because most applications are different and attacker have to perform different test to find vulnerability and we will identify many of these requests as potentially malicious and block them. For this reason, some web applications take automatic reactive measures to frustrate the attacker who is working in this way. For an instance, they might respond increasingly slowly to the attacker’s requests or terminate the attacker’s session, requiring him to log in or perform other steps before continuing the attack.