I think we can start.
So our next speaker is Dheeraj, who is going to talk about JavaScript security.
You should care about that subject, because it's an important one.
And Dheeraj, when he's not coding, he's thinking about food or drinking coffee.
So I guess, as all of us developers, big round of applause for Dheeraj.
Hello everyone. My name is Dheeraj, and I'm very excited to be here.
And thank you all the great organizers for having me.
This is my first time at Fosdame, so I'm very excited.
And today I'll be talking about JavaScript security.
Before we get started, just with a show of hands, how many of you are passionate about security,
or think of security before building applications?
There we go. Yeah. Oh, all right.
A lot of fun. That's great.
I'm sure this is a very important topic for all of us,
and I hope to share some of my learnings.
Just a little introduction about me.
I work with the amazing front-end team at GitLab.
It's been almost more than four years.
And I also like playing table tennis, and I can switch my hand in between.
Just to have fun and winning the game.
And I like to find security bugs with all the applications I use,
just to poke around sometime for fun, sometime for swag, for swags.
Who doesn't like free swags or goodies?
So I've reported some of the companies where I've reported bugs.
I've been doing it for a long time.
This mere alert is something which I'm very much excited about,
and we'll be talking about it in the next slides.
To give you an idea today, Agenda is very simple.
We're going to be talking about XSX, CSP, TEMO,
and some of the initiatives we have been taking at GitLab
to improve our security posture,
and some of the best practices we can follow while building any application.
And as time permits, we will have some questions and answers.
First and foremost, security is important.
Everyone knows security is like an elephant in the room when everyone agrees to it,
but only a few take it very seriously.
But like most of the companies do not know that if their app is compromised,
they'll lose the trust from the users,
and they'll not be able to get too much customers.
So there's a famous saying that there are some companies who have been hacked,
but some of them do not even know that they have been hacked yet.
It's like speeding on a highway where first you get used,
drive incredibly fast, and then you get fined,
and then you start driving a bit slower.
And our primary perspective about security is always about...
The security is always at the back end,
but in this talk, I'll be giving a lot of insights on the front-end security.
There's a little story time.
There have been many instances reported here and there about security bugs,
where one of the popular ones was where somebody was stealing your McDonald's website passwords,
how they were able to...
was just using a reflected XSX, using a sandbox bypass for AngularJS,
and as soon as a user visits McDonald's sites and they type their password,
they were storing the password in the client side in local storage,
and when you visit a link sent by an attacker,
they would be able to use the passwords being stored on the local storage
and send it over to the attacker website.
And another instance where popular WordPress has been hacked a number of times,
where there have been instances where a plugin has a malicious code which it uses a database,
and once it is rendered on the UI with a vulnerable code,
and if somebody was able to log in using admin,
would be able to send a request and create fake accounts.
So it's just like installing a keylogger using just a code.
You might be familiar with this particular application, chatGPT.
Even in that, a known researcher was able to just pass this code as a markdown link
with a JavaScript protocol and it was being rendered and it was quickly fixed.
So we have been talking about XSX, so it's called cross-site scripting.
It's so complex that I have been knowing somebody who has been doing PSD in this particular topic,
and to know more about it, it's very simple when data being supplied to the application
becomes part of your code. In this example, like an image tag with a source which is invalid,
and an honor attribute will help you to add some JavaScript to it.
And the screenshot has an example where I reported about to Uber,
where I just add this particular code to my name,
and when admin sees that this name is malicious, they try to delete it,
and when they delete it, that pop-up will appear, and that was reported using their HackerOne program long back.
So it's more than just an alert pop-up.
It's just a try, maybe.
You can write it through the document.
Yeah, exactly, right.
So the problem here is with the document to write, it's just taking the URL from the query parameters,
and without sanitizing or escaping, it's just putting it in the DOM,
and which can actually lead to NexusX.
So how do we fix or how do we protect this?
So we have to analyze, inspect all the places where DOM elements are created,
and there's a famous attribute called innerSTML function,
which should be actually avoided at all,
and to prevent these bugs, we can also have a linter rule to be placed
so that these sort of vulnerable functions are not being used in the code base,
and like famously, we should just do input sanitization or output encoding.
We'll be talking more about it.
Then we have on the client side, we can have multiple flags.
We can help you secure the cookies.
So there's two flags, which I would like to mention.
One is secure, which will help you make the cookies, which are sensitive in nature,
are always transmitted over STTPs protocol,
and there's something called STTP only.
It doesn't even know what its STTP only flag does.
It cannot be accessed by JavaScript.
That's correct, yeah.
So this is something you might see for all the session cookies we have on all the applications.
This will make sure that even if an NexusX bug happens,
it will not be able to read the session cookies data.
Or the cookie which has the STTP only flag data.
At this point, I would like to show a demo.
Maybe I can just show a demo rather than a screenshot.
I thought that would be fun.
So this is a vulnerable application,
which is a secure site.
And if you try to do like a hello world,
you can see that it's a hello false name being displayed here at the bottom.
And if you try to enter any HTML to it,
let's see if it does render or not.
And with just an underlying tag, there's underlying being rendered.
So that gives a hint that it might be rendering HTML.
So how about we just add the code which we have been seeing like as
a maze tag with invalid attribute, invalid location, and the honor attribute.
So it just adds a prompt or an alert, but this is again not really harmful.
So we can try to read something like, like this is the website's name.
And we can also try to have local storage data.
Oh, here we go.
So it's like you can read the local storage data which have been
stored on this particular website.
So to talk more about the code base, which is making this vulnerable.
So in this, this is react application where you can just see that there's
a piece of code called dangerously set in an HTML.
It's a variant of, it's a variant of inner HTML for react.
And it can be harmful.
So actually it's not even needed here.
So, yeah, please go ahead.
Oh, sir.
Yeah, sorry about that.
So, so that, that was the code which was being vulnerable, which is being used
to render the data.
We put it in the search bar.
But if you want to fix it, we could just, you know, remove this and just
render it directly because react view such frameworks does escaping by default.
And there is no need to render HTML.
And if you just try to save it and refresh it.
So it just tried to render exactly what you write in and not render the HTML we have.
Right.
So going back to the slides.
That was backup.
Like if the demo doesn't work, I can show some slides.
And yeah, so like I mentioned, it's the dangerously set in an HTML should,
can be avoided here.
Very possible.
And if it's not possible to avoid it, what we can do is like add some sanitization to it.
So tool of rule of thumb for, for, for preventing such issues like first of all,
never trust any user input you have in your application, wherever the user input is
coming through it and avoid such inner HTML variants like dangerously set in an HTML,
V HTML for Vue.js and always sanitize your input and escape it wherever possible.
Though the framework like react view will do it for your automatically.
And there's also things like links, links must be secure by default.
There's not something browser does it and not even the frameworks does it for you.
And then the ESLint or similar linters can be used to prevent that these functions cannot be used in the code base.
Then the next we'll be talking about content security policy.
So it's like an advance or defense in layer, defense in depth layer mechanism where,
which allows you to restrict your website to load certain resources.
And you might have seen this error in the console when, whenever a malicious content is being loaded,
it will prevent and throw this error.
I can, I can just show how content security policy can fix this particular issue.
Let's, let's go back to the code base and just,
so this is the vulnerable code.
And, and if I go to his index dot HTML and try to add this meta tag and just write that we only want to allow certain script from the self self means the same origin.
And if we, if you try to refresh it.
Maybe I did not save it.
Yeah, so, so if we go to the console and I zoom it, and if you can see that the,
it was being refused to execute that in line event.
And that's because we have added to, to allow only the scripts from this, from the same origin.
That was an example to showcase that.
So content security policies is really very defensive in depth measure by browser and can be applied for all the web applications.
It can help with cross-scripting attack like what we show, what I showed in the example.
And also being helpful with secure form submissions that it should not let your form being submitted to any STTP websites or to prevent MITM attacks or STTP as migrations or mitigating vulnerabilities like click jacking.
This is how the CSP added can be added like what I shown.
This is a particular code for Node.js helmet framework.
And what I shown was the meta tag.
So it could be done with any of it.
Like another example where content security policy where it can be prevented.
If there's example that it only allows resources from example.com and if somebody tried to request malicious.com website to load some JS, it will be prevented.
And other security headers which can be helpful and can make a note of its X frame options.
It is also helpful to prevent click jacking vulnerabilities.
And HSTS is strict transport security for making sure your website is always accessible over STTPS.
Then we have access, X protection, X content type options as well.
These are generally being part of all the frameworks you might be using the modern browser frameworks are always having secure by default having these headers.
But if you're not using any framework and going for a vanilla thing, then make sure to have it them.
And now the interesting part like I would like to share some insight what we have been doing at GitLab and how we have been improving our security posture.
So first and foremost, it's everything we try to do make as much as public.
So that was something we decided a couple of few years back that we should work out upon improving our front end security posture and taken note of multiple steps.
We can take it forward and firstly and foremost what we did was we have VSTML very similar to dangerously set in an STML in React.
We built a safer version of it, which is V safe STML and V safe STML is basically remove the malicious part from the scripts.
And how we are able to do is using an open source known sanitizer called Dom purify.
We try to apply that sanitization to all the input we get VSTML and then we say FSTML and we just render it.
So and also we have added a ESLint rule to our front end code base that nobody would be able to write VSTML unintentionally so that we don't really forget about it.
And so far is doing good.
And then we also made an effort to make sure that our link component which we use it GL link renders links safe by default so that we don't have to developers don't have to think about writing secured code.
The component does it for them.
In the GL link, if a malicious link like JavaScript protocol will be just set us about blank or null.
And then it was interesting story about iframe sandboxing.
This is a mechanism where you can contain a third party module.
We have been using a third party library to render charts and it we like it lab can allow you to add charts in the comments notes description everywhere.
And and if there is a vulnerability with with the charting library, it would also impact it lab.
So what we did was to contain the entire execution of the charting library inside an iframe with this with sandbox and do not allow any cross origin request.
And we implemented this and all the issues with the third party module were just fixed with the one simple fix.
And applying all these defenses actually helped us reduce front end security policy. This is one of the instance where we were getting a lot of reports on our hacker one program and applying these defenses has helped us to make the security issues come down to.
Manageable numbers and they like you can see in this example in the graph that the issue got increased around some of the time in November 21 and then we applied these defenses and the issue dropped very significantly.
And I'm sure what we have been doing nowadays also it's keeping the numbers low and we try to keep it to us. We are trying hard to keep it more lower than this.
So to get an idea like how how do you improve your security posture is like just try to shift left integrate your.
Such thing into HDLC your software development lifecycle adopt secure by design principles so that developers don't have to think about it and just use the make sure they come component you're building or framework you're using has though all those secure by a default design.
And you security middle middlewares don't read when the wheel and build your own framework or things like that. So helmet jay's is popular one for node jay's and use standard sanitizers again like Dom purifier is doing pretty good job.
And then if you want to audit your vulnerable packages sync is a nice tool and NPM also has a audit functions which can use.
And there's some learning resources I found it really helpful which is Stanford CS 253 scores and my favorite one is over at developer guidelines where it keeps updated with the latest attacks and the vulnerability information and Hector one Hector one oh one is also a nice way to learn about security.
And anybody plays CTF or nice yeah I love CTF so it's the way to learn about security and and we have also have secure coding guidelines which can be followed to learn about these stuff.
Thank you so much for listening me out.
If you have any questions I'll be around or if you have time.
We have time for questions.
Yeah so it's not always.
Yeah so I'll just try to repeat some of the.
So what are the options when we are not possible to set X frame options as a deny.
Sorry.
Yeah the question is all about if if your application is not able to use X frame option as a deny.
Some of this applications might share that I frame being used into the website.
So I think one of the option is making sure them to use content security policy because it can actually allow the vendors who are using the the I frames on their website would only allow that.
Content security policy is one way otherwise.
I think that's that's way otherwise if you want to.
Build a more advanced mechanism there would be like I frame post message communications which can allow you to you know only do secure communication with the I frame.
Yeah I would love to know what you think about that.
I would love to know more about this so that I can give more better answer to it.
Any other questions.
I will.
Can you.
Can you.
Ah this question is about have you looked at new firewall mitigation to fix these issues.
To be honest no I have not known a good firewall which because that's something.
Needs to be trustworthy and stuff like that and all only worked upon like operating environments where they have installed a firewall for all the systems.
But this this was more about like how general developer guidelines.
Anyone else.
I have a question.
Big I love you guys.
Thank you.