With this article, we list some of the common web application attacks, 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 previous session ID is null, empty, or no session with Session ID= previous session ID exists, create a new session.
- Generate new session identifier new Session ID with a secure random number generator.
- Identify the session with new session ID and no longer by previous session ID
- Transmit new Session ID to client
Frame Injection
when an attacker inject 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 at client side as well as sever 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 Character Encoding
< < or < > > or > & & or & ” " or ” ‘ ' or ‘ ( ( ) ) # # % % ; ; + + – –
Directory Listing Enabled
When affected resources allow directories on 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 remove them from 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 Application sends query parameters in GET request which is not considered as 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 POST request instead of GET.
Inadequate Account Lockout and session timeout Policies
when application doesn’t have account lockout protection threshold mechanism configured. Also when session time-out is not set in application.
Impact
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 users’ accounts 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, application should end the session. It is recommended to assign timeout property (for 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 web site. 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 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 on how a site works.
An Attacker can extract company-related internal information (Team member, location of data or backup) from 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 in 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, 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 which 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 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.
