I agree, this is a cool idea-- just one caveat-- you can't guarantee
that your get 100% coverage (What if you have an admin section, and
someone only goes there once a year?) You could probably combine this
approach with a web-spidering application, and then manually go through
and see about special pages, or password protected sections.
Michael Scovetta
Computer Associates
Senior Application Developer
-----Original Message-----
From: Matt Fisher [mailto:mfisher@spidynamics.com]
Sent: Wednesday, April 20, 2005 2:13 AM
To: Amit Klein (AKsecurity); Ory Segal; Jarmon, Don R;
webappsec@securityfocus.com
Cc: wasc-technical@webappsec.org
Subject: RE: webapp dependencies
That's not a bad idea. Capturing at a lower level would indeed give
more details. I don't think I've ever used strace. Would the output be
relatively clean ? Ie, not too much work to filter the wheat from the
chaffe ?
-----Original Message-----
From: Amit Klein (AKsecurity) [mailto:aksecurity@hotpop.com]
Sent: Wednesday, April 20, 2005 2:27 AM
To: Ory Segal; Jarmon, Don R; webappsec@securityfocus.com; Matt Fisher
Cc: wasc-technical@webappsec.org
Subject: RE: webapp dependencies
On 19 Apr 2005 at 23:21, Matt Fisher wrote:
I'd really be interested in hearing about it if anyone
finds a good
tool / technique but at this point I really don't see how
it could be
sufficiently performed from any client sided product such
as crawlers,
scanners, accessibility testers etc.
I'd take quite a different approach. At runtim, attach to the
web process at a low level (kernel?), e.g. strace, and log
access to files. Then use a crawler to enumerate (to the
extent possible) all flows through the app. This should give
you the list of files accessed by the web server process
(there are many detailed to be ironed out, such as server
caching, spawning new proceses, etc. but I believe it's doable).
In the above example, once you make a hit on the page.asp,
strace would first show the web process to read page.asp, and
immediately thereafter page1.html.
-Amit
