APIs will continue to drive business and accelerate digital transformation this year to the extent that nearly no other technology can; according to the 19th Developer Economics survey by Slashdata, almost 90% of all developers use APIs. This makes them a target for attackers who aren’t afraid to engage in any tactic, especially tried-and-true methods like parameter tampering attacks - malicious API attack traffic surged 117% from 2021 to 2022. While well known, these attacks can be successful due to security holes left by the speedy development culture that drives API usage in the first place. To responsibly employ APIs within an organization, these holes need to be looked at and parameter tampering attacks addressed.
Define Parameter Tampering
According to OWASP, a web parameter tampering attack is “based on the manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc.” The compromised data is usually found in stored cookies, hidden form fields, or URL Query Strings and is intended for optimal site functionality.
In other words, there are unseen business logic gaps within the setup of a web server, web page, or web-based query where bad actors can get through. As OWASP continues, “the attack success depends on integrity and logic validation mechanism errors, and its exploitation can result in other consequences including XSS, SQL Injection, file inclusion, and path disclosure attacks.”
Common examples of Parameter Tampering techniques APIs can fall prey to include the following:
By taking advantage of a vulnerable input form, attackers can inject malicious code into a web page that will initiate every time an unsuspecting user clicks on the link. XSS attacks can then obtain cookies, session tokens or other valuable data intended for the legitimate website and even rewrite the HTML of the page.
A SQL injection attack is designed to give the attacker access to back-end server information they otherwise would not have. Using an injection of malicious SQL code – a SQL query – hackers can trick the database into giving them unauthorized information. As OWASP states, “a successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.”
Often, sites will employ hidden fields to host status information for the Web application. Designed for ease of use, convenience also presents an issue. If a hidden field contains HTML specifying the price and quantity of an item, a hacker could find and alter the code, changing the price and scamming the organization out of the intended amount.
If an HTML form submits its results using the GET method, all form parameters will appear in the next URL query string the user sees and can subsequently be altered from there. For example, <http://www.examplebank.com/pretend.asp?accountnumber=123456> can be changed easily to <http://www.examplebank.com/pretend.asp?accountnumber=987654> and funds can be transferred to the wrong account.
URL Attribute Parameters
When it comes to viewing or sharing permissions, those can also be displayed and changed in the query string of the URL. As an example, a Web application that allows one user to view content only <http://www.examplebank.com/getpage.asp?id=111222&mode=readonly> could be tampered with to allow the same user to edit as well <http://www.examplebank.com/getpage.asp?id=111222&mode=readwrite>, changing what the user sees, what the customer sees, and what ultimately happens on the website.
Preventing Parameter Tampering Attacks
Fortunately, these schemes are easily preventable, making it easy to secure your API against these low-grade (but high payout) attacks.
Proper security-mindedness in the programming stage (the “shift left” approach) is incredibly effective in combatting XSS and SQL injection attacks. By denying certain characters, adding a strict character count, or allowlisting, attackers will be limited in their scope and hopefully stymied in their attempts at data theft or command execution.
Never store critical data in hidden parameters
This might go without saying, but organizations should stop the practice of hiding critical data – product numbers, prices, numerical count – in either cookies or hidden parameters because this puts them and their data at inherent risk.
Web Application Firewall (WAF)
A Web Application Firewall (WAF) blocks bad IPs and filters and monitors HTTP traffic between the web application and the internet. It is signature-based and is designed to look for patterns and block known vulnerabilities. However, due to limited resources, WAFs are unable to decode nested encoding, inspect the entire payload, and handle all protocols - rendering them insufficient against modern API-targeted threats (and malicious traffic accounts for over 2.1% of all API traffic).
Rigorous application testing should be applied in addition to all of the above best practices, as spotting a vulnerability in development is far better than falling prey to one down the road.
Securing against modern threats
Ultimately, transaction-based attacks (the kind that rely on signatures) were a key attack vector of the past. Traditional methods – like a WAF – are designed to spot known patterns and act as a firewall, blocking the known threats and mitigating these challenges. However, as API usage has evolved, the attacks have too, and security must follow suit.