Many users access web applications from a shared environment in which an attacker may have direct access to the same computer as the user. This gives rise to a range of attacks to which insecure applications may leave their users vulnerable. There are several areas in which this kind of attack may arise.
Some applications store sensitive data in a persistent cookie, which most browsers save on the local file system.
Cached Web Content
Most browsers cache non-SSL web content unless a web site specifically instructs them not to. The cached data is normally stored on the local file system.
Most browsers save a browsing history, which may include any sensitive data transmitted in URL parameters.
Many browsers implement a user-configurable autocomplete function for text-based input fields, which may store sensitive data such as credit card numbers, usernames, and passwords. Autocomplete data is stored within the registry by Internet Explorer and on the file system by Firefox.
Preventing Local Privacy Attacks
Applications should avoid storing anything sensitive in a persistent cookie. Even if this data is encrypted, it can be resubmitted by an attacker who captures it.
Applications should use suitable cache directives to prevent sensitive data from being stored by browsers. In ASP applications, the following instructions will cause the server to include the required directives:
<% Response.CacheControl = “no-cache” %>
<% Response.AddHeader “Pragma”, “no-cache” %>
<% Response.Expires = 0 %>
In Java applications, the following commands should achieve the same result:
response.setDateHeader (“Expires”, 0);
Applications should never use URLs to transmit sensitive data, as these are liable to be logged in numerous locations. All such data should be transmitted using HTML forms that are submitted using the POST method.
NEXT is..A Web Application Hacker’s Toolkit…………………………,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,