Testing your application for business logic vulnerabilities is the digital version of a deep sea exploration. On the surface, you can identify various technical vulnerabilities, similar to how people snorkeling may come into contact with sandshark. However, the business logic vulnerabilities that hide within the application’s business logic are more difficult to detect and can be more dangerous, much like the box jellyfish. 

Hidden parameters in web applications are the developers’ version of the box jellyfish since they’re difficult to detect but can have a critical impact on security. 

What are hidden parameters in web applications?

Hidden parameter refers to an HTML input element that web developers use to store data while preventing users from seeing or modifying it through the user interface, typically represented as <input type=”hidden”>. However, these attributes may be visibility for people using a browser’s developer tool or “View Source” functionality. 

The HTML input elements can be things like HTTP Headers, cookies, or parameters that contain information like:

• User identifiers: sensitive information like user ID, IP address, email, or phone number
• Session attributes: information like current webpage URL or step on multi page forms
• UTM parameters: data about users reaching forms from marketing campaigns
• Database record ID: storing the unique ID of a database record to be modified
• Security token: token generated to mitigate cross-site request forgery (CSR) attack risks

What is parameter tampering?

A parameter tampering attack occurs when malicious actors make unauthorized modification to a URL’s parameters or a web application’s form data fields. By manipulating the parameters that the client and server exchange, the malicious actors can modify additional application data, including user credentials, user permissions, and product data listed on an e-commerce website. 

Since hidden parameters are not visible or easily identifiable in the user interface, threat actors target them when trying to evade detection. 

What do attacks that exploit hidden parameters look like?

A hidden field manipulation attack occurs when threats actors use these hidden fields to bypass security measures, gain unauthorized access to data, or engage in other malicious activities. 

Authentication bypass

Web applications often use hidden HTML form fields to session tokens that uniquely identify users. Threat actors can leverage open-source or paid tools to unhide the form fields, remove input field limits, and remove form validation. 

For example, if a malicious actor can identify that a hidden field’s value is set to a legitimate user’s ID, they can change the input to their own ID to gain unauthorized access.

Privilege escalation

Attackers that gain bypass authentication and only gain standard access can use the hidden parameter to elevate privileges. If session variables contain privileges or roles, then the attackers can manipulate these values to gain more access. 

For example, if the application sends an HTTP POST request that includes <input type=”hidden” name=”permissions” value=”3”>, attackers can change the value element to “useradmin” to elevate the privileges. 

Payment manipulation

A web application may store product data, like price,  on the client-side rather than server-side by using a hidden parameter. An application may also use the HTTP POST method to send inputs to a URL. Attackers can manipulate the hidden fields by altering a local copy of the page or typing different parameters into the browser’s location bar. 

For example, an e-commerce website may store sale price information as a hidden parameter, like <input type=”hidden” name=”price” value=”$20”>. Attackers can tamper with the various URL parameters, including those developers thought were hidden, to alter the sale price to $1. By altering the hidden parameter, they can purchase the item without the application recognizing the attack. 

How to prevent hidden parameter tampering

Hidden parameter attacks often arise from business logic vulnerabilities where the threat actors use an application’s legitimate function in an unexpected way. Mitigating risks arising from these vulnerabilities requires a combination of automated and manual code review. 

Identify all third-party components and dependencies

You should create a Software Bill of Materials (SBOM) that identifies all:

• Third-party libraries and components
• Dependencies 

Understand data flows

You need to know how data flows across your application to gain visibility into potential business logic flaws. To gain this insight, you need to understand:

• Data movement across modules
• Controls paths that drive program execution
• Business protocols and multi-stage processes

Use threat modeling

Threat modeling gives you a structured process for identifying the different ways malicious actors can use your application in unintended ways to undermine its security. You should understand your application’s intended use so you can look at different ways to manipulate it. 

Automate vulnerability scans

In some cases, your vulnerability scanner can review headers, cookies, and parameters to identify sensitive data that they store. 

Engage in penetration testing

Securing applications from hidden parameters attacks means thinking like threat actors. Penetration testing leverages your threat modeling to determine whether attackers can compromise your application’s security using hands-on-keys methodologies. 

Prioritize remediation actions

For faster time-to-market, you need to know which vulnerabilities attackers can compromise within the context of your unique source code. Leveraging real-world threat intelligence to detail the exploits, threat actors, ransomware, and botnets exploiting vulnerabilities in the wild gives you insights into which actions you should take first to ensure you’re pushing out the most secure code possible.

Qwiet AI: Analyzing Your Source Code for Hidden Parameters 

With Qwiet AI’s preZero platform, you can identify and remediate your application’s most critical and impactful vulnerabilities. Our Code Property Graph (CPG) breaks down code into its fundamental parts so that you have a comprehensive component inventory. Our lightning fast scans can help you  discover source code vulnerabilities quickly. To understand how malicious actors evolve their supply chain attacks, you can use Qwiet Blacklight, the only threat intelligence feed focused on application security. 

Try Qwiet AI’s preZero platform for free to see how it can help you mitigate risks arising from hidden parameters.