►
Description
Developers today realize the importance of thourough tests for their applications. However, most developers only write test cases for the good paths, and perhaps a simple bad path. But what about testing for malicious paths? Bizarrolout is a tool for the Hapi web framework that allows you to automatically fuzz every route and verify what happens when your application is given malicious input.
Recorded: 2014-12-11
A
This
is
my
first
conference
talk,
so
I
apologize
if
it's
horrible
bear
with
me
what
I'm
talking
about
is
cool,
so
I
am
John
Lennon
Dola
and
you
can
find
me
on
github
under
the
same
name
as
well
as
on
Twitter
I'm,
be
talking
about
bazaar
Allah,
which
is
the
beginnings
of
a
tool
for
happy
to
do
some
static
analysis,
as
well
as
dynamic
analysis
to
help
make
secure
apps.
So
I
first
want
to
look
at
why
we
lack
good
security
tools
in
node,
as
it
is
right
now.
A
One
of
the
main
reasons
is
that
a
javascript
is
pretty
free.
You
can
do
a
whole
lot
of
different
things
with
it.
You
can
use
just
about
any
programming
paradigm
that
you
want,
which
means
that
it's
hard
to
make
a
static
pattern.
You
can
look
through
in
an
application
and
find
out
okay.
Well,
this
this
particular
method
is
bad.
It's
a
it's!
An
insecure
default
kind
of
thing.
Right
so
happy
happens
to
help
that
problem
a
little
bit
by
creating
some
more
structure
which
you
can
see.
A
A
Instead,
you
got
to
handle
them
yourselves.
The
trade-off
for
the
freedom
is
similar
to
the
problem
that
you're
going
to
find
with
any
complex
parser.
If
you
want
the
parser
to
handle
the
input
well,
you
have
to
define
clear
structures
and
fail
when
those
structures
are
corrupted.
When
there's
no
structure,
there's
no
parsing.
If
you
try
and
put
a
piece
of
random
binary
data
to
your
PDF
reader,
it's
gonna
crash.
We
have
a
great
tool
for
overcoming
this,
though,
and
happy
validating.
All.
Data
structures
is
the
norm
rather
than
an
outlier.
It's
it's.
A
What
people
do?
The
more
common
thing
you'll
see
in
a
happy
application
is
validators
for
everything
which
is
awesome,
structure
and
happy
is
not
optional.
It's
consistent!
It's
validated,
it
doesn't
let
you
do
a
lot
of
crazy
things
that
other
frameworks,
let
you
do,
which
I
really
a
security
person
I,
think
that's
great
and
it
allows
me
to
parse
the
routing
table.
A
Well,
I
was
working
on
something
similar
a
couple
months
ago
and
thought
you
know
what
I
wonder
if
I
could
use
this
to
actually
test
the
application
and
fuzz
it
without
having
to
give
it
a
whole
lot
of
manual
context,
and
this
brings
us
back
to
the
beginning.
The
security
automation
is
difficult
because
there's
so
little
consistent,
structuring,
node
but
happy
solves
that
problem,
so
break
man
is
two
rails
as
a
bazaar.
Lout
is
the
happy
that's
kind
of
what
I'm
trying
to
build
for
the
happy
space.
A
So
I've
got
lout
as
the
foundation
for
the
beginnings
of
the
the
parsing
of
the
routing
table,
with
some
things
added
on
there.
So
I
can
I
can
warn
about
some
basics,
but
there's
also
parts
of
your
application,
like
your
route
handlers
themselves
that
are
still
not
going
to
be
using
a
necessarily
a
set
pattern
like
you
can
use
promises
or
you
can
use
callbacks.
You
can
use
any
kind
of
database.
You
want
or
connection
library
that
you
want
right,
so
that
kind
of
stuff
is
difficult
to
parse
once
again.
A
So
what
I've
done
is
to
use
that
routing
table
information
to
pull
out
your
parameters
that
you're
going
to
be
expecting
in
the
API
get
types
for
them,
like
string
number,
whatever
find
out
what
you're
looking
for
in
the
API
endpoint
and
actually
inject
a
very
complicated
set
of
fuzzing
algorithms,
that
I
don't
have
time
to
explain
but
yeah.
It's
it's
pretty
cool
stuff,
I'm
excited
mostly
about
that
part.
A
This
is
what
I
have
right
now
these
components
were
working
at
some
point
now,
they're
kind
of
disconnected
and
I've
got
to
link
them
back
together,
so,
unfortunately,
I
won't
be
able
to
have
a
demo,
but
are
there
an
authenticated
routes
is
first
one
really
simple.
You
just
check
the
route
handler
see
if
there's
there's
a
no
offset
to
all
the
routes.
Have
CSRF
protection
on
them.
Are
the
input
fields
validated
or
rejected?
Do
you
allow
unvalidated
input
fields?
A
Do
you
have
empty,
validate
handlers
in
your
routes
and
as
their
sensitive
data
being
compared
in
securely,
I
can
check
that
with
some
simple
static
analysis
stuff
as
well.
So
is
bizarre.
A
lot
effective
well
within
the
first
10
seconds
of
turning
it
on
I,
found
a
denial
of
service
issue
with
a
process
dot.
Next
stick
in
a
pretty
popular
module
and
last
night
there
is
this.
So
I
have
a
repeatable
segments
in
v8
core,
so
that
was
that
was
a
fun
two
a.m.
adventure.
A
A
So
it's
it's
currently
more
of
a
proof-of-concept.
You
can
use
it
if
you're
interested
in
that
to
fuzz
the
internals
of
node
and
v8,
but
it's
not
going
to
be
terribly
informative
for
actually
figuring
out
the
security
of
your
application
right
now.
But
what
I
want
to
be
able
to
do
with
this
is
basically
to
have
a
tool
that
developers
can
integrate
into
their
testing
phase
and
just
run
a
simple
test.
It
doesn't
have
to
be
crazy,
complicated.
It
doesn't
have
to
be
this
huge,
intimidating
thing.
A
You
should
be
able
to
just
put
something
into
your
tests
and
know
whether
or
not
you've
got
routes
that
you
forgot
to
put
not
handling
right.
That's
not
a
crazy,
difficult
thing
right,
so
I
want
to
be
able
to
do
that
and
as
well
as
as
testing
for
some
of
those
more
configuration
side
of
things,
I
want
to
make
it
easy
for
developers
to
battle-hardened
their
applications
to
actually
go
and
put
more
malicious
path
test
cases
in
there
because
I'm
sure
most
people
that
write
a
good,
solid
application
will
write
good
test
cases
for
it.
A
But
most
of
those
test
cases
are
pretty
binary.
Does
this
route
work
when
I
put
good
stuff
into
it,
yeah?
Okay!
Does
it
fail
when
I
don't
put
stuff
into
it?
Yeah?
Okay,
it
fails,
but
there's
not
a
whole
lot
further
than
that.
It's
not
going
to
be
repeatedly
injecting
okay,
it's
my
parser
that
I
wrote
like
gonna
fail.
So
that's
that's
kind.
The
roadmap
is
where
I'm
wanting
to
head.