Tải bản đầy đủ - 0trang
6 Observing Live Response Headers with TamperData
Figure 3-12. Response headers accompany every web page
The response headers can be found next to the request headers, as mentioned in Recipe 3.3. Header information can also be found via a proxy, such as WebScarab. We’re
going to use this task to introduce you to TamperData, which is a handy tool for this
task and several others.
Install TamperData according to Recipe 2.2. It is installed in the same way most addons are installed.
Open TamperData from the Tools menu. Then, browse to a page. In the TamperData
window you’ll find an enumeration of pages visited similar to WebScarab and FireBug.
Clicking on one will reveal the request and response headers, as shown in Figure 3-12.
There is a difference between the response headers and the response itself. The headers
describe the response; they are metadata. For instance, response headers will generally
include the following:
3.6 Observing Live Response Headers with TamperData | 45
Response headers have evolved over the years, and so the original specification (available at http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html) is only accurate for
some of the items, such as Status.
Additionally, some response headers will indicate the server software and the date and
time when the response was issued. If you’re going to allow everyone on the Internet
to see the server and platform that you’re using, now would be a good time to ensure
that you’re up-to-date on patches, and any known vulnerabilities are prevented.
Pay special attention to the Content-Type header. The majority of the time it will simply
read something like “text/html; charset=UTF-8,” indicating a normal HTML response
and encoding. However, it may also refer to an external application or prompt unusual
browser behavior, and it’s these unusual cases where attacks can slip by.
the query string (details at http://www.adobe.com/support/security/advisories/apsa07
-01.html ). If your application serves PDFs, does it do so directly by setting the ContentType to application/pdf? Or does it instead set the Content-Disposition header to ask
for the ride?
Dynamic redirects are another dangerous feature, as they allow attackers to disguise a
link to a malicious website as a link to your website, thus abusing the trust users have
for your website. Dynamic redirects typically look like this as a link:
You can see that these details can be tricky; if your application is using any special
headers for handling file uploads, downloads, redirects, or anything else, be sure to
research any specific security precautions, as there are more out there than can be listed
New response headers are still being developed, and may help fuel one of the more
popular aspects of blogging. TrackBacks, PingBacks, and RefBacks are competing
standards for a new kind of web functionality, generally known as LinkBacks. These
LinkBacks provide a two-way linking capability.
For example, if Fred links to Wilma’s blog from his, their blog-hosting services can use
one of the standards to communicate, and Wilma’s blog will show that Fred is linking
to her. HTTP headers help identify which standard is being used, as well as communicate the link information.
Concise LinkBack details can be found on Wikipedia; to see the same version we did,
follow this historical link http://en.wikipedia.org/w/index.php?title=Linkback&oldid=
46 | Chapter 3: Basic Observation
Viewing the source is helpful for checking the results of your own attacks, but it’s not
efficient to sort through all the HTML code looking for vulnerabilities. Often there will
be clues left behind. The two best sources for these clues are comments, left behind by
As mentioned in Recipe 3.6, WebScarab provides the ability to view details on any
HTTP request. Furthermore, it groups requests according to the website host. To the
right of the host URL, three check boxes indicate whether or not that host set a cookie,
On a page with either comments or scripts checked, you may right click to view either
of these hidden items, as seen in Figure 3-13. Doing so will open a plain-text window
with the information requested.
Comments often disclose details about the inner workings of a web application. All too
often comments include stack traces, SQL failures, and references to dead code or
circumvented or manipulated by a user.
In one case we’ve seen, a major gambling website had extensive test suites set up,
configured, and automated so that they could be executed merely by visiting a set of
links. Unfortunately, rather than properly removing the test code before releasing the
application, they just commented out the test links. Commented-out links are always
a big hint—obviously someone didn’t want you seeing that URL. Following those links
displayed the entire test suite, complete with a function labeled with a warning: “Danger! This test executes irreversible transactions!”
One technique that you have to learn to test web applications for security is the ability
hackers do, and this is what you must also do to simulate certain kinds of real attacks.
we learn to look for it.
Start by browsing to the page you’re interested in. Log in or do whatever setup is necessary to get there. Then view the source of the web page using ether View Source or
the View Source Chart plug-in (see Recipes 3.1 and 3.2).
The most important places to look for them are in the important tags like: