Front end Security

Well, our presentation will be an idea with a general knowledge of the purpose. We will talk about Front-End Security. This is Martin, I am Spas, I am a QA engineer, and he is... Yes, let me introduce myself first. As a principle, I work as an Application Security Engineer in DXC. And soon I will be DevSecOps, the word you heard earlier in the lecture. Before that I was a web developer and from there the direction for today's topic comes. Also, I added the next row yesterday, because yesterday I managed to defend the master thesis on information security. And also... Thank you. I am also a member of the foundation that Miglen mentioned earlier, the Foundation for Responsible Disclosure Policy.

and on Saturdays I do web security, challenges online, capture the flag events and so on. Very good at CKF, by the way. God is on cross-site scripting. This is me. I am a professional construction engineer. I have also worked for the agency "Patna infrastruktura" as our new minister asked for volunteers if I would definitely try as a pentester, but that's it. At this moment I work as an automation QA and security has always been interesting to me and I am quite confident that every tester should understand, to have at least a general idea of pentesting, security and all kinds of good practices in this direction. The devs too. Let's introduce What is the content for today? We will start

with what exactly FrontEnd Security represents. Let's wait for the screen to open. We will also present a few errors in the area of FrontEnd Security. and then we will present you some features, for which each of them we will tell what it is, we will present a demo, so you can see how it works, we will tell you what is the impact of this feature and how to possibly use it and how you can test it, most importantly, how to discover it if you have a system. Plus, more additional things. - Okay, good. The evolution of the CoinSite applications At the beginning you can see how the websites looked like on the Internet. We have a static Yahoo page. And then

in today's time, what happens? You open a browser and you don't know what happens. So, at the beginning of the Internet we have static pages. We send a request to the backend, the backend generates this static page, returns it to the browser, presents it, the browser presents it. We have some scripts, but these scripts at this stage, in 2000 and some years, are used only and only to start moving the ads on the site. I remember my first video with JavaScript was a crazy thing. You open a page like this and around the cursor you start to get ants. Here it was, yes. A few years later we entered the static page stage era to the edge-hack

stage era. With the appearance of such massive applications as Gmail, Google Maps, it became clear that this site somehow had to interact with the user. and the scripts start to ask for information, to extract some data from the backend, to process it and to update what is seen on the page. Everything is fine, but at this point, after the scripts are no longer used just to develop a campaign for the site, a framework or a something that all such possibilities and scripts come with. The first such framework is BackboneJS. It uses ModelView controller layers. The controller layer is very poorly adapted. It only listens to some clicks from the user. And nowadays, single-page applications, you

know what I mean, React and Google View, this is an application that There is a lot of logic, a lot of code, fetch data. You can say that the whole logic is presented on the frontend and simulates a multi-page application. And so on. Yes, I will say about some of the mistakes we made regarding security, because as we mentioned, our coverage today will be on these client-side applications. We will not pay attention to any microservices, back-ends or any other integrations. We will host a front-end application and how can we secure only it. And the most common mistake is that if we put validations on the frontend against dangerous symbols, for example, you register somewhere and you don't want to have dangerous symbols for any type of injection, that this

will somehow save the backend. But this actually does nothing, because A real attacker would simply take the application, change it or make a proxy between the client and the server to change things so that it is useful for him and thus bypass these filters. What can actually be done is to filter the data that is loaded into the client-side, because by showing them on the page, there is a very high chance that they will be executed as a script. Another mistake is that these clients with disabilities have no impact and no impact and that no one should take them seriously. And in reality, this can be said to be one of the most insidious disabilities, because it As

shown in the presentation, every cross-site scripting and account takeover, which means it can lead to consequences, to steal a user's account, to control his actions, to extract personal data and so on. And so, here we have another misunderstanding, something that happens to me quite often in my work. Devs work with super modern frameworks, which may We accept that they take care of everything instead of them. There will be filtering, there will be validation. We also accept that browsers will somehow protect us, because we update them, possibly, and we no longer use Internet Explorer. But yes, we know that there are some security measures that we need to take. The question is not only to know about

them, but to really take them and implement them in an adequate way. The three features that we will show today are two of them are more basic and all of them have been known for many years, maybe for 20-plus years. They are Clickjacking and XS . The third one is something quite new, almost no one has heard of it, but even if they heard it, they wouldn't want to hear it because it is quite difficult to explain. We will try to explain it. But starting with the first two, we made a short demo in which you can see how things happen. Clickjacking is a very basic but very popular attack. In the first years, Facebook was

constantly appearing. The user had a screen on which there was a player trying to play the video. The video was not playing. In fact, it was down. and we all notice how our friends start liking some strange things, strange pages and so on. What does the attack itself look like? Here we have a small demo that we need to... Can we play it? What actually happens? A site that has no protection, which we will talk about a little later, can be framed in the attacker site the website we want to abuse in some way, we put it in an iframe and reduce its transparency, we put a button on top, click or click here because you

will win an iPhone or something like that and nothing is on the dosing user. If there is no good hygiene for the use of the Internet, it can click and not know what will happen next moment. Here we demonstrate exactly this thing. You may not see what the red button says. This is a button with which we just demonstrate to delete an account somewhere. Yes, this is a demo account. When you click on the red button, the account is deleted. Here, at the moment, this is an attacker site, in which we frame the site we want to use. In a div we put a button "click me", even though the button is text, and at the moment we

are trying to announce this div "click me" above the button "delete account". Yes, here you can see how the process of this vulnerability is, how it really one site on top of another, but you really see only one and by clicking on something that looks like this intended for the user, you actually make a completely different function. Yes, thanks to iFrame and CSS, miracles happen. After a while, when this button is announced, click me, delete the account, We will reduce the opacity of the iframe, it will become invisible, because at the moment we can see what we have loaded into this iframe, our website. After a while, when we make the opacity 0.0000, nothing is visible. We give this to a user, click me, he will

win an iPhone, he will win a lot of money, and he clicked it, or this is our basic demo. What is the impact of such an attack? Basically, it's a simple attack, but I'll show you a little bit of a hack from HackerOne, which shows that such attacks exist, you even pay for them and they are not small. The idea is to make the user who is not following anything to do something that he would not have done and in this way you use it. You can make him delete his account, share information that he shouldn't share. How can we protect ourselves from such an attack? One option is when we use FrameKiller.js. This is a script that checks if the file is in iframe

and if it is in iframe, we can get out of it, break it. The other option, the more adequate option is when headers are added to the site. One option is with XFrameOptionsHeader, which is my preferred option because these headers are supported by all modern browsers, except Internet Explorer, which is not a modern browser. The other option is when you use Content Security Policy. These are the two options. It is enough for only one of these options to be implemented, so that there is protection from such a type of attack. And how do I check things like a tester? There is a different way. Clickjacker.io is a site that tries to charge an external site in iFrame and checks

if there are any security headers. The second option is with the tools from the BURPSuite and ZAP proxy. I guess most of you in the room know what they are. These are proxy tools, they are used a lot for pen tests. ZAP is free, BURPSuite has a free and paid version. BURP or Bandita is part of the free version. Everyone can check and generate POC with it. Here, clickjack.io site, we have created a famous Bulgarian site, which is in the top 50, even in the top 20, a site where trade is done, which, as you can see in the bottom right corner, it lacks both headers. And two protections. Yes, there is no protection, and since at the moment we

do not have way to say on the site without thinking that something is wrong. Such bad intentions towards them are forced to hide the URL, to blur everything and to talk to you, right? Imaginary. But the site is traded. In recent years, such trading sites have become the object of such and you send messages like "Are you selling this product?" or "One person is selling 5 stocks and he/she might decide to click this URL to see what happens and if he/she doesn't pay attention to where and what it says, he/she might get fired." Here we have another demo with the click bandit from Burp, with it you can generate POC. We used Wikipedia for the demo. BIRB opens, Clickbandita opens, and they just copy JavaScript.

This JavaScript, here you can see that both of them are missing, this JavaScript is pasted in the console, DevTools opens and it is pasted in the console. When this thing is pasted in the console, this bar comes out from above and we are currently in record mode, we save, disable, we end clicking, so we don't click directly on the site, at the moment there is. something like iFrame from above and at the moment we see a generic... - ... on our CSS instead of ours. - Yes, a fork. At the moment, if a person clicks on a click, in fact, on the click on the click button he thinks, the click from below is redirected to some page. So it's easy to validate such things. Here

