Saturday, April 13, 2024

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


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.


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


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


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.

Query Parameter Sent In Get Request

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.

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.


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.

Improper Error Handling – Information Disclosure

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.


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


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


Latest articles

Alert! Palo Alto RCE Zero-day Vulnerability Actively Exploited in the Wild

In a recent security bulletin, Palo Alto Networks disclosed a critical vulnerability in its...

6-year-old Lighttpd Flaw Impacts Intel And Lenovo Servers

The software supply chain is filled with various challenges, such as untracked security vulnerabilities...

Hackers Employ Deepfake Technology To Impersonate as LastPass CEO

A LastPass employee recently became the target of an attempted fraud involving sophisticated audio...

Sisence Data Breach, CISA Urges To Reset Login Credentials

In response to a recent data breach at Sisense, a provider of data analytics...

DuckDuckGo Launches Privacy Pro: 3-in-1 service With VPN

DuckDuckGo has launched Privacy Pro, a new subscription service that promises to enhance user...

Cyber Attack Surge by 28%:Education Sector at High Risk

In Q1 2024, Check Point Research (CPR) witnessed a notable increase in the average...

Midnight Blizzard’s Microsoft Corporate Email Hack Threatens Federal Agencies: CISA Warns

The Cybersecurity and Infrastructure Security Agency (CISA) has issued an emergency directive concerning a...

Top 3 SME Attack Vectors

Securing the Top 3 SME Attack Vectors

Cybercriminals are laying siege to small-to-medium enterprises (SMEs) across sectors. 73% of SMEs know they were breached in 2023. The real rate could be closer to 100%.

  • Stolen credentials
  • Phishing
  • Exploitation of vulnerabilities

Related Articles