thank ball all right so let's talk about
a little bit about security today I'll
introduce myself first my name is Ron
Ptolemy developer advocate at sneakin
from Israel I sneak we build developer
tooling real for security tooling to
help developers and empower them to
actually fix security vulnerabilities
that they have in their open-source
projects I am also actively involved in
an OG air security working group to help
improve the state of security of no GS
and the NPM ecosystem as well and to a
lot of other projects like OS node goat
and some books I wrote about security if
you're interested in any of those and
getting involved I'll be happy to help
so just ping me on Twitter and we can
take it offline so open source is
awesome right we're all using virtually
everyone is using open source in one way
or the other it is a great way for us to
go ahead and just focus on the business
logic of things that we need to build
and reuse what we need what we can from
the ecosystem we can also go ahead and
contribute back some of us even
contribute and create and maintain
project which is amazing and they
probably don't need to convince you that
you probably already know that and true
as a testament of that we have seen a
lot of growth in all the NPM all the
packaged ecosystems of different
languages even Java as it seems I don't
know if virtual T or not but generally
we've seen this growth going up through
all of them actually in just 2018
yes last year NPM has added 250 K
packages to the repository earlier this
year in June we already crossed 1
million packages on NPM which I probably
don't need to tell you that because all
of you are pulling half the universe
when you're done doing an NPM install so
really the question is how much do we
know about the NPM dependencies that
we're pulling into the project try to do
a mental exercise just now yourselves
try to imagine your package is on your
package manifest how many packages do
you know do you recognize those direct
dependencies and how many transitive
dependencies do you also pull in so
there's a lot of dependencies a lot of
unknown that we are using in our
projects and you know possibly involving
some risks
an interesting article or a research
paper that was actually published
earlier this year that I had a chance to
read and write about is something that
actually compared a Python hacker system
with the NPM ecosystem and it found that
61% of all NPM packages could be
considered abandoned now abandoned is a
very open to interpretation you know
different people have different opinions
on it for the sake of the research what
they did is considered any package that
didn't have a release in the last 12
months is abandoned which is arguable
because you could just say that you know
the package is well known it's mature
it's reached its and state and go except
in 2018 some of us may remember the
event stream incident probably the most
sophisticated attack that we've seen on
NPM happening happened to a package
called event stream which has been there
for almost a decade like eight years did
not have any release for the last two or
three years depending how you count it
but someone was actually able to
socially engineer their way into getting
into gaining NPM publish permissions to
publish a module injected a malicious
package in the dependency tree of event
stream itself and in this way we're able
to steal money from cryptocurrency
wallets this actually happened there's a
whole post more than one chain events if
you're interested in following that as
well but also what that research paper
actually you know highlighted is an
important note about that the dependency
tree that we are always pulling in so it
actually found that on average we'll be
pulling in four and PM packages nested
deep in every time we'll go ahead and
install and be an NPM package so this
actually is you know very interesting in
terms of how many packages are we
pulling in and what do we know about
those packages and all of those nested
dependencies in the tree watch go to
vulnerabilities they may have so as an
example and security vulnerabilities
happen all the time we just usually less
hear about them as we're less conscious
on this but where do we go with yawn
yawn is popular NPM package manager it
was it was found to be vulnerable to a
man-in-the-middle attack so for example
if you were here on the workshop or in a
coffee shop you are using a you were
doing a yarn install someone could
actually eavesdrop the connection and
get the NPM tokens that you were
sending off to to npm itself because
that was sent off on an insecure medium
so not on an HTTP so that's that's one
and I could probably do a safe a safe
estimation and guess that no one is
using this latest version of yarn that
was just released a few months ago
another example is markdown marked down
for j6 this package is actually pretty
popular it's used for a storybook UI in
several gatsby teams obviously in
several UJ s and n react.js components
as well and it is also vulnerable to
some XSS vulnerabilities which were
again only recently fixed sequel is
another even more the most up-to-date
example of an SQL injection SQL
abstraction library that is usually
popularly used on OJ's project actually
was found to be vulnerable to several
SQL injections and was just fixed last
month so if you know that one of your
teams is using that you should probably
scan and make sure that you're fixing it
and upgrading very quickly now this
means that a lot of open open source is
amazing and it's written by humans but
you know as we come to think about all
of this risk we come to also understand
and realize that we do not know who
wrote them and you know what is their
proficiency what is going on with those
packages for example we actually
conducted a state of open source
security in February 2019
we found a lot of interesting fact for
example this one where maintainer x'
would feel less confident in fixing
security issues once they are disclosed
because they do not think that they have
a strong enough security knowledge to
actually fix that and do something about
it similar to that for example
maintainer is usually or a 26% of the
time will not add a to their packages
they will not have any such kind of
security testing that static application
dynamic application security testing not
even a security code review so imagine
your projects although dependencies
count one out of four that did not go
any kind of security test now that
pretty is pretty easy to do an hour on a
direct dependency but just think about
how all of those are indirect
dependencies that you're pulling in as
well so as we come to talk about you
know the code that we have and how much
we rely on open source it's a it's a
simple app I built based on vgs and a UI
framework called Bouma so it doesn't
have a lot of dependencies but you can
already see that what a code is
generated from my app and from the
bundle of all the vendors
that you know I'm actually dependent
upon you know it's only represents 0.2%
my code through the whole app and I
think this is the most thing that you
know struck lightning in terms of being
able to understand and realize how much
we're using open-source because this is
a common misconception for me as a
developer were I'm building code pushing
it to production and you know this is my
app except my app is actually you know
it is that but my code what I write you
know my own responsibility is actually a
very small piece or that whole thing and
when I'm pushing this whole thing I'm
pushing a lot of code into production a
lot of risk that you know other people
would usually catch such as DevOps and
security engineers and figure out that
there's a lot of risk that I'm actually
pushing in so at this point I guess some
of us are wondering you know we're
talking about security vulnerabilities
in open-source libraries and how much
are we dependent upon so how do we jump
from a security vulnerability in a
package in a dependency that we're using
to a security vulnerability in our
application it actually puts it into
risk so let's go ahead and go to the
hands-on part of this of this
presentation so over here I have a
simple goof to do application you can do
things like I'm pretty nervous here and
it's basically a to-do app that I can
just add some stuff into it as the
security conscious developer you might
start already to think about how you
could go ahead and you know attack this
one so it has an SQL injection input
maybe I can do something around it maybe
I can do an exercise several things
right so maybe I would go ahead and add
something like that maybe it works maybe
it doesn't work I don't think that we
should know about this is I've built
this using marked so marked I'll go
ahead and increase that so you can see
mark is a fairly popular as well package
for doing work down one example of
understanding security and being aware
of this is this is a bad example of it
in terms of you need to opt in to
security right to sanitize the data
that's coming in when you use it so it's
not turned on by default you actually
need to know to do that so as a
developer if you
if you're reading this you have to like
understand the API is read I need
security disclosure and then then turn
it on so we have marked her and I have
marked down support so I can go ahead
and do stuff and actually scan this up
with weed snake and I can see that you
know I have I am vulnerable to
cross-site scripting right and I'm part
of like 448 libraries that I have read
so again like how what could I do next
to go ahead and cause maybe an XSS as of
sin how about if we try a different
vector we know that there is markdown so
I can do like this and get something
bold but then I also have this vector of
attack where I can add things so imagine
someone adding a JavaScript link into
this so maybe something like this
right and then we have links so now I
can go ahead and take this one step
further and perhaps I want to change
this with something else
this is a good way to start except it
doesn't work because markdown is
actually sanitizing it as we actually
provided it so it's doing something with
the data just you know we're not yet
there one thing that is common is to go
ahead and represent data in a different
way so we can go ahead and say : on a on
a web page could represent that by the
HTML entity for that so we could go
ahead and do something like this
represent this as well and do it and the
way that I know this I do not need to
reverse engineer something that is you
know very difficult because markdown is
open source I can just go to the
repository figure out what sanitize true
does and just reverse engineer that so
it's pretty easy to figure this out so I
can do this I can already see that
something different is happening so
perhaps I'm on the right path
and at this point again I can go into
markdown source code and figure out why
did these get sanitized in a different
way
the true it is the sanitization process
in marked work this way that it actually
rejects as disco part of the string so
it actually looks for this kind of code
strips this out so while I'm trying to
be outsmarting it it is actually someone
as a developer that wrote it was able to
actually think about this vector as well
what they hadn't took into account is
something that that happens in the
browser and that is router are usually
very nice in terms of they help us to if
we write like bad code but you know
broken divs or brought off forgotten
deals or stuff like that they would go
ahead and complete that so if I would
just write something like this like
literally this I know it's hard in
JavaScript bear with me but if I her if
I put a valid JavaScript statement like
this as a keyword it will go ahead and
pass the sanitization process by marked
because marked does not look for this it
looks for a specific string as someone
trying to hack this out so when I do
this I get this link actually working
and what the browser does is it says
well I think you meant to end that a 58
character with a with a semicolon so let
me do that for you it adds it and
because this is a valid JavaScript
statement the whole thing gets validated
as far as well and we have an XSS in our
application so one example of dust of
that is this we can go ahead and figure
out some other examples for example I
have this about page which is based on
so this is I'm not doing anything
dynamically I'm actually using a
template engine for nodejs called dust
J's developed by LinkedIn for a
framework called cracker and it's
actually pretty secure project etc but
bit of an oldie reference here anyway
what I have is an about page on this app
and you can see how I'm like really
great at CSS because I have this skill
to make it big make it alright so let's
go back to this so it is a mobile first
application you can see it actually
responds reactivate to what I do and at
this point again I'm trying to figure
out what can I do with us as a
templating engine on this application so
give you a bit more context into what's
going on
no this is a template for it right about
you it has the test extension I have
this condition where if something is a
device equals the desktop or mobile it's
gonna run through one of those branching
statements in my conditions and draw it
draw the draw the HTML for this so
pretty straightforward but the question
is what we can do with this if we were
to figure out what is what is that's
viable for you know if you would scan
your app you could scan it with whatever
you want sneak or NPM audit or OS
dependency check doesn't really matter
but you would find something like this
like dust is vulnerable to a code
injection what does it mean a code
injection how does that really happen
how does that impact from a library to
my own application so the thing is
there's a user input here so we can go
ahead and start and doing something with
it and for example I can go ahead and
put maybe a quote because maybe I'm
trying to escape this whole quote
condition and do something with this
part of the code maybe I would do
something like this except that seems to
be okay dust it's probably behind the
scenes and coding it doing it properly
etc and we can actually see that dust
has this escape HTML part of the code so
it's actually taking a string trying to
see if there's anything malicious that
should be encoded you know something
dangerous that should go trying to
encoding and then it's going to go and
encode it so it's gonna replace it with
the HTML entity for it and this way try
and you know not use the original quote
or whatever fragment or I was trying to
do to circumvent the app this is great
except it is actually only going into
this safe condition when I'm giving it a
string at this point is it too
interesting to figure out how do i hack
through that and do not give it a string
because I need to put something else but
to bypass this part which is not a
string so one example one way to do that
is to think about array parameters for
the way that you could go ahead and do
our request poisoning like this with an
HTTP parameter pollution and you would
say
Desktop is now actually an array this is
very common where you have like end user
ID equals something and use ready equals
something and you want to pass an array
to a request parameter or you can also
use the bracket notation to go ahead and
convey the same the same in terms as you
can see when I'm doing that this
continues to work just fine because when
the evaluation happens over here over
here I'm just go ahead going ahead and
doing a two string for an array that's
gonna give me the first item under so it
seems that the app is actually working
well but what's interesting is if I go
ahead and try to put a quote or
something fails and we can already see
what's going on so to understand a
little bit better what what is actually
going on behind the hood with the
security issue is this if condition is
actually something that gets evaluated
through runtime because this is
generally how the template engines work
and dust has this helper were for if
it's going to go take that condition and
evaluates it so knowing this I can go
ahead and figure out well if that
condition works maybe I can provide a
specific string to do something let's
try to run a commander so we're at a
request
probably a life so we can do this
together and I'm gonna go and see that
everything is okay I will add a quote
see that everything is okay again I'm
gonna go and add this to do the whole
thing and reproduce the whole bag and
you know now I have a working example I
can actually work with and this is where
the fun begins right because we know
it's an evaluation statement so it is a
simple for me as doing something like
sorry note and then evaluating desktop
equals desktop for example it's gonna be
true but now that I know that I have a
way to inject data there that is not
being treated in any others a safe way I
can go ahead and do something like this
which is trying to evaluate an
expression for a place that expects a
value so as I do this I don't really
care about whether that's false or true
I care about the fact that I was
actually able to invoke a function
through this evil statement so going
back to a request I can do something
similar and I will make this a bit
bigger so you could see I was able to go
ahead and put on the server side a
function expression write a function
invocation that actually did a console
log so remove the code injection now
this is just for the example right just
for us to be very fast in this example
in the demo but imagine what I could do
here just require process child process
invoke something that I want to get from
your application or anything else all of
this is done through dust if this page
was not even authorized you know
anonymous it means everyone are able to
do this so it's kind of a remote code
injection so we're talking about all
these examples with open source
libraries and and how much you know how
much they affect us and what's the risk
that we have in them and the thing is
for attackers that's a really easy way
to do it because it's easy to think
about attackers and you know hackers as
those with hoodies
you know worrying that trying to hide
the Pentagon or something else but
mostly like the easy for the low-hanging
fruits the easy stuff that they can do
is just figure out all of those
non-public vulnerabilities that you know
everyone know about it's publicly known
but people are really late in terms of
patching and keeping up to date with
them so one vulnerability that they find
in an ecosystem like NPM for example
will mean many victims because everyone
are using open-source you know millions
of downloads for its press sample our
react whatever vulnerability that they
find and apps act is pretty hard right
that's one example of it and there's so
many things that need to happen in a
secure application development lifecycle
just one example but what's really
challenging is software delivery has
sped up it is really fast everyone
trying to be really mature in terms of
CI CD pushing value pushing data out
pushing code out etc but do we forget do
we do we actually do to actually embed
security testing in part of our
application in what would and what we
develop and what we push out do we have
this confidence that everything we push
out is really tested very well and does
not have any kind of security
vulnerabilities like this we're also
outnumbered in organizations right in
organizations the ratio that like
Gartner report was was saying is one
security person for 100 developers
that's actually a good example of it
because in most organization it's
actually pretty worse than that how
about the fact that as developers we do
not really get any knowledge or any
experimental experience or expertise on
security for example these are the top
computer science programs in the United
States of America I imagine that you're
able to recognize some of them I
filtered at least to show all those that
actually have a requirement for a
software security course yep
so no wonder that you know as developers
we sometimes feel that we do not have
that that knowledge then that gap that
exists for us to build applications that
are secure
how how equipped do we fill in terms of
not just finding but actually fixing a
vulnerability actually being able to
remediate it but because at the end of
the day it is our responsibility and
it's great that it is like that open
source is awesome we just need to do it
in a very good way it is not so easy to
fix of vulnerability and another thing
that we learned from that state of open
source security report is as we looked
at the data that sneak has on all of its
users we just can't package manifest
file so we really care just about the
dependency that you're using and what we
try to pull it out is how does that work
in terms of different ecosystems like
where do we find security
vulnerabilities so for NPM for example
you can see that 78% of the time we will
find security vulnerabilities in
transitive dependencies so even if
you're like a conscious developer and
very responsible and you track all the
change logs for no reactive you whatever
it is and you go through each code
change one by one most of the time we'll
find the issues in the vulnerabilities
that those dependencies pull in and the
problems that exist err so what if
security was a bit easier right what if
it was something that is actionable that
is really friendly for me to interact
with that I as a developer it is aligned
with the way that I work it's not a
security system that I need to log into
and find out about all of these things
what if for example the same way that
you have a Travis or a circle CIO code
coverage running in your in your you
know pull request you would have another
test and you can you can replace
sneakier with anything else that you
want generally but what if you had if
you add that right what if a new
developer was now introducing a security
Vaughn a package that has security
vulnerabilities whether on it or it's
transitive dependency you would go ahead
and fill the build because you already
detected it right there you do not need
to find it as you go to production and
find it you know a few months later what
if that security tooling was really
really good in terms of not just opening
a pull request for you and fixing it
which is a great step and doing that but
also doing that in a smart way so in
terms of if the dependency had a
vulnerability and then a fix in a major
version it will actually try and fold
the
the most minor and minimal version it
can to resolve the security fix so to
not you know get you through the hurdle
of actually taking in a major change or
breaking change or future changes that
you may not want to pull in with that
security fix so I'm going to leave you
with that notion open-source is awesome
just please join it responsibly thank
you
[Applause]