I have taken out a statistic from HackerOne. It has documents that are open. Here I have taken out open documents in different programs. There are programs on Twitter, WordPress, Yahoo, Melro, in which these are the open documents, which are documented, each of us can go and read them, see them. In every row I have taken out a more interesting document. At the end of the list is the number of the report, you can just go to the URL of HackerOne Reports and read it. There are also reports that have been rewarded with a bounty. This is HackerOne, some of you may not have seen it, I assume that many people are familiar with it. This is a report that can be added after Bounty Hunter

is so vulnerable, the site is fixed, This document is made public if the vendor allows it. And so, if he is interested, he can read it. We come to Cross-Site Scripting. Yes, here what exactly is Cross-Site Scripting? This is just a JavaScript injection. And why is it happening? Mainly for two reasons. One of which is that dangerous functions are used without the appropriate knowledge. The other reason is that sometimes output is applied directly on the interface, which can be rewritten either HTML or JS. A little story, this bug is 23 years old, but it still exists. In the beginning Microsoft coined it and they wondered what name to put it, and then it came to

the name Cross-Site Scripting.

There are several types of cross-site scripting. Based on persistence, there are stored and reflected. Stored is when the injection data is stored somewhere in a backend service or in a database. While reflected is something that is instantly reflected from the URL itself. For example, we have some parameters in the URL that are immediately reflected on the page. Also, based on context, there can be different types. The most common one is DOM-based, which means HTML injection. Everyone knows that there is JavaScript in HTML, and that's where things come together. It's more complicated when it comes to MUTATION_XSS. Here we give it broken HTML in order to bypass some more serious filters. And another thing I wanted to mention are polyglots. These are special strings.

It's not very visible on the picture, but it's a lot of symbols and all of them are intended to enter as many contexts as possible. For example, I test a site, there is a user input and I don't know exactly how I should construct the string. That's why I use such ready polyglots. in order to at least one of all types of contexts to attack and trigger JavaScript injection. So this one in the case of the video I did it myself and it works in 14 contexts. Any kind, for example, to trigger in iframe, to trigger in header, to trigger in script source, any kind. Very good with cross-site scripting. I have to say it again. It is

interesting, because we are presenting today, a little history back, we have tried several times on such programs to add bugs, we have some additions in Red Bull, which do not pay the bounties, but send the tokens. He is very good with encoding and all kinds of JavaScript functions. Can you hear him? I am a good hand, but I can't use any tools, so when it comes to automation, he is the man. This is a demonstration we prepared, in which we have a free site of bSite, which we created. And in this site we have put some cookies. We will try to steal it. Interestingly, there are two rows of valid code that are sufficient to apply cross-site

scripting injection. And what happens? We give it a parameter in the URL, this parameter will then be directly written in the document, which is Reflect Detects, as I said earlier, the types. In case we want to provoke the alert function and it is visible that it works. We will try to alert data already. from the website, in the case of Kuki, which we have already discovered. It shouldn't be available, but it also comes without any problems. Another functionality, apart from calling some alert functions, is to redirect the user to a foreign site. In this case, we just change the location of the page with the string google.com. And this is something successful. What does this help us? By moving users to another site,

we can also provide additional data for the site to see and possibly log in. That's why I made a small Capture server here, which just waits for applications and looks if there is any parameter in the application, it will log it in. After we launch the server, we can now try to send the user's cookie to this server. In this case, it is on localhost, but this does not prevent us from proving that it works. Again, we use the same technique, we use location and we set it a new address, with the difference that this time we add data to the address from the page itself. And now you can see that it is loading

successfully, but what is not visible is that the server itself has already logged in the cookie. In this way, we can steal the user's account. Cookie, session ID, tokens. They are good things. Can I? Yes, you can. what can happen, what is the impact of cross-site scripting, it can extract personal data from users, it can force them to make applications that they wouldn't want, which is the request forger, it can steal their credentials, tokens, but in the worst case, it is always account takeover when it takes the whole account, You can look at cross-site scripting as giving someone a seat while you are logging into Facebook and start to do whatever you want. Only it is automated

