►
From YouTube: requireSafe - Adam Baldwin @ OPO.js
Description
A talk about the OWASP top 10 and requiresafe.
Recorded on 2015-02-26
A
All
right,
nobody
is
move
all
right,
so
the
other
thing
is
I'm,
extremely
jet-lagged.
Still
after
being
here
for
like
four
days
so
yeah
we
have,
we
have
to
get
like.
We
have
to
get
excited
and
it's
it's
security
and
I
know
that's
really
exciting.
Actually,
it's
really.
It
can
be
really
boring
and
dry,
so
I'm
gonna
try
to
make
it
exciting.
I
get
animated.
I
really
hope
that
this
tether
that
I
have
on
me
doesn't
stop
me
from
like,
like
moving,
but
hopefully
we'll
be
fine.
A
So
for
those
of
you,
first
of
all,
I'm
gonna
talk
about
note
security,
I'm,
Adam,
Baldwin
I'm,
not
the
actor
Adam
Baldwin
did
not
start
on
Firefly
or
Chuck.
You
can
find
me
at
Adam,
Baldwin
on
the
internet
or
Twitter.
That's
the
Internet,
I
guess
and
github
evil
packet.
Where
there's
some
like
crappy
code,
there
I
work
at
a
place
called,
and
yet
with
with
David
and
an
amazing
team
of
people
that
we
build
software,
we
build
stuff
with
node,
who
else
build
stuff
with
node.
A
A
And
it's
just
it's
it's
my
passion,
sort
of
like
like
pointing
out
all
this
stuff
and
finding
this
stuff
about
three
years
ago,
I
started
a
project
called
the
the
node
Security
Project.
Has
anyone
seen
anything
about
the
node
skater
project?
A
few
people
cool
awesome,
yay,
that's
good,
because
we're
gonna
talk
a
bunch
about
that
and
towards
the
end
and
sort
of
talk
about
some
of
the
goals.
Well,
I'll.
Do
that
now
we'll
talk
about
the
goals
of
the
project,
so
I
started
this
to
basically
evangelize
security
within
the
node
community.
A
The
the
problems
that
I'm
gonna
talk
about
today
have
existed
for
since
the
dawn
of
time.
Right
like
like
these,
these
problems,
with
related
to
scary,
are
not
new
to
the
node
community.
New
to
JavaScript
they've
existed
back.
You
know
in
the
sea
days
back
in
the
pearl
days,
with
Sipan,
with
Python
and
pip
and
Ruby
and
Ruby
gems.
These
these
these
problems
are
prolific
across
all
of
these
platforms
and
so
I
wanted
to
change
the
perspective
when
it
came
to
note,
I
was
like
alright
damn
it.
This
is
enough.
A
We're
gonna
change
it
and
we're
gonna
try
something
new.
The
note
security
project
is
basically
I'm,
a
hacker
and
I
like
to
try
experiments,
and
so
that's
what
this
is.
This
is
this
an
experiment
on
the
community?
I'm.
Sorry,
you've
all
been
a
part
of
an
experiment.
So
today
that's
not
there.
Today,
I'm
going
to
since
I'd,
like
to
evangelize
security
topics
and
I,
don't
I!
Don't
often
talk
about
this
in
depth.
A
I'm
gonna
we're
gonna,
do
a
review
of
the
OS
top
10,
who
has
heard
of
the
aw,
stop
10,
that's
more
hands
that
I
normally
see,
which
is
good.
So
for
you,
this
is
going
to
be
a
very
quick
review,
but
I'm
gonna
try
to
give
my
spin
on
it.
The
patterns
that
we
see
auditing,
no
taps
when
it
comes
to
the
aw,
stop
10
during
the
ordering
that
we're
also
going
to
get
sort
of
like
a
little
like
peek.
A
We
look
for
data
sinks
and
we
see
where
the
data
traverses-
and
this
is
this
is
a
big.
This
is
a
big
area.
This
is
why
it's
the
number
one
on
the
u.s.
top
ten
is
that
it's
that,
when
these
actually
exist
in
an
application,
they
are
extremely
like
they
have.
They
have
large
impact,
and
so
one
of
the
ones
that
I
that
we've
been
seeing
lately
is
with
Express
and
and
specifically
like.
We
see
that
combination
lot.
A
A
If
you
know
the
actual
answer,
is
it
get?
Is
it
gonna
just
produce
a
string?
Is
it
gonna
produce
like
what
would
be
the
result
right?
So
it's
you're
gonna
get
an
object
back.
It's
gonna!
Look
like
this,
but
most
the
time
we
want.
We
want
like
value
or
key
value
right,
just
like
just
like
the
able
to
talking
about
key
and
value.
That's
typically
what
we
want,
but
qsr
cute
like
so,
and
that's
only
because
because
of
this,
this
structure
here,
and
so
normally
you
take.
A
You
might
say
if
we
have
say
something
like
a
database
and
we
we
parse
something
like
like
this,
where
you
got
an
ID
and
you
got
a
not
in
and
you
got
a
value,
you
can
even
create
a
really
complex
object
with
your
URL
query
string
and
that
ends
up
in
you're
database.
So
if
you
put
this
in
a
find
query
for,
say,
authentication
or
something
like
that
to
retrieve
data
from
a
database,
you're
gonna
end
up
with
you
can
do
really
complex
queries.
A
So
you
end
up
with
a
regex
query
or
something
like
that
and
you
might
might
be
able
to
pull
out
data
that
that
you
shouldn't
have
access
to
or
something
like
that.
So
that's,
oh
by
the
way
I
have
Fred,
say:
I'm,
gonna
go
really
really
fast.
So,
if
you're
interested
in
any
of
this,
you
can
go
to
Olaf's
org
and
get
more
in-depth
information
regarding
each
one
of
these.
A
The
second
one
is
broken
authentication
and
session
management,
which
basically
has
to
do
with
things
like
not
properly
hashed
passwords,
because
everyone's
source
passwords
in
clear-text
right.
Like
that's
a
thing,
we
actually
see
that
on
tests,
people,
laughs
and
developers
do
that.
So,
if
you're
doing
that-
and
you
know
about
it-
don't
laughs
change
it
because
we
see
it
like
I
hate
to
like
you
sound,
like
I'm,
shaming,
but
we
see
it.
A
We
actually
do
see
it,
and-
and
this
is
partly
to
about
protecting
things
like
session-
identifies
your
session
identifier,
so
cookies
that
deal
with
sessions
and
things
like
HTTP
only
Flags
on
cookies.
So
an
HTTP
flag
on
a
cookie
basically
says
that
the
JavaScript
on
the
front-end,
the
JavaScript,
that
you
want
to
write,
can't
consume
that
cookie
can't
actually
have
access
to
the
cookie
and
just
able
to
send
it
so
as
well
as
SSL
for
data
in
transit,
which
is
which
is
this
particular
category.
A
So
moving
on
cross-site,
scripting
I
would
probably
everyone
knows
what
that
is
right.
Number
three
cross-site
scripting
super
super
prevalent
web
applications.
We're
definitely
seeing
it
less
in
the
in
the
apps
that
we
audit,
because
of
frameworks
because
of
templating
languages
that
actually
actually
give
good
defaults.
And
this
this
is.
This
is
sort
of
a
table
of
escaped
values
and
unescape
values,
and
you
can
do
yourself
a
favor
when
you're
audited
or
when
you're
when
you're
writing
an
application.
A
If
you
search
for
a
knows
any
one
of
these
sort
of
it's
kind
of
hard
to
see,
but
you've
got
like
there's
only
little
values
that
differ
between
and
escaped
and
on
escape,
and
you
haven't
like
an
insecure
situation
here,
potentially
and
if
you
just
search
for
these
patterns,
if
you
search
for
triple
trouble,
trouble
mustaches
if
you're
using
mustache,
conveniently
curly
brackets,
whatever
just
grab
across
your
entire
code
base.
You're
gonna
see
all
the
instances
use
using
that
and
potentially
you've
got
an
injection
point
for
those
who
aren't
familiar
site.
A
Scripting
cross-site
scripting
is
when
you
take
user
input
and
it
is
basically
reflected
back
out
from
a
stored
from
stored
from
the
database
or
from
the
query
parameters
in
the
in
the
URL
put
back
into
the
browser
and
that
that
then
is
rendered
in
the
Dom.
Instead
of
displayed
so
a
script,
a
script
tag
might
might
execute
and
then-
and
then
it's
basically
the
same
as
if
I
gave
you
a
code,
a
piece
of
code
to
run
as
Dave
example
floppy
disk,
which
we
use
anymore.
A
A
So
so
that's
an
injection
point
as
well
as
handlebars
safe
string,
any
of
any
of
you
using
ember
and
ember
helpers
that
may
use
safe
string
it
may
you
may
have
to
escape
that
that
data
by
default
afterwards,
so
going
way
too
slow,
so
insecure
direct
object,
references,
something
that
we
see
here.
Basically,
this
is
where
developer
exposes
a
reference
like
a
URL
or
something
like
that,
and
basically
you
can
access
it
just
by
changing
an
ID
or
changing
a
value
right.
A
You
can
just
you
can
flip
that
reference
and
just
tick
tick,
tick
and
what
and
walk
through
them?
And
that's
that's
basically
it
you
always
have
to
check
and
validate
that
somebody
actually
has
access
to
that
resource
before
you
before
you
rent
her
back
out.
It
would
be
something
like
this
just
saying:
send
back
the
data
when
we
find
it
with
just
whatever
ID
was
in
there.
We
didn't.
Actually
we
didn't
actually
check.
There
was
authorization
there.
We
see
this
quite
a
bit
and
we
see
this
stuff
protect
instead
of
instead
of
good
authorization
code.
A
We
see
it
ended
up
being
protected
by
by
say
just
random
values
and
those
random
values,
and
instead
what
we?
What
we
do
then,
is
we
we
go.
You
go
back
to
the
first
slide
where
we
can
create
complex
queries,
know
the
query
string
and
we
end
up
getting
around
that
the
fact
that
we
can't
guess
that
value.
So
it's
it's
useful
same
thing
with
like
just
reading
something
off
of
disk
and
just
sending
it
back
to
the
user.
A
You
have
directory
traversal,
where
just
dot,
slash
dot,
dot,
slash,
move
yourself
way
out
of
the
route
where
you're
you're
reading
files
and
display
it
back
to
the
user.
So
that's
that
security
miss
configuration-
this
is
basically
just
like
this
is
OAuth
like
we're.
Just
gonna
dump
a
bunch
of
crap
in
a
category
which
is
just
come
comes
down
to,
though
insecure
defaults,
and
which,
which
the
most
useful
piece
out
of
this.
That
I
can
tell
you
about.
A
Again,
security
is
most
security
when
it
comes
down
to
this
is,
is
usually
about
security
of
data
in
transit
in
use
and
at
rest,
so
in
transit,
SSL
right
at
rest.
We
want
to
make
sure
we've
hashed
passwords
in
a
secure
way.
The
current
the
current
trend
is
to
use
bcrypt
or
s
crypt,
depending
on
what
type
of
attack
you're
preventing
your
trying
to
protect
against
and
the
other
thing
we
see
a
lot
of
is
just
like.
A
Then,
if
we
happen
to
get
into
a
logging
machine
or
something
like
that
missing
functional
level,
access
control,
this
gets
confused
with
direct
object
reference
a
lot
and
it's
it's
related
where
this
has
to
do
with
authorization
as
well,
basically
has
to
do
with
checking
permissions
before
you
give
somebody
access
to
something
again,
I
feel
it's
basically
the
same.
There's
some
nuances
between
the
two
I'm,
not
gonna,
explain
it
because
I
think
it's
the
same
as
the
other
one
cost
request
forgery.
A
A
Cross-Site
script,
cross-site,
request
forgery
exists
when
you,
okay
backup,
so
imagine
you
you're
submitting
a
form
to
change
your
profile
and
it's
just
a
simple
web
form
and
when
you,
when
you
submit
that
form-
and
you
change
your
email
and
you
submit
it
and
it
goes,
it
sends
a
post
request
to
some
URL
right
and
then
your
email
is
changed
as
I'm
attacker.
When
you
visit,
say,
evil,
calm
and
I
have
I
can
have
that
same
form.
A
Existing
without
being
visual
and
I
can
I
can
submit
that
automatically
with
JavaScript
and
then
I
can
change
your
email
address,
and
so
there's
only
really
one
way
of
preventing
that,
and
that's
that's
where
you
include
a
secret
token
on
render.
So
when
I
render
it
on
example.com
I
put
the
server's
gonna
put
a
token
in
their
evil
coms,
not
going
to
check
that
server
side
when
it's
submitted,
evil
coms,
not
gonna,
know
what
that
token
is
a
lot
of
apps,
get
there
they're
sort
of
their
get
saved
by
using
that
they
use.
A
You
know
the
separation
of
an
API
and
a
rendered
application
where
you're
using
something
like
a
bearer
token
to
do
authentication
when
you
have
to
send
those
to
the
API,
if
you're
doing
that
through
a
header,
it's
only
allowed
on
that
domain.
You've,
basically
you've
kind
of
killed,
two
birds
with
one,
because
in
a
remote
attacker
won't
have
that
value
and
it
won't
be
get
submitted
to
that
API.
A
So
now
we
kind
of
get
into
a
little
bit
of
where
the
node
security
project
comes
in
for
node
applications,
and
this
is
this
is
this-
is
more
fun
stuff
than
listen
to
me,
babble
about
other
stuff,
so
we've
got,
we've
got
a
tool
called
NSP
that
we
publish,
so
you
can
basically
do
those
slides
came
out
wrong.
You
can
basically
do
n
PM
ID
s
GN
SP,
and
that
gives
you
a
binary
that
you
can
run,
and
so
you
can
run
basically
n
SP
package
or
an
SP
shrink-wrap,
depending
on
a
few.
A
You
string
up
files
or
package
files
and
what
that
does
is
it
actually
gives
you
output?
That
looks
like
this.
It
queries
it.
Basically
recursively
goes
down
your
entire
dependency
tree
and
looks
at
every
single
dependency
and
compares
that
against
our
database
of
known
vulnerabilities
and
says.
Is
this
basically
is
this
a
vulnerable
package
to
something
that's
known,
and
it
doesn't
mean
that
your
products
are
so
exploitable,
but
it's
it's.
A
You
know
why
not
just
bother
to
upgrade
if
you
about
it,
so
this
particular
said
that
the
the
Q
s
package
in
request,
two
three
six
is
is-
is
vulnerable
and
it's
patched
in
this
one.
So
probably
you
should
upgrade
your
request
or
you
should
complain
to
Michael
that
you
know
he's
using
a
version.
That's
that's
vulnerable
doesn't
really
mean
again
that
your
spy,
durable,
so
I'm
gonna
go
back
to
this
slide
here
and
talk
about
requires,
say
for
just
a
minute
basically
require
safe
is.
This
is
why
this?
A
Why
I
didn't
really
want
to
talk
about
it
in
in
in
depth
is
because
it
would
have
just
ended
up
being
a
product
pitch.
It's
basically
lifts
Enterprise
version
of
the
node
security
project.
So
when
I
said
that
I,
when
I
started
the
node
security
project,
I
wanted
to
sort
of
sort
of
a
ocean
boiling
endeavour
right.
We
wanted
to
change
the
perception
of
security
in
the
community
and
turns
out
that
that's
a
really
hard
problem
and
then
it's
a
full-time
job.
A
We
said
when
we
started
that
we're
gonna
audit,
all
the
modules
in
NPM
there's
eighteen
thousand
modules
when
we
started
the
project,
there's
over
one
hundred
twenty-five
thousand
modules
now,
and
that's
just
an
insane
task
for
a
small
group
of
four
people
that
sort
of
like
work
on
it
to
to
actually
accomplish.
So
what
we
basically
we
need
to
do
is
we
need
to
make
this
project
our
full-time
job
and
to
do
that
we
need
funding.
A
Therefore,
we
need
to
basically
trick
enterprises
or
businesses
and
funding
the
node
security
project
by
buying
a
product,
that's
useful
for
them.
So
it's
just
the
the
the
whole
thing
there
is
its
intent
full
auditing
of
your
dependency
tree,
which
I'll
get
into
a
little
bit
later.
I
want
to
talk
about
dependency,
graphs
with
NPM.
So
that's
that's!
No
more
salesy,
sorry!
A
A
He
wrote
retire
and
it
actually
uses
the
node
Security
Project
data
as
well,
but
it
also
does
something
else:
that's
cool
and
it
it
looks
at
your
your
dependencies
like
jQuery
and
angular,
and
all
those
other
like
front-end
libraries,
to
see
if
they've
got
known
vulnerabilities
and
they-
and
it
can
tell
you
you-
can
give
you
a
very
similar,
similar
view.
Like
you
know,
I
can,
as
I
can't
has
bars
whatever
jQuery
was
I
had
known
vulnerabilities,
and
it
gives
you
like
some
references
for
you
to
read
about
it.
A
I,
but
really
just
go
update
your
update,
your
dependency
dependencies.
We
did
something
interesting
with
retire
and
we
ran
it
against
the
entire
Bower
because
Bowers,
like
you
know,
it's
a
lot
of
fronting,
so
we
ran
it.
We
ran
it
against
a
bower
and
basically
found
just
a
ton
of
data
and
that
it
tons
so
much
that
it
would
be
rather
difficult
to
communicate
with
all
with
all
the
people.
A
So
we
basically
we
wrote
about
it,
we
sort
of
evangelized
about
it
and
we
put
the
data
up
there
so
that
everyone
can
have
that
and
so
basically
look
up
if
they've
got
something.
That's
vulnerable.
Just
to
sort
of
talk
about
that.
So
that's
that
last
one
is
unvalidated
redirection
for
words
and
so
web
applications.
Typically
like
redirect
you
you,
you
go
to
hit
a
URL
you're,
not
authenticated,
so
it
redirects
to
the
login
form
and
says
says:
hey
login
and
then
will
return
you
to
your
old
place,
a
common
method
to
do.
A
That
is
to
put
something
like
a
return
to
URL
in
the
query
string
or
something
like
that.
We
see
that
a
whole
time
it's
useful
in
phishing
attacks
where
I
might
send
you
a
URL
that,
with
a
redirect
to
to
my
domain,
it
might
be,
it
might
be
useful
again.
It's
it's
a
low
impact
vulnerability
typically,
but
it's
part
of
that
last
top
10.
So
that
is
the
OLS
top
ten.
A
In
a
nutshell,
I'm
sure
somebody
else
could
explain
it
a
lot
better,
but
that's
that's
a
great
place
to
start
when
you're
talking
security
of
web
applications
known
applications.
So
let's
talk
about
some
some
just
things.
It
says:
I've
got
like
three
minutes
left,
but
I'll
probably
go
over
just
a
couple.
A
So
you
know
you
can
build
something
off
of
you
know
David's
WebRTC
Explorer
and
build
on
top
of
that
and
not
have
to
do
all
the
work
that
he
did
and
you
can
you
can.
We
can
use
it
as
stepping
stones.
However,
you
end
up
with
an
interesting
problem
and
when
you
come
to
security
in
that
is
trust,
do
I
trust
all
of
you
to
ship
code
into
production.
For
me
right,
you've
got
your
team
there
and
you've
got
all
the
other
people,
but
you
might
have
one
bad
actor
and
not
somebody.
A
That's
necessarily
intentionally
writing
bad
Co,
but
they
just
went.
This
might
produce
the
shitty
module
and
it
does
the
thing
that
you
want
it
to
do,
but
it
does
so
in
it
that
has
a
vulnerability
in
it.
Unless
you
go
look
at
your
dependency
tree
and
you
actually
audit
all
those
modules
intently,
you
might
not
find
that
it's
actually
got
that
problem
and
chances
are
if
you've
got
a
giant
dependency
graph.
You're
gonna
have
bugs
in
there
right.
That's
just
software.
A
So
that's
that's!
That's
sort
of
been
the
premise
behind
all
of
the
research
that
we've
done
and
I'm
not
gonna
show
you
who
this
is
and
who
the
module
is.
Who
here
has
changed
their
NP
and
password
in
the
last,
let's
say
ninety
days,
none
of
you
I
did
because
I
asked
that
question
at
another
conference.
A
A
little
unsanctioned
work
and
just
I'm
not
gonna,
tell
you
what
we
did,
but,
let's
just
say,
weak
passwords,
and
so
we
found
we
found
users
with
weak
passwords.
This
is
getting
addressed
by
NPM
to
try
to
improve
that.
But
let's
say
that,
like
we
found,
we
found
one
account.
That's
really
shitty
I'm
purpose.
We've
found
one
maintainer,
and
this
is
this
maintainer
dependency
dependency
graph.
A
They
actually
only
have
I
think
it's
it's
like
three
or
four
modules
that
they
publish,
but
then
those
three
or
four
modules
are
dependent
on
by
another
level
right
and
then
those
modules
are
dependent
on
and
for
some
projects
that
goes
very
far
and
that
amp
that
reach
has
has
has
large
impact.
Let's
just
say
so:
the
security
of
your
account
and
your
code
actually
matters
for
other
people,
which
is
which
I
think
it's
kind
of
interesting.
It
was
very
interesting
to
see
what
impact
those
those
had.
A
A
How
can
you
improve
the
security
of
your
project
or
your
the
the
stuff
you
ship
to
production
without
actually
touching
any
code,
so
this
is
this
is
like
open
source,
intelligent
right?
How
can
we?
How
can
we
pay
attention
to
what's
going
on
the
community?
You
know
one
might
be
keeping
up
with
the
new
security
project.
You
know
on
Twitter
and
seeing
what
what
vulnerabilities
we
published
or
using
require
safe
and
in
getting
those
alerts.
Another
way
might
be
just
pay
attention.
I
wrote
a
really
this.
A
Is
this
really
horrible
application
that
that,
just
that
just
scrapes
all
of
the
issues
for
anything
that
had
a
github
URL
any
any
product,
that'll
get
a
beer
L?
It
would
scrape
issues
every
24
hours
and
it
just
kept
track,
and
it
would
just
would
in
with
just
full
text
index
those
and
say.
Is
there
any
keywords
in
those
issues
that
might
be
security
related,
put
them
in
a
queue?
Let
a
human
look
at
them,
and
then
we
basically
say
yes
or
no.
A
This
is
good,
or
this
is
bad
and
there's
about
five
a
day
and
if
I
can
keep
up
with
the
entire
registry
chances
are,
you
can
keep
up
with
your
projects
and
actually
do
that
intently
and
it
actually
has
a
great
impact.
We
found
a
vulnerability
that
was
that
I
didn't
know
about
that
was
open
for
marked
the
markdown
processor.
That's
still
unpatched.
A
It
was
open
since
last
October
and
just
maintain
their
a
vulnerability
and
seek
sequel
eyes,
sequel
injection
and
there's
a
bunch
more
that
are
on
pache
that
were
sort
of
trying
to
work
with
authors,
but
they're
out
there,
they're
public
people
know
about
them.
So
you
could,
you
could
potentially
maybe
switch
to
a
different
library
or
something
like
that
or
or
send
a
pull
request
to
fix
that
and.
A
A
Somebody
just
says
is
a
security
issue,
or
maybe
they
don't
know
it's
security
issues,
it's
just
a
bug,
and
so
they
drop
it
in
github
issues
and
then
it's
it's
there
for
all
the
world
to
see,
but
it
impacts
you
because
they're
part
of
your
dependency
tree-
and
you
might
not
even
know
that
they're
part
of
your
dependency
tree
because
you're
using
let's
say
four
modules,
but
you
have
a
dependency
tree
of
sixty
modules,
and
so
it
might,
it
might
trickle
down
from
there.
So
so
I
really
understand
what
your
dependency
tree.
A
The
other
thing
I
want
to
sort
of
preach
about.
I
guess
is:
if
you
fix
a
security
problem
in
one
of
your
modules,
please
self
disclose.
Please
let
the
community
know
that
there
was
an
actual
security
flaw
to
motivate
them
to
update
their
their
module,
and
you
can
do
so
by
emailing.
A
report
at
node
security
IO
we're
just
going
to
note,
secured
at
IO
and
letting
us
know,
and
that
way
we
can
publish
an
advisory
and
just
it's
it'll
be
part
of
NS
PE
and
everyone
will
know
about
it.
A
There
builds
will
break
and
their
CI
system
and
they
can
just
update,
and
the
last
thing
is
some
docker
stuff
I've
been
doing
over
the
last
couple
of
weeks,
so
anybody
here
heard
of
rim
rim
Rafal
a
module
that
was
publicly
says.
Okay,
so
what's
interesting
is
somebody
in
Lisbon
which
I
have
yet
to
meet
I've
been
here
and
I'm
like
I
met,
I
met
them.
There's
this
big
there's
a
big
situation,
so
anybody
can
publish
any
garbage
on
npm
right.
A
You
just
be
like
this
modules
and
mp3
and
you
can
just
publish
it,
and
so
somebody
in
and
NPM
modules
have
install
hooks,
so
pre-install
post,
install
post,
remove
stuff
like
that,
but
install
hooks
are
very
interesting
because
they're
just
un
PMI
and
it
runs
that
code
before
it
installs
a
module.
So
if
you
say,
publish
a
module
that
is
RM
dash,
RF
slash
star
as
a
pre
install
hook.
A
It's
going
to
you
over
if
you
do
that,
so
they
publish
that
and
then
they
put
it
on
Hacker
News
in
the
description,
the
description
of
the
module
said,
don't
install
this,
it
doesn't
mean
people
aren't
gonna,
frickin
install
it
so,
but
it
got
me
thinking
like
it's
it
is.
It
is
a
problem.
How
do
you
do
that?
There's
one
there's,
there's
a
ignore
scripts!
A
I
think
it
is
that
you
can
use
when
you
install
modules,
which
is
great
for
CI
systems,
so
that
somebody
can't
just
Jack
your
CI
system
it's,
but
for
a
developer
machine
like
the
first
thing
I'm
gonna
do
is
if
I
can
get
if
I
so
I'm
at
you
know:
weak
passwords,
+,
patching
code,
+
pre,
install
scripts,
+,
owning
a
developer,
patching
all
of
their
modules,
publishing
those
modules
it's
going
to
spread
right.
It's
a
it's,
a
it's,
a
problem
with
our
ecosystem,
and
so
the
problem
is,
is
we
can't
we
can't
police
it?
A
You
can't
stop
people
from
writing
or
obfuscating
code
or
any
of
that
stuff
in
putting
it
into
our
ecosystem.
It's
just
it's
a
part
of
the
problem.
It's
it's
not
unique
to
us
pip.
Has
it
Ruby
gems?
Has
it
pearl?
Has
it
right?
It's
just
intently
malicious,
so
I
thought
how
can
we
actually
detect
some
of
this
and
I
went
back
to
my
days
at
Symantec,
where
we
did
sort
of
blended
threat
type
work
where
we
had
like
a
bunch
of
ghosted
machines,
so
we
could
reset
the
state
and
we
could
drop.
A
A
If
you
just
run
docker
diff
and
it
just
craps
out
all
of
the
changes
it
just
says,
here's
all
of
the
changes
of
file
system
adds
changes
and
deletes,
and
you
can
immediately
see
oh
we're
deleting
bin
home
Lib
Etsy
root
right,
and
you
immediately
see
that
like
this
is,
this
is
an
extremely
bad
actor
now.
This
is
not
perfect.
This
is
back
in
the
day.
A
This
is
this
is
like
this,
like
shitty
antivirus
detection
right,
but
it's
better
than
what
like
we're
now
watching
for
this,
please
don't
publish
stuff,
it's
gonna
be
like
cause
community
happening
whatever
intently,
just
to
see.
If
we're
gonna
catch
it,
if
you've
got
an
idea,
please
just
send
it
to
us
of
how
you
would
have
made
detection
of
something
like
this,
and
maybe
we
can
make
it
better.
It
is
just
antivirus
s,
but
it's
better
than
what
we
had
before
and
so
now
we're
kind
of
watching
yeah.
A
So
that's
basically
it
if
you
didn't
learn
anything
from
the
presentation.
Please
take
some
of
the
knowledge
that
you
have
that'sthat's
that
you
that
you
already
knew
about
and
spread
it
to
a
couple
of
people.
It's
the
greatest
like
as
well
as
if
you
learn
new
things,
please
please
spread
it
to
co-workers
or
friends
that
might
benefit
from
this.
It's
a
great
thing
that
you
can
do
for
a
community
when
it
comes
to
security.