19.09.2017 Views

the-web-application-hackers-handbook

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 4 n Mapping <strong>the</strong> Application 99<br />

In this example, <strong>the</strong> strings electronics and iPhone3G should be treated as<br />

parameters to store a search function.<br />

Similarly, in this URL:<br />

http://eis/updates/2010/12/25/my-new-iphone/<br />

each of <strong>the</strong> URL components following updates may be being handled in a<br />

RESTful manner.<br />

Most <strong>application</strong>s using REST-style URLs are easy to identify given <strong>the</strong> URL<br />

structure and <strong>application</strong> context. However, no hard-and-fast rules should be<br />

assumed when mapping an <strong>application</strong>, because it is up to <strong>the</strong> <strong>application</strong>’s<br />

authors how users should interact with it.<br />

Request Parameters<br />

Parameters submitted within <strong>the</strong> URL query string, message body, and HTTP<br />

cookies are <strong>the</strong> most obvious entry points for user input. However, some <strong>application</strong>s<br />

do not employ <strong>the</strong> standard name=value format for <strong>the</strong>se parameters.<br />

They may employ <strong>the</strong>ir own custom scheme, which may use nonstandard query<br />

string markers and field separators, or <strong>the</strong>y may embed o<strong>the</strong>r data schemes such<br />

as XML within parameter data.<br />

Here are some examples of nonstandard parameter formats that <strong>the</strong> authors<br />

have encountered in <strong>the</strong> wild:<br />

n /dir/file;foo=bar&foo2=bar2<br />

n /dir/file?foo=bar$foo2=bar2<br />

n /dir/file/foo%3dbar%26foo2%3dbar2<br />

n /dir/foo.bar/file<br />

n /dir/foo=bar/file<br />

n /dir/file?param=foo:bar<br />

n /dir/file?data=%3cfoo%3ebar%3c%2ffoo%3e%3cfoo2%3ebar2%3c%2ffoo2%3e<br />

If a nonstandard parameter format is being used, you need to take this into<br />

account when probing <strong>the</strong> <strong>application</strong> for all kinds of common vulnerabilities.<br />

For example, suppose that, when testing <strong>the</strong> final URL in this list, you ignore <strong>the</strong><br />

custom format and simply treat <strong>the</strong> query string as containing a single parameter<br />

called data, and <strong>the</strong>refore submit various kinds of attack payloads as <strong>the</strong> value<br />

of this parameter. You would miss many kinds of vulnerabilities that may exist<br />

in <strong>the</strong> processing of <strong>the</strong> query string. Conversely, if you dissect <strong>the</strong> format and<br />

place your payloads within <strong>the</strong> embedded XML data fields, you may immediately<br />

discover a critical bug such as SQL injection or path traversal.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!