through script. Yes, the truth is that both clickjacking and cross-site scripting are super basic attacks. They don't have any impact at all, but if you chain, if you use a combination, the possibilities are endless. Also, every such application The more functionalities there are, the more attack vectors and the more possibilities for exploitation. What can we do to prevent this? First, we should not use these dangerous functions or if we use them, we should know how exactly and if we will use them, always to filter the data that goes into them, as well as to filter the data that goes later to the interface. The most common security mechanism that is built into your browsers is Content Security Policy. This

is quite effective, but no one uses it. Fortunately for me. Here are some of the tools. The last tool is Cross-Site Script Hunter. This is a site that has ready-made payloads, which can be used for blind cross-site scripting. payloads are included in different pools, and if they get triggered at some point, this application can be read on this site. The other two tools are DAOFOX and XSStrike. XSStrike is one of the command line tools. XSStrike was Python, I think. DAOFOX is written on Go. XSStrike is a well-known tool. There are a lot of them, at the end of the day, there are a lot of stars in GitHub. Dal Fox is a new tool, developed by

a Korean, who, in my opinion, is one of my favorite tools. He is very powerful, he can use the terminal, he can be given parameters from something before that, for example, to launch a spider or something, to encode the site, to extract some URLs and then to pipe them to DAOFOX and it will research them. Here we also have a demo, which will show you how to launch an URL. You can just click on it, but nothing is visible. DAOFOX has the ability to It's good to search for parameters in the DOM, it's good to be in the URL, but yes, it immediately finds Cross-Site Scripting, gives a POS, when it's pasted in the browser, it gives

an alert. This is here. So, here I have taken out a statistic from HackerOne. These are public documents, generic cross-site scripts have 881 documents, STORT have 359, REFLEKT have 297 and DOM cross-site scripts have 106. And here, different types in different programs, how many documents they have, these are only public ones. There are many that are not public, we have no idea what the number is for them. But here you can see that, for example, New Relic paid $3,000 as a bounty for the cross-site script. So, this is something I added to my class. Last year I decided that it was boring and I made my experiment to see how many Bulgarian websites are vulnerable to XSS. As you don't ask how long

it took, but I went through about a thousand sites. And it turned out that at least 100 findings were there, which means that 10% of Bulgarian websites are vulnerable to access. It depends on what's there, if there's logic, if there are users, if there's something more dangerous than this script can be executed. But still, absolutely everything was accurate, there are not many answers, not many patches, but this is just proof that this thing still exists and there are many of them everywhere.

The next bug we will show is Cross-Site Leaks. It is a bit more complicated here. It works on the basis of extracting information for the user. And how does it do that? It extracts all kinds of interactions between sites. What does this mean? It means that in the browser Each site has different behaviors, it can be tuned, give error, give the right response, to slow down, to open iframe and each such action gives a little information. For this purpose, oracles are used. Oracles are just two lines that one listens to yes, the other listens to no. And we try to give this information exactly in this way, it becomes binary, yes or no, 0-1. But what can this lead to? This can

lead to learning tokens, to understanding some important information about the user. And it happens in many, many ways. The most common example is for access search. This works as a principle. We frame a site, if we use it and we are tired of learning different applications on it, we don't even need to frame it, but we make the user make applications. And through these applications we track on the basis of time, on the basis of errors, on the basis of everything you can remember, whether this response was returned before, whether it was cached, whether it gives yes or no. And so many thousands of requests can be made which will eventually give valuable information to

the user. And this is? The whole browser provides a rich selection of APIs which provide such information. This vulnerability, which is literally from that day, from 2018 to 2019, there are very few papers about it, mainly from Google, And in the last 20 years we have been living with cross-site scripting and clickjacking and other attacks, not knowing how much more we will... This is a good thing to mention that it was discovered recently by Google and if you can change it, as sources of information can be used. The original wiki, which is at the address of TexasLeaksDev, there are all types of attacks and how to protect yourself from them. And if you want to test your website and see if

it is vulnerable to this type of attack, there is a website called accessinator.com. It can quickly check which type of access leak you are vulnerable to. I have also left a link to a very interesting blog in which the access search technique is used so that all emails of a given user can be leaked through the Google search engine, which is quite interesting. Well, that's all, friends. Thank you.