good morning it's the steer this thing
is on welcome to my talk exercises dad
we just don't get it it's actually not
really a talk it's just like me ranting
for one hour if that's okay I think
that's quite a deal for the early hours
in the morning I have two tendency to
talk too quickly if that happens just
like way if I'm gonna slow down it's
okay already so a quick word about
myself my name is Mario I have been to
the confidence for many many many times
many years in the past and then I did
like a break for five years and now I'm
back here and this thing is huge this is
awesome so I'm from Berlin I lead a
company this coke here 53 is mentioned
we do pen tests and I wrote some books
and wrote some papers and my core
research topic is cross that's cryptic
and I'm here because of the fact that
I'm slowly getting bored by this topic
because I think that we're actually at
the point of being able to solve it but
somehow we just don't wanna so this kind
of corresponds with the title slide
across that scripting is dead like there
is nothing new to it we just don't get
it and I want to kind of have a look at
why we don't get it what the problem is
and maybe find like a different problem
during this particular journey
so let's first see who is here like what
kind of people are here who here is a
pen tester raise your hand please that's
like a couple people that's good cool
here is a developer security developer
or like a defender of web applications
who here is like like a manager like an
IOC so or something like this one person
one excellent all right and who hears
about body hunter who hunts for bug
bounties also not that many anyway thank
you very much umm let's get started and
quickly talk about the structure of this
particular talk the first act is gonna
be the unborn we're gonna learn why
we're actually here are we going to be
talking about and then we're gonna talk
about a small historic overview how we
got here because the thing that's
fundamentally important to understand
and then but not least last but not
least or almost left but not least we're
gonna talk about the problem statement
because we will learn that something is
a problem and we need to fix it and in
the final act I'm gonna propose
solutions most of them are garbage but
at least a proposal we can maybe
them to kind of think about a little bit
and eventually find something together
so let's talk about the first act the
onboarding why are we actually here well
the topic we're talking about is cross
that scripting but we don't want to kind
of uncover new techniques because most
of them have been uncovered so let's go
very much back and past and talk about
what cross-site scripting actually is so
this is like a classic process cryptic
situation right we have your L and there
is like the get parameter and then we
put something in who here thinks that
this is cross-site scripting or that the
result is cross-site scripting no one
that's good because it's not because
that's just a script injection we just
take something we put it in the URL and
it reflects cross-site scripting as
Sarge is pretty much an attack where one
side scripts the other across origins
this is not cross that scripting there
is no multiple origins we just call it
like this but it's pretty much wrong
anyway I mean if you put Facebook
Connect into your web site or Google
Analytics that's actually cross that
scripting but it's legitimate benign
cross-site scripting you want that
because they script your page across
origin boundaries and that's XSS like in
the classic meaning of the word anyway
that's observed objection but we can
call it cross-site scripting because why
not because it goes so well off the
tongue and the name is just so nice and
we can kind of give it like this XSS
there is a couple of different kinds of
cross-site scripting like this the
easiest kind the stuff that you put in
by URL where I get parameter or by a
post field of whatever you sent over to
the server and that's usually called
reflected cross-site scripting
then there's persistent cross-site
scripting that is something from the
database or any other storage system
that then reflects on your site so you
can't find it in the parameters then
there's dom-based cross-site scripting
that comes from only broker browser
based clients have properties and last
but not least this mutation XSS
something that the browser takes and
forms into something that is bad whereas
the server things say everything is fine
here this is valid markup I think most
of these categories are highly debatable
it's questionable whether they make
sense but this is pretty much what we go
with in pen test reports and how we kind
of line it out and how we kind of put it
into shelves and basically say this is
this particular kind of thing so we know
all this this is no new to be able to
kind of understand how this all came
together and how we arrived at this
point
and how we can actually get to the
problem statement of this particular
talk I would say let's go back in time
and let's go back a couple of years more
than 20 years and let's go to that year
where cross-site scripting was actually
invented or found or first documented
and let's adjust our time line and let's
say this is the year 0 after cross-site
scripting the year 0 after scarcer
scripting is about 20 years ago and we
want to see how it all came together and
where people did back then to realize
what it is to fight it and to tackle it
because that's actually quite funny the
year 0 after cross-site scripting is the
year 1999 of our current calendar and it
was the three kings called how scheming
partout came and visited baby brain and
I she was born in an iframe what he got
was a blank Martinez of course it's
really not accurate but in this
particular year Microsoft coined the
term cross-site scripting they called it
like this and they had a discussion in a
blog post and basically said like so
there's this thing now you can like put
stuff from somewhere into some others
website and then it executes like HTML
or JavaScript how should we call it what
would a name should we give to it they
came up with a couple of proposals back
then the first one was unauthorized site
scripting I actually liked that quite a
lot because it's kind of true in its
meaning but it really sucks to talk that
you just like to spell it out or to
pronounce it it's just not really fun
it's like too long and if an official
site scripting which is a bit better
goes better off the tongue then you have
your L parameter script insertion ups I
you've seen nope then you have
cross-site scripting which eventually
won the trophy and you have synthesized
scripting not sure who came up with that
and last but not least fraudulent
scripting so all of them are sort of
correct but this one actually got the
trophy and the whole attack technique
was called Raza scripting and not soon
after the first advisory from cert was
issued describing this particular attack
because back then people knew sequel
injection remote code execution of all
these things
targeting servers but this one was new
who back then 1999 and they postulated
that a website may inadvertently include
malicious HTML text or a script in a
dynamically generated page based on
anomaly dated input from untrustworthy
sources and so
and so on and when input is not
validated to pretend malicious HTML from
being presented to the user and I think
this is one of the most compact most
accurate descriptions of cross-site
scripting this is what's actually going
on like back then in the year 1999 they
had it figure out already
so they had figured out the problem
that they were just like millimeters
away from the solution still we're in
2018 and we still don't have a solution
everybody has XSS so that's a bit
strange anyway back then the whole topic
of web security was so small and so tiny
that it was possible for experts on
completely different fields like for
example Human Genome Research to on the
side write like a book about web
security because it's just such a tiny
over topic and linkle steen in fact a
human genome researcher at the Cold
Spring Harbor Laboratory he wrote this
particular book good web security in a
spare time and he also got it quite
right he said cross-site scripting
allows the bad guy to Crick an innocent
guy into running code the bad guy wrote
that's quite accurate like he completely
gets what is going on here he writes
something on the client kind of gets it
across to the victim and then it
executes it's more accurate than most
descriptions than we read nowadays but
well people start to think about how to
fix it I like this one specifically I
like to read php.net especially the docs
because there's hilarious comments in
there but this one kind of really there
was this one jump to shark it was from
and he was talking about how you can use
HTML entities and HTML special chars to
actually fix cross-site scripting he
said this function is particularly
useful against XS a success makes use of
whole the code whether it be JavaScript
or PHP xsf often if not always uses HTML
entities to do its evil deeds and so of
course complete bullshit but still he
says it so this function is in
cooperation with the earth Script
cooperation with the script particularly
search or submitting script is a very
useful tool in combating Haxorus
right that was about 13 years ago that
people had this particular attitude it's
completely wrong content wise it has
nothing to do with HTML entities
and still that was the level of
discussion that they had back then I
thought this be like a very good example
so back then we had a set a small set of
tools that we could actually use as
defenders to protect our websites
against cross-site scripting escaping
escape your stuff before processing it
on the server to protect your database
or whatever is going on there and encode
your staff before echoing it to the user
because then you can't have HTML
injections and you can't have process
scripting right it's a simple fix for a
simple buck for very simple and very
trivial attack and pretty much we can
say case closed and that's that that's
it right but unfortunately not it
continues in the year 2002 which should
pretty much be like the year 3 after XSS
with the release of Internet Explorer 6
service pack 2 the first targeted
mitigation against cross-site scripting
was published and was introduced in this
ancient browser that no one uses anymore
hopefully and there was HTTP only
cookies now thanks to H should be only
cookies it's not possible anymore for
the attacker to steal cookies when they
have a cross-site scripting situation
and back then people were like I don't
know is that really like so much of a
contribution because let's be honest if
you really want to exploit across that
scripting attack and you don't really
give jack about cookies like come on
there are so many more sexy things you
can do but cookies who cares about
cookies so basically lots of money and
lots of resources were going into
inventing something that didn't have any
effect with the attacker would say like
ok so this door is closed but there's
another open door so let's take one of
these so what keeps well XSS was not
quite yet defeated I think HTTP only
cookies are still particularly useless
and I don't think they don't make too
much sense but still we recommend them
and penetration test reports so I think
the only scenario where HTTP only
cookies actually makes sense is where
you have the possibility of being able
to find a cross-site scripting on a
subdomain where you can't have plausible
phishing or markup injections or don't
have the possibility to steal see surf
tokens
you have good cookie security and you
want to prevent that the sub domain XSS
can interact with your main domain and I
think that's like the only thing where
this really makes sense
yesterday alert something new because
last day I learned that there is like a
new use case for HTTP only cookies so
since yesterday or a couple of days ago
they make more sense that they did for
the last 20 years 17 actually and it
turns out that HTTP only cookies can be
used to mitigate a text like specter
because by using HTTP only cookies you
make sure that they don't even hit the
renderer and Chrome or v8 and that makes
sure that you can't execute these kinds
of attacks and this is like a new layer
that kind of makes HTTP only cookies be
useful again but this just happened a
couple of days ago so well exercise is
still there it's still not defeated to
be able to kind of go further and cover
all the complex cases that web sites
have and the developers create we need
to kind of find a way to determine who
can execute scripts and who can't so we
have this escaping and the encoding
that's all fine but we don't have trust
yet and again Microsoft Internet
Explorer and very early versions was the
first browser to invent and introduced
something that allowed us to add trust
so we could for example say well there
is one site and that is ours we trust
this this can execute JavaScript but we
want to embed another side with an
iframe we don't trust this side because
who knows what that stuff is so we want
to distrust it and there was no way of
actually doing this until Microsoft
invented and they call it restricted
iframes it's pretty much the predecessor
or the precursor to the development of
sandbox iframes but it was there years
and years and years before that and
basically you had the possibility to
load an external resource in an iframe
and say look you're not trusted you
can't do anything you can't do audio you
can't do video you can't do scripting
you can't annoy people this just doesn't
fly it's untrusted script that should be
good and it gives us another tool right
now we have content transformation we
escaped and we encode and we have
content restriction we define who and
what can do what and where by simply
saying look we can trust your recon
trust you that that's pretty much it
what a simple anymore because once
Trust is being added to like a security
model usually it's already something is
already quite wrong because Trust is
hard to be find in an extremely complex
topic but at least there is another tool
that we can use so are we close to
fixing it yet
probably let's see well then there was
another thing happening and what reads
here is German that says like it vermin
this is like yeah there's warmth and
people figured quite quickly out what
they could do with cross the scripting
attacks if they went from the classic
alert to doing something actually
creative and they looked at certain
platforms like social media platforms
like MySpace or web mailers or stuff
like this and they erased wait a second
if I can execute JavaScript on behalf of
the locked and victim then I can do
whatever the victim can do so that means
I can just like emit clicks and
keystrokes and do all sorts of things so
that means in a web mailer I can likely
send emails normally only the victim can
do this or the legitimate user but the
process scripting can do this as well
and depending on the context of the site
you can do a lot of stuff usually the
sky's the limit and people figure that
out and people did that and played with
us in the Year 3ax
there was the mention of the ad Vigano
virus and the at Oh godoh virus was
something that basically had the
possibility of injecting JavaScript and
HTML into an existing website and then
propagate from there and infect other
web sites as well so the user would go
there and then it would kind of
propagate through the contacts and at
some point you have a lot of infected
users with a lot of impact and a lot of
calculation from computing power and it
gets interesting then needless to say
there was myspace that thing that sent
me actually unleashed a couple of years
ago and he also basically found a way to
take his payload and when people visited
his profile he would take his payload
put it into their profile as well and
visited their profile
well you kind of can see what happens it
spread exponentially and it was pretty
bad and also you went to prison for that
so that wasn't good don't do this at
home and in the year six after
cross-site scripting there was a paper
by Wade Elkhorn who was a long time
behind beef and
he pretty much specified what needs to
be done to create a cross that's
crippling virus in create a
proof-of-concept he specified what is
necessary in terms of components and you
can see in those early years in 2005
people were already all around that like
they realized what's going on what you
can do what the potential is and some of
them even did it but the problem is to
tackle this particular kind of thing you
can't just have encoding you need more
because in these situations you usually
have websites or platforms that want the
user to submit rich text and this which
takes to be stored and then to be shown
could be like a web mailer of course you
have rich text in your emails that you
send it could be like your Facebook
profile or anything else that requires
you to have like bold fonts and red
backgrounds and all these things so now
this is a new challenge because by using
encoding we destroy all that we don't
want this so what we have to do is we
have to find a way to sanitize to tell
apart the good from the bad parts and
only leave the good parts and throw out
the bad parts and then hopefully be safe
that was being done and all of a sudden
everybody wrote their own sanitizer as
you can imagine that most of them are
extreme and you should never use them
don't touch them with the stick but
there is many of them there's HTML
purifier which is actually quite good
there's anti semi which has been
discontinued it's no nois project
there's HTML lot which you should never
use it's really really broken there's
what's what's HT wash HTML on the ratio
or how to how to actually pronounce it
it's used in roundcube
don't don't use it oh by the way also
don't use roundcube on there is cases
that was used for wordpress a while ago
then they forked it and they kind of do
something else now there are safe HTML
and then there's sanitized HTML HTML
sanitizer HTML - sanitizer HTML space
sanitizer and HTML rule sanitizer and
last but not least there's google kaha
which also has been discontinued I have
no idea if any of these are good I know
that HTML purifier is pretty good and I
know that the next project that came out
of this one here is pretty good but
that's pretty much all I know
I created a sanitizer myself because why
not I called a Dom purify it still
maintained and still very active about
180,000 people downloaded per month and
it's a good tool however it doesn't run
on the server
advance in the browser directly so it is
different use cases and different
different attack scenarios but the fun
thing is that pretty much most of these
sanitizers had a back or a problem at
some point so we can't really trust them
here's like a code that I really liked
and I found it on the SourceForge page
of cases and it says cases it's an XHTML
HTML filter written in PHP it's a good
sign in the first place it removes all
unwanted HTML elements and attributes
and it also does several checks and
attribute values cases can be used to
avoid cross site scripting XSS note I
don't have time for cases right now so
there's this guy and he writes a
security tool and then he tells people
on the source forest page yeah I don't
really have time for this right now so
your mileage might vary like whatever
happens I really care so this product
description is like so vague it's like
yeah some things we remove maybe it does
this maybe it does that but also I don't
really have time for this so yeah most
of the other tools going in this
direction had a similar level of
seriousness so you can kind of imagine
all of them had bypasses literally all
of them including our own of course we
hit bypass to some of the bypasses were
reported and them are fixed some of them
were not reported so they're still there
some were attempted to be fixed by the
developers and then they failed and it
had to be done again and some simply
ignored the reports so sometimes you
don't get feedback from the maintainer
it's not really a problem or hey I'm
doing something else right now or hey I
retired I'm in southern France right now
in my small house who knows so maybe we
have to change the title slide because
maybe the title slide is not that super
accurate anymore
I mean XSS sort of is that because we
have all those tools we have all those
sanitizers and encoding and escaping and
Trust and all these things but we
somehow don't seem to have the
possibility to use them the right way we
seem to be not smart enough because
whatever tool we create it's either
insufficient or broken or we use it the
wrong way and that's maybe why we still
have cross-site scripting maybe maybe
not maybe the reason it's a different
one I'm just trying to get closer here
so the tools we have our content
transformation
mentioned them before we escaped we
encode we don't echo before we actually
do this we have content sanitization we
tell apart the bad from the good we
leave only the good and work with that
and we have last button this content
restriction so we add trust we define
who and what can do what and where sorry
honest those three tools really fix
99.9% of all the cross-site scripting
problems we just have to use them the
right way that is all that we need to do
somehow we seem to be stuck and using
them the wrong way or propagating wrong
news or having broken tools in the first
place but this can be fixed so I wanted
to have a look at what academia says
about this because when a problem slowly
blows up out of proportion than usually
academia is there and tries to harvest
some papers I did so myself so no blank
most of Chris's reading is covered and I
wanted to find out what happened in the
year aid after cross-site scripting in
the year 2007 what I could omit it until
then and with Google Scholar you can do
like these these state windows and you
can find out how many people were
actually publishing about a certain
thing in a certain time frame and then
check for cross-site scripting and a
gave it a custom date range and it told
me that there is like one thousand nine
hundred and thirty different papers and
articles about cross-site scripting holy
shit that's like too much like this is
impossible 1930 and no it no actual
process no actual progress sorry so even
though academia really went the whole
nine yards here and try to kind of fix
it they didn't seem to manage because
cross the scripting is still around 2000
papers didn't fix it well maybe the
reason is that there's like a lot of
niche problems and edge cases and
special situations where even if you use
those three tools that we have
consistently and the right way then you
still have cross-site scripting or the
possibility for people to inject stuff
into your website because there's like
da mixer says with like location
certification hash and all these
properties there is mutation XSS where
style properties are changing when being
treated by the web browser and stuff
like this and this is maybe something
where those tools can't really help
because they're not strong enough or not
fine right
what can we do if those tools are not
enough one of my favorite ones is mine
sniffing cross-site scripting basically
in most situations where you want to
inject HTML and JavaScript you need to
have some kind of scaffold around where
you inject into so it actually executes
this HTML or SVG or XML but if you for
example inject into something that would
be returned from the server as plain
text or as application Jason then you
usually say well Jason in plain text
they don't really execute anything if
you open them directly so we don't have
to encode here it's not true because a
couple of browsers including latest
versions of Microsoft Internet Explorer
still execute JavaScript and HTML from
text files if you iframe them from an
EML file and it's again ie 11 that
executes JavaScript from jason files if
you iframe them with applicator with a
regular page and then reload the iframe
once the never gets the content type and
boom you have code execution it's
documented in our browser security
papers you can read it up in there and
there's more and more and more of these
weird niche cases still in the year 20
after a cross-site scripting and they
can't easily be tackled with our
trust or sanitization cause I mean they
could but we have to know that it's an
issue to actually apply those tools
there and then was plugin exercise I
really like this one it's it's quite a
while ago it was a thing in 2009 when
Adobe's PDF reader had a back and you
can pretty much open any PDF any like
whatever PDF out there and you would use
any parameter name whatever you could
come up with and you would call it
JavaScript alert 1 and then it would
execute just so because they were like
oh this is like a JavaScript your eye we
should kind of parse this and put this
into an eval no one knows why but they
did the spec then that's pretty much
meant that every single website out
there had cross-site scripting if the
victim had Adobe Reader installed and of
course pretty much everybody had this
installed so that was kind of bad and
this is one of the situation where those
three tools that we have really don't
help like there's nothing they could do
because it's a problem and a different
software that locks itself into the
browser and the
her needs to fix it and people need to
upgrade whatever you do as a developer
you can't do anything I remember that
back then people were seriously
recommending to developers to delete all
the PDFs from the web prudence come on
just like wait for the fixes on Ted that
anyway so we can see the tools that we
had so far binary trust encoding
escaping and sanitization are not really
100 percent enough they're still like a
couple of niche cases that we need to
address that we need to tackle and we
need something that's more granular
needs to say there's also more complex
but let's see with this there probably
everybody here knows CSP right as far as
I know in fact - there's like a CSP 12
happening right now but CSP content
security policy allows us to do that
exact thing we can kind of define a rule
set that clarifies whom to trust and
from whom to execute JavaScript fetch
images and whatnot
CSP had its origin in the Year five
after cross-site scripting that's the
year 2004 few people know that and was
called not CSP but content restrictions
0.5 and it was created by Joe bass mark
hem of Mozilla back then and he
basically says yeah we need headers in
these headers need to specify trust and
do things and well then then we should
be able to kind of make sure that the
evil guys can't execute JavaScript in
our website anymore because we don't
trust them in the first place we'd
already trust us and then then we're
done yeah the result from that respect
then very simple approach was a more
complex thing co-developed by Brennan
stern from Mozilla and they call it
content security policy CSP and
meanwhile we're at CSP version 3.0 and
it gets bigger and bigger and there's
more directives and more complexity and
more implementation work for browsers
and still across the scripting is around
and I believe that the problem with CSP
is that it's too complex and not really
suited for the use case it's pretty much
like this gun that tries to shoot in all
four directions at the same time but
never hits the target
and I think CSP is great for websites
that have one single purpose for example
something like global leagues or secure
drop like something where you can't have
any attacks against something that needs
to be secured and only does one thing
but this thing
really really well but if you look at
the website like Facebook or something
that has like decent complexity how are
you gonna put CHP in there how are you
gonna tell apart the bad from the good
the trusted from the untrusted there's
literally no way and it's quite
interesting because we have a couple of
clients that come at us and then
basically say like hey so um we created
CSP policies for our website and we want
to have a review can you have a look at
our CSP so they don't come for us for a
pen test they exclusively comment as for
a CSP reviews and want us to tell them
whether their CSP policy is actually
good if the two years that they invested
were well invested or if it turns out
that the rules are broken and we can
still bypass them and we look at the one
from Facebook and I encouraged you to
have a look at the CSP policy from
Facebook as well because it's ridiculous
it doesn't do anything it's like pretty
much half a kilobyte of absolute nothing
and has no purpose because in the first
line it essentially says default source
is asterisk so they pretty much trust
everything then why have CSP in the
first place if you trust everything look
it up it should be online right now we
refer to this as cargo called CSP do we
know what carbuckle is who knows what
cargo cool this I think it's like the
perfect the perfect example here are
like the perfect metaphor that's
actually quite a sad story imagine
you're like an injudicious people you're
living in the Amazon in the Amazon
jungle right and then you're living
there you're hunting and you're doing
your stuff and you're like in unity with
the forest and everything is like
perfectly fine and then someone comes
with like a silver bird aka airplane
look at these and lands on a landing
strip that they made and then there is
like weird people coming out with
different skin color and they do stuff
in your jungle and you're like wow who
are those people they come with silver
Birds holy shit they must be gods and at
some point they disappear again because
they did whatever they wanted to do and
you're like oh man it would be really
good if the gods came back because that
was so cool so they need this landing
strip right so here's what we're gonna
do we're gonna chop some trees and we're
gonna create some some some some some
you know some some planks and then we
built like an artificial landing strip
for them because maybe then they come
back needless to say building a wooden
artificial landing strip is not gonna
make the gods and their silver birds
come back so this is
futile but people at least believe that
they might come back and if they're
trying the hardest they can and maybe it
works and I have the feeling that with
many CSP policies that we see it's the
very same thing people just hope that
maybe magically with the budget that
they put into their headers that are
actually gonna fix cross-site scripting
but they don't because those policies
are meaningless and just a waste of
space so it's expensive to implement
it's hard to get right there's browser
Baxter's bypasses and it's not yet the
solution and I'm not really sure if it
will ever be the solution because there
is a lot of unrest in the specification
I think like okay this is bad and that
is bad and this we can't do and this we
can tell so we kind of had to invent
this and you don't have to invent that
it's growing more and more complex and
I'm not really sure if it's messing more
time into this thing actually helps so
we have another tool but it's again not
enough or not suited for most of the use
cases that actually exist out there
there's a lot of new security features
coming at us and some of them are
already live in the Canary versions or
will be live or are hidden behind the
flag and there's tons of stuff like
sandbox iframes we know already we've
had them for ages and basically have the
possibility to add more granularity to
the trust of externally loaded content
same with a sub resource integrity which
kind of checks for hashes when we
request something external from a CDN or
something like this there's sub oranges
to kind of isolate different apps on
which other that are residing in the
same origin there's permission
delegation trust subtypes the referrer
policy and tons of other things if you
want to find out how much is happening
right now in the realm of web security
in browser security go to the pull up
through the platform Status pages to the
chrome platform Status page or to two
edge status page or to Mozilla's pages
and check out how many new features are
actually relating to security I have
like a little search field you can just
let go in there and check it out and
we'll see oh my god this is like 38 new
features coming in the next three months
that are all security relevant we should
know these things we're pen testers or
security developers but the point is not
that we should know these things
the point is that there's so much coming
at us so much new edit complexity and
still we haven't solved the problem and
I'm not really sure of more more more
more morally the answer here so the
tools that we have
content transformation we escape stuff
we encode stuff so the easy things
content sanitization we tell the good
stuff apart from the bad we only leave
the good content restriction we define
who and what can do what and where and
we hope that the trustee is actually
trust able because we don't know that
maybe jquery.com got hacked and they
deploy petrov ascription or maybe HX the
google api Starcom has insecure
javascript or knows which is we can just
hope that everything is fine and that
our policies are holding and making
sense in the end and keep people from
injecting JavaScript into our website so
again i think you have to change the
title flight because it's again on
accurate anymore Chrissa scripting is
dead we just forget about this because
we have all the tools and the tools are
good but we don't use them quantum
transformation people just forget to
escape and to encode and this is how we
find box and then we get money for them
content sanitization senators will get
bypass the authors don't fix it so what
or it's being used in such weird context
that something completely different must
happen to defuse it or this any ties a
library that is being and uses outdated
because the website owners don't update
this thing on the website is abandoned
but still has users who know and content
restriction was just too much more or
our ads won't work anymore we have a
couple of clients that we asked look why
don't you use CSP not that we wanted to
encourage them to use this but we just
wanted to know why they don't use CSB in
the first place but we have so many
affiliates and partners we want to buy
iframe we want to be I framed by those
but not by these and then we have like
ads and trekking and all this garbage
scripts so if we don't have these we
lose a lot of money and if we have CSP
we can't have those or we have a policy
that is so generous that it doesn't do
anything in the first place like
Facebook's
so that's kind of complicated no one
really wants to fix it or sometimes
people forget about fixing it the right
way and we're not really moving forward
so I think we've seen enough of history
and where we actually are right now to
kind of formulate a problem statement
and to be able to solve something we
need to have a problem first and maybe
we don't even really know
what the problem is with cross-site
scripting because it's so complex so it
has grown so complex over time so year
20 ax which is where we are right now
20:18 we have all the research we know
what cross-site scripting is we know how
it works everybody can do it it's
actually quite easy to learn with all
the tools the encoding the escaping the
sanitization the the trust and so on we
pretty much know all those nasty tricks
because there's always tricks and
browser backs and these things and I
notice that in the golden years a couple
of years ago like five years ago people
were like publishing cross-site
scripting tricks all over the place but
this is decreased like it's not
happening anymore it's pretty much
flatlining because there is not many
tricks left that's maybe something
exotic here maybe something exotic there
but this gold rush that we had a couple
of years ago when everybody and their
dog was finding new attack techniques
every day this is over and it's not
gonna come back we know all the risks we
know what worms are we know what you can
do with cross-site scripting we have
seen life attacks we have seen server
going down we have seen code execution
we have seen all the mess that is
happening on the crypto websites with
their wallet implementations on a
website because you put some JavaScript
into the transaction commit and then
you're rich we know all that we know
that it's real we know how to fight it
we know what it does what it is and we
have pretty much found almost all the
tricks that exist to sneak it in anyway
we know how to kill it now we don't do
it and the question is why why is this
still a topic why am I still standing
here and talking about this topic and
it's this may be something that is
symptomatic maybe for other security
problems as well or for other
technologies as well let's see I think
there might be like a variety of reasons
the stuff that we usually hear when
talking to developers after a
penetration test it's like normally we
do it but this one time we forgot it all
right oh yeah this is like the legacy
system and the legacy system we don't do
patches anymore and she's like we
migrate slowly to the new one this mess
is just as much safer or we don't have
budget for security right now because
management decided that security is
something that should be tackled at a
later point in time
or people say yeah this isn't really an
issue for us because we don't really see
the scenario our custom code is much
faster than
the framework we don't have to have Auto
escaping so yeah that happens or our
advertisers don't like CSP it's too
restrictive or the developer who wrote
this code is now selling used cars and
can't take care of this anymore we don't
have any idea about the code we actually
heard the story like this and it was a
bit more tragic because someone died and
that was horrifying because they lost to
developer yeah to an accident and then
the pretty much the entire code paper
was useless to them and they couldn't
fix the backs anymore because they
didn't know how so that's a couple of
reasons
but we're turning ourselves what I
believe in to achieve excuse officers
because we basically come up with more
more excuses that effectively try to
hide that we don't really want to fix it
now then we'd already have time for that
and I'll be actually quite comfortable
with the situation as it is we cannot
implement foo because bar or I was
dehydrated I've been writing that code
or we delegate guilt and responsibility
and that's something that pretty much
everybody in here likely that's
including myself yeah that was the dirty
intern like they wrote this code like
blame them or the Project Lead accepted
the risk our management is not running a
security budget there's always some sort
of excuse that we can come up with
select yeah but this part like this is
totally not our fault and what we could
derive from that is the assumption that
the fish rots from the head down
basically this is like a flying word the
basically says management this
management's fault they don't give us
money it's it's them up there like it's
all their fault which is of course
extreme nonsense because I think it's
all of us I think it's like the entire
community developers security people pen
testers even myself we're all stuck with
those because we don't really want to
fix the problem because we actually
quite comfortable with the situation as
it is and I ran into like a very
interesting situation in while ago that
was about half a year ago and it was in
India and it knock on and go on and it
was quite late already I was pretty
hammered and I was going to the bar to
grab another beer and I was talking to a
friend over there and I was like yeah
this talk about how crusted scripting is
dead but not really is the interesting
interesting and then he looked at me and
says like oh man I hope cross that
scripting is never gonna die because
then a lot of people are gonna lose a
lot of money it's like wow that's yeah
that's kind of exactly the materia that
I need for my presentation because yeah
that actually happens if this particular
entire attack class dies then a lot of
people will lose money a lot of business
models will not exist anymore or shrink
so why would we wanna fix cross-site
scripting if all that happens as the
consequence is us losing money or losing
incentives we would be with suffer
gnashing who here would suffer
financially if process scripting was
solved all of a sudden if it was gone
just me two people okay thank you so
that kind of sucks and it makes it hard
to fix a problem if you don't wanna if
you don't have him I haven't any
motivation if we don't have any
incentives so now the question is like
what do we really want do we really want
to solve cross-site scripting or Doby
just like pretend to our clients to our
customers to our users that we do so and
tell them oh yeah you need to do this
you need to do that but secretly we hope
that the issue is gonna be around for a
long long time because new nights we
treat money and it is I have to ask that
myself do I want to keep popping alerts
until I'm 85 and make money with them or
do a kind of at some point want to move
to something else not sure yet so what
do you think should be like soft
cross-site scripting and be done with it
because I think we can do it or should
we gets just leave things as they are
who who is for solving sik process
scripting and kind of getting rid of it
a couple of people are for solving who
wants to keep things as they are not
that many it's fine it's fine and not
judging or judging anyway so a couple of
people went to solder a couple of people
want to leave it as it is let's move to
the final act and ask ourselves to what
now can we do anything about this is
there anything that we can kind of
derive from this from this run anything
that's productive or constructive at
least I don't know if we want to solve
it we need to ask ourselves the question
do we really need more tools do we
really need more stuff in the browser on
the server in our headers to actually
feed to developers and ask them to
implement
do we need more HTTP only cookies do we
need more CSP or whatever other proposal
do we need SEC metadata or yet another
layer in the stack do we need more
complexity and are we are working on the
right
direction as pen testers as browser
vendors as developers and certainly also
as users I found this thing on the
shipping announcements for Chrome and
it's about tech headers or SEC metadata
one of the new headers that is that is
implemented pretty much right now and it
says yes this mechanism is simply an
additional HTTP header there's little
risk created by shipping it other
vendors can pick it up over time or if
it turns out to be a bad idea we can
drop it without much fanfare which is
awesome because it basically says like
yeah think about like a feature for
security and we have really no idea if
it's any good let's just try it out and
if it's shit that we remove it again so
let's see this kind of shows me that
there is like not really much focus
anymore and that people actually don't
really know what to do anymore so they
just try it's like a shotgun approach
just like maybe maybe we could fix it
with this maybe not if not the mill just
did lead it again which is quite funny
quick glance at academia in the meantime
so I mean paper solve everything and I
checked from the beginning of days to
today how many papers have meanwhat been
written remember before it was 1930 and
then I checked from back then - no and
it was like nineteen thousand five
hundred papers holy shit like this is
ridiculous and still the problem is
around so papers don't fix it and you
can write as many as you want and get
your currency in academia to get your
PhD it doesn't have any actual
contribution sorry but well pencils down
we need to maybe kind of step back a
little bit and think about what actually
is missing for us for all of us to solve
this particular problem and I think what
is missing is motivation we don't have
the right motivation because we do all
these things for completely different
purposes and that's wrong because that
ruins it how about we think about adding
some motivation through punishment I
like punishment
so we use punishment pretty much
everywhere we use punishment to fight
crime and keep people from speeding and
we raise our kids using punishment Oh
Polly not that much why do we not punish
developers for the security box that
they create could have like a small box
with kitty litter and every time to
develop crates like a pack is like into
the head with the kitty litter goes
super disgusting the developer would not
produce any security bugs any time soon
so maybe that works you think that works
punishment it's a good thing excellent I
like it I like we should have a beer or
we use gratification maybe that's better
we use gratification for like bonus
systems or compromise managers or giving
a trophies badges Awards candy for good
grades maybe we can put some candy into
the kitty litter that the developer can
wrap our breath nah we shouldn't do this
but well why not reward developers for
producing fewer security box for
actually contributing to more secure
software like why don't we do this maybe
this works who thinks this is gonna work
like gratification giving give me people
candy again everything works excellent
maybe we should also kind of try to find
out who introduced the security bug I
mean it's not always as obvious as it
was with that lock like this particular
disaster but we need to find out who
actually did the exercise who put it in
the code who edit the sequel injection
where does the code injection who did it
and who reviewed the code and then
greenlit it and why someone must have
done it and we need to talk to those
people and kind of explain to them that
this was like a bad idea and tell them
how to do it better in the future so
that same issue doesn't pop up again how
about like a fix of a month
how about gratifying developers for
outstanding performance in securing the
platform even more fix challenges fix
bounties or something like this but then
it kind of gets us again into the
situation saying like we put ourselves
on a very high force since again us
suggesting to others were to do and the
point that I'm trying to make is that
it's all of us that are involved in this
we need to maybe start with ourselves
and I think one of the ways to actually
get there and
getting the right motivation to actually
fix and terror attack classes would be
to stop the buck fetish because I think
we have a serious back fetish we love
box so marches like what look at this
critical look at this logo back here
logo back there everything is fucked
like this is bad this is not an healthy
attitude this is not an attitude that
actually allows us to fix things and to
keep them fixed we keep fetishizing the
back but not the fix we praise the back
hunters but not the fixers we completely
ignore those people who do the dirty
work afterwards or entire mindset is
around box and not to fix this it's not
secure software that we want at parks
dogs dogs including myself I'm not
judging maybe we could have fixed
bounties and CC on Google dude already
sort of and I wanted to find out how
many people actually do fixed bounties
and if you look for fixed boundaries or
patch bounties on Google you will find
2,000 hits so that's not that many and
you look for background this and you'll
find 431 thousand hits so that kind of
tells us something like this this weird
ratio so we keep glorifying the finder
but not the fixer if like interviews
with legendary buck hunters with like
media campaigns to raise awareness
self-proclaimed super hackers and people
who kind of call themselves cross-site
scripting gods and masters and this and
this and that bullshit's makes no sense
and they get praised for what we've top
lists also fame award ceremonies what's
next an audience with the Pope I don't
know I would kind of propose for us to
stop doing this to stop living this back
fetish or at least give the fixers some
glory as well because they deserve it
not everybody agrees with this I receive
a response or two days ago or three days
ago about this like he was very much in
disagreement with this particular bit of
the presentation it's just like no
there's no way we can do this we need to
punish developers and like they produce
the buggy software fair enough what
everybody has to agree but what we can
agree on and this is pretty much the end
of this particular presentation we don't
really have a working solution yet and
the problem is not that we don't have
enough technology I don't have the
solution needless to say I'm probably
part of the problem as well but maybe
maybe if we start realizing what and who
and where the problem is actually
located we can kind of find out how to
get there and solve it because this is
what we need to do
and I think it's all of us that can
contribute to this not just a couple of
people not just academia not just
industry not just researchers and I
think we need to start by being honest
we need to either say alright I don't
want to fix it I'm fine with the status
quo I'm not complaining or judging as
mentioned but at some point it's going
to fix anyway and you need to rethink
your business model or you can say well
I do want to fix it and then I want to
explore what is afterwards what's
happening after that many interesting
let's meet let's discuss let's talk
about this let's together use Occam's
razor strip off although the nonsense
strip of all the bullshit and identify
the actual obstacle and then work on
this and create a new post cross a
scripting security business models
because they exist there's still so much
more stuff to explore and it's getting
interesting so I think we can now
conclude and say process scripting is
indeed dead we have everything that we
need
we just need to accept it for ourselves
we need to have the motivation to
actually pull it off to accept that it's
dead that we have all that is there as
we don't need additional technology and
that pretty much we're good to go and
now the only thing is if you want it
let's let's do it let's throw away all
the other garbage let's focus on solving
the problem identifying the problem the
ROI for the first or the right way in
the first place and if not they're not
but then please don't stand in the way
of those who will because that's
actually quite annoying and that's
pretty much it so summary I think we
have all that we need we have all the
tools we have all the knowledge we have
all the research we know all the tricks
what we're lacking is the motivation and
we need to kind of get together and
build up this motivation and then we can
actually do this we can kill this and
maybe other attack classes if we saw
what thank you very much
[Applause]