►
From YouTube: UX Showcase - DAST scan site validation
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Das
stands
for
dynamic
application
security
testing,
it
analyzes
your
running
web
application
for
known
runtime
vulnerabilities
within
gitlab.
It
runs,
live
attacks
against
a
review
app,
which
is
created
for
every
word
request
as
part
of
gitlab's
ci
cd
capabilities
users
can
provide
http
credentials
to
test
private
areas.
Vulnerabilities
are
shown
in
line
with
every
merge
request
in
addition
to
those
desk
scans.
We
also
have
on-demand
desk
scans
and
the
job
to
be
done,
for
that
is.
A
It
would
run
a
scan
against
a
live
website,
perhaps
on
a
schedule
or
just
at
any
time
that
you
want
an
on-demand
deskton
is
comprised
of
a
scanner
profile
and
a
site
profile,
and
this
is
this
is
where
my
issue
takes
place
within
site
profiles.
So
the
mvc
looks
like
this
and
it's
you
add
a
profile
name,
you
choose
your
site
type
target
site
and
then
you've
got
this
validation,
toggle
validating
your
website
means
that
you
can
run
active
scans
against
it.
So
you
can
actively
attack
your
website
for
known
vulnerabilities.
A
Active
scans
like
this,
can
slow
down
a
website
or
take
it
down
completely.
So
it's
something
that
you
want
to
be
careful
doing.
You
probably
don't
want
to
run
it
on
production,
or
only
do
it
at
specific
times,
and
we
want
to
make
sure
that
if
you're
going
to
use
gitlab's
dash
tool
to
run
an
active
scan
that
you
actually
own
that
website
and
you're,
not
just
attacking
other
websites.
A
So
in
order
to
ensure
that
you
do
own
that
website,
we
offer
these
methods.
You
can
choose
a
validation
method,
for
example,
meta
tag.
Validation.
You
add
that
to
your
website,
push
that
to
production
and
then
confirm
the
location
and
validate
once
that
has
been
confirmed.
You
can
go
ahead
and
run
your
active
scans
against
that
website.
A
In
the
current
design,
this
toggle
does
a
couple
of
things:
it
you,
you
click
that
and
then
you
can
see
this
form
show
up,
but
before
that
it's
it's
triggering
a
request
in
the
background
to
check,
if
that
url
has
already
been
validated
if
it
hasn't
been
validated,
this
appears
just
as
it
is
shown
right
here.
If
it
hasn't
validated,
it
shows
a
banner
and
says
your
site's
been
validated.
You
can
run
active
scans,
so
within
the
entire
site
profile
form
it's
doing
three
things
you
create
your
overall
site
profile.
A
You're
also
checking
the
status
of
the
validation
on
that
url,
and
you
can
potentially
validate
that
url
all
within
this
one
form,
so
it
got
it
gets
a
little
complicated,
but
this
flow
does
work.
The
reason
I
open
the
issue
to
begin
with
is
just
because
I
thought
that
it
should
be
a
checkbox
instead
of
a
toggle
based
on
our
docs.
A
A
toggle
should
be
used
when
the
results
are
effective,
noticeable
immediately
and
there's
no
need
for
user
to
click
a
submit
button
because
it
confuses
users
and
dilutes
the
experience
by
preventing
instant
results.
So
it
made
sense
to
use
a
checkbox,
and
I
thought
this
would
be
a
relatively
quick
change
and
I
was
so
wrong.
So
the
first
solution
I
came
up
with
was
using
this
checkbox
and
also
keeping
all
of
the
options
in
view
at
all
times,
rather
than
showing
and
hiding.
A
That
was
that
immediately
came
up
with
so
many
problems,
because
at
least
when
we
were
hiding
it
originally,
we
were
able
to
be
able
to
click
that
send
that
request
to
check
the
status
and
then
populate
this
with
the
correct
data
before
you
could
see
it.
So,
for
example,
this
step
three
confirm
location
should
match
the
target
type
that
you
put
in
before.
A
If
everything
is
shown
right
off
the
bat
we
needed
to
come
up
with
defaults
for
here
and-
and
here
I
guess
which
could
change
depending
on
when
you
updated
the
target
site,
so
that
was
already
kind
of
a
little
bit
of
a
weird
interaction
there
that
was
yeah
one
of
the
problems.
Another
problem
was
just
that
the
inputs
had
to
be
disabled
and
enabled
at
various
points
throughout
the
flow.
A
You
could
get
that
same
banner.
That
says
it's
validated,
but
this
is
where
some
of
the
weird
experience
comes
in.
If
you
have
validated
this
url
on
a
different
profile,
you're
not
going
to
see
the
validation
method
that
you
used
on
that
because
it
doesn't
actually
matter
so
we
would
have
to
just
hide
this
entire
box
and
it
just
it
might
cause
some
some
strange.
A
They
were
too
tightly
coupled
the
validation
portion
and
the
site
profile
portion.
If
we
could
pull
that
out,
it
would
make
the
site
profile
creation
so
simple,
and
then
that
validated
url
could
be
used
to
cross
site
profiles
with
no
problems.
The
other
problem
or
the
other
theme
that
came
out
a
lot
was
revoking
that
validation,
and
this
is
another
reason
why
the
toggle
and
the
checkbox
weren't
great.
A
They
weren't.
They
don't
work
as
you
might
expect,
because
toggling
this
off
or
unchecking,
it
doesn't
actually
affect
the
validation
once
it's
already
been
validated.
So
at
the
moment
you
cannot
invalidate
it,
and
I
don't
know
if
there's
even
an
issue
for
that
yet
so
we
wanted
to
incorporate
that
too.
There
are
lots
of
use
cases
for
wanting
to
revoke
validation,
mostly
because
you
might
not
want
certain
users
actively
attacking
your
website.
A
So
the
solution
that
I
came
up
with
next
was:
let's
try
removing
validation
from
site
profiles
and
the
concept
I
came
up
with
was
here's
your
site
profile
now
and
it's
exactly
as
it
has
been
in
the
past.
It
just
does
not
include
that
validation
portion,
so
you
would
save
your
profile
and
you
would
be
dropped
onto
the
manage
das
scans
page,
which
also
already
exists,
but
the
difference
here
is
that
we've
included
validate
target
site
button
on
every
single
row.
A
In
this
example,
you
can
see
that
this
row
and
this
one
and
this
one
all
have
the
same
base
domain,
which
is
example1.com
if
you
click
validate
on
the
first
one
you're
you're
taken
to
this
modal,
which
looks
familiar
it's
exactly
the
same
as
the
content
from
the
previous
validation
section.
You
follow
the
steps
as
usual.
You
click
validate
and
immediately
you
see
validating
on
every
row
that
shares
that
same
base.
A
If
I
wanted
to
revoke
that,
you
would
click
that
another
modal
pops
up
and
I'm
thinking
it
might
be
useful
to
know
how
many
other
profiles
will
be
affected.
If
you
revoke
this
validation,
we
could
even
list
them.
If
that's
helpful,
I'll
need
to
check
check
with
the
pm
and
check
with
some
users
to
find
out
if
that's
something
they
want
click
revoke,
and
these
are
no
longer
validated
and
you
can
go
ahead
and
re-validate
them
if
you
want
to,
but
you'll
have
to
start
from
scratch.