►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Lightning Talk: Access Control and URI Path Normalization - Yan Avlasov, Google
Majority of Envoy’s access control policies are defined using the path component of the request URL. How can we be sure that URL Path Based Access Policies (PBAC) can not be bypassed? Two nominally different URL paths may in fact identify the same resource, and need to be normalized to their canonical form, before comparison. The normalization is standardized in RFC 3986, however it may not be enough to ensure safety of the access control. In this talk we explore the effects of URL path normalization on request access control, Envoy’s configuration options for path normalization and general principles for ensuring the safety of the PBAC policies.
A
Hello,
my
name
is
Jan
I
am
a
Envoy
senior
maintainer,
a
software
engineer
on
on
Google
working
on
gcp
platform,
core
networking
I'm
going
to
talk
about
somewhat
of
an
obscure
subject
today.
But
it's
nonetheless
it's
very
important
if
your
Envoy
enforces
some
sort
of
security
policy
like,
for
instance,
for
example,
an
access
control
policy
for
requests,
and
specifically
it
is
the
effect
of
normalization
of
the
URI
path
on
the
safety
of
the
security
policies.
A
Before
we
go
any
further
here,
sort
of
like
a
bird's
eye
view
on
what
happens
within
Amway
when
it
Proxes
a
request,
request
comes
from
Downstream
client,
Downstream,
endpoint,
and
the
first
step
is
service
selection,
where
Envoy
takes
routing
table
and
some
requests
of
the
pro
some
properties
of
the
request
and
then
determines
the
route
where
the,
where
requests
have
to
go
next
and
the
Second
Step.
If
it's
configured,
there's
a
policy
application
and
conceptually
it's
the
same
same
process.
A
Where
only
looks
at
the
list
of
policies,
takes
request,
properties,
figures
out
which
policy
to
apply
evaluates
the
policy
depending
on
the
result.
It
may
reject
the
request
or
let
it
go
through
and
by
far
the
most
common
request,
property
that
is
used
for
both
service
selection
and
policy.
Application
is
the
path
component
of
the
request.
Url,
its
syntax
is
standardized
in
RFC
3986.
A
But
in
fact,
May
point
to
the
same
resource,
and
here,
where
path
normalization
comes
in,
it's
a
transformation
that
determines
the
canonical
form
of
the
path
which
intermediate
is
like
Envoy
used
to.
You
know,
compare
password
equivalence,
which
is
very
important
when
you,
you
know
when
you
want
to
find
a
policy
or
a
service
that
corresponds
to
a
specific
path,
stand
up.
It's
it's
a
you
know.
According
to
the
standard,
it's
actually
a
fairly
simple
procedure.
You
know
all
the
percent
sequences
are
normalized.
There
are
three
steps
there.
A
All
of
the
percent
sequences
are
normalized
to
the
uppercase,
then
anything
that
doesn't
need
to
be
present
and
coded
is
decoded
the
so-called
unreserved
set.
And
if
you
look
below
them,
you
see
that
it's
actually,
you
know
a
fairly
small
subset
of
characters
that
are
that
is
unreserved,
and
then
there
is
a
path
segment,
normalization
in
all
the
dot
and
the
dot
sequences
are
collapsed
and
the
thought
sequence
actually
collapses.
Also
the
previous
segment.
A
So
the
you
know,
standard
based
path.
Normalization
is
relatively
simple,
but
the
problem
is
that
the
actual
implementations
are
very
often
not
standard
compliant.
They
evolved
over
decades,
there's
a
lot
of
craft
in
them.
There's
a
lot
of
special
cases.
Very
often,
it's
also
controlled
through
configuration
so
determining
what
the
origin
or
Upstream
service
will
actually
do
for
path.
Normalization
is
tricky,
so
here's
just
to
kind
of
title
together,
I'll
give
a
quick
example.
A
Let's
say
we
have
a
very
simple
policy
where
all
requests
to
the
admin
endpoint
have
to
be
to
the
admin.
Prefix
have
to
be
authorized.
You
know
some
sort
of
chrome
authorization
is
token
attached
to
your
request
or
maybe
a
peer
certificate
and
all
other
requests.
You
know
we're
just
not
even
going
to
look
at
it.
Doesn't
matter
authorized
or
not
authorized
they
all
go
through,
and
here
are
some
examples.
So
let's
say
a
request
to
the
admin
exchange,
endpoint
and
path.
Normalization
has
no
work
to
do
here.
A
It's
unchanged,
we
find
the
prefix
admin
and
request
undergoes
the
authorization
check.
So
then
a
little
bit
more
complicated.
You
know
user.admin
in
this
case
the
standard
compliant
normalization
takes
out
the
dot
dot
in
the
previous
segment.
You
know
produces
admin
path,
matches
our
prefix
and
we
check
for
authorization
and
now
here's
where
the
sort
of
the
rubber
starts
to
meet
the
road,
let's
replace
one
of
the
forward
slashes
with
its
percent
encoded
form
percent.
To
f
these.
If
you
remember
you
know
from
the
previous
slide,
we
only
decoded
reserved
characters
forward.
A
Slash
is
not
one
of
those,
so
the
path
normalization
actually
doesn't
change
the
path
at
all.
It
doesn't
match
the
admin
prefix
and
such
request
is
going
to
go
through
now.
The
interesting
question
here:
did
we
just
created
a
sort
of
a
trivial
bypass
of
the
security
policy
and
the
answer
is
Maybe
and
it
actually
depends
on
what
is
your
Upstream
server
or?
What's
what
is
your
origin
server?
A
Just
for
just
as
an
example
I
took
you
know
we
can
take
Apache
very
common
origin
server
and
it
depends
on
its
configuration.
If
you
in
your
configuration
set,
you
know
specific
option
to
either
off
or
don't
decode.
Oh
no
problem
so
request
either
gonna
be
rejected
or
normalized
the
same
path
as
Envoy
and
there's
no
policy
bypass.
A
A
Some
more
examples,
that's
actually
a
very,
very
small
slice
of
what's
possible
and
it's
you
know
it
really
depends
on
the
different
types
of
you
know.
Different
types
of
back-ends
go
servers,
have
you
know
their
own
set
of
possible,
bypasses,
node.js
and
so
on,
and
actually
the
key
takeaway
that
I
wanted
to
sort
of
point
out
from
this
presentation
is
that
there
is
no
one
hat
one
Hatfield
normalization
that
an
intermediary
can
do.
A
There
is
no
one
right
way,
even
if
we
do
strictly
standard
compliant
thermalization,
it's
not
enough,
as
you
know,
as
I've
shown
them
from
the
example
and
the
Really.
The
right
way
of
doing
that
is,
if
is
to
match
path,
normalization
on
Envoy
and
back
normalization
on
the
origin
of
steam
server,
and
in
this
case
you
know
for
sure
that
your
Access
Control
policy
will
be
applied
safely
as
a
sort
of
a
little
bit.
You
know
a
little
bit
worse
example.
A
So
for
practical
suggestions,
you
know
the
best
practical
suggestion
is
know
your
origin
server
path,
normalization.
It
performs,
you
know
what
transformation
it
makes.
That's
you
know.
Sometimes
it's
very
difficult.
Sometimes
you
have
a
container
that
you
put
from
the
internet
and
you
don't
know
what's
inside
It
Go
Java,
who
knows
so?
There
are
some
I
think
practical
suggestions
that
can
improve
the
security
considerably
and
the
first
one
is
actually
just
simply
enabling
the
option
on
way
to
do
path.
Normalization.
The
option
is
off
by
default,
we're
changing
it
in
the
future.
A
The
second
is
to
enable
merging
of
these
lashes.
There
is
virtually
no
real
world
systems
that
would
you
know
that
it
would
that
that
this
option
would
break
I
always
recommend
it's.
Just
a
no-brainer
also
removes
a
very
large
attack
surface
and
the
last
one.
The
last
option
that
I
wanted
to
bring
up
is
actually
decoding
how
how
they
present
to
F
sequences
are
treated
and
the
safest
option
is
just
simply
to
reject
those
requests.
This
might
not
always
work.
A
There
are
some
applications
that
actually
you
know,
use
use
this
feature
and
they
encode
their
slashes
for
one
reason
or
the
other,
and
in
this
case
you
have
to
be
really
careful.
If
you
use
access
point
access
policies,
take
a
look
at,
you
know
what
paths
they're
applied
to
and
what
the
backend
service
is
doing.
But
this
is
really
one
of
the
more
dangerous
policies.