the-web-application-hackers-handbook

Chapter 15 n Exploiting Information Disclosure 629
In cases where sensitive information must be disclosed to an authorized user
(for example, where users can update their own account information), existing
data should not be disclosed where it is not necessary. For example, stored
credit card numbers should be displayed in truncated form, and password fields
should never be prefilled, even if masked on-screen. These defensive measures
help mitigate the impact of any serious vulnerabilities that may exist within the
application’s core security mechanisms of authentication, session management,
and access control.
Minimize Client-Side Information Leakage
Where possible, service banners should be removed or modified to minimize the
disclosure of specific software versions and so on. The steps needed to implement
this measure depend on the technologies in use. For example, in Microsoft
IIS, the Server header can be removed using URLScan in the IISLockDown
tool. In later versions of Apache, this can be achieved using the mod_headers
module. Because this information is subject to change, it is recommended that
you consult your server documentation before carrying out any modifications.
All comments should be removed from client-side code that is deployed to
the live production environment, including all HTML and JavaScript.
You should pay particular attention to any browser extension components
such as Java applets and ActiveX controls. No sensitive information should be
hidden within these components. A skilled attacker can decompile or reverseengineer
these components to effectively recover their source code (see Chapter 5).
Summary
Leakage of unnecessary information frequently does not present any kind of
significant defect in an application’s security. Even highly verbose stack traces
and other debugging messages may sometimes provide you with little leverage
in seeking to attack the application.
In other cases, however, you may discover sources of information that are of
great value in developing your attack. For example, you may find lists of usernames,
the precise versions of software components, or the internal structure
and functionality of the server-side application logic.
Because of this possibility, any serious assault on an application should include
a forensic examination of both the application itself and publicly available
resources so that you can gather any information that may be of use in formulating
your attacks against it. On some occasions, information gathered in this
way can provide the foundation for a complete compromise of the application
that disclosed it.