Tải bản đầy đủ - 0 (trang)
4  Observing Live Post Data with WebScarab

4  Observing Live Post Data with WebScarab

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

Figure 3-7. Setting up Firefox to use the WebScarab proxy

Then, to use WebScarab to observe POST data:

1. Browse to a page that uses a POST form. You can recognize such a form by viewing

its source (see Recipe 3.1) and looking for specific HTML. If you find the

tag, look for the method parameter. If it says method="post", you have found a form

that uses POST data.

2. Enter some sample information into the form and submit it.

3. Switch to WebScarab, and you should see several entries revealing your last few

page requests.

WebScarab picked up what you can see in Figure 3-8.

Double-click any request where the method is set to POST. You’ll be presented with

all the details for this page request. Underneath the request headers, you’ll find a section

containing all the POST variables and their values.

These headers follow the same format as request headers, just name-value pairs, but

are set by the server rather than the browser. For an example, see the bottom of Figure 3-9, where URL-encoded POST data is displayed.


WebScarab is a powerful tool. As a proxy it reveals everything there is to see between

your browser and the web server. This is unlike Firebug, which resets every time you

click a link. WebScarab will keep a record for as long as it is open. You can save this

history, in order to resubmit a HTTP request (with certain values modified). In essence,

with WebScarab, you can observe and change anything the web server sends you.

3.4 Observing Live Post Data with WebScarab | 41

Figure 3-8. Page request history in WebScarab

Figure 3-9. WebScarab knows what you hide in your POST

This proves that POST data, while slightly harder to find than the query string or cookie

data (both found in the request header itself), is not difficult to extract, change, and

resubmit. Just as applications should never trust the data in the query string, the same

goes for POST data, even hidden form fields.

42 | Chapter 3: Basic Observation

Figure 3-10. Revealing hidden fields with WebScarab

WebScarab will cause various warnings to pop up if you attempt to

browse to a SSL-protected page. These warnings indicate that the cryptographic signature is incorrect for the website you’re accessing. This is

expected, because WebScarab is intercepting requests. Do not confuse

this warning (the result of using a tool) with an indication that SSL or

cryptography is not working on your website. If you disable the use of

WebScarab and you still see SSL errors, then you should be concerned.

Similarly, FTP requests will outright fail while WebScarab is configured

as a proxy.

There is a Firefox add-on called SwitchProxy (https://addons.mozilla.org/en-US/firefox/

addon/125) that will allow you to switch between using a proxy like WebScarab and

another proxy (e.g., your corporate proxy) or not using any proxy at all. SwitchProxy

is especially handy if your normal environment requires you to use a proxy, because it

is very inconvenient to switch back and forth.

3.5 Seeing Hidden Form Fields


Your website uses hidden form fields and you want to see them and their values. Hidden

fields are a good first place to look for parameters that developers don’t expect to be



Within WebScarab, choose the Proxy tab and then the Miscellaneous pane of that tab.

Check the check box labeled “Reveal hidden fields in HTML pages” as shown in Figure 3-10. Now browse to a web page that has hidden form fields. They will appear as

plain-text entry boxes, as shown in Figure 3-11.

3.5 Seeing Hidden Form Fields | 43

Figure 3-11. Hidden form field on PayPal’s login screen


Some developers and testers misunderstand the nature of “hidden” form fields. These

are fields invisible on a rendered page, but provide additional data when the page is

submitted. WebScarab picks up these hidden form fields along with everything else,

so they are not really hidden at all. Relying on the user’s ignorance of these hidden

values is dangerous.

When you are determining which inputs are candidates for boundary value testing and

equivalence class partitioning, you should include hidden fields as well. Because these

inputs are now plain-text inputs, and not hidden, your browser will let you edit them

directly. Just click in the box and start typing. Realize, however, that some hidden

values are calculated by JavaScript in the web page, so your manually entered value

may get overwritten just prior to submitting the form. You’ll need to intercept the

request and modify it, as described in Recipe 5.1, if that’s the case.

3.6 Observing Live Response Headers with TamperData


Response headers are sent from the server to the browser just before the server sends

the HTML of the page. These headers include useful information about how the server

wants to communicate, the nature of the page, and metadata like the expiration time

and content type. Response headers are great source of information about the web

application, particularly regarding unusual functionality.

Response headers are where attackers will look for application specific information.

Information about your web server and platform will be leaked as part of standard


44 | Chapter 3: Basic Observation

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

4  Observing Live Post Data with WebScarab

Tải bản đầy đủ ngay(0 tr)