About this talk
This talk explores the importance of security in web applications, specifically focusing on Vue.js. The speaker creatively uses the analogy of a castle to represent applications as structures that must protect valuable user data and identities. She discusses how Vue provides automatic escaping for user-provided content to help mitigate JavaScript injection risks and emphasizes the significance of being proactive about security threats. Various security practices are highlighted, including managing dependencies, utilizing the Vue router for access control, and implementing Content Security Policy (CSP) to safeguard applications from attacks. The session also touches on the resources available through the Open Web Application Security Project (OWASP) to assist developers in staying informed about vulnerabilities and securing their applications.
Full transcript
Oh boy, it looks so great to be back again and having all of you guys here not my iPad right now. So, please join in. Hopefully it comes with live demon praying because even though VJS Amsterdam is a like a class reunion for me I'm super happy to have so many new faces here because there's one thing which is a first time for me as well. And
you see I don't have a clicker I have a small pencil. My hands are shaking. Bear with me please. Because this is the first time I enter any stage without having actual slides. So, I'm a little scared, but to have you all with me give me a sense of security and I hope I can show or basically share the sense of security with you or at least
a pretty hand handy sketch note handout later on. So, without further ado, welcome to my session. This will be my sketchbook and we will do live sketch noting together on view security and I stop talking and start when it comes to the relevant stuff. The first thing I will draw is a castle. A castle because I think all of our applications, all of our projects, no matter
if it's view or not, they are basically castles because they have lots of things which are important to protect. May it be a feature, but especially all of the data, all of the information your user have, the identity, which is the most important thing in my opinion. And it's pretty similar in real life as well. No matter if it's in the medieval times or if it's in
so in basically all media movies where a castle is castles are under siege right I don't know how many of you guys work with react sometimes as well at least I do however I guess some of you guys who work with react didn't have a holy night silent night right because around like Christmas there has been a um remote server execution security issue So yes, we cannot
feel safe. We need to be really careful when it comes to our application and especially when it comes the identity of our users and all of those things because there's lots of people living inside of this castle who are worth it to be protected no matter if it's React, no matter if it's Angular or Vue. And even if view has our back already, let me quickly um
copy the view logo because I don't want to waste too much time drawing it and colorizing it. Um we need to protect it to keep the cats here secure. We're going to finish that real quick. The first thing I want to do to know how can I be having a stressless Christmas with my family or a birthday or basically any other day is checking up. What does
view for us? How does Vue keeps us secure? And it does have our back, right? So let's copy paste this real quick. And there's one thing where Vue is helping us a lot. So all user provided content may be in templates especially when it comes to the template syntax is automatically escaped. Let me quickly write that down. Content automatically. With escape I mean like if there's some
weird person trying a JavaScript injection. So basically trying to inject JavaScript into an input field. this typical hey there's a script inside of my input field and being executed. So this will be escaped automatically. You don't need to do anything. We will get to cross-ite scripting a little later as well in detection. So I will be pretty short right now. So everywhere where you see the wonderful
oh it doesn't need to be perfect right now. Right. So where you see the curly braces, you know there's escaping in place, but it's also with the render functions. So let's say template and I be quick, but also attribute bindings Attribute bindings. So the typical title one you may have used yourself is secure when it comes to cross-ite scripting as well. However, I guess it's too much
of an ask to expect that V is fixing everything for us, right? So is it enough? Huh? I don't think so. It's still important for us to be the last line of defense because we do know we can learn and we will want to keep everyone secure, right? So okay, how do I start? How do I learn about threats which I don't know yet or how do
I learn what's up there? And there's a system which helps me and where I could find one or two entries connected to Vue as well. But to stay inside of our image as our view developers or a view project as a castle, I want to start with the underground, the supply. May it be the water supply, is nutrition, all the things a castle needs to be working.
In view terms, this might be all the packages you use, all the dependencies. And there I found some CVE so to say. So this is B the CVE common vulnerability and exposures exploitations is a um system to catalog and prioritize security issues and there's two when it comes to view and two of those are connected to those water supplies it's to the supply chain so we will
talk about supply chain failures right the first let me quickly check if I can show it here if the internet is kind to me and it looks like it's kind to me is an IATN which is a package which I guess many of us use for internationalization and there was a prototype pollution inside of the handle JSON function which is pretty scary right but also there's another
CVE so another security risk we would need to take a look it's connected to readers that's basically a denial of service angle caused by a regular expression I will consider consider that dependency as well. So yes, there could be a inefficient evaluation in par HTML causing your server to hold the nonf service. So yes, supply chain is important and I would like to draw it as a
well because water supply is a wonderful metafera to describe it, right? So let's get a well built up. Yeah, my hands a little shaking. I'm sorry about that, but I guess it's okay because a well doesn't need to be perfectly aligned when it comes to the bricks, right? So, yes, we do have our There you go. It's open. And there's lots of weird dependency issues which might
poison the whale. And I'm not that great at drawing um bottles. So please, hopefully I'm not the only one in this room who is not able to do that. But I hope you can still see this should be a bottle with a content which you shouldn't drink, right? We don't want to be poisoned. So there you go. It's filled with pretty ugly stuff. The ugly stuff being
outdated dependencies, dependencies having security issues, or worse, not being maintained at all. Let me quickly toss the poison into the well. Bad stuff. So, yes, be really careful when it comes to your dependencies. Do you remember like every few months there's an npm package being poisoned as well because contributors are still human and I guess being fished is pretty easy. So yes, you cannot feel secure here.
So let's see what we can do there. I wanted to move it away because we can close the lid. Clothing the lid are really fixes we can hopefully do when it comes to supply chain issues. And there I want to do a shout out to circle in case you would you haven't been here before. Check the recording of his tree shaking talk because it showcases really well
what what happens and when you don't mind your build and how you can secure your build. So this is important. Mind your build. Obviously, I want to write it down. I hope it's obvious, but mind your dependencies as well. Mind your dependencies. Please send help if you cannot read my handwriting. This means that doesn't need to mean that you need to check every of your dependency on
your own or basically read through all the CVEEs or be online on Twitter all the time 247. That's not healthy. But there's a couple of tools helping you with that and many of them are open source as well. I'm thinking about retirejs for example or the OASP dependency checkers. There's so much dependency mapping but also if you happen to see Jakob's talk yesterday he was talking about
the dependency cruisers. Visualizing your dependencies will help you as well. So consider that. And last but not least, I guess it's not new for many of you people, but if you do AI generated code, vet it. No matter if it's by copilot, attri a agent or written by yourself or assessed, vet your AI code. Readers attacks are my favorite example when it comes to just copy pasting
reg X and hoping that it works out. Vet your AI code. So yes, this is all I want you to share for now when it comes to supply chain issues. But the word supply chain issues I already heard at another point and I was thinking okay how can I learn about general risk? How can I learn about new risk? There's an interesting project helping a lot and
you might have heard the short term of it already. I want to draw it as a shield like this. It's interesting that it's one of the most weirdest um drawings I do, but I shouldn't be perfectionistic. The group I want to talk about has a certain name which has the word w wasp in it and I already called it out for a tool. It's called Ovasp which
is code for open um web application security project and as the name already implies its goal is to raise security inside of the web or basically anywhere and they do a lot of initiatives to help us to stay For example, I love their sophisticated application where I see what can go wrong basically. So it is broken by purpose if you want to call it like that. And
all of those people are um open-source people and um sometimes even volunteers which is super cool. But there's a nonprofit behind it as well called is the over foundation. So yes there's lots of people taking care of us. Hopefully I can write normal eyes. Yay. So yes, the Oasis people are there so we don't need to fight alone to protect our They are our guide as well.
And the ranking they have supply chain issues are at the I guess it's the third place right now. I want to quickly touch upon the first rank because it's super important. Albeit it's not a completely front-end related topic, but there's still a lot of things we can do. I'm talking about um broken access control. Access control is important to make sure that your user only does the
things you allow them to do. So this is basically if we take our castle analogy into account. It is basically important to have wardens in place or I don't like to call it gatekeepers because this sounds so negative, but it's basically those serious looking people having a spear and a shield and basically block the way if you're not allowed to enter something. So, let's give our own
warden a little helmet and an armor so it can really protect our entry points of our I will give it the shield we already have. It's a little big, I think. Let's make it a little smaller. There we go. And give it a spear. So the obvious choice to help our wardens if implementing access control most of it is done server side and there's tools like the
open FGA solution which is hosted by the um CNCF open CNCF which is pretty trustworthy if you ask me and you don't need to make sure to build a complete access control layer when it comes to having relationship based ed um access control and PI layers and stuff, you can just use this open source tool for that. But as a front-end dev in charge of our Vue
application, there's a pretty easy way to do our part and it's the Vue router. Let's make it a little prettier right now. So, this is our wonderful broken access control warden. So, it's never broken at all. And this is a simplified code of a view router where I basically went for a small snippet here to see what we can do. In our case, let's imagine we have
our castle and there's an admin room and only admins are allowed to enter that room. So we put their reward in and it will look at our token a JWT token for example and see if we are allowed to and we will check the require admin flag. It will be set to true for the route to the admin room. It's done by this statement here. We will
check it here and then if it doesn't have the check on it papers on its token we will say no we will stamp it 4 03 forbidden go away please it's important to note though that this is only client side you still need the back end here so please really think about going for an access control um mechanism maybe open FGA maybe whatever my colleague colleague did
a wonderful session yesterday. So if you're interested to learn about access control mechanisms, authorization, authentication in this regard, please check his recording. And now we will get to the most important part. And I briefly mentioned it before. Let's go back to the castle analogy. I will quickly um copy that one. And I didn't want to go completely out, but um there this is the problem with shaky
hands, I guess. We will go for our little carel here. Copy it. And then imagine an inside job because we talked about our supply. We talked about our personal wardens and bodyguards and all those people. But what happens if we have an inside job in our courtyard? What happens if there's an impostor who already smuggled stuff in? So, I will basically go for another cat here. And
this time it doesn't look that friendly. I will I guess I will give it a um a hoodie or something so it looks even more like an imposter like these capes you used in Halloween or in movies. Yeah, it looks a little messy right now. I will clean it up in a bit. Like this. super imposter, right? I was thinking about writing uh drawing an actual imposter,
but doing gaming references is sometimes a little risky, so I'm not doing that. But this is the imposter. Please, please um imagine the music to it. So, let's go. This is a evil person. And it's not only the person, it has a box. And this box is filled with evil things. May it be malicious code. May it be a payload which does weird things. It can be
a a script tag which the attacker wants to execute. This would be the JavaScript injection or it could be an SQL injection sneaking in some queries being executed alongside our code. So cross scripting is basically all kinds of injection. And this is super dangerous for us in the front end because it is the entry point for that. So in really simple words um the imposter tries to
trick us or to trick to execute their code to to execute and there has been a CVE I guess it's not completely two years ago where this happened in the view comp template compiler so again it was runnable to client side cross-ite scripting and we saw already in the um VM1. It was a prototype pollution and I already forgot to explain it at that point, but just
to get back to that um a pro prototype illusion is basically trying to inject um weird code to um the object prototype and I would assume this is pretty central part of the application, right? So the same if you feel poison into water, it will trickle down. So yes, prototype pollution is pretty scary, I guess. So yes, this is a point where we really need to take
care and do our homework to keep everyone Let's make it a little easier than that. And yes, Vue is already protecting us a little bit. However, there's some edge cases you need to be aware where the automatic escaping might not be in place. The first one is an obvious one and this is taken from the view documentation but I cannot stress it enough. It is this line
here. So basically trying to use a template directly and getting it executed getting it compiled. Never do this. Never use untrusted templates because here you have an arbitrary JavaScript execution and it can get even worse if you have serverside rendering. This is a direct server breach because if the user has this provided spring, it will write the rules. So yes, be really really careful when it comes
to that. Never ever ever ever do this. Don't. Another a little more sneakier exception is the VHTML directive. it is this one When it comes to a HTML injection, which is basically this one, this directive disables the guards, the castle guards. So the auto escaping we talked about before. So if you need to render raw HTML directly, be really really careful. See this example here. It is
an image which is user provided. But if it cannot be rendered because there's no source here, it will go to the on error and there is an alert. So be careful to use it. If you want to use it, please think about sanitization I like to go for dump purify, but there's lots of libraries you can use. So basically going here and sanitizing the input. Okay, this
is a bad place to draw. Maybe here it's better. It can work like a filter. So basically doing all the sanitization for you and render any scripts unusable. There's another place which is especially interesting for SKL injection as well. The URL injection. So I'm talking about href here. There you need to make sure to take care of the sanitization as well. It's pretty similar. So make sure
that your URL will adhere to protocols. So if it's not HTTPS, HTTP or MA 2 um it will do sanitizing as well. So Okay, that's a little small plus um stripping out everything which might be of risk. All right. So, this is it when it comes to some edge cases, but there's one which is a little more tricky because the culprit is not technically our view application.
It's something different, but we need to stop people using it. Imagine the fair warning things. We have an another evil cat. Not in green and black, please. So evil cat and the evil cat wants to trick the castle into doing things but gaslighting the people doing things. So they basically do something completely different what they than what they perceive. So I will finish this impostor from before
be because it's and it's basically using a mask or an invisib. It has its attack vendor. So basically a really dangerous and sus button we shouldn't click. But one way to make people click it without knowing that they click it is using the cloak. Let's imagine it it's like a curtain. So the button is still there, but it's basically covered by something looking legit and in worst
case by something looking exactly like our project. legit friendly button. So the user will click here instead of our website which means that the attacker embedded or even mimics our website. This is called click checking. And what I basically talked about right now it's one variant. There's one more recent one which was interesting especially if you're taking care of accessibility and password managers. There were some malicious
sites where they the attackers hit hidden input fields listening to the autocomplete functionality of password managers and this is super scary because everyone of us doesn't like to enter passwords right and for people who have cognitive disabilities they need it. So basically getting accessibility and security into composition uh competition sorry but I will not get too deep into it because otherwise I will not mind your time.
But yes these are lots of angles where clickjing could lead a user to do certain things without being aware of it. But there's something how we can block those attacks. So let's get back to our warden. We will give him another way of keeping us safe. So there's the friendly warden. I will copy it real quick to be mindful of your time. And hopefully I find the
right spot. There it is. And of course the warden will keep their shield. So it's not like I really remove it. But let's imagine we will take a look at the back side of the shield. So like a how is it called? I don't know how it's called in English, but those small pieces of paper we wrote when we were in a nex right with some let's
call it tips. So, we have a document here for the wardens. In best case, they know it by heart, but they have a document as well. And on it there's like requests to the world and who is okay to be let in or to use our library or our books or whatever is inside of the causal and who's not able to use that. And yes, this is
basically in the real world it's called CSP or content security policy which is our ultimate false field to try to get inside jobs under control. CSP is basically a HTTP response header that defines where the browser is allowed to load resources from and where not and define some rules to get that set in stone. This is a small snippet how you could do it. The first one
is basically blocking everything. So this one says like we will not be allowing any other resources being loaded or embedded or the other one basically um specifying trusted sources. So in the um castle analogy sister this is nothing we can um configure in plain metal view. So if you only use Vue and nothing else, you need to use your hosters configuration. But if you have next in
place, you can use its configuration directly for example by going by nitro rule uh rule rules difficult word or even easier use the next security module because it gives you the opportunity in its configuration to automatically generate strict CSP headers. So yes, there's lots of ways on how to do it. And I already see we're running out of time. So, let me wrap up real quick. And
let's keep it a little more um general. So, it's not only ovasp. There's a logo. I had a clipboard so I don't need to completely hurry up. So, our view shield. Let's define our view shield. This is basically everything I want you to remember when you go out of our talk and need to wait for me to merge all those sketch notes into one document. So the
first thing is view already has our back in a way. So it automatically escapes some user provided content. But that's not all. So we still need to be the last line of defense. It's still important for us to do our homework. For example, especially when it comes to C XSS cross-ite scripting mind the extra mile. No matter if it's the view HTML directive or href or click
checking, go the extra mile. Sometimes be a little more stricter when it comes to sanitization using tools, stuff like that. Mind your dependencies, no matter if it's in your inside of your build, inside of all the packages you include. And don't ignore dependable. Please, I'm sometimes guilty of that, too, but it's not a good idea to do that. Don't underestimate view router when it comes to access
control, but be aware that it's only client side. Use content security policy and remember that there's a community helping us. We're not alone. There's OASP. They have lots of resources to help us guard our applications. A small other shout out. If you work with you and you see something suspicious or maybe even a security issues, please don't hesitate to contact the team so they can fix it
and fix it for everyone and keep us all secure. And I guess that's about it. The full sketch notes. So everything we were drawing together, I will just merge it into one big um document. So we have actual sketch notes. You can use it as a cheat sheet. Come back in like one or two hours. As soon as I can, I will upload them on the ZQR
code. And if you need something to read while waiting for the sketch notes, there's a QR code showing what I'm working on right now. So, with that being said, my name is Ramona Shraring. I'm a developer advocate at Octa Oville, and I'm so happy to have you here. I felt so secure to do this live thing, which was plainly scary, but you made it worth it. Thank
you so much for being here. Find me somewhere around here on all social media platforms, you know. Thank you so much for being with me.
