WebApp Sec mailing list archives

RE: Testing app with heavy use of JS


From: "Matt Fisher" <mfisher () spidynamics com>
Date: Tue, 14 Sep 2004 18:32:10 -0400


Lluis is right.  (Hey Lluis !) This is the approach to do it manually,
and there's several open source or free local proxies you can use to do
this.  All local proxies perform the same basic functions - expose the
full HTTP packet to you ( not just the body) , and let you manipulate
the packet and send it back to the server for testing.  By giving you
packet level access, there's no need to use the browser at all except
perhaps to "crawl" the site.   The browser only exposes half the packet
to you anyhow - the body - and to do any level of real testing you need
to have access and control of the entire packet.  

Burp is a great example of an open/free proxy.  It knows how to use and
authenticate against proxies, decrypts SSL and presents plaintext, and
even does some unexpected things such as automatically modifying the
content-length header of POST requests.  There are other proxies
available as well.  

If you're doing sponsored work, you may want to take a look at the
commercial scanners available.  All of them will do everything any of
the open/free proxies do, but then will perform automated testing as
well.  This can save *massive* amounts of time, labor, and frustration
(there's a huge amount of research and development that goes into their
vulnerability databases and programs). In addition, they'll provide
comprehensive reports on each vulnerability along with greater
configuration and customization control and extremely "usable"
interfaces.  Of course, everyone knows that no automated scanner can
find everything, particularly in the realm of higher end logic /
architecture issues, so the commercial web application scanners  also
provide additional tools for manual work, such as  proxies and packet
editors.  That said, however, the amount of manual work you would have
to do should be quite minimal compared to that of doing a full
assessment manually. 

And, like any web hacker, they'll parse javascript for the sake of
navigation, but will handily ignore it during testing ;)

Hope this helps.
- Matt. 



-----Original Message-----
From: Lluis Mora [mailto:llmora () sentryware com] 
Sent: Monday, September 13, 2004 9:41 AM
To: tblinux () covad net
Cc: webappsec () securityfocus com
Subject: Re: Testing app with heavy use of JS

Hi,

What about using a HTTP "modification" proxy - it allows you to
manipulate the raw HTTP request after the browser has generated it (via
JS or whatever) and sent it.

They usually allow replay - you just have to submit the form once with
the values the application is expecting - so that you do not trigger the
client-side input validation - then intercept the request and do as many
modifications to the parameters as you want.

A search for "pentest http proxy" should bring a few nice tools, I
personally like burp_proxy.

Cheers,

Lluis
.

tblinux () covad net wrote:
Anybody know of a good way to strip or catch and manipulate input to a

web app that uses JS to do error checking AND specify the input target

address? ...oh and the "submit button" is JS driven too...

Other than hand editing 30 screens of JS code?




Current thread: