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.
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
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.
when an attacker injects a frame or an IFrame tag with malicious content which resembles the attacked site.
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
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
< < or < > > or > & & or & ” " or ” ‘ ' or ‘ ( ( ) ) # # % % ; ; + + – –
When affected resources allow directories on the web server to be listed.
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.
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.
when the Application sends query parameters in a GET request which is not considered a good practice
An attacker can intercept the request and manipulate these parameters which can lead to further attacks.
It’s recommended to sensitive information should always be sent in a POST request instead of a GET.
when the application doesn’t have an account lockout protection threshold mechanism configured. Also when session time-out is not set in the application.
A brute force attack can be carried out on the password-based authentication mechanism.
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.
when an application is not properly protecting application internal information & exception error.
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.
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 access“ etc. With this configuration, an attacker can enumerate the existing files /directories as the default 403 errors confirm that the files actually exist.
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
Recent research has revealed that a Russian advanced persistent threat (APT) group, tracked as "GruesomeLarch"…
Microsoft's Digital Crimes Unit (DCU) has disrupted a significant phishing-as-a-service (PhaaS) operation run by Egypt-based…
The Russian threat group TAG-110, linked to BlueDelta (APT28), is actively targeting organizations in Central…
Earth Kasha, a threat actor linked to APT10, has expanded its targeting scope to India,…
Raspberry Robin, a stealthy malware discovered in 2021, leverages advanced obfuscation techniques to evade detection…
Critical infrastructure, the lifeblood of modern society, is under increasing threat as a new report…