Tải bản đầy đủ - 0 (trang)
6  Observing Live Response Headers with TamperData

6  Observing Live Response Headers with TamperData

Tải bản đầy đủ - 0trang

Figure 3-12. Response headers accompany every web page



Solution

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.



Discussion

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:











Status

Content-Type

Content-Encoding

Content-Length



3.6 Observing Live Response Headers with TamperData | 45



• Expires

• Last-Modified

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.

For instance, some older PDF readers are known to execute JavaScript passed in via

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

the user to download the PDF first, thus preventing any JavaScript from coming along

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:

http://www.example.com/redirect.php?url=http://ha.ckers.org



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

here.

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=

127349177.



46 | Chapter 3: Basic Observation



Figure 3-13. Revealing JavaScript scripts



3.7 Highlighting JavaScript and Comments

Problem

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

developers, and JavaScript, the primary source of dynamic behavior online. This recipe

helps quickly find embedded comments and JavaScript.



Solution

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,

included HTML comments, or ran JavaScript as part of any of its web pages.

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.



Discussion

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

admin pages, even development or test notes. Meanwhile JavaScript functionality is a

prime target for attacks discussed in later chapters; any local JavaScript code can be

circumvented or manipulated by a user.



3.7 Highlighting JavaScript and Comments | 47



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!”



3.8 Detecting JavaScript Events

Problem

One technique that you have to learn to test web applications for security is the ability

to bypass JavaScript that the application expects to run in your browser. This is what

hackers do, and this is what you must also do to simulate certain kinds of real attacks.

Before you can bypass client-side JavaScript, you must know it exists. So in this recipe

we learn to look for it.



Solution

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).

Search the source (using Ctrl-F or ⌘-F) for some of the more popular JavaScript events.

They include:















onClick

onMouseOver

onFocus

onBlur

onLoad

onSubmit



The most important places to look for them are in the important tags like: