

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. 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.

Authentication –

Username and password mechanism to check validity of user or anonymous user is the basic one. Now days, 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. 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 . 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.





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: alert(1)

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. 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.

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.

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.

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.



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.