Web Application Attacks – Types, Impact & Mitigation – Part-2

With this article, we list some of the common Web Application Attacks part-2, impacts, and possible mitigation. In part -2 we are covering the following attacks.

• Session Fixation
• Frame Injection
• Directory Listing Enabled
• Query Parameter Sent In Get Request
• Inadequate Account Lockout and session timeout Policies
• Improper Error Handling – Information Disclosure
• Directory Enumeration via Error Response

Session Fixation

The session fixation attack is a class of Session Hijacking, which steals the established session between the client and the Web Server after the user logs in.

Instead, the Session Fixation attack fixes an established session on the victim’s browser, so the attack starts before the user logs in

Impact

An attacker can trick a legitimate user to follow a link that has a session ID set into it. If the user follows the link then the session ID set by the attacker will be sent to the application in the cookie.

The application will then set this as the session ID of a legitimate user. After this attacker can hijack the session and compromise the account of the legitimate user with the help of the fixed session.

Mitigation

• Accept only server-generated session IDs
• Get previous Session Identifier from HTTP request.
• If the previous session ID is null, empty, or no session with Session ID= previous session ID exists, create a new session.
• Generate a new session identifier new Session ID with a secure random number generator.
• Identify the session with the new session ID and no longer by the previous session ID
• Transmit new Session ID to the client

Frame Injection

when an attacker injects a frame or an IFrame tag with malicious content which resembles the attacked site.

Impact

An incautious user may browse it and not realize that he is leaving the original site and surfing to a malicious site. The attacker may then lure the user to log in again, thus acquiring his login credentials

Mitigation

The application must perform validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed.

Any meta-characters should be filtered for, in all input-accepting fields, both on the client side as well as the server side. Server-side validation is mandatory. The validation should not attempt to identify active content and remove, filter, or sanitize it.

There are too many types of active content and too many ways of encoding it to get around filters for such content. Encoding user-supplied output can also defeat XSS vulnerabilities by preventing inserted scripts from being transmitted to users in an executable form.

The application must be configured to filter meta-characters and unexpected characters such as Character Encoding
< &lt; or < > &gt; or > & &amp; or & ” &quot; or ” ‘ &apos; or ‘ ( ( ) ) # # % % ; ; + + – –

Directory Listing Enabled

When affected resources allow directories on the web server to be listed.

Impact

The severity of this vulnerability depends upon the information disclosed in the directories. Some critical information regarding web services being used was disclosed through directories being listed.

Mitigation

Access to such directories/information should always be secured by putting authentication; authorization and access control or if not necessary then removing them from the web directory.

While this is not, in and of itself, a bug, it is recommended that these directories should be manually inspected to ensure that they are in compliance with company security standards and are not revealing any critical information.

Query Parameter Sent In Get Request

when the Application sends query parameters in a GET request which is not considered a good practice

Impact

An attacker can intercept the request and manipulate these parameters which can lead to further attacks.

Mitigation

It’s recommended to sensitive information should always be sent in a POST request instead of a GET.

Inadequate Account Lockout and session timeout Policies

when the application doesn’t have an account lockout protection threshold mechanism configured. Also when session time-out is not set in the application.

Impact

A brute force attack can be carried out on the password-based authentication mechanism.

Mitigation

Account lockout is a security feature often present in applications as a countermeasure to the brute force attack on the password-based authentication mechanism of the application.

After a certain number of failed login attempts, the user’s account should be disabled for a certain period of time or until it is unlocked by an administrator.

Also If the user does not refresh or request a page within the specific time period, the application should end the session. It is recommended to assign a timeout property (e.g. 10 minutes) to the session object.

Improper Error Handling – Information Disclosure

when an application is not properly protecting application internal information & exception error.

Impact

Improper handling of errors can introduce a variety of security problems for a website.

The most common problem is when detailed internal error messages such as stack traces, database dumps, and error codes are displayed to the user. These messages reveal implementation details that should never be revealed.

Such details can provide hackers with important clues on potential flaws in the site and such messages are also disturbing to normal users. Even when error messages don’t provide a lot of detail, inconsistencies in such messages can still reveal important clues about how a site works.

An Attacker can extract company-related internal information (Team member, location of data, or backup) from an application & can perform social engineering attack.

Mitigation

• Ensure that the entire software development team shares a common approach to exception handling.
• Disable or limit detailed error handling. In particular, do not display debug information to end users, stack traces, or path information.
• Ensure that secure paths that have multiple outcomes return similar or identical error messages at roughly the same time.
• If this is not possible, consider imposing a random wait time for all transactions to hide this detail from the attacker.
• Various layers may return fatal or exceptional results, such as the database layer, and the underlying web server (IIS, Apache, etc).
• It is vital that errors from all these layers are adequately checked and configured to prevent error messages from being exploited by intruders.
• Be aware that common frameworks return different HTTP error codes depending on if the error is within your custom code or within the framework’s code.
• It is worthwhile creating a default error handler that returns an appropriately sanitized error message for most users in production for all error paths.
• Overriding – Although security through obscurity, choosing to override the default error handler so that it always returns “200” (OK) error screens reduces the ability of automated scanning tools from determining if a serious error occurred.
• While this is “security through obscurity,” it can provide an extra layer of defense.
• Some larger organizations have chosen to include random/unique error codes amongst all their applications.
• This can assist the help desk with finding the correct solution for a particular error, but it may also allow attackers to determine exactly which path an application failed.

Directory Enumeration via Error Response

When default error responses are set on the remote web server.

Impact

The Web server responds with the default error response for errors like “file/directory not found ”, “forbidden access“ etc. With this configuration, an attacker can enumerate the existing files /directories as the default 403 errors confirm that the files actually exist.

Mitigation

It is recommended that the web server should be configured with a customized and common error response in place of 404 and 403 error responses. This customized error response should not reveal any information related to the web server, underlying OS or the webserver files/directories.

You can read part 3 Here.

Also Read

Web Application Attacks – Types, Impact & Mitigation – Part-1