hey everyone
my name is j.r johnson and my talk today
is going to be a
crash course for web application
penetration testing
so first just a little bit of background
about me i'm a principal security
engineer at
triaxium security i've got a bunch of
letters
up to this point in my career including
some web app related certs from sans and
offset
um more importantly i'm a dad uh to two
mostly wonderful kids i enjoy competing
in ctfs with the other guys on our pen
test team
and i also enjoy collecting and drinking
bourbons and ryes
there's my twitter and discord handles
if you have any questions during or
after the talk
i'm pre-recording this so i can respond
to any questions that come up
live during the talk so reach out to me
on twitter discord
a little bit more about me so i don't
normally do this much background on
myself
but i added this slide in because i
think it's it's valuable to understand
how i got into pen testing and kind of
what perspective i'm approaching it from
so i spent a little over seven years as
primarily a full stack developer
supporting the air force
during that time i accumulated a lot of
different responsibilities
things like server enclave management
certification accreditation
that started to shift my focus more
toward application security
ultimately before i left that job i
started performing cyber security
evaluations
for command and control systems used by
joint services
which really kind of convinced me to
make the full jump over to the private
sector and start doing penetration
testing
with that background when i got into the
private sector obviously web
applications kind of naturally became my
specialty
when i was working as a consultant so
and as a lot of you probably know
when you work as a consultant that does
penetration testing
you get to work with a really diverse
set of organizations
and so i got to see a lot of different
types of applications a lot of different
architectures
over the past several years working as a
penetration tester
and so during those years and more
specifically as i was kind of
researching this
talk um one thing was pretty clear
people absolutely love the owasp top 10.
every talk i watched preparing for this
that was even remotely related to pen
testing
had an oauth top 10 slide or was
covering the oauth top 10.
um and don't get me wrong there's
certainly value there and the olaf's top
10 is important
but you know it's not really the focal
point of
thoroughly testing an application
and so that kind of led me to organizing
this as a primer for web app pen testing
based on
my real world approach so this is what
i've used to train other penetration
testers
in this space over the past several
years it's what i continue to use
as i do application penetration testing
or as i encounter applications and other
types of testing
and so just for basic background
the oauth top 10 is not a testing
methodology
it's a categorization of vulnerabilities
you know based on industry surveys
that were sent out so it kind of
categorizes them into these groups and
ranks them
by impact and prevalence and it's a good
thing because it
can be used to educate companies on how
they can weed out those vulnerabilities
and their development processes
it gives them an idea of some of these
really important things they should be
looking for and trying to avoid
but ultimately as i mentioned it's not
going to teach a penetration tester how
to conduct an assessment
owasp does have a security testing guide
which they publish
which is very detailed um and it's a
really great reference to use during
testing
but it's more of a checklist of making
sure you've covered everything
rather than an approachable process as
you're evaluating an application
so it's a little bit of a complex set of
vulnerabilities that you should be
looking for
but they're not really in a particular
order where you can you know kind of
run down the list
and ultimately a ton of talks in this
space in web application security in
general focus
on some really cool attacks some
relevant exploits
or things that are particular to a
certain technology or stack
but these things don't apply in all
situations
so one of the things i didn't find as i
was looking through all these different
talks and looking for
other industry resources is a more
realistic approach to penetration
testing something they can use that you
can use
that's more repeatable and in every
scenario
and so that kind of led to to this talk
ultimately and
and so when we're going through this why
should you care
um well first and foremost if you're a
penetration tester
the goal here is to start off with a
basic repeatable approach that works for
any application you encounter
this is going to be across uh
every type of penetration testing really
so you know this is going to focus on
web application penetration testing
specifically but it's got applications
in network level testing where you may
find an application on an external
perimeter of an organization
or internal penetration testing maybe
when you're running out of
options on an internal network so you
start looking and digging into
applications a little bit more
through each of these different
approaches or areas that you might
encounter web applications
the goal here is to just give you a
consistent approach to identify more
vulnerabilities
so you feel comfortable when you start
looking at applications
and if you're a blue team or a developer
there's still a lot that you can learn
from
this material today if you can
understand
how an attacker thinks about your
applications
that you're trying to defend you could
better identify the tax
the attacks that they're going to be
using and it'll help you
cut those attacks off earlier in the
kill chain potentially
yes i just said kill chain so drink
and so a brief overview of what we're
going to cover today
so i'm going to touch on what makes web
application penetration testing unique
first of all compared to the other types
of assessments that are out there
and why this is a more unique problem to
web app pen testing than say
coming up with a process for an external
pen test
and then we're going to talk through
what that realistic high-level
assessment approach that can be used
is so we'll start with planning and
we'll work our way all through
qa and reporting
and so like i said uh web applications
are
unique so as an attack target
there are um some differences and some
things to consider when you're when
you're looking at them
first and foremost web applications are
important um so
in more and more cases uh applications
represent
you know the primary if not the only
things that organizations are exposing
to the internet
we're seeing more and more attack
surface get cut off through the use of
vpn
of multi-factor authentication on things
like vpn and email
and so attackers are focusing on other
targets like web applications
in addition to that applications are
often driving the core
business of organizations now so what do
i mean by that
things like sas companies companies with
an e-commerce presence
the impact of application compromises
can be extremely high
when your business model is focused on
these applications staying up
not being compromised things like that
so
overall web applications are important
um
you know quick statistic from a recent
report i saw from forrester on the state
of application security
uh 42 percent of organizations that had
experienced an external attack
blame the incident on a software
security flaw now
take this work you will you know this is
just some random statistic i think the
number might be a little high honestly
if you had to ask me
but the point still stands as network
security improves in other ways
attackers have to shift their focus so a
lot of times we're talking about this in
the context of social engineering which
is certainly still true
but this also applies to exposed web
applications
and so when you're looking at a web
application
typically there are some starting points
for our approach that are true most of
the time
if you're calling something a web
application penetration desk it really
needs to be
an authenticated assessment um if you
just do unauthenticated web app testing
it's kind of like having a home
inspection
but you know they're just checking if
the front door is locked maybe checking
around the house to see if the outside
of it looks good
they're never actually going into the
house so there's so much that could be
wrong inside but you never know if
you're not doing authenticated testing
for an application that you're really
trying to evaluate
and that's why in most cases web
application penetration tests are
conducted as
gray box assessments um you know we're
given some things maybe an application
walkthrough
uh some credentials to authenticate as
different user roles
maybe we're given some information about
the architecture or the business use
cases
but most of the time we're not going to
have full access to source code
a lot of organizations will kind of
categorize this as a separate type of
assessment
that's usually a lot more thorough so
this is not going to be
kind of the norm for what most
organizations can
afford or what they're ready for
but you know what makes web app testing
different given all these things well
first and foremost every application you
encounter is going to be different um
just from the sense of
the tech stack it's using you know what
language it's written in
what framework it's leveraging uh the
underlying architecture
you know everything from cloud
architecture now
uh to linux versus windows operating
systems
to um how is it built or how
how does the traffic flow through the
application you know is it
a thin front end where there's an api
are using
what all these different things create
these unique combinations
and each unique combination has a unique
attack surface
so a standard testing checklist is
extremely difficult when we're talking
about web applications
um web applications are all going to be
unique they're all going to be different
so you
there's certain things that just aren't
going to apply you have to really
consider
what you're looking at and how to to
kind of manipulate your checklist
to work in every scenario
and so that's what we want to try and do
here i want to try and address some of
those challenges
to create a baseline just a simple
basic repeatable approach that you can
use in any situation when you're trying
to evaluate the security of a web
application
and so here's what you know the high
level process i'm proposing looks like
so this is what i tend to use as we're
going through an application
and you know these steps should be
somewhat familiar
you can break them down in a lot of
different ways and you know maybe you'll
want to customize this is
something you're going to use over and
over again but ultimately the
five steps that we've broken this into
are planning and preparation which is
basically
everything you need to do before you
start testing anything
then we've got unauthenticated testing
so this is the part of testing where
you're basically emulating an attacker
on the outside trying to break in trying
to
gather sensitive information anything
that you can do that doesn't require
credentials to the application
then we focus on the login process so
basically everything that happens
as you authenticate to the application
and how the application
application tracks your state so what
what state you're in how it performs
session management
um and then the authenticated testing
piece which is
most of the time going to be the bulk of
your testing but basically looking for
all these different types of
vulnerabilities after you've logged into
the application
and finally just hit on some things that
are important to keep in mind as you
wrap up with
quality assurance processes and
reporting for an assessment
so first plenty of preparation
at this point you're really just getting
ready to test something so
there's really nothing technical you
need to be doing at this point
you need to have all the necessary
paperwork in place things like contracts
your roe
prior to getting started there's plenty
of other
talks that have gone through things like
this you've got to get some
target information credentials from
whoever you're doing the testing for
and make sure you understand any
restrictions that are in place for your
testing any areas of the application
that are off limits what is and is not
in scope you know in a lot of cases
maybe you're going to get an application
walk
through from a stakeholder of the
application
on how they use it just so you could
kind of have a little bit more context
as far as a use case or what
normal usage of the application uh looks
like
and that'll kind of help inform your
testing too um and
ultimately for all these things uh we're
not going to spend too much time here
during this talk
you know really this isn't the
interesting stuff so there's no reason
to spend too much time here
and then there are other talks that
focus on you know
penetration testing preparation um
that that is repeatable and things that
you can do for any type of assessment so
but with this with your preparation i do
want to touch on some important
considerations with your tooling at this
point
so this is probably going to be the most
specific i get in this talk and just
talking
through some of the things to keep in
mind as you're getting ready to do
testing
the most important tool in our toolkit
as web application penetration testers
is arguably whatever intercepting proxy
we're going to use for the app for the
assessment
i primarily use burp suite pro i think
it's by far the most prevalent at this
point in my experience and i just really
think it's the best for this
but when you're using this and you know
these things can apply for every
intercepting proxy but you'll see my
screenshots do use burp suite as the
example
there's going to be a few tips that will
help save you time and make sure you're
you're consistent in how you're
assessing applications
moving forward um the first thing here
is just to always
always start projects that are saved to
disk
you know this is something that i've
learned the hard way unfortunately from
time to time it's very easy to just
start up temporary projects as you're
testing
helps you get into it more quickly but
even if you're doing some quick checks
you're going back to double check things
it's always good to save
those burp files to a project folder
just so you can go back and reference
them
and then obviously clear them out over
time as you don't need them anymore
but i can't tell you how many times i've
gone back and had to retrieve some type
of valuable information
from those burp files that i wouldn't
have had if i hadn't saved them
so very simple but something that's
really valuable as you go through and
want to be more consistent in your
testing
additionally when
you your organization finds in and
sets up a set of valuable configurations
um so things that you guys have
collected over time
or things that you want your entire team
to use
um little quality of life changes even
these things should really be saved into
configuration settings and reused so you
can export these from burp suite
as project options or user options
and there's different options that apply
to a project versus a user
um so there's some slight differences
there but these things can really speed
up
your startup time when you're beginning
a test and make sure you don't
forget anything that's really important
so under project options you know we use
this for things like your custom burp
collaborator
um so if you leverage a custom
collaborator such that
you own the host that all of your client
traffic is flowing to and from
um you want to make sure that that's
configured every time you do an
assessment
additionally under user options there's
things that can just be
you know simple quality of life
improvements to make things a little bit
faster a little bit less painful
you can change your backup frequency so
i think by default it's something like
60 or 90 minutes burp's going to do an
automatic backup
i think there's a lot of value in that i
like the automatic backup feature
but a lot of times i will increase that
time period to something like 120 or 180
minutes just so it's less disruptive
additionally things like disabling your
proxy on startup so you're not
automatically intercepting traffic
and wondering why your your webpage
keeps freezing i know that's happened to
me several times
uh make sure that that's disabled on
startup or configuring a socks proxy
that you leverage every time you do
testing so if you have specific testing
instances where you need to proxy your
traffic through
for web applications you can save all
that and just load that as
a configuration file the next time
also within burp um there are some
um amazing capabilities you have at your
fingertips with extensions
um and new ones just continue to roll
out that i find more value in every day
so a couple of the
common ones that i use um are things
like active scan plus plus
this just extends all the scanning
checks that burp uses
helps to identify some things that
there's value in as an attacker but that
burp won't look for natively
so things like suspicious input
transformations
host header attacks little things like
that
um additionally beyond active scan plus
plus
there's j2ee scan this just provides
some additional coverage for
vulnerabilities that are specific to
certain frameworks so things like jboss
struts grails and it does provide some
tools to exploit those vulnerabilities
if they're found as well
um so it you know really just provides a
thin layer of extra checks that you
don't really have to do anything
additional it'll just look for that
stuff in the background
probably most importantly is logger plus
plus so this
really extends burp's logging
capabilities in such a way that makes
the
uh request and response logging more
valuable so this is really really useful
for troubleshooting or tracking
responses when you're doing scanning
so a lot of times if you're doing a scan
it's really difficult to see
if what kind of responses you're getting
maybe if you're
accidentally timed out or your
authentication macro isn't working
properly
logger plus plus kind of fills that gap
and gives you more ready access
to to burp logs
and then there's a ton of other
extensions to consider just based on
your target
so like i said this isn't going to be
necessarily going into
some specific extensions to use
for for specific scenarios but there's
tons of stuff that you can use like
json web tokens is an extension that
helps manipulate jwt's
um java deserialization scanner
is exactly what it sounds like but that
will help you identify deserialization
issues and then exploit those issues and
then things like graphql raider
if you end up testing applications that
leverage graphql
that'll kind of ease that process as
well so a ton of random stuff definitely
go check out the
the list in the burp application store
within the extender tab
another thing to consider so whenever
you're doing testing you want to
configure your scope every time
and so this is something that is so
simple it takes two seconds
but you want to make sure you do this
and use advanced scope control
so you're not missing any sub domains or
valuable information in your target tab
but you're not collecting extra
additional information that you have to
sift through
let's just basically make sure that
you're only seeing things that are in
scope
based on what you define here and you're
not getting anything extra that muddies
up the information
another thing to consider here is we
need to use a browser to send traffic
through burp obviously
so we have two distinct options
um on the left you'll see the first
option and
you know i'm a huge fan of it now that
it's become more stable
is burp's embedded browser so this is
very easy from your
proxy tab you can simply open a browser
it's dedicated
it automatically proxys things through
burp it automatically uses burp ca
certificate so there's really no other
setup you need to do
it's the easy button and you can still
do other things
in your other browsers um without
proxying that traffic through burp so if
you're doing
multitasking doing other things this is
super convenient
if you do still want to use another
browser rather than burp's embedded
browser
then you've just got to make sure you
have a way to quickly proxy traffic
through burp
so i use foxy proxy in those cases to
make it really easy to turn my
intercepting proxy on and off in the
browser
and then make sure you install burp ca
certificate or else you can run into a
lot of strange
issues with trust
so finally to summarize um
burp suite pro or whatever intercepting
proxy you're using
consider some quick checks before
getting started just to make things or
make sure things are going to go as
smoothly as possible so remember to save
your project to disk
loader save configs so you can reuse
them be more consistent
leverage extensions to make sure you're
not missing anything in your testing
configure scope so you're only seeing
what you want to see
within your burp application and then
make sure you configure
the browser or use a browser that will
proxy your traffic smoothly
and then you know profit so this way
everything that you're doing during
testing should be flowing through burp
um and that way you won't miss anything
um whether you're doing a web
application penetration test
specifically
um or other types of testing we're
looking at an application for maybe a
small a shorter check
all right so now let's jump into actual
testing here so
first is unauthenticated testing and
at this phase of the project our goal
is to gain access to the application
without using any credentials we are
provided
or find sensitive information that
shouldn't be exposed so this could be
information that
is sensitive in nature that may be a
risk on its own or it may help us
in future attacks and i break this down
into four
primary pieces or steps here so the
first
is ocean plenty of people have done
plenty of talks on the specifics here so
i don't want to dive too far into the
weeds of what ozin is or how you do it
but you know to be honest for web app
testing it isn't always a gold mine
so it's something to consider it's
certainly something you don't want to
skip over
but it may not be incredibly valuable
depending on the context of the
assessment
so it can do things like provide context
into the organization's business itself
maybe information about how they operate
or what they use this application for
this could give you a hint as far as
what's most critical within the
application or what should be a biggest
consideration
and it could be helpful as you're trying
to determine impact and risk of specific
vulnerabilities
otherwise it often provides
hints into application architecture as
well so when you're doing oscent
maybe you want to look at linkedin or
job descriptions as they have posted to
help fill in some of the blanks as far
as what application architecture you're
looking at
this could give you some indication of
what types of operating systems are in
use
whether they use any containerization
like docker or kubernetes
um and it could fill in some of the
blanks
if we don't find that information at
later phases and then finally uh you
know gathering emails and usernames
could come in handy
i don't always do this right off the bat
unless i have some kind of target
but it can't be useful if you find
somewhere to launch password attacks
or if you need to consider any other
types of back doors that may be in scope
for the application
try and find usernames or credentials to
use there
and so next step is to evaluate the
network layer i feel like this is often
forgotten
or completely bypassed when you're doing
an application level assessment
but i've definitely had luck here in the
past so it's really not something you
should completely ignore
when you're conduct excuse me when
you're conducting a holistic assessment
you've really got to start at the bottom
and work your way up um
you know you don't have to do anything
fancy here i'm just really talking about
an nmap scan
to help identify what other ports and
services may be available on the host
and then check into those to see if
there's any potential attack surface we
need to consider
so we're just basically checking to see
if there are any side doors or back
doors that may be open
and then whatever you do find from an
nmap scan you want to manually interact
with those services
and try to identify vulnerabilities
there look for vulnerable versions of
software maybe
try password attacks if you see
something like ssh
open with username and password
permitted maybe try uh
authentication bypasses or password
attacks on like a tomcat login or
something
on a dish on like port 843 maybe
any of these can help to either confirm
attack or confirm architecture excuse me
of the application itself
or they could provide additional avenues
of attack that we want to explore
so we've covered ocean we've covered the
network layer we're continuing to work
our way up and now we're starting to try
and identify the application
architecture itself
um so this is the part where you really
want to gather as much information about
the application
as possible and start creating kind of a
mind map
understanding how the application
functions and what pieces exist
really really simple but i like
wapalizer
as part of as a browser add-on that
basically helps to quickly identify
these technologies and versions
this is like my very very first most
basic check when i look at an
application
it just automatically scrapes the page
for artifacts that indicate which
services or libraries are in use
it'll tell you the version numbers if it
finds them really really simple stuff
but can help speed up the process
in addition so you know as you start
making this
this map or as you start mapping out the
application infrastructure
um you want to figure out or get a good
assumption
about different portions of the
environment just so you know what you're
working with
and this is going to help inform testing
later on in the process
so from your browser to the web server
first of all what web server is being
used
based on that web server do we have any
indication
of the os that's being used or where
it's hosted
do we know if it's in azure do we know
if it's in aws
you know do we see any any artifacts
that could indicate they're using
containerization services like i
mentioned
beyond that you could start to
guess different parts of the
architecture right so
maybe in certain scenarios we see a
net application right that's that's uh
very likely hosted
on a windows operating system because we
see it's using the iis web server
while we now have a pretty decent guess
about in most scenarios what the
database type will be
probably 75 to 80 of the time it's going
to be a microsoft sql database being
used
on the flip side if we see other
indicators maybe that could
be a guess that you know yeah it's
probably not microsoft sql this might be
my sequel or might be
oracle database or postgres something
like that these little things are just
assumptions we want to start trying to
make in addition
what is processing our data or request
for the application
um is it being processed by the front
end itself like a like an aspx page
where the front end is doing the heavy
lifting lifting and the data processing
or is it like a thin client front end
where there's really an api that's doing
all the heavy lifting in between
um is that on a subdomain what what does
that look like where how does that
traffic flow
so we're starting to build this out in
our mind we're trying to make make
make educated guesses or or assumptions
about the architecture that's in place
but beyond just the architecture itself
and what types of servers are in use
what types of of
what pieces of the application may be
there we also want to know what's
sitting in between
us and the web server um so this these
are just things that we have to account
for during our testing
so this might be a web application
firewall that could be
killing our requests something like
cloudflare something like
aws's waff there are
going to be certain things that could
kill our traffic before it even reaches
the web server
so if we identify that there's a laugh
in place
maybe that's going to affect how our
requests are processed
is there a load balancer in place this
could tell us things like
if we're seeing differences in response
headers
or if we're seeing different
changes to our traffic as it goes to and
from the server
there may be a load balancer that's in
the middle there and that's kind of
changing
how it handles the traffic
so finally we're doing an authenticated
testing we want to evaluate the
application content itself
um once we get to the application
content itself
this is again really we're getting more
into that traditional
web application process at this point
but we're trying to identify
again any sensitive information that may
be disclosed
this can be through things like direct
rebrute forcing
maybe we're looking at the http response
headers in our proxy that we've got
maybe we see code comments that we see
from the responses in our proxy
we're going to be looking at the account
registration processes forgot password
processes authentication processes
all these things that are traditionally
exposed if they're
available to us we're going to be
assessing them for things like username
enumeration
uh password reset weaknesses password
policies
and then of course things like injection
on on inputs maybe sqlite or bypass
authentication little things like that
but at this point in that process you're
really looking to evaluate anything that
is exposed
prior to authenticating and then
any other vulnerabilities at this point
so you know if you're scanning inputs
and you see other vulnerabilities that
may be based on the specific target
application architecture we want to test
all those that don't require
authentication as well
moving into the login process so at this
point
we've tested the application as an
authenticated attacker now we want to
use the credentials that we've been
given
in order to evaluate the login process
to get into the application
so at this point i'm stepping through
each request and response of the login
event
and really focus only on this attack
surface so everything where it processes
my credentials
allows me into the application and
issues me some kind of
cookie or token to identify my session
that's what i'm focused on here
and so when i'm doing this it's more
helpful to me to think about it in terms
of what questions am i trying to answer
as i evaluate it
login processes can be so different it's
really difficult to have a specific
checklist because it's going to be
you know you're going to kind of have to
adjust based on how they handle
authentication
so you know everything from how do you
log
in how do you log out how do you change
your password uh
does the application have username
enumeration that we were able to exploit
does the application support single
sign-on so if it does support single
sign-on
does it send you to a third party or is
it an on-prem sso and
is that in scope that could you know
really cut out a significant piece of
our assessment here if we're not able to
evaluate that single sign-on solution or
how that information is communicating
back and forth
are all the functions associated with
the login process encrypted very simple
but is
anything not flowing over https
basically
um are there any anti-automation tools
in place so this may require going back
and forth to the authentication process
obviously
but is there a captcha that's required
or is there an
account lockout that's in place is there
anti-brute forcing where maybe there's
ip lockouts
exponential back off all those different
kinds of things and then if you
do encounter a lockout is it sending an
email to the user
providing them a notification is there
any evidence that there's logging of
that event or anything like that
once you get into the application though
again
session management is very very
different different across the board
um so is it issuing you a cookie and
um if it does if it is issuing you a
cookie or some kind of token
is that a homegrown type of solution or
is it leveraging something that is built
in
so something like a php session id or an
aspx off cookie
those are built in using known good
libraries
so there's generally less attack surface
less to check there but if it's
something where you're not sure
or it looks like a custom solution then
you want to be looking for things like
the entropy of that
does it have cookie flags set on it how
is that session being managed so is
there a way to modify
any contents of the session or token is
there
a a new session id that's issued when a
user logs out for example um
and then for tokens
you have to consider any unique attack
surface there as well
json web tokens or jwts are becoming
extremely popular as an open source
standard
and so they have a lot of unique attack
surface that's outside the scope of this
presentation
but it's really really interesting if
you run across them so make sure you
dive into those
if you see them
and then finally jumping into
authenticated testing so the last piece
of the the tactical testing here
once we've completed testing the login
process
now we basically have to look at
everything else in the application so as
i mentioned earlier this is the bulk of
testing a lot of times
this is where you really got to check
all the features or all the elements of
an app
and this is where you're looking for
those exciting exploits most times so
injection points file uploads
any type of parameter tampering things
like that
and the goal here is to again get access
sensitive information you otherwise
shouldn't have
escalate your privileges in order to
gain access to more sensitive features
or or functionality you shouldn't
or take over the underlying host
ultimately
and so when you're jumping into testing
the authenticated portion of an app
this is where a lot of people get really
overwhelmed really quickly
um so this is where it's important to
try and have a plan and stick to it
so for me i follow a couple rules as i'm
assessing an application
that are you know loose it can change
from time to time but i generally focus
on testing from the least privileged
account to the most privileged account
um and this is order in order to
again focus on the things that are most
impactful first so if there's a sql
injection for
a free registered user that gives
full access to the database that's going
to be more impactful than a sql
injection
as an employee administrator for example
it's also a little bit easier to sift
through what functionality within the
application
is accessible to a low-level user versus
an administrative user
i also test features in kind of the same
way so i'm testing features
in order of highest potential impact for
the organization
so i try and look through and understand
the application and as i'm looking
through i see what i want to target
first or what features or areas of the
function
of the functionality i want to target
first so
maybe i want to look at where sensitive
data is stored within the application
first or how it's manipulated
for a healthcare you know sas product
ephi disclosure is going to be really
really important so i'll probably focus
on
any areas where i find that first you
know whereas for an e-commerce website
i'll probably be looking at the cart
first maybe how users payment card
details are stored
or if they're stored things like that so
you really want to adjust and focus on
the highest potential impact
so you can really make the most of your
testing
additionally you may need to jump back
and forth as you're testing
to in order to
get full coverage and make sure you're
checking everything so what do i mean by
this
when you log in as one user you may need
to grab identifiers
names you know different accounts to
target
so you can check that when you're logged
in as a different user
so if i want to move laterally i'll log
in as one user to get ids
or or you know particular data that i
want to try and access
and then log out and log in as a
different user and check whether i can
access that data
same thing applies for when you're
trying to access
administrative functionality as a lower
level user
if you're trying to change parameters
and access features
you may not even know they're there
until you log into the administrative
user and then you'll have to go back and
check for them
so just keep in mind that testing is a
loop um and when you're doing that
it can be hard to keep track of features
for
you know that one account has access to
versus another
um from most of most of the time for
small applications
i'll do this by hand and create kind of
a list of what one user can access but
another user can't
but for larger apps you can definitely
use built-in tools
like burps compare sitemaps
functionality so you can basically
browse to the application as one user
log out browse the application as
another user and another instance of
burp and contain
compare the site maps of the two to very
easily identify what one user has access
to but the other user doesn't or
shouldn't at least
and so as you're doing this testing as
you're going through all of this testing
and looking for things like parameter
tampering or looking for things like
um you know cross-site scripting
you've got to keep context in mind more
importantly here than in any other type
of assessment
you've got to make sure you're looking
for the right types of vulnerabilities
you know it doesn't make sense to look
for a polar bear in the rain forest
basically what i'm saying here is if no
input is being sent to the back end
don't bother checking for sql injection
if there's not a templating engine in
use for example
there's not going to be server-side
template injection
so many times i've seen testers that
want to look for these
really crazy vulnerabilities and look to
take over an underlying host
but there's no file upload functionality
for example so you're really
kind of barking up the wrong tree and
putting all your eggs in the wrong
basket
so just keep that in mind as you're
going through a web application
and then one final note here on
authenticated testing so
as i mentioned we really didn't go into
any details on specific vulnerabilities
or what specific
issues to check for but as you're going
through and doing manual testing
you still want to make sure you're
scanning with burp um or whatever
active scanning tool you're using as you
go through because this is really going
to cover a lot of fuzzing
you know vulnerability checks trying to
induce useful errors that you can
analyze
you still want to make sure you're doing
that and so as you do that
the important thing i want to note here
is not to just click
click go and throw an application scan
at
the entire web application tree for
example you know you don't want to do an
active scan of every single thing in
your
in your target map within burp suite not
only is this going to be really really
inefficient
but it can get really messy within the
application so you could end up masking
real findings with garbage input
or you could be missing stuff you know
if you scan all these things at once and
the scan fails
you have absolutely no idea how far it
got or where the scan started to fail
or if you got de-auth for example you're
never going to know so you're going to
be missing pieces of things
so for me and one of the most important
things i do as i'm going through and
trying to scan an application
is to be a little bit more selective
about how i do that
so i configure my scanner i have a
specifically configured scanning profile
which for you guys the most important
thing there is just to make sure you're
doing a thorough scan within burp suite
because that will do
all of the checks for vulnerabilities
but also to aim it at specific
parameters
and when i say aim it so i'm basically
looking at
particular requests of interest and i'm
choosing which parameters i scan
rather than scanning all of the
parameters associated with with a
particular request
and you know maybe i'll scan all the
parameters once or i'll scan certain
parameters once but on subsequent tests
or when i'm looking at different
requests with the same parameters
i'm only going to look at the ones that
are of high value or of interest to me
the ones that i know that are being
processed by the back end for example
or ones that are particular fields that
might be interesting
and by doing this not only is scanning
going to complete a lot faster
with a lot less errors we're not going
to overwhelm the application with too
many requests
any issues we run into during scanning
we're going to be able to quickly
identify them and know where to restart
all any issues we have are just going to
be localized effects
and so if you're not familiar with how
to do that within burp here's just a
quick screenshot to cover it
on a request you can see at the very top
you can just scan something
broadly and that's going to hit every
single header every single cookie
every single parameter within the
request what i do instead is i send a
request to intruder
and then within tr within intruder i
mark the specific parameters that are of
interest to me
and then i scan those defined insertion
points
and again by doing this i'm scanning in
bite-sized pieces i get results a lot
more quickly
and i make sure i don't overwhelm the
application
and so to wrap up our high-level process
here with q a and reporting
so the goal here is at this point in the
project is really just to make sure that
every vulnerability is reported
accurately
and you're giving organizations enough
information to fix these issues
so you know again nothing exciting or
sexy here we're really just kind of
covering this for completeness
but you want to make sure you've got
full coverage in your testing of the
application
make sure you didn't miss any major
portions or major features that could be
considered critical
beyond that you also want to make sure
you identified key strengths
alongside weaknesses during your testing
you want to be realistic
in how you're ranking risks for the
organization you know if you call
everything you're critical
uh they're not going to know how to
prioritize their efforts they're not
going to know what to really focus on
so make sure the criticals are really
critical and others are are
just ranked lower um and then ultimately
make sure all of your findings that you
are reporting regardless of criticality
are are clear and detailed enough for a
developer to be able to fix them
our goal as penetration testers is
obviously to create more secure
applications
and if developers don't know how to go
back into an application and fix these
things
then there's going to be problems we're
going to see the same vulnerabilities
pop back up again
in future tests
and finally just to wrap us up here so
ultimately the whole point of this talk
is to
make web application penetration testing
more organized and more approachable for
everyone
so everybody loves to talk about the os
top 10 but for testers that really
doesn't do you much good when you're
trying to figure out how to approach an
application
so hopefully now i know this was really
high level there's definitely
room for more detail and a lot of these
different sections that could be entire
talks of their own
but hopefully you now have a repeatable
process for any time you come across
apps whether that is with web
application testing specifically
or in other types of application testing
where there's a web application as part
of the
attack surface and for defenders now you
have a little bit of an idea about how
penetration testers or attackers are
going to think about applications they
come across
all right and as i mentioned earlier i
recorded this talk so i will be
available on
twitter or discord at any point to
answer any questions that may come up or
to go into more detail
because i know this was a really small
time window in to fit everything you
want to know about web application
penetration testing
so if you want to have a further
conversation about any of these topics
i'd love to just reach out to me
thanks everyone for your time