- [Narrator] In the discovery phase
of web application testing,
we're lifting each page of the application
to uncover all vulnerabilities.
This phase can also be performed
using different approaches.
Again, we can do it manually.
We can use an automated approach.
Or a little of both, with a hybrid type scan.
We can do this using an automated tool,
or manually by browsing each and every page
of the site or application.
An automated scanner will take the results
of a web spider, that was done in the mapping phase.
It will then begin to probe those results
to identify possible vulnerabilities.
The scanner does this by correlating
a database of known vulnerabilities,
against the context of the application that was mapped.
From there, we'll produce a report
on what it suspects could be vulnerable.
Keep in mind that these results, many times,
are false positives,
and need to all be validated.
At the very least, this type of tool
will give you an idea of where to look.
The manual discovery process is fairly self explanatory.
It is literally the manual process
of walking through each identified page of an application,
and looking for possible vulnerabilities.
There are a number of automated web scanning tools
available these days.
Each has its merits and its flaws.
We won't get deep into the specific features
of these in this module,
however I can tell you that the best approach
to testing is using multiple scanners.
The reason why is that one might find
some things that others miss.
So, by using multiple scanners,
we can validate the results against each other.
From an open source perspective,
W3AF is a good option.
However, it's hard to compare with
the commercial scanners that are available today.
Here in this slide, we have a few different ones
that we can talk about.
Burp Suite, of course, we already mentioned.
Here in this slide we show a few
of the automated scanners that are available.
Burp Suite of course is an interception proxy,
but it also has automated scanning capabilities.
Although they aren't as comprehensive
as the other scanners here mentioned,
it does have that capability available.
As for the other three,
they're all similar in features.
Of course they have additional features in some cases,
that may work better for specific types of applications.
Most automated scanners work in a similar way.
You provide the scanner with a starting point,
usually the homepage of the application.
You can choose to provide credentials,
if authentication is required for the application.
The scanner will crawl the application,
with the permissions it has,
mapping out all edges of the application.
From there, it will compare the results
against its database of known vulnerabilities.
It will report possible vulnerabilities,
based on what was found.
Keep in mind that many of these will be false positives.
So we need to validate.
Some scanners will attempt to exploit the vulnerability,
or give you the option of exploiting manually.
The result will be a report detailing the application,
and what is recommended.
An automated vulnerability scanner
is actually just an application
that you would run on your attack or testing machine.
What you would do is, you would point the scanner
at the web server that you're evaluating.
With an automated vulnerability scanner,
we need to provide some information to get it started.
So, for instance, we would give it the base URL
that we want it to start with.
In this case, hackazon.net.
We normally want it to start at the root,
so that it can analyze the whole site.
However, depending on the size of the site,
we can also pare things down,
and test individual sections at a time.
We also need to tell the scanner
which port the application
we want to test, is listening on.
Some websites respond on port 80, or 443.
But others might respond on totally different ports.
So, in this case, our web server is running on port 80.
We might also need to provide the username and password
to authenticate to the site.
This is another piece of information
that we would need to provide to the web scanner,
so that it can authenticate,
and scan all of the pages.
For our test site, hackazon.net,
we won't provide authentication.
Now once we've given the scanner
all of the information we need to start,
we'll kick off the scan.
From here, what the web scanner is gonna do,
is it's gonna start by crawling the website,
to map out the application.
So, essentially what it's doing
is it's gonna keep sending requests to the web server,
and as the web server responds to those requests,
the application is going to record all of the responses.
From there, it's going to analyze the responses,
to determine where there may be vulnerabilities
in the site.
It does this based on a database
of known vulnerabilities that it has.
So, the next step that the scanner will take,
is to send attacks at those vulnerabilities,
to try and validate them.
Again, based on the responses,
the web scanner will record the responses,
into its database, for later reporting.
And of course last but not least,
the web scanner will report what it's found.
Normally the form of the report
is of high, medium, and low categorization,
but depending on the actual web scanner,
that may differ.
In this demo, we will show
the Netsparker automated web vulnerability scanner.
As we mentioned in previous slides,
there are many commercial scanners available.
They're all very similar, so we won't
go into the details of how to use Netsparker.
Our goal here is to give you an idea
of how automated scanners work,
so let's jump into it.
First we start up our web scanner tool,
in this case Netsparker.
This specific one runs on Windows.
There are others that run on multiple operating systems.
The first thing the scanner needs, is a target.
To do this, we click on the Start New Scan button.
Here we type in our target, which is hackazon.net.
All scanners have a way to set specific options
for the scan.
For instance, if we click on the Scan Policy Editor button,
we can see all the different options.
We can choose to scan for specific defects,
or scan for everything.
For this scan, we'll take the default security checks.
Another important configuration option is authentication.
If your site requires authentication
to view any of the pages then,
you want to run the scan with specific credentials.
Most sites have different levels of authorization.
For instance, user or admin type roles.
For testing this, you want to run a scanner
as an administrator,
then run it again as a normal user.
Then compare the results.
For hackazon.net, we will just run a non-credentialed scan.
If we click on the arrow next to Start Scan,
we see there are a few different options.
We can of course Start the Scan.
This would crawl the site, and attack at the same time.
We can select Crawl and Wait,
meaning the scanner will just map out the site for us.
It won't perform any attacks.
We can also do a manual crawl.
This is like using an interception proxy.
We would use our browser to crawl the site manually,
telling the scanner where to look.
We can also tell the scanner to attack
an imported list of links from another crawler.
Those are all typical options
that are in most automated scanners.
So, let's kick that scan off now.
While the scan is running,
we can see the results come in.
Depending on the size of the site,
the scan could take from minutes to days.
So, for the purpose of this demo,
what we'll do is we'll pause the recording,
and skip to the finished scan.
Now let's take a look at the results.
With Netsparker, it does a great job
of showing us clearly, how many defects it found,
and the severity.
The scanners really just give you an indication
of where there might be an issue.
It's up to you to validate them.
Some scanners give you the ability
to do the validation inside the application.
So let's take a look at the results
of this specific scan.
One of the first ones we see here, on the left,
is an outdated version of Apache.
If we click on it, we can get the details
of any vulnerabilities that may apply.
This one is easy to validate.
We just need to verify that
the version of Apache is correct.
We can actually look at, back at our results,
from the Nikto scan, to see that it matches up.
Let's take a look at another vulnerability that was found.
This one is suspected cross-site request forgery.
If we click on the Request and Response tab,
we can see that there is a field highlighted.
This is the field where the scanner suspects
there might be cross-site request forgery.
From here, I would normally take this request,
and replicate it in Burp Suite,
to validate that it really is CSRF.
The main use for automated scanners
is to identify the areas where we should look deeper.
It usually catches the low hanging fruit as well,
like basic authentication, and outdated versions, etc.
Most of your work will be sifting through
the results of the scans.
You can also export the results into a report format.
This is another feature that
is common to automated scanners.