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:
- Testing app with heavy use of JS tblinux (Sep 11)
- Re: Testing app with heavy use of JS Peter Conrad (Sep 13)
- Re: Testing app with heavy use of JS Lluis Mora (Sep 14)
- <Possible follow-ups>
- RE: Testing app with heavy use of JS Matt Fisher (Sep 15)