►
From YouTube: Browserker Authentication Demo
Description
A discussion of how Browserker Authentication works.
A
B
B
D
B
A
Yeah-
and
this
might
be
something
we
want
to
throw
into
an
end-to-end
test,
so
multi-step
authentication.
This
is
also
in
dast,
but
it's
also
now
part
of
browsworker,
where
we
can
have
a
multiple
like
supply.
Username
click
submit
supply,
password
hit
login,
and
then
it
goes
off
and
does
its
capturing
of
cookies
information
and
then
passing
it
off
to
zap
the
other
stuff,
pretty
standard
custom,
headers,
custom,
cookies,
yeah.
B
A
A
Some
upcoming
features
allowing
users
to
supply
logged
in
detectors,
so
this
is
basically
going
to
be
a
pretty
simple
function
that
the
user
supplies
in
a
configuration
file.
Saying.
Okay,
I
want
a
verification
url
if
they
put
that
in
once
the
user
once
the
the
login
authenticator
goes
to
that
submits
it,
and
then
the
next
url
or
the
url
that
it
lands
on.
If
it
matches
that
verification
url,
we
consider
them
logged
in
and
we're
also
going
to
be
building
support
for
css
selectors.
So
they
can
say
verification,
css
selector.
A
B
B
C
A
A
Some
other
ideas
we
could
trigger
on
session
ids
or
storage
tokens
being
set.
This
may
or
may
not
be
worth
the
investment
of
engineering
time,
but
basically
we
can
do
whatever.
We
want
to
try
to
create
these
little
detector
systems
so
and
then
authentication
reporting,
which
is
what
this
demo
is
about,
which
I'm
going
to
hop
right
into.
Is
there
any
questions
on
that
or
any
other
ideas
or
features
that
people
have
that
would
like?
They
would
like
to
see
in.
A
Or
is
that,
basically,
what
your
report
is
yeah,
that
the
authentication
reporting
will
be
the
screenshot
stuff
cool,
and
just
so
everyone's
on
the
same
page
here
this
is
very
much
in
a
draft
mode.
I
just
wanted
to
get
something
in
there
to
demo
to
show
like
hey.
This
is
what
I
think
would
be
very
useful
for
customers
and
then,
as
a
team,
we
can
decide
if
there's
more
information,
that's
needed
less
information
and
then
also
we
need
to
obviously
come
to
a
consensus
on
what
it
should
actually
look
like.
A
So
to
give
you
an
idea
of
that,
I
have
two
jobs.
One
is
just
a
let's
see,
yeah
two
branches
here.
This
is
just
a
end-to-end
test
that
I
built
for
myself
that
runs
in
the
pipeline.
It's
calling
browser
directly,
it's
not
going
through
dast.
It
has
a
configuration
file.
The
first
one
is
just
doing
dvwa,
where
we
just
have
an
admin
and
then
the
wrong
password.
So
this
is
using
the
auto
log.
Let
me
zoom
in.
A
Zoom
in
yep,
so
the
in
this
case
the
auth
report
is
being
set
in
the
configuration
file
in
the
real
world.
It
would
be
an
environment
variable,
but
once
this
job
is
kicked
off,
it
would
basically
look
like
this,
so
browser
would
run
the
configuration,
and
this
this
made
me
realize
that
we
need
to
get
rid
of
this
database
logging
because
it
just
clogs
up
the
logs,
but
the
end
result
is
the
last
line.
Authentication
failed.
A
The
login
form
was
found
after
attempting
to
log
in
so
the
way
that
the
login
detector
works
is
it.
It
tries
to
log
it
tries
to
log
in
it
notices
the
form
and
then
once
it
executes
the
login
sequence.
It
looks
for
that
same
form,
again
says:
hey.
Do
I
have
a
username
and
password
field
again?
If
so,
then
I'm
there's
a
very,
very
good
chance
that
I've
failed
to
log
in
so
the
job
fails.
B
A
B
C
A
Yep
and
then
I'll
show
you
a
more
complicated
multi-step
one
in
a
second
here,
so
this
is
it
failing.
If
they
supplied
that
gl
das
report,
they
would
get
this
html
file,
which
they
click
on
and
since
it's
on
a
domain
it
actually
loads.
Oh
man,
it's
that
it
was
doing
screenshots
earlier,
and
this
is
basically
what
they
would
see.
So,
let's
say:
okay,
there's
loading
the
login
page,
so
each
sequence
that
it
takes
it
tries
to
take
a
screenshot
as
well
as
capture
the
dom.
So
you
can
see
that
it
has.
A
So
if
I
were
a
customer-
and
I
didn't
have-
I
didn't
know
what
css
selector
to
use
or
any
other
field,
I
could
be
like.
Okay,
I
need
a
let's
see,
input
class
login
name,
so
I
would
want
to
create
a
selector
for
name
equals.
Username
they'll
be
able
to
add
that
to
their
field,
and
then
it
has
thrusted
on
there.
They
can
close
that
down.
Then
they
can
look
at
the
requests
and
response,
so
they
say:
okay
when
it
loads
it.
This
is
what
the
request
looked
like.
A
Here's
what
the
response
looked
like
for
that
login
page,
and
I
noticed
a
lot
of
times
when
I
was
trying
to
get
das
working.
I
was
getting
completely
different
or
I
didn't
even
know
what
the
response
would
be
so
now,
in
this
case
a
user
would
be
able
to
see
an
exact
response
of
what
the
loaded
page
looked
like
and
then,
when
it
actually
does
the
login
submission
the
dom
is
going
to
be
the
same.
You
can
see
here,
it
says:
login
failed.
A
A
File
or
not
all
the
redirects,
our
redirect
handling
is
not
great
right
now.
What
ends
up
happening
because
of
the
way
that
dev
tools
works
is
we
would
get
the
original
request
so
the
get
request
we
would
pretty
much
not
lose,
but
we
wouldn't
really
capture
any
of
the
the
redirect
redirect
redirect.
But
what
we
would
get
is
the
final
response
so
that
the
initial
get
request
and
the
final
load
response.
Those
would
be
the
the
request
response
pair
that
they
would
see
in
this
report.
A
A
A
A
Yeah,
I
didn't
want
any
sort
of
third-party
requests
going
out.
So
all
the
images
are
inlined
using
the
the
data
tag
or
data
url
and
again
we
can
work
on
what
it
should
actually
look
like
for
customers.
It
could
potentially
have
username
and
passwords
in
it
right
yeah
and
I'm
worried
about
the
masking
stuff.
There's
some
functions
within
browser
go
to
mask
credentials.
A
We
can
do
that.
It
would
need
to
be
after
the
fact,
because
we
need
to
match
the
way
that
it
kind
of
determines
what
the
request
response
should
be
displayed,
as
you
would
you'd
supply
the
you
say
if
it's
a
login
username
match
the
requests
that
contain
the
username,
so
we
we
need
that
data
just
to
match
the
request
response
pair.
But
after
that
we
can
mask
it.
A
A
This
is
going
to
login.live.com
it's
putting
in
a
username
that
is
invalid.
It
has
a
css
selector
for
the
username
field,
a
selector
for
the
username,
submit
field,
password
password
field,
submit
button
and
again
the
same
auth
report
stuff
and
the
the
gitlab
ci
is
exactly
the
same.
It
just
spits
out
there
in
that
case
it
goes
through
and
this
one
just
says,
login
form
found.
This
is
the
same
issue.
It
tried
to
identify
this
time.
A
Instead
of
looking
for
the
username
and
password
field,
it
tries
to
use
the
selectors
so
basically
reruns
the
selectors
and
say
hey
did
that
selector
match
again.
Yes,
okay,
then
it
probably
didn't
log
in
and
this
report
gets
a
little
bit
bigger,
because
it's
multiple
step,
but
again
it's
all
self-contained.
A
It's
going
to
be
harder,
I
think,
for
customers
to
really
to
know
what
the
difference
was,
which
makes
me
think
we
might
want
to
do
some
sort
of
diffing
and
show
like
the
difference
of
when
it
attempted
to
supply
the
username
or
password,
and
then
what
the
difference
in
the
dom
was.
But
that's
future
stuff,
so
here
we
can
see
that
the
says
microsoft
account
doesn't
exist,
enter
a
different
user
account.
So
that's
going
to
fail
in
this
case
the
request
and
response.
Oh,
this
one
does
send
it
right.
A
So
when
you
in
microsoft's
case
when
you
click
the
user
name
submission
it
actually
submits
a
username,
a
lot
of
them,
don't
they'll
just
kind
of
store
it
in
the
dom
and
then
wait
for
the
actual
password
submission.
Then
they
send
the
request.
So
again,
it's
totally
up
to
the
the
developer
of
the
application
of
what
it's
going
to
look
like
so
the
same.
A
Oh,
if
exists,
result
one.
So
clearly
this
username
doesn't
exist
and
then
it
tries
to
click
on
the
next
button.
After
putting
that
invalid
user-
and
it
says
troubleshooting
details,
so
you
can
see
there's
this
difference
that
would
be
a
user
would
be
able
to
see
like
oh
okay,
so
there's
some
sort
of
difference
between
the
username
submission
and
the
password
submission
and
that's
the
result
we
get
for
that.
B
A
A
Let's
see
the
request
response:
oh
this
one's
empty!
Oh
this
just
takes
the
the
url
of
the
browser
at
the
time.
So
in
the
reporting
there's
this,
the
sections
field,
where
you
do
an
ad
section
you
would
put
in
part
of
it,
is
pulls
out
the
end
url.
So
whatever
url
the
browser
is
on
would
be
displayed
there.
It's
going
to
be
different.
Obviously
oh
actually
I'll
show
you
in
the
next
one,
which
is
our
one
of
our
unit
tests
where
in
this
case
after
the
login
submission
you
get
a
redirect.
A
A
C
B
A
B
C
A
A
Directly
into
the
browser,
so
that
actually
wouldn't,
since
there
would
be
no
real
login
page,
it
wouldn't
really
kick
off
the
authentication
service.
In
that
case
it
would
it
it
doesn't
really
treat
the
custom
headers
or
cookies
as
being
part
of
authentication.
It
just
assumes
that
that
value
should
be
set
on
every
browser.
Instance.
That's
started
up
so.
C
C
C
A
C
C
Blocking
you
yep
and
then
two-factor
authentication,
there's
no.
I
guess
infrastructure
right
now
to
handle
that.
So,
if
you
know
you
get
past
the
username
password
and
then
usually
that
third
screen
is
hey
plug
in
your
two-factor
authentication.
That
would
probably
block
them
as
well
and
we'd
just
see
the
the
the
jpegs.
A
I
don't
see
how
they
would
be
able
to
do
this
like
they
would
need
to
be
physically
waiting
at
their
somewhere
waiting
to
put
in
the
token
value,
but
that's
yeah,
also
mutual
tls
authentication
certificates
is
not
in
there,
but
I've
looked
up
how
to
do
it.
It
doesn't
look
too
hard.
So
I
don't
imagine
it'll
be
a
significant
amount
of
work
to
get
it
to
work.
D
A
D
C
D
A
A
A
B
A
B
A
C
A
That
it's
built,
we
do
have
a
so.
The
cli
option
allows
you
to
run
just
the
authentication
as
well.
So
technically,
yes,
you
just
call
browser
and
then
auth
and
then
you
would
pass
in
whatever
translated
configuration
values
we
would
need.
So
the
plumbing
is
all
there.
It's
just
not
wired
up,
but
it's
I
would
presume.
We
would
want
to
do
that
eventually,
especially
once
the
author
port
stuff's
in
because
that
would
give
customers
a
a
huge
win
for
just
normal
dust.
B
A
Right
so
well
I
mean,
if
we
break
that
down
a
bit,
there's
two
if
a
customer
is
using
a
target
website.
Now
that
does
use
session
local
storage
or
session
storage
in
the
browser
they're
going
to
be
out
of
luck,
no
matter
what?
Because
authentication
is
just
going
to
fail
or
it'll
look
like
it.
It'll
set
a
cookie,
but
then
the
crawler
won't
do
anything.
It's
going
to
be
the
same.
A
A
A
A
Are
generated
would
not
have
it
and
I
think
craig
brought
this
up
a
while
back
when
we
were
talking
about
the
das
url
path,
information,
it
wouldn't
have
those
it
needs
to
generate
new
requests,
so
it
wouldn't
have
session
cookies.
We
have
to
inject
it,
which
we
do
with
the
zap
api
http
sessions
like
had
cookies
or
whatever,
but
we
wouldn't
be
able
to
do
the
storage
stuff.
B
A
B
C
D
C
D
C
C
I
think
we
should
be
able
to
test
it
fairly
well
against
what's
stock,
because
the
authentication
for
das
is
pretty
straightforward,
it
looks
for
it's
got
auto
login
and
then
it
looks
or
you
can
pass
in
two
values.
So
we
can
check
to
make
sure
that
same
functionality
is
working
in
in
the
browser,
and
I
think
that
should
cover
most
cases
unless
someone's
done
something
very
strange.