what is Parameter Tampering

MRunal
Jun 21 · 7 min read

Parameter Tampering: Special Characters

Summary

Parameter manipulation involves tampering with URL parameters to retrieve information that would otherwise be unavailable to the user. Risks from exploitation depend upon what parameter is being modified, and the method by which it is submitted to the web application server. Parameter manipulation attacks can be used to achieve a number of objectives, including disclosure of files above the web root, extraction of information from a database and execution of arbitrary operating-system level commands. Recommendations include adopting secure programming techniques to ensure that only expected data is accepted by an application.

Explanation

The impact of this particular vulnerability depends upon what parameter is being manipulated, and how it is being submitted to the application server. At the least, an attacker would likely be able to gain information useful in orchestrating further, and more damaging, attacks. However, it is not out of the realm of possibility, or even probability, that this vulnerability could be utilized to take complete control of the system. Values that can be modified include:

Query strings: Web applications often use query strings as a simple method of passing data from the client and the server. Query strings are a way to add data calls to a hyperlink, and then retrieve that information on the linked page when it is displayed. By manipulating query strings, an attacker can easily steal information from a database, learn details about the architecture of your web application, or possibly execute commands on your web server.

Post data: Since manipulating a query string is as easy as typing text in the address bar of a browser, many web applications rely on the POST method coupled with the use of forms rather than GET to pass data between pages. Since browsers normally don’t display POST data, some programmers are lulled into thinking that it is difficult or impossible to change the data, when in fact the opposite is true.

Headers: Both HTTP requests and responses use headers to deliver information about the HTTP message. A developer may not consider HTTP headers as areas of input, even though many web applications will log headers such as the “referrer” or “user-agent” to a database for traffic statistics.

Cookies: Many web applications use cookies to save information (for example, user ID’s and timestamps) on the client’s machine. By changing these values, or poisoning the cookie, malicious users can gain access to the accounts and information of other users. As well, attackers can also steal a user’s cookie and gain direct access to the user’s account, bypassing the need to enter an ID and password or other form of authentication.

Recommendation

For Development:

This problem arises from improper validation of characters accepted by the application. Any time a parameter is passed into a dynamically generated web page, it must be assumed that the data could be incorrectly formatted. The application should contain sufficient logic to handle the situation of a parameter not being passed in or being passed incorrectly. Keep in mind how the data is being submitted, as a result of a GET or a POST. Cookies should be treated the same as parameters when developing secure and stable code. The following recommendations will help to ensure you are delivering secure web applications.

  • Stringently define the data type:
    Stringently define the data type (for instance, a string, an alphanumeric character, etc) that the application will accept. Validate input for improper characters. Adopt the philosophy of using what is good instead of what is bad. Define the allowed set of characters. For instance, if a field is to receive a number, only let that field accept numbers. Define the maximum and minimum data lengths for what the application will accept.
  • Parameter not being passed:
    If a parameter is expected to be passed to a dynamic web page and is omitted, the application should provide an acceptable error message to the user. Also, NEVER assume that a parameter is being passed before using it in an application.
  • Parameter of incorrect format:
    A parameter should never be assumed to be of a valid format. This is especially true if the parameter is being passed to a SQL database. Any string that is passed directly to a database without first being checked for proper format can be a major security risk. Also, just because a parameter is normally provided by a combo box or hidden field, do not assume the format is correct. A hacker will try altering these parameters first if trying to break into your site.
  • Allowing file names to be passed in via a file name:
    If a parameter is being used to determine which file to process in any way, never allow the file name to be used before it is verified as valid. Specifically, you should test for the existence of characters that indicate directory traversal such as …/, c:\ and /.
  • Storing of critical data in hidden parameters:
    Many programmers make the mistake of storing critical data in a hidden parameter or cookie. They assume that since the user doesn’t see it, it’s a good place to store data such as price, order number, etc. Both hidden parameters and cookies can be manipulated and returned to the server, so never assume the client returned what you set via a hidden parameter or cookie.

For Security Operations:

Issues that arise from parameter manipulation will ultimately need to be rectified in the application code.

For QA:

For security reasons, it is important to test the web application not only as a normal user, but also as a malicious one. Simple manual testing can include changing numeric parameter values sequentially, modifying cookie values, or including letters in number parameters to see how the application responds. This assessment will thoroughly test parameters for susceptiblity to manipulation.

References

For Development:

This problem arises from improper validation of characters accepted by the application. Any time a parameter is passed into a dynamically generated web page, it must be assumed that the data could be incorrectly formatted. The application should contain sufficient logic to handle the situation of a parameter not being passed in or being passed incorrectly. Keep in mind how the data is being submitted, as a result of a GET or a POST. Cookies should be treated the same as parameters when developing secure and stable code. The following recommendations will help to ensure you are delivering secure web applications.

  • Stringently define the data type:
    Stringently define the data type (for instance, a string, an alphanumeric character, etc) that the application will accept. Validate input for improper characters. Adopt the philosophy of using what is good instead of what is bad. Define the allowed set of characters. For instance, if a field is to receive a number, only let that field accept numbers. Define the maximum and minimum data lengths for what the application will accept.
  • Parameter not being passed:
    If a parameter is expected to be passed to a dynamic web page and is omitted, the application should provide an acceptable error message to the user. Also, NEVER assume that a parameter is being passed before using it in an application.
  • Parameter of incorrect format:
    A parameter should never be assumed to be of a valid format. This is especially true if the parameter is being passed to a SQL database. Any string that is passed directly to a database without first being checked for proper format can be a major security risk. Also, just because a parameter is normally provided by a combo box or hidden field, do not assume the format is correct. A hacker will try altering these parameters first if trying to break into your site.
  • Allowing file names to be passed in via a file name:
    If a parameter is being used to determine which file to process in any way, never allow the file name to be used before it is verified as valid. Specifically, you should test for the existence of characters that indicate directory traversal such as …/, c:\ and /.
  • Storing of critical data in hidden parameters:
    Many programmers make the mistake of storing critical data in a hidden parameter or cookie. They assume that since the user doesn’t see it, it’s a good place to store data such as price, order number, etc. Both hidden parameters and cookies can be manipulated and returned to the server, so never assume the client returned what you set via a hidden parameter or cookie.

For Security Operations:

Issues that arise from parameter manipulation will ultimately need to be rectified in the application code.

For QA:

For security reasons, it is important to test the web application not only as a normal user, but also as a malicious one. Simple manual testing can include changing numeric parameter values sequentially, modifying cookie values, or including letters in number parameters to see how the application responds. This assessment will thoroughly test parameters for susceptiblity to manipulation.


=======================================

Best book for Hacking and Penetration Testing

Penetration Testing: A Hands-On Introduction to Hacking — https://amzn.to/2YUvteh

The Hacker Playbook 3: Practical Guide To Penetration Testing — https://amzn.to/2KEDonb

Mastering Modern Web Penetration Testing — https://amzn.to/2Hct6IX

Kali Linux Web Penetration Testing Cookbook: Identify, exploit, and prevent web application vulnerabilities with Kali Linux 2018.x, 2nd Edition — https://amzn.to/31IjPQG

=======================================

MRunal

Written by

MRunal

Blogger && Security Researcher && digital forensic analyst

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade