HTML supports a form element called "hidden." These variables along with their included values are sent to the user by the Web server and in return get embedded into the HTML response to the user. These hidden elements were never intended to be seen by the user nor were they supposed to be changed or manipulated.
Users can alter these HTML elements changing their values causing unexpected input results. It is relatively a simple process for the auditor to download the Web page, change the HTML in a simple text editor, save it and then replace the Web page in the browser and have the page submitted to the Web server. For example:
Method = "Post">
Users may change the last value statement to [value = "/etc/password"]. It is possible if the user input were not filtered, it could result in the password file being passed from the server to the user's browser. There is a practical rule of thumb, when filtering user input, it is best to define permitted characters and deny everything else as opposed to attempting to predict everything that is not permitted and removing those elements. Basically, the rule is this one, if it is not specifically allowed, it is denied. For example, if a form is requesting a person's telephone area code, nothing more than three numeric digits are acceptable and all other entries are denied resulting in error messages.
Attackers can easily use search engines such as www.Google.com to find potentially vulnerable fields in Web pages. For example, if an attacker were looking for vulnerabilities on the XYZ Corporation Web page, she enters the following in Google: "type = hidden" and "name = price" site: xyzcorporationonline.com. Using search engines with entries similar to this entry will reveal all pages within the domain, xyzcorporationonline.com that contain strings of "type = hidden" and "name = price." These hidden fields are used to pass price information to the Web server. If the user-input information is not screened for correctness, the price paid may be significantly less than the actual price. For example, a Web page that states the purchase information for a particular product. Frequently, the page is downloaded to the user's browser and a request of the user is made to indicate the number of the product the user wishes to purchase. The user downloads the HTML and changes the price of the product from $500 to $5 using a text editor, saves the modified page and submits the page to the server for processing. The order is processed as there is no more field checking in the shopping cart software. With the order shipped, the vendor is shorted $495. It is important that auditors consider that this type of financial attack is possible by testing the shopping software and making certain that all user-inputs are checker for correctness.
Get vs. Post Commands in CGI Forms
Auditors should carefully examine the method used by Web developers to collect and send user-supplied data. In world of HTML and where CGI, common gateway interface scripts are used, there are two methods of transmitting data. In HTML, the default method for form requests is Get so if the developer did not specify the attribute from the Form tag, the system will assume the developer meant Get. The Get method is the easiest request method. It requests a document from the Web server. When the browser uses the Get method to request a document from the Web server, the request looks like this example:
GET HTTP1.0/index.html
When a form is submitted using the Get method, the URL-encoded data is tacked onto the end of the URL that's requested, with a question mark inserted between them as a separator. So, if the auditor were to submit the data in a form using the Get method, it could look something like:
GET HTTP/1.0/CGI-BIN/SAMPLE.CGI?USER NAME = ALICE+DOE
The Web server is programmed to send everything after the question mark to the CGI script sample.cgi file for processing. A problem with the Get method is that it does not provide any privacy to the user. Using the Get method has some possible user-related problems:
It is possible that using the Get method may cause URLs to contain sensitive information such as account numbers, passwords, user names and addresses. Browser security exploits may permit malicious Web sites to steal the user's browser history file. If an attacker should gain physical access to the user's workstation, it is possible for her to steal the browser's history file and all the user-sensitive information it contains.
From the auditor's point of view, the preferable HTML method for forms is the Post method. The Post method sends the form data back to the Web server after the headers are sent. Using the Post method adds the attribute as:
METHOD ="POST"
to the Form tag used to create the HTML form. For example:
user name = Alice+Doe
The Post command tells the server to expect more data after the reset of the header is sent. A blank line is included between the header and the posted data to let the server know when the browser is finished with its header and is starting to send the actual form data. There is a difference between the Get and the Post methods in the way the form data is communicated from the Web server to the CGI program. In the Get method, data is stored in an environment variable, where it can be accessed by the CGI program. In the Post method, the data is submitted to the Web server and from there directly to the input of the CGI script.
So what is the best method for form handling in CGI? For nonsensitive routine matters, Get is an acceptable form handling method. There are many examples of search engines on the Internet that use Get as the form handler. For form data where there should be some expected or required degree of security, the Post method of form handling is the preferred method. Auditors reviewing HTML downloaded from the audit targets Web pages should be looking for these distinctions
Web Page Referrer Fields
Current versions of HTML support the HTTP referrer header field. When a browser follows a link, the referrer field can contain the URL of the page the user came from. The referrer field can also be present when a form is submitted to the Web server for processing. Web Servers can check the referrer field when receiving a completed form and reject it if it did not come from the permitted URL. If this filtering action is performed, attacks from anywhere other than the specified URL should fail. Auditors should be mindful of referrer fields in the case of sensitive information being provided as form-input.
Web Page Referrer Fields
Current versions of HTML support the HTTP referrer header field. When a browser follows a link, the referrer field can contain the URL of the page the user came from. The referrer field can also be present when a form is submitted to the Web server for processing. Web Servers can check the referrer field when receiving a completed form and reject it if it did not come from the permitted URL. If this filtering action is performed, attacks from anywhere other than the specified URL should fail. Auditors should be mindful of referrer fields in the case of sensitive information being provided as form-input.
