Improving Web Application Security: Threats and Countermeasures
Examine how your application uses parameters. These parameters include form fields, query strings, cookies, HTTP headers, and view state that are passed between client and server. If you pass sensitive data, such as session identifiers, using parameters such as query strings, a malicious client can easily bypass your server side checks with simple parameter manipulation. Table 5.8 shows the most common parameter manipulation vulnerabilities.
| Vulnerability | Implications |
|---|---|
| Failing to validate all input parameters | Your application is susceptible to denial of service attacks and code injection attacks, including SQL injection and XSS. |
| Sensitive data in unencrypted cookies | Cookie data can be changed at the client or it can be captured and changed as it is passed over the network. |
| Sensitive data in query strings and form fields | This is easily changed on the client. |
| Trusting HTTP header information | This is easily changed on the client. |
| Unprotected view state | This is easily changed on the client. |
Examine the following questions to help ensure that your design is not susceptible to parameter manipulation attacks:
-
Do you validate all input parameters?
-
Do you pass sensitive data in parameters?
-
Do you use HTTP header data for security?
Do You Validate All Input Parameters?
Check that your application validates all input parameters, including regular and hidden form fields, query strings, and cookies.
Do You Pass Sensitive Data in Parameters?
If your application passes sensitive data in parameters such as query strings or form fields, examine why your application favors this approach over the much more secure approach of passing a session identifier (for example, in an encrypted cookie). Use this information to associate the session with the state of a user that is maintained in the state store on the server. Consider the following review points:
-
Do you encrypt cookies with sensitive data?
If your application uses a cookie that contains sensitive data, such as a user name or a role list, make sure it is encrypted.
-
Do you pass sensitive data in query strings or Form fields?
This is not recommended because there is no easy way to prevent the manipulation of data in query strings or form fields. Instead, consider using encrypted session identifiers and store the sensitive data in the session state store on the server.
-
Do you protect view state?
If your Web pages or controls use view state to maintain state across HTTP requests , check that the view state is encrypted and checked for integrity with message authentication codes (MACs). You can configure this at the machine level or on a page-by-page basis.
Do You Use HTTP Header Data for Security?
Make sure that your Web application does not make security decisions based on information in HTTP headers because an attacker can easily manipulate the header. Do not rely on the value of the HTTP referer field to check that the request originated from a page that is generated by your Web application ” this creates vulnerabilities. Doing this is inherently insecure because the referer field can easily be changed by the client.
Категории