the-web-application-hackers-handbook

802 Chapter 21 n A Web Application Hacker’s Methodology
to the server. These controls can be bypassed easily, because you can
send arbitrary requests to the server. For example:
...
3.2.2 Test each affected input field in turn by submitting input that would
ordinarily be blocked by the client-side controls to verify whether these
are replicated on the server.
3.2.3 The ability to bypass client-side validation does not necessarily represent
any vulnerability. Nevertheless, you should review closely what validation
is being performed. Confirm whether the application is relying
on the client-side controls to protect itself from malformed input. Also
confirm whether any exploitable conditions exist that can be triggered
by such input.
3.2.4 Review each HTML form to identify any disabled elements, such as
grayed-out submit buttons. For example:
If you find any, submit these to the server, along with the form’s other
parameters. See whether the parameter has any effect on the server’s
processing that you can leverage in an attack. Alternatively, use an
automated proxy rule to automatically enable disabled fields, such as
Burp Proxy’s “HTML Modification” rules.
3.3 Test Browser Extension Components
3.3.1 Understand the Client Application’s Operation
3.3.1.1 Set up a local intercepting proxy for the client technology under review,
and monitor all traffic passing between the client and server. If data is
serialized, use a deserialization tool such as Burp’s built-in AMF support
or the DSer Burp plug-in for Java.
3.3.1.2 Step through the functionality presented in the client. Determine any
potentially sensitive or powerful functions, using standard tools within
the intercepting proxy to replay key requests or modify server responses.
3.3.2 Decompile the Client
3.3.2.1 Identify any applets employed by the application. Look for any of the
following file types being requested via your intercepting proxy:
n .class, .jar : Java
n .swf : Flash
n .xap : Silverlight