In previous tutorial we realized about a number of the common web application attacks, impacts, and doable mitigation. In half -2 we’re masking the under listed web application attack strategies and we are going to learn fundamentals about them.
- 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 through Error Response
If you need to undergo half – 1, you’ll be able to read right here
The session fixation attack is a category 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 a longtime session on the victim’s browser, so the attack begins earlier than the user logs in.
An attacker can trick a authentic user to observe 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 probably be despatched to the application within the cookie.
The application will then set this because the session ID of a authentic user. After this attacker can hijack the session and compromise the account of the authentic user with the assistance of the mounted session.
- Accept solely 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 brand new session.
- Generate new session identifier new Session ID with a secure random quantity generator.
- Identify the session with new session ID and not by previous session ID
- Transmit new Session ID to client
when an attacker inject a body or an IFrame tag with malicious content material which resembles the attacked site.
An incautious user might browse it and never notice that he’s leaving the unique site and surfing to a malicious site. The attacker might then lure the user to log in once more, thus buying his login credentials
The application should carry out validation of all headers, cookies, question strings, type fields, and hidden fields (i.e., all parameters) towards a rigorous specification of what must be allowed.
Any meta-characters must be filtered for, in all input accepting fields, each at client aspect in addition to sever aspect. Server aspect validation is obligatory. The validation shouldn’t try and establish active content material and remove, filter, or sanitize it.
There are too many varieties of active content material and too some ways of encoding it to get round filters for such content material. Encoding user provided output also can defeat XSS vulnerabilities by stopping inserted scripts from being transmitted to customers in an executable type.
The application have to be configured to filter meta-characters and surprising characters such Character Encoding
< < or < > > or > & & or & ” " or ” ‘ ' or ‘ ( ( ) ) # # % % ; ; + + – –
Directory Listing Enabled
When affected resources enable directories on web server to be listed.
The severity of this vulnerability relies upon upon the information disclosed within the directories. Some essential information concerning web services getting used was disclosed by means of directories being listed.
Access to such directories / information ought to at all times be secured by placing authentication; authorization and entry control or if not vital then remove them from web directory.
While this isn’t, in and of itself, a bug, it is strongly recommended that these directories must be manually inspected to make sure that they’re in compliance with firm security requirements and aren’t revealing any essential information.
Query Parameter Sent In Get Request
When Application sends question parameters in GET request which isn’t thought of as an excellent observe
An attacker can intercept the request and manipulate these parameters which may result in additional attacks.
It’s really helpful to delicate information ought to at all times be despatched in POST request as a substitute of GET.
Inadequate Account Lockout and session timeout Policies
when application doesn’t have account lockout safety threshold mechanism configured. Also when session time-out just isn’t set in application.
Brute force attack may be carried out on the password primarily based authentication mechanism.
Account lockout is a security function usually present in applications as a countermeasure to the brute force attack on the password-based authentication mechanism of the application.
After a sure variety of failed login makes an attempt, the customers’ accounts must be disabled for a sure interval of time or till it’s unlocked by an administrator. Also If the user doesn’t refresh or request a page inside the particular time interval, application ought to finish the session. It is really helpful to assign timeout property (for e.g. 10 minutes) to the session object.
Improper Error Handling – Information Disclosure
when an application just isn’t correctly defending application internal information & exception error.
Improper dealing with of errors can introduce a wide range of security issues for a web site. The most common problem is when detailed internal error messages similar to stack traces, database dumps, and error codes are exhibited to the user. These messages reveal implementation particulars that ought to by no means be revealed.
Such particulars can present hackers necessary clues on potential flaws within the site and such messages are additionally disturbing to regular customers. Even when error messages don’t present plenty of element, inconsistencies in such messages can nonetheless reveal necessary clues on how a site works.
An Attacker can extract firm-associated internal information (Team member, location of data or backup) from application & can carry out social engineering attack.
- Ensure that your complete software improvement team shares a common strategy to exception dealing with.
- Disable or restrict detailed error dealing with. In explicit, don’t display debug information to finish customers, stack traces, or path information.
- Ensure that secure paths which have a number of outcomes return related or equivalent error messages in roughly the identical time. If this isn’t doable, think about imposing a random wait time for all transactions to cover this element from the attacker.
- Various layers might return deadly or distinctive outcomes, such because the database layer, the underlying web server (IIS, Apache, and many others). It is important that errors from all these layers are adequately checked and configured to forestall error messages from being exploited by intruders.
- Be conscious that common frameworks return completely different HTTP error codes relying on if the error is inside your customized code or inside the framework’s code.It is worth it making a default error handler which returns an appropriately sanitized error message for many customers in manufacturing for all error paths.
- Overriding – Although security by means of obscurity, selecting to override the default error handler in order that it at all times returns “200” (OK) error screens reduces the power of automated scanning tools from figuring out if a severe error occurred. While that is “security through obscurity,” it could possibly present an additional layer of protection.
- Some bigger organizations have chosen to incorporate random / distinctive error codes amongst all their applications. This can help the assistance desk with discovering the right resolution for a specific error, however it might additionally enable attackers to find out precisely which path an application failed.
Directory Enumeration through Error Response
When default error responses are set on the remote web server.
The Web server responds with the default error response for errors like “file/directory not found ”, “forbidden entry“ and many others. With this configuration, an attacker can enumerate the present files /directories because the default 403 errors affirm that the files truly exist.
It is really helpful that web server must be configured with a personalized and common error response rather than 404 and 403 error responses. This personalized error response shouldn’t reveal any information associated to the web server, underlying OS or the webserver files/directories.