►
Description
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
B
So
we're
gonna
talk
about
managing
content,
security
policy
and
same-side
cookies,
jumping
right
in
what
is
content
security
policy.
This
is
not
going
to
be
an
in-depth
discussion.
We
will
definitely
do
this
at
a
very
high
level.
So
content,
security
policy
or
CSP
is
an
HTTP
response
header
that
can
manage
the
capabilities
of
browsers,
primarily
what
JavaScript
can
and
cannot
execute
once
you
have
it
in
place.
It
has
some
pretty
nice
assurances
about
what
your
app
can
and
cannot
do
or
what
you
know.
B
B
So
I
show
you
this
partial
policy,
not
because
I
want
to
go
over
in
detail,
but
just
to
demonstrate
that
this
this
semicolon
delimited
a
bunch
of
garbage,
is
pretty
powerful,
but
it's
definitely
not
easy.
Takes
a
lot
of
consideration.
Testing
experimenting
planning
it's
about
a
thousand
times
more
difficult
to
apply
retroactively
lis
than
if
you
had
started
from
the
beginning.
But,
let's
be
honest,
nobody
applies
CSP
from
day
one.
B
If
they
know
about
what
CSP
is
at
day,
one
I
would
be
surprised
to
really
the
primary
thing
is
you're
trying
to
avoid
unwanted
JavaScript
execution
and
that's
dictated
by
the
script
source
directive,
and
the
goal
is
eventually
to
remove
these
two
values
that
say
unsafe,
inline
and
unsafe
eval.
The
inclusion
of
the
word
unsafe
is
very
intentional.
To
say
you
should
not
be
doing
this
unless
you
have
a
reason
to
unsafe
inline
allows
your
your
typical
sort
of
reflected,
XSS
or
stored
XSS
in
a
page
that
javascript
is
inline.
B
A
lot
of
applications
are
able
to
extract
all
the
remaining
Java
scripts.
Such
they
don't
have
to
allow
inline
JavaScript
and
they
have
effectively
taken
away
a
lot
of
XSS.
The
eval
line
is
a
little
more
nuanced.
The
eval
code
and
the
eval
function.
Javascript
evaluates
JavaScript
as
code,
which
is
another
primary
vector
of
XSS.
B
Unfortunately,
it's
a
little
more
subtle,
for
example,
jQuery.
If
you
were
to
insert
a
snippet
of
a
script
tag
into
a
live
Dom
that
would
not
trigger
an
inline
script
violation.
Historically,
that
would
actually
trigger
an
eval,
so
it's
not
very
intuitive,
sometimes
either.
So
you
have
a
nice
mix
of
things
that
are
both
not
obvious,
counterintuitive,
very
opaque
and
hard
to
understand,
but
the
goal
is
to
eliminate
cross
site
scripting.
That's
a
good
goal
that
we
work
towards
simply
defining
a
policy
for
your
website
is
very
hard.
B
B
Csp
does
have
a
report
only
mode
so
that
you
can
sort
of
test
things
out,
but
unfortunately,
a
lot
of
people
never
make
it
out
of
the
report.
Only
phase
but
like
I,
said
CSP
when
implemented
properly,
is
really
good
at
github.
We
are
always
worried
about
XSS,
but
we
are
significantly
less
worried
and
applications
that
don't
have
a
policy
such
as
ours.
B
We
do
have
a
lot
of
confidence
in
it
and
it's
worked
out
pretty
well
for
us,
so
we're
in
some
ways
more
worried
about
you,
injecting
a
link
on
our
website
that
looks
official
than
you
getting
an
access,
actual
XSS
execution
on
our
website,
so
just
be
successful
with
CSP.
You
can't
just
pop
this
in
your
engine
X
file.
This
is
not
meant
to
be
a
static
header
that
your
Ops
people
set
and
you
as
an
application
owner,
have
nothing
to
do
with.
You
need
to
be
in
control
of
your
policy.
B
You
need
to
be
able
to
find
a
global
policy.
You
need
able
to
modify
that
policy
at
runtime
for
whatever
needs
you
for
whatever
need.
You
have,
and
you
know
yes,
content
security
is
a
header.
It
is
a
string,
you
can
generate
a
string.
This
is
not
rocket
science,
but
given
the
complexity
of
CSP,
I,
really
think
people
should
have
more
purpose-built
tools
for
managing
the
policy
and
abstracting
away
a
lot
of
the
hard
stuff.
B
This
was
more
important
historically,
where
implementations
across
browsers
greatly
differed,
but
still
today,
I
would
argue
you
need
a
library
to
manage
it,
so
your
global
policy
should
be
as
tight
as
reasonably
allowed
for
the
majority
of
your
website.
You
should
not
be
making
a
global
exception.
For
example,
if
your
admin
page
contains
a
little
bit
of
inline
JavaScript
for
your
WYSIWYG
editor,
you
don't
want
to
enable
inline
JavaScript
for
your
entire
application.
B
B
Going
on,
okay,
all
right
student,
instead
of
asking
someone
what
the
CSP
should
be
for
the
page,
it's
a
terrible
question
to
ask
what
about
this
page
is
special,
that
it
needs
an
exception.
Asking
that
question
makes
someone
justify
why
they
need
to
change
the
policy.
Sometimes
the
required
modifications
are
a
little
more
than
we're
comfortable
with,
but
because
it
is
limited
to
one
end
point
one
user,
one:
whatever
we're.
B
Okay
with
allowing
protect
you,
no
more
dangerous
activity,
and
by
providing
these
familiar
api's
for
adjusting
the
policy,
you
can
hook
something
into
your
DevOps
pipeline.
To
simply,
you
know
a
static
analysis
tool
or,
or
even
just
a
simple
regular
expression,
to
look
for
these
methods
in
these
common
ways
of
modifying
your
policy.
So
the
security
team
can
then
go
in
and
review
these
exceptions
to
this
policy.
B
Now,
taking
a
step
back
before
we
talk
about
the
code
to
accomplishment
I'm
going
to
give
the
worst
explanation
of
the
model-view-controller
pattern,
ever
a
real
programmer
will
probably
cringe
but
I'm
going
to
describe
it
as
rails.
Presents
it
to
my
brain.
The
model
is
something
that
represents
data
in
rails.
The
simple
example
is:
it
represents
a
row
in
the
database
and
it's
foreign
key
relations.
It
really
just
means
a
bunch
of
data.
A
controller
takes
the
incoming
HTTP
request
and
does
stuff
with
the
data.
B
The
view
takes
the
data
after
the
controller
has
done
stuff
and
turns
it
into
something
that
can
be
read
in
this
case.
We're
talking
about
the
view
generates
the
HTML
from
the
data
that
the
controller
pulled
out
of
the
models
again,
apologies
to
any
real
programmers.
The
model
isn't
really
a
place
where
you
would
manage
content
security
policy.
The
controller
is
absolutely
where
you'd
want
to
do
it,
and
sometimes
even
the
view
is
appropriate.
Let's
go
over
those
cases.
B
So
for
anyone
who
doesn't
understand
Ruby
apologize,
I
know
people
have
their
own
opinions
on
the
language,
but
I'm
going
to
try
and
explain
what's
going
on
here
without
getting
into
too
much
detail
at
the
very
top
there
we
have
the
application
controller.
This
is
the
controller
from
which
all
other
controllers
will
inherit
from
so
you
define
the
method
that
simply
calls
append
content
security
policy
directives
and
has
this
funky-looking
thing
even
for
Rubeus.
B
That
says,
look
for
a
constant
called
CSP
exceptions
and
we
have
a
sub
controller
that
subclasses
from
application
controller
that
defines
this
constant
in
this
case,
we're
going
to
add
food
calm
to
the
list
of
frame
sources.
Now,
if
there
was
no
frame
source,
it
would
create
it.
Otherwise
it
would
just
sort
of
tack
it
onto
the
end
of
the
list.
The
line
below
that
says
before
action
at
CSP
exceptions
only
show
that
is
root
that
is
rails,
ism
fork
call
this
method
anytime.
The
show
method
is
called
in
a
controller.
B
Each
method
represents
an
end
point
essentially
so
by
saying
only
show
I'm
saying:
I
only
want
to
frame
food
comm
on
the
show
action
and
not,
for
example,
index.
That's
great,
that's
the
very
simple
case
like
I.
Have
this
this
end
point
there's
this
only.
Does
this
one
thing
on
this
one
page
I
want
me,
add
it's
this
one
end
point,
or
maybe
the
whole
controller
or
half
the
end
points
whatever
you
get
the
flexibility
with
the
built-in
functionality
rails.
B
Now,
at
the
bottom
we
have
a
more
flexible
approach
like
this
is
inside
the
code
of
the
index
function.
We
want
to
append
some
more
content
security
policy
directives.
Now
this
feature
enabled
is
a
made-up
function
because
it
can
be
anything.
Is
the
user
logged
in?
Is
it
an
employee?
Do
they
have
a
specific
feature
enabled
just
for
that
subset
of
users?
Is
it
a
Tuesday?
Does
the
current
hour
end
in
a
three?
It's
really
flexible.
You
can
do
whatever
you
want
and
you
need
that
flexibility
to
support
all
use
cases.
B
Now
I
talked
about
the
views
thing
I'm
sure
this
violates
some
principle
of
programming
too,
but
again,
I'm,
not
a
real
programmer,
but
I
make
things
at
work.
So
we
have
a
reusable
component.
That's
perhaps
shared
across
various
parts
of
the
site.
These
sites
may
earn.
These
components
may
or
may
not
be
related.
B
This
little
piece
of
JavaScript
here
will
generate
the
nonce
set
the
nonce
on
the
tag
and
also
set
them
value
in
the
header.
So
you
don't
have
to
do
anything
to
manage
ahead
of
yourself.
You're,
just
like
I
need
to
run
this
piece
of
JavaScript
I
cannot
running
in
my
JavaScript.
I
have
a
function
that
lets
me
run
in
my
in
JavaScript.
B
Another
common
use
case
is
just
you
need
a
completely
different
policy
whatsoever.
This
can
happen
in
a
lot
of
cases
and
github.
This
happens
on
our
static
404
page.
The
404
page
doesn't
need
a
whole
lot
of
functionality
and
certainly
far
far
different
from
what
the
actual
website
needs.
So
we
have
this
handy
function
at
the
bottom
for
render
404
calls
a
method
called
set
static,
CSP
that
one
sort
of
overrides
the
global
policy.
B
B
Unfortunately,
the
same
size
cookies
are
in
an
interesting
State.
Chrome
is
trying
to
roll
out
same
site
Lacs
by
default.
I'll
explain
a
little
bit
later
due
to
the
current
situation
and
the
difficulties
they
likely
encountered
now
gone
back
on
that.
But
the
goal
is
eventually
to
make
all
cookies
have
at
least
same
site
lacks
same
site
refers
to
the
new
attribute
itself,
which
can
have
the
values
of
none
strict
or
lacks.
B
None
is
sort
of
was
sort
of
an
afterthought
when
things
started
breaking
where
we
do
need
cross-site
cookies,
sometimes
that
fake
only
comes
up
in
sam'l,
for
example,
if
you
have
a
redirect
or
a
post
from
a
third-party
site,
if
you
were
to
drop
those
cookies
well,
you've
just
ruined
the
whole
transaction,
so
the
same
site
nun
says:
go
back
to
the
current
state
of
how
cookies
are
by
default.
Today,
strict,
unfortunately,
sounds
really
cool.
B
That
is
not
really
that
useful
and
practice
strict
will
not
send
cookies
unless
you
are
essentially
coming
from
and
going
to
the
same
site.
So
if
you
were
to
click
a
link
from
your
email
or
a
search
engine
or
chat,
client
or
third-party
site
and
I
went
to
github
and
our
cookies
were
all
strict,
you
would
be
logged
out
and
we'd
have
no
idea
who
you
were
until
you
hit
refresh,
which
is
not
a
good
user
experience
we
do
do.
We
do
set
one
of
our
same
site.
B
Cookies
are
strict,
but
only
because
we
have
another
cookie
with
the
same
value
set
to
lakhs,
and
we
compare
them
from
time
to
time
to
make
sure
you
are
doing
a
site-to-site
post.
For
example,
lacs
is
sort
of
the
the
Goldilocks
in
between
this
provides
a
lot
of
protective
functionality.
If
you
have
an
image
or
a
form
on
a
third-party
site
that
posts
back
to
github,
the
cookies
will
not
be
sent.
You
don't
have
the
C
surf
in
any
ways,
but
that's
not
really
the
point
the
internet
by
default
sends
cookies
everywhere.
B
If
you
make
a
request
to
github.com
on
any
site,
those
cookies
would
have
gone
along
with
it,
but
now
that
we
are
starting
to
apply
same
site
lacs,
they
get
dropped
along
the
way,
but
like
CSP,
every
great
control
is
not
exactly
the
most
user
friendly
thing
and
comes
with
plenty
of
gacho's
rails
added
the
ability
to
mark
all
same
site
cookies
as
lacks,
and
now
they
do
not
because
everything
breaks,
especially
retro
actively.
It's
it's.
If
you
have
a
third
party
interaction,
your
website
will
break.
B
They
definitely
did
not
go
as
strict,
but
even
this
is
a
problem
at
github.
We're
starting
to
incremental
rollout
seems
like
cookie
protection
to
everyone,
but
we
can't
do
that
if
it's
all-or-nothing
thing
and
if
it's
all
or
nothing
thing,
I
mean
people,
don't
like
it.
When
you
can't
use
github,
that's
that's
one
thing
I've
been
reminded
of
quite
frequently,
but
so
we
need
something
a
little
more
flexible
here.
B
So,
as
already
mentioned,
the
chrome,
rollout
and
rollback
was
kind
of
not
so
great.
The
getting
the
internet
to
set
same
site
equals
none
and
all
their
cookies.
Didn't
seem
like
something
the
internet
could
accomplish.
So
chrome
had
had
this
weird
fallback,
where,
if
you
don't
set
a
same
site,
cookie
it'll
treat
it
as
same
site,
none,
but
only
for
two
minutes
after
it
was
created.
So
that's
not
really
very
intuitive
and
it's
very
hard
to
test
and
leads
to
a
lot
of
confusion.
B
But
if
you
have
a
nice
friendly
library
to
set
things,
you
can
experiment
with
things
and
you
can
testing
on
your
employees
and
you
can
roll
things
out
and
that
same
library
has
the
same
functionality.
Where
you
know
dynamically
at
runtime,
you
can
override
the
cookie
policy
for
the
application
we
had
to
set
same
site
num
on
our
sam'l
cookies,
like
I
had
mentioned,
so
that
they
would
work,
and
that
worked.
But
the
problem
was
when
we
wanted
to
try
applying
same
site
lacks
two
more
cookies.
B
More
things
broke,
so
you
see
in
the
original
one.
We
have
none
for
only
those
two
tokens
and
the
bottom
one.
We
still
keep
the
none
for
those
two
tokens.
We
add
elack's,
except
for
those
two
tokens
plus
two
more
anytime.
You
see
underscore
legacy.
You
can
assume
that
some
jenkki
workaround
was
necessary
and
it
was
so
Safari
the
not
not
the
most
recent
version.
Some
version
is
listed
here.
If
you
said
a
cookie
with
same
side,
none
Safari
would
do
quite
the
opposite
of
what
you
meant
and
would
treat
that
as
same
site.
B
Strict,
that's
not
exactly
great,
and
it
kind
of
breaks
a
lot
of
things
too.
So
we
actually
have
to
set
two
cookies,
and
then
we
read
them.
We
just
sort
of
fall
back
to
the
other
one,
so
it
doesn't
break
in
Safari.
It
doesn't
break
in
chrome.
It
rolls
back
to
the
original
protection,
but
all
of
our
other
cookies
are
fine.
Unfortunately,
what
I
found
out
when
making
this
presentation
was.
This
was
not
actually
true
and
we
had.
B
B
Maybe
tomorrow,
since
we're
at
a
Security
Research
me
up,
I
should
get
a
shout-out
to
our
maintainer
advisories
and
if
anyone
might
have
been
thinking
who
dynamic
code
to
apply
string
manipulations
to
something
that
lives
in
the
header
of
an
HTTP
request,
what
could
go
wrong
again?
It's
a
semicolon
delimited
thing,
so
injecting
semicolons
is
not
going
to
work
out
so
well,
and
injecting
new
lines
is
not
gonna
work
out
so
well.
Thankfully,
the
new
line
thing
was
mitigated
by
some
default
behavior
in
rails,
so
the
impact
of
these
were
more
or
less.
B
You
could
disable
CSP
for
a
requests
and
not
necessarily
gooder
injection
and
there's
also
a
third
one
that
is
currently
open.
So
this
is
what
happens
when
you
treat
a
string
as
a
string
and
not
apply
the
actual
grammar
from
a
spec,
but
that's
it
just
you
know,
create
a
library
that
is
easy
to
use
easy
to
audit
takes
away
a
lot
of
the
hard
things
it's
tracks
away
as
much
as
possible
and
provides
as
much
flexibility
as
you
can
and
definitely
do
not
set
this
in
or
nginx
file.
B
A
Thank
you
neither
great
and
ok
folks,
so
thank
you
very
much
to
all
presenters
that
was
awesome,
so
I
hope
that
people
also
on
Twitter
enjoyed
it
and
it
has
been
recorded.
So
you
will
be
able
to
replay
this
when
it
will
be
available
on
our
website.
So
now,
for
those
who
are
in
this
meeting,
we
will
move
to
the
networking
networking
session.
So
we
will
try
something
here.
We
will
try
to
create
rooms
where
we
were
in
shuffle
people
in
these
rooms
randomly
for
five
minutes
spin
dating
sessions.
A
So
what
I
will
ask
you
is
to
grab
a
snack
and
a
drink
to
recreate
the
meet
up
with
the
Pompeians,
so
take
one
minute
to
grab
a
snack,
grab
your
drink
and
then
come
back
and
you
will
be
invited
in
your
respective
rooms,
and
here
you
can
find
some
icebreaker
ideas,
but
I'm
pretty
sure
you
won't
need
them.
Okay,
so
see
you
in
one
minute
in
the
in
the
rooms.