►
Description
Testing applications before they go live goes beyond syntactic analysis of the changes made for vulnerabilities. Some vulnerabilities only show up when the application is deployed and pushed to the limits by users. Dynamic Application Security Testing (DAST) examines applications for vulnerabilities in deployed environments.
In this video, Abubakar will explain how DAST can be used to test your application and end it with a demo.
Documentation: https://docs.gitlab.com/ee/user/application_security/dast/
#devsecops #dast #gitlab #security #appsec
A
Hi
I'm
abubakar,
City,
Ango,
developer,
evangelism
program
manager
at
gitlab
and
in
this
video
I'll,
be
sharing
with
you
how
to
set
up
Dynamic
application
security
testing
in
gitlab
now
oftentimes
testing
in
CI,
when
your
CI
jobs
are
running,
usually
involves
static.
Application
testing
just
checking
your
code
to
check
if
the
right
syntax
is
used,
certain
errors
or
things
are
and
other
things
like
that.
Just
syntactic
errors.
A
What
if
you
really
want
to
test
how
your
application
behaves
in
environment,
where
it's
supposed
to
run,
or
you
have
certain
regulatory
requirements
like
PCI
DSS,
where
certain
way
input
how
applications
are
input?
How
data
is
handled?
How
requests
and
responses
are
handled
is
very
critical.
That
is
where
Dynamic
application
security
testing
comes
in
and
in
git
lab
you
can
set
up
different
kind
of
dust,
thus
Dynamic
application
security
testing.
The
first
one
is
proxy
based
dust
which
is
basically
used
for
websites
that
are
not
heavy
on
JavaScript
and
maybe
probably
the
simple
HTML.
A
Then
we
not.
We
also
have
a
browser
based
analyzer
for
dust
which
is
used
for
applications
that
have
heavy
use
of
JavaScript
and
the
for
the
browser
based
analyzer.
It's
checks,
the
application
story,
even
executes
clicks,
execute
impute
execute
differences
just
to
test
how
the
application
will
respond
and
how
it
will
behave.
A
We
also
have
the
API
analyzer
for
dust
which
helps
you
to
test
your
apis
and
it
supports
different
types
of
API
Frameworks,
for
example,
like
this
Wagga
I
think
open
API
framework
post,
one
collections,
a
HTML
archive
and
a
couple
of
others
that
are
used
to
build
apis.
So
in
the
gitlab
documentation,
I'll
be
adding
it
to
the
description.
You
can
learn
how
to
configure
these
different
types
of
application.
For
the
browser
based
analyzer,
you
can
even
set
up
authentication.
Maybe
the
page
you
want
to
be
tested
requires
authentication.
A
You
can
set
up,
oh,
which
Pages
authentication
going
to
happen.
Where
what
are
the
authentication
details
you
should
choose
which
text
boxes
is
for
the
username,
which
one
is
for
the
password,
and
so
you
can
set
all
of
that
up
and
the
spiders
that
are
used
by
the
analyzers
to
analyze.
The
pages
we
use
that
information
to
log
in
before
they
test
the
pages
now
I'll
be
showing
you
how
to
set
up
dust
on
gitlab
and
we'll
see
a
demo
of
how
it
works.
A
Now,
moving
to
my
browser
here,
we
have
a
project
here
already
now.
Let
me
go
back
to
my
main
projects.
Page
then,
to
set
up
dust
you
go
to
secure
and
you
go
to
security
configuration
now
under
security
configuration.
You
have
information,
we
have
different
security
testing
that
you
can
set
up.
We
have
SAS,
which
is
static,
application
security,
testing,
infrastructure
scanning
and
so
on.
But
our
focused
for
today
is
dust
now
to
enable
dust
you
have
to
enable
this
from
here
or
by
enable
dust,
and
he
it
works
with
profiles.
A
The
first
one
is
scanner
profile
and
we
have
site
profile
with
scanner
profiles.
You
configure
how
the
spiders
and
scanners
that
analyze
the
website
or
your
page
or
your
application,
how
they
behave
should
they
behave
active,
should
they
behave
passive
and
how
should
they
run
then?
The
site
profile
is
where
you
give
more
information
about
the
page
or
the
website
or
application.
That
needs
to
be
tested
and
information
that
is
needed
to
authenticate
with
the
application.
You
can
also
specify
pages
to
exclude
or
pages
to
include
in
the
analysis.
A
Now,
let's
see,
we
have
an
example
of
a
scanner
profile
that
has
been
created
here.
So
let's
review
it
and
see
now
this
camera
profile
says:
okay,
the
name
you
need
to
specify
your
name
critical
dust
and
the
first
one.
The
first
scanning
mode
here
is
active.
It's
going
to
really
test
and
test
your
application,
making
requests
interacting
with
the
application
actively.
Now
it
is
very
important
that
you
don't
use
this
against
Production
service
that
are
running
live,
that
might
impact
users.
You
should
test
it
before
it
gets
to
production.
A
Obviously,
now
for
Passive,
it's
basically
going
to
monitor
HTTP
requests
and
responses
that
are
going
between
the
application.
Now
then,
despite
that,
I'll
be
doing
the
analysis
what's
the
time
and
when
should
we
stop
and
Target
timeout,
so
the
maximum
number
of
seconds
allowed
for
the
Saturn
are
to
respond
to
a
request.
If
you've
sent
a
request
either
it
doesn't
reply
on
time.
How
long
should
you
wait
before
you
stop,
then?
If
you
want
to
use
Ajax
spider
to
run,
maybe
we
have
some
websites
that
heavy
on
Ajax.
You
can
enable
this.
A
Also
now,
once
you
are
done,
you
click
save.
Then
we
have
site
profile
inside
profile.
Here
you
can
specify
what
kind
of
application
are
we
testing?
Is
there
an
API
that
is
API
ready
to
use
the
API
analyzer
or
a
normal
website?
Then
why
is
the
target
URL
now
one
way
for
you
to
set
up
in
this
example
here
I'm
using
my
personal
websites
to
test,
because
I
can
test
against
this
mine.
A
I
can't
attack
someone
else's
website
now,
if,
in
a
situation
where
you
are
testing
your
application,
it's
important
to
use
something
like
review
apps,
that
is
where
you've
set
up
a
testing
environment
that
has
a
URL
that
you
can
test
against.
So
anytime,
you
are
deploying
you
deploy
to
that
test
environment
and
the
URL
is
specified
in
your
site
profile
for
that
steps
to
run
against.
A
So
now
you
can
also
exclude
URLs
Parts
within
your
website
that
you
don't
want
you
to
scan
and
you
can
add
additional
headers
here
that
might
be
required
for
the
scanning
to
happen.
Now,
if
there's
an
authentication
needed,
you
can
enable
authentication.
What's
the
authentication
URL,
what's
the
username?
What's
the
password?
A
What's
the
field
for
the
username
and
what's
the
field
for
password,
we
already
have
defaults
here
and
what
is
the
submit
button
so
that
when
the
analyzer
is
analyzing
the
website
going
through
the
website,
it
will
look
for,
oh
that
feel
for
username
and
the
field
for
password,
and
once
it
has
entered
the
information
into
the
value
element
of
that
those
fields
it
can
execute.
It.
A
Click
on
the
submit
button
ID
that
you
specified
so
gitlab
uses
a
browser
tool
to
do
the
analysis
so
that
it
can
be
able
to
test
the
website
thoroughly
now,
but
one
thing
that
is
also
that
you
need
to
take
note
of
when
it
comes
to
site
profile.
This
you
need
to
validate,
especially
if
you
want
to
use
here.
If
you
set
your
scanner
profile
to
passive,
you
don't
need
to
validate.
A
You
have
to
run
passive,
just
money,
chain,
request
and
responses,
but
if
you
want
to
use
active,
you
need
to
validate
validation
is
important.
You
see,
it
will
tell
you,
you
cannot
run
active
scan
against
an
invalidated
website.
This
is
to
ensure
that
you
are
only
running
this
test
against
sites
that
you
own,
so
you
validate
that
by
adding
a
header
to
the
website
or
adding
some
form
of
validation,
to
ensure
that
it
is
your
website.
A
We
want
to
know
that
it's
your
website,
it's
your
application,
so
I'm
going
to
change
this
to
passive
for
now,
and
you
can
then
get
the
code
to
add
to
your
CI
file.
So
here
we
have
it
example:
CI
file
that
we're
going
to
use.
So
let
me
you
can
either
copy
up
to
go,
add
to
your
gitlab.yamo
file
or
you
can
copy,
and
it
should
automatically
open
for
us
here.
So,
let's
replace
this
and.
A
A
A
Gitlab
uses
oops
Z
attack
proxy
to
run
all
the
tests
it
does
with
your
website
and,
like
I
said,
it
is
important
to
validate
your
website
to
ensure
that
you
are
not
running
this
against
other
people's
website,
basically
attacking
them
and
advisably.
You
don't
do
this
against
production
system.
You
should
have
done
your
test
within
you
know
the
CI
before
it
gets
to
production.
A
Now
you
can
learn
more
about
the
different
waste.
It's
done.
We
can
see
here
all
the
tests
it's
run
and
some
of
the
responses
you
got
from
the
website.
Let's
scroll
down
it's
a
requesting
access
to
these
stats
and
scan
is
better
starting
to
with
Target,
and
it's
doing
a
lot
of
execution
and
scanning
script.
Passive
scan
rules,
pass
text,
Loosely,
scoped,
cookie
cookie,
not
no.
A
It's
running
different
tests,
content,
type
header,
missing,
directory,
browsing
hash
disclosure,
private
IP
disclosure,
a
lot
of
tests
are
executed
against
the
allocation,
and
you
can
see
here
that
this
website
passed
all
there
was.
There
was
no
vulnerability
that
was
discovered.
Now
you
can
learn
more
about
Dynamic
application
security
testing
and
how
you
can
implement
it
in
the
gitlab
documentation.