Test or Fail: List of Possible User Input For a Web Application
Security for Everyone
The most dangerous areas for web applications are the user inputs, of course in terms of cyber security. Generally, user inputs can be a query parameter, request payload, or request headers. If you are a technical guy, you realized that these are part of an HTTP request. In this article, we'll show you a few examples of user input and attack vectors.
User input comes in many forms. It can be as simple as a query parameter in the URL, or it can be more complex, like a JSON object in the request body or as value of a HTTP header.
Understanding user inputs (part of an attack vector of a web app) is very very important. So, let's say you want to scan securityforeveryone.com for vulnerabilities. But which parameters do you want to test? The search area at the blog page, user auth form, and product pages? You can either start a full scan to test all vulnerabilities or you can use a simple scanner tool by selecting a user input.
Why User Inputs Are Dangerous?
User inputs are dangerous because they can be used to exploit vulnerabilities in web applications. For example, if you're not validating user input, an attacker can easily inject SQL code into the text box and execute a SQL query. This is called SQL Injection.
Another example of a dangerous user input is cross-site scripting (XSS). If you're not sanitizing the user input, an attacker can easily inject malicious JavaScript code into the text box. This code will be executed by the browser when the user visits the page. The attacker can use this to steal cookies, session tokens, or sensitive information from other users who visit the page.
So, how do you protect against these attacks? The answer is input validation.
To better understand what they are, let's see some examples of user inputs.
User Inputs In the Query Parameters
The following are some examples of query parameters that can be used in a URL:
http://securityforeveryone.com/?name=John&age=21
http://securityforeveryone.com/?q=searchForThis
http://securityforeveryone.com/?page=2&sortby=id
As you can see, query parameters can be used for various purposes, like passing information about the user (name and age in the first example), or sending search keywords (second example). Query parameters can also be used for pagination (third example).
Sometimes these parameters can be shown as a slug such as:
http://securityforeveryone.com/blog/article-name-goes-here
The query parameter is everything after the last '/'. So, in the above example, "article-name-goes-here" would be the query parameter. Also, the parameters can be at the fragment part of the URL.
Here is an example:
http://securityforeveryone.com/blog/article-name-goes-here#another-area
In this case, everything after the # can be used as input. There are a few other scenarios, like port (:8080), or username in the URL (http://username:[email protected]) but we won't discuss them because they aren't common.
User Inputs In the HTTP Body
Query parameters aren't the only place where user input can be found. Sometimes, user input can be in the HTTP body as well. The following are some examples of data that can be in the HTTP body:
POST /login HTTP/1.1
Host: www.securityforeveryone.com
Content-Type: application/x-www-form-urlencoded
name=John&age=21
This is a simple example of an HTTP POST request where the user's name and age are sent in the body of the request.
Another example would be if you were to upload a file to a website. The file contents would also be considered part of the HTTP body. Here is an example of what that might look like:
POST /upload HTTP/1.1
Host: www.securityforeveryone.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarynUJPqXd0AI6oLbP
------WebKitFormBoundarynUJPqXd0AI6oLbP
Content-Disposition: form-data; name="name"
John
------WebKitFormBoundarynUJPqXd0AI6oLbP--
In this example, you can see that the name "John" is being sent as part of the request body. This is just one example of the many different ways that user input can be sent in the HTTP body.
User Inputs In HTTP Headers
In addition to the URL and the body, user input can also be found in HTTP headers. Here are a few examples of data that might be found in HTTP headers:
Accept-Language: en-US,en;q=0.5
Content-Type: text/html; charset=UTF-8
Cookie: test-cookie
Host: www.securityforeveryone.com
Referer: https://www.google.com/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
As you can see, there is a lot of sensitive information that can be found in HTTP headers, like the Accept-Language header which can be used to determine the user's location, or the User-Agent header which can be used to fingerprint the user's browser and operating system.
User inputs are not limited to the URL, body, and headers of an HTTP request. They can also be found in any data that is used in the backend. Need example?
Let securityforeveryone.com a web app use DNS TXT records to validate your domain. So whenever you want to validate your domain on securityforeveryone.com, Security For Everyone gets your domain TXT records, processes it in the background, and does some validations. Then, your DNS TXT records are a user Input for security for everyone.
Now that we've seen some examples of user input, do you need to check user inputs of your app? Try a full scan.
control security posture