Types of security testing.
So, of course, there would be several types of testing methodologies for Web applications.
And it's sometimes difficult to differentiate between them.
I'll be honest with you.
So in the field, sometimes the names are well used interchangeably, and I think that kind of adds
to the confusion.
So this sets incorrect expectations of every single one of these tests.
Right.
So you got to remember that each methodology has a different scope and goals, each with their own strengths
and weaknesses.
Also, what about the requirements behind the security testing, those can vary as well.
I mean, the requirements may be mandated by corporate policies as well as compliance requirements for
PCI or compliance with regulatory standards such as the Sarbanes Oxley or so to make it clear.
Each method is very different from one another, even though they may have similarities.
Some of them can be completely automated, but others have to be done manually.
So in other words, the way we do these tests differ.
Now, we're going to briefly describe some of these methods and we'll continue with our penetration
testing, I assure you.
Source code review.
So it's always good to have a look at the code.
Because every vulnerability is there except operational and deployment problems, of course.
So when source code is reviewed, the code itself is checked manually for any vulnerabilities such as
bad input validations, logic bombs or others.
It's not always easy with security source code analysis, the way I see it, if companies don't include
SDLC in their development process, a source code analysis is, well, getting really difficult to do.
And mostly companies prefer penetration testing as the technique of choice for technical testing.
Do they get where they've invested it, you know?
So a source code analysis is very efficient with a proper SDLC.
Vulnerability assessment.
Now, a vulnerability assessment is focused on finding security weaknesses or vulnerabilities within
the Web application without exploiting.
It can be completely or partially automated.
And several vulnerability scanners can be used to identify the vulnerabilities.
Also, a very great feature to keep in mind is if the scanner can prioritize the vulnerabilities that
it finds, Web application audits, security audit is well, it's really much broader than a vulnerability
assessment.
The scope of a Web application audit may contain other associated components, such as change management,
databases, application servers, firewalls and so on.
An audit team should collect data from all components of the system and then make a vulnerability assessment
according to the policy and procedures of the company's documentation.
It's also possible to interview the staff as well as other personal aspects of the business.
So the primary objective of an audit is to measure and report on conformance.
They like that word, I think it's a I like to think of it as a combination of compliance and performance
penetration testing.
OK, so sometimes people think of defense is the best offense.
Well, with penetration testing, it's actually more offense than defense.
It's more offensive than other techniques, in fact.
So then the purpose of the test you're here is to find the vulnerabilities and compromise them to prove
the security risk of the system.
So you first need to identify the scope of the test, then you can attempt to compromise the vulnerabilities
found in the application you might have come across that penetration testing is sometimes called ethical
hacking.
However, it's actually a subset of ethical hacking, but it definitely differs from the concept of
ethical hacking.
Because it's a more streamlined way of identifying vulnerabilities in the systems and finding out if
the vulnerability is actually exploitable or not.
So in this course, we're going to dive into Web application penetration testing.
So penetration testing, as we've been describing, is a way to simulate the methods of attackers in
order to circumvent an organization's security controls and then gain access to their system.
Sometimes you'll hear about vulnerability scanners as well as some other automated tools.
Now, I don't want to underestimate their strengths, but this is not an exact penetration test.
You got to get in there and get your hands dirty.
You'll see what I mean soon.
Post remediation testing.
So after conducting a penetration test, the tester or you should produce a report, right?
And this report may include a whole range of things about each particular vulnerability.
But the most important one is the advice or a way to explain how they're going to fix the vulnerability.
A pen test report without remediation is almost absolutely worthless to the customer.
So for a proper penetration testing report, the testers should verify if the vulnerabilities found
during the penetration test have been or are they able to be completely remediated.
Now, this, of course, is a separate testing, so it should be clearly defined in your contract.
Otherwise, it's not wise to test it.
OK, so we're almost done with this kind of administration stuff, but I do want to share with you three
more terms.
Now, of course, you may hear them while working in the field, and you do want to be able to know
exactly where they come from and what they mean.
So this is another approach to security testing.
The first term is white box testing.
And what this means is that you can reach almost every resource that is going to be within the boundaries
of the test, you work closely with your organization to identify potential security threats and the
IT team helps you out while interacting with the system.
That way, you can analyze the source code and talk with the internal teams of the client.
You can check the configurations, network diagrams and more if you need to.
And you will have access to insider knowledge and you can launch attacks without fear of being blocked.
Now, the second term is Dreambox Box testing.
And what this means is that you will have partial info about the assets which are going to be tested.
You may have some basic or broader information about the system if you need.
So the last one is box testing.
So in this type of test, you have almost no prior information about the assets that will be tested.
So I'm like white box testing, this time in a black box, you are not provided any knowledge about
the system.
So with this type of testing, organizations might be able to evaluate their internal security team's
ability, as well as identify their detection and response operations.
Box testing is designed to simulate the actions of an attacker, right, just like any other ethical
hack or penetration test.
However, this also relies on far too much reconnaissance.
So this type of test can be costly and time consuming.
They require way more skills than gray box tests, and I have mostly been in this type of scenario that
is often preferred by clients because you're actually simulating an absolute real world attack.
So therefore, as a protester, you will typically attempt to find vulnerabilities in a particular target.
And one more thing, in a real life pen test, you don't classify the test.
You and your client just defined the scope and then you start to test.
So what I mean by that is that test doesn't need to be just one sided, right?
Your test may be close to black, it might be close to white somewhere in the middle.
Again, this is for you to define with your client.
In the end, it doesn't really matter just as long as you know what you're doing.