Last week, a client was in the process of migrating a web application(not a complex one fortunately) to a HTTPS only version.
As part of the task, external resources(like any scripts) delivered over plain HTTP needed to be identified(originally the app was a HTTP only one).
Obviously this is not something that a SSL Scanner(like SSL Labs for example) can do because it falls outside the scope of such a tool(too complex).
The scanner must crawl the entire site, being able to record some login sequences(form based in this case, –> detect if the cookies were marked as secure), parse HTML content/whatever, see how (external) resources are requested and observe HTTPS to HTTP transitions(if any), to name a few.
In this case, some of those external resources were easy to identify: gravatar images needed to be served over SSL and the secure API of reCAPTCHA to be used.
To make sure nothing was missed, some form of automatic scanning was needed.
Someone brought in the Acunetix Vulnerability scanner.
Looking though some of its options, especially at the crawler settings, we saw the “Enable CSA (analyze and execute JavaScript/AJAX)” and “Fetch external scripts” options.
Also the scanner seemed able to detect some insecure transitions from HTTPS to HTTP.
To test it a little for a start, we crawled a basic dummy HTTPS web site, first requesting on a page a local JavaScript(plain HTTP absolute URL), which Acunetix found and on the site structure displayed it without the SSL padlock(we did not seem to receive any warnings about external resources loaded over plain HTTP or so, which would be useful if the site structure is a complex one).
Second we crawled the same test HTTPS web site, but now we requested the script on the page from an external destination(plain HTTP absolute URL), here we lost Acunetix, we did not see it trying to request that script(from the logs), thus we did not notice the presence of that script.
Third we crawled having another page this time to dynamically retrieve static data(basically using the loadScript() function to load another local script file when a button was clicked), once again we lost Acunetix which only found the local script file within the loadScript() function was stored.
Gave up on Acunetix, either that’s the way it works or we missed something (obvious).
Proceeded to manually search the code(first quickly with Notepad++ “Find in files” search option) for absolute plain HTTP URLs. We rapidly found like so somewhere in the administration area that an Ajax script was requested over plain HTTP.
Additional code verifications did not reveal other external resources being requested over plain HTTP.