Web application security


msgConfirmationIt’s a real possibility that the web server is locked down and secured.


Web application hacking requires the attacker to understand application logic.

A website may be ripped entirely and stored locally. While this does not give out the code behind, it shows how input is passed, what types of error messages are returned, and the types of input that various fields will accept.

Here is a list of vulnerabilities and possible attacks to add to your list. Also check this list that Microsoft put out:


Check out this article: http://msdn.microsoft.com/en-us/library/ms998375.aspx


Hidden Fields


Hidden fields used for obscuring values are poor coding. The theory is that if end users cannot see it, it is safe from tampering. Many sites use these hidden value fields to store the price of the product that is passed to the web application. An example pulled from a website is shown here:


<INPUT TYPE=HIDDEN NAME=”price” VALUE=”$345.50″>


<INPUT TYPE=HIDDEN NAME=”return” VALUE=”http://www.vulnerable_site.com/cgi-bin/cart.pl?db=stuff.dat&category=&search=Mens-Rings&method=&begin=&display=&price=&merchant=”>




Here is an example tampering with a poorly written shopping cart:


Save the page locally and open the source code.


Modify the amount and save the page. As an example, change $345.50 to $5.99:




Refresh the local HTML page and then click Add to Cart. If successful, you’ll be presented with a checkout page that reflects the new hacked value of $5.99.

This is an extreme example for illustration purposes that an application should never rely on the web browser to set the values for sensitive data. Even without changing the price, an attacker might just try to feed large amounts of data into the field to see how the application responds. Values from hidden fields, check boxes, select lists, and HTTP headers might be manipulated by malicious users and used to make web applications misbehave if the designer did not build in proper validation.

If you think that there is a shortage of sites with these types of vulnerabilities, think again. A quick Google search for type=hidden name=price returns hundreds of hits.


Cookies have a legitimate purpose. Security by obscurity is never a good idea. Cookies used with forms authentication or other remember me functionality might hold passwords or username and cookies can be viewed with cookie viewers. Example:

Set-Cookie: UID= bWlrZTptaWtlc3Bhc3N3b3JkDQoNCg; expires=Fri, 06-Jan-2010

The UID value appears to contain random letters, but more than that is there. If you run it through a Base64 decoder, you end up with mike:mikespassword. It’s never good practice to store sensitive information, encrypted, in a cookie, a hash should be preferred.

Cross-Site Scripting

Cross-site scripting (XSS) is a computer security exploit that occurs when a web application is used to gather data from a victim. Here is an example of a possible entry in a text field:

<A HREF=”http://example.com/comment.aspx?mycomment= malicious code”>Click here</A>

XSS can be prevented by HtmlEncoding displayed data and the input from a form is validated. Prevention also requires that the users remain leery of embedded links.

Interception, Inspection, Modification

A web proxy allows interception, inspection, and modification the raw contents of the traffic, as explained in the following:

  • Intercept Allows you to see under the hood and watch the traffic move back and forth between the client and the server.
  • Inspect Allows you to enumerate how applications work and see the mechanisms they use.
  • Modify Allows you to modify the data in an attempt to see how the application will respond; for instance, injection attacks.

These tools make it possible to perform SQL injection, cookies subversion, buffer overflows, and other types of attacks.