Message-ID: <AA8E3CBBF6E2E7489931D9F30A7BDBD81B2A34@zajnbnt006.za.deloitte.com>
Date: Fri, 26 Sep 2003 09:35:46 +0200
From: "Dawes, Rogan (ZA - Johannesburg)" <rdawes@...oitte.co.za>
To: 'RAFAEL SAN MIGUEL CARRASCO' <rsmc@....es>,
	bugtraq@...urityfocus.com
Subject: RE: Sanctum AppScan 4 misses potential vulnerabilities in wrapped
	 links


I am inclined to agree with Sanctum's position here. Without actually
executing the javascript, and triggering all the possible events, and
tracing the javascript (in a sandbox, maybe), it is pretty much impossible
to identify the fact that the function called would result in a new URL to
investigate.

For example, the page could include a function to redirect to the SSL
version of a site by getting the web site name from the location bar,
prepending https:// to it, and appending the supplied path.

There are only really three ways of discovering the resulting URL. 

1. Browse it yourself through a monitoring proxy, and let your browser
execute the script.
2. Let the application extract all Javascript and javascript hrefs, and let
the observer decode them manually, and enter URL's.
3. Identify all "entry points" [1] from which javascript can be triggered,
and execute each and every script in a sandbox to observe any URL's that get
constructed.

1. is Sanctum's solution
2. is very manual and intensive, but the user should arguably be reviewing
the javascripts anyway.
3. is the ideal situation, in my mind, but I think that it is a bit
unreasonable to expect at this point. It would be a really good selling
point, though!

3. is still never going lead to a complete replacement for an intelligent
operator, though. There may very easily be situations in which there are
interactions between components in a page or form, javascripts, etc that
would be overlooked by this technique. I'm still of the opinion that *no*
automated tool can provide complete coverage of an arbitrary web
application, simply because of the potential complexity. It's like solving
the halting problem, to my mind.

Rogan

[1] By "entry point", I mean all onEvent triggers, all "javascript:" hrefs,
etc.

> -----Original Message-----
> From: RAFAEL SAN MIGUEL CARRASCO [mailto:rsmc@....es] 
> Sent: 24 September 2003 11:11 PM
> To: bugtraq@...urityfocus.com
> Subject: Sanctum AppScan 4 misses potential vulnerabilities 
> in wrapped links
> 
> 
> "AppScan 4.0 Audit Edition, the market leading application 
> vulnerability assessment 
> tool, accurately detects security vulnerabilities 
> automatically as an integrated 
> component of an enterprise security process review."
> 
> AppScan 4 have a flaw regarding the way the "Explore stage" 
> is implemented
> when the "Automatic Scan" is selected.
> When a reference to a URL in a "a href" tag is made using a 
> wrapper function 
> instead of directly calling "window.open" or 
> "document.location" javascript 
> functions, AppScan will not detect the link and the URL will 
> not be tested 
> against any attack.
> 
> As this is a common way to reference URLs (it enables the 
> coder to do some 
> stuff before the window is actually opened), many pages of a 
> website may not
> be analyzed by AppScan, hiding potential vulnerabilities to the user. 
> An attacker with this knowledge would scan first pages 
> referenced in the way 
> explained above, speeding up the vulnerability discovery process.
> 
> Here is an example of a link that will be ignored by AppScan:
> 
> <script>
> function openBrWindow(theURL,winName,features) 
> { window.open(theURL,winName,features); }
> </script>
> 
> <a href="#" onClick="openWindow('bla.html','','');">
> <img src="bla.jpg"></a>
> 
> I contacted SanctumInc, and this was the solution proposed:
> 
> "We are aware of this limitation and in case of extensive 
> usage of Java Script 
> we recommend the user to choose "Interactive" Scan Type and 
> explore the site 
> manually. If you do so, just like a normal user will explore 
> your site, AppScan 
> will test the encapsulated links."
> 
> More information about this product: www.sanctuminc.com
> 
> 
> Rafael San Miguel Carrasco
> División de Infraestructura y Seguridad en Redes IP
> Telefónica I+D
> 

Important Notice: This email is subject to important restrictions, qualifications and disclaimers ("the Disclaimer") that must be accessed and read by clicking here or by copying and pasting the following address into your Internet browser's address bar: http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form part of the content of this email in terms of Section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you cannot access the Disclaimer, please obtain a copy thereof from us by sending an email to ClientServiceCentre@...oitte.co.za.

Powered by blists - more mailing lists