Web AppSec 101

Hello everyone, thank you for coming here at 10:15 AM. As I said, this is a Beginners section, so maybe some of you already know it. There is an Advanced section. Let's moderate expectations. I will tell you something about myself, and then I will tell you what the answer will be. Even if you are not interested, you first listened to me, and only then went. My name is Andriy. I used to work with Python programming. I sold my first programs at school. But then I got tired of it. I found this guy and started doing application security. For a short time we have successfully broken all kinds of banking applications, trading platforms, insurance applications with Fortune 50 on the list,

security providers, mailing providers and all others who can take something interesting and give it to someone for money. But we are good hackers, we help We break it, we say, "We did this, we can fix it." To be honest, the plan of the answer is here. This is the plan of the answer. If you think you know a lot of things, half of them, then this is not your path. To be honest, I give you 30 seconds, 10 seconds to understand what Okay, everyone is here. I won't be offended if I'm honest. What are we going to do? I'll tell you some basic things about how to break something in WebCheck. Does everyone know what pen

testing is? Who knows what is web application security? Who knows what pen testing is different from web application security? Vova. In short, there is a word "pentesting" which means "test for penetration" and in pentesting we also distribute flash drives under offices so that someone from the employees can get into their computer. In pentesting we write all sorts of scam emails and say: "Here, I honestly answer, I am your accountant, I need to transfer this money urgently". In pentesting we also assess the security of the networks, In the potential we also run tools that don't work, scan them. There is also a thing called web application security, which is also done by pentesters. This search for

fraud is almost only in applications like this. If you have a bank add-on that checks bank fraud, we say, "Okay, let's see what we can break here." And for the networks, there are some guys who are doing well in the network. And we will do well what we can, and we will be all the inputs that we find. If something goes wrong, we will bring it to mind, we will check you, show a cool demo to your SEO, and everyone will be happy. So, there is a lot of information about what is there, Web Vulnerabilities, I will not tell everyone. I tried to do it this way, to make it so that a very smart

QA could listen to it, then look at all four links, read them and start doing something in Application Security. I hope you will need it. If there are guys who are very advanced and they will tell you about XSS, and you will say, "No, we know it, let's do something more, you tell us, maybe I'll tell you some other cool cases that I saw from work with other things." So, let's continue. So, to do something in Web Application Security, you need to know a few very simple things. This is how the HTTP protocol works. Who knows how HTTP works? Ok, it works very simple. Spoiler alert. You need to know some basic HTML, because it's a web. Any

programming language, including some basic JS, because if we do XSS, we need JS. We almost don't need tools, except for the browser. any proxy utility, that is, you can set up a proxy in the browser, you can set up a proxy in the system if you are a masochist, or you can use the proxy proxy plugin or any other very simple one in your Chrome, Firefox or maybe Internet Explorer to make a proxy for you. I will use a tool called Burp Suite. It's a broadcasting proxy. Everything you broadcast online, first passes through this Burp Suite. And you can change everything you touch there. There is a community version, it is free. There is an enterprise version, it costs $ 250 per year,

but it is also free if you find it in the Burp Suite Telegram channel. The problem with security is that people don't know about security. For example, a common case of a company that develops enterprise software is that we still don't know anything about security, or we use encryption, which means that we have security. Everything else, we use Amazon, so part of the risks are taken by Amazon, and we are programmers in the USA. The biggest problem is to bring to management that security is needed. And even more problem is find normal vendors of this security that won't come, won't run some scanner with web interface. If someone has security chat, it's enough to have security chat. In short, those who won't run any scanner, they will

say, we found you 5 times, we found another scanner, we found two more, you have so many thousand dollars, now you are secure. And they put such a logo on their website, like, "HP Web Inspect Secured". So, I will talk about how to do it manually. There are automatic tools, they don't work at all, but there are nuances. The first problem that you can find without even opening a browser is a faulty configuration. Most of the problems are not important and you will never get the management or the people that it's bad. For example, you have dozens of open ports. You don't know what kind of ports they are, but they are on the Internet,

they are open. They exist, but you can't say if it's bad. If there is a port and you don't know what it is for, you close it. It's very simple. Because, for example, here's the second problem. It's default passwords or password-referencing. For example, you have a backend. It has several tools that run there. For example, focus rabbit MQ. It's on the backend and it doesn't have... no access to the outside world. So, the answer is, we will make a default password, because to break RabbitMQ with our default password, we need to break our server, and if they break our server, we don't care about that RabbitMQ. But few people know that RabbitMQ has a port that sticks out by default.

If there are default login passwords, and we have a port that sticks out, you can go to your internal queue and see what your application is doing, you can modify something in this internal queue and see what can do something bad. There is even an open source project that just scans all RabbitMQ ports in the world, all 4 billion IPv4 addresses and sends you letters, saying, please close, you're stupid. There are some backup files on all servers, there are some gits, svn folders, and not all of them are closed by default. Someone can go to site/.svn and nothing will happen, because it's just forbidden. And then someone will go to .git/headers And here we have a file with git headers. And

then we run the loop that is like a git. in the test it doesn't save the name of the file. Someone can access the file only if they know its name. But Git doesn't save the real name, it saves some coding. But it's only half random, it can be decoded. We had a similar setup at a conference, we had a CTF, we needed to break the site. The website was written at night, there was a normal CTF, we threw in the CTF, and I just did a command line, like, "cp" and the site folder to the server. And since the git folder is hidden by default, I didn't notice it, it copied, and then we solved the whole CTF, but with the

wrong key. I asked him what the hell was going on. He said that there was a Git folder, I hacked it and got a discount of 500 hryvnias for a ticket. The site was writing at night, there was a normal CTF, we threw CTF in, and I just did a command-and-correct, like, "cp" - the site folder - to the server. So, there are such problems, and I'll tell you why later. There are bugs like that. Default features. The same problem as with RabbitMQ. You have a big framework with 10-10 features. They all do something. No one knows what they are doing. One of them will be posted on the Internet. One of them will be

outdated. You will be hacked. The same thing with the ports. If there is something you don't use, you close it. Why? Because it's necessary. The management won't understand, you can explain, but in general, it's a rule that you have to follow. If something works for you, and you don't use it, you delete it, close it, make some restrictions. A cool thing is that we have websites on the Internet, and we have some dev server, staging server, where QA or developer tests what's going on. So, the bigger the number, the less it's protected. You go to "dev" some size dot com and you see some dev environment, some layer, some test features, and some smart hacker finds problems in what developers

are developing, what about release, what about QA tests, they make some XSS injection and then they drop devs' keys, hack their computers, because they don't update either. I have Windows XP and I think it's cool, for example. Any staging environment, testing environment should be closed, at least with basic HTTP authorization. This is the easiest thing to do. Next security header smithing. If you know what clickjacking is, we'll talk about it later. There are a lot of headers. that are responsible for the security, for how the browser will behave with the site. So there are cool security headers that can to use any JavaScript, except for this one. There are headers that say, "No, please don't insert us into

your site, into your iframe, into any other site." There are headers that say, "We have a certificate on the site, please use it only, and nothing else." So, if you wanted to hack NSA, and Google bought your certificate, and it replaced your certificate with another one, then still nothing will come out of NSA, because you're smart, they're not. Sometimes we use random programs. For example, when we generate a new password for a user, or when we receive SMS with confirmation that we are a person, please enter the authorization code that came in the SMS. In order to do this, and to avoid collisions between users, they use random programming conditions. And here's a surprise: all default functions of random programming conditions are not secure. That

is, knowing a few outputs in this function, you can predict the following consequences, and sometimes even the previous ones. If someone uses a Java.util.random code to prove that it is secure, it's all bullshit. We've seen this in the generation of passwords, in the generation of secret links, in the generation of PIN codes. Don't do this. Do you know what it is? HTTP only security for the RUK. We'll talk about it later if you don't know. And the most popular feature on... On small applications, which you have uploaded in your laboratory work in Univeri, for example, there are about 20-40 dependencies, that is, libraries, modules, and other things. On enterprise applications, there are 200+ dependencies. And with some

probability, half of them will be in the future. So, you need to check if there are no new flaws in your application. How to do it? You take this site or this site, enter the name of the component, the name of the library you use, and check if there are no flaws in it. your current version of some kind of visibility. It's very simple. There are two autotools that can do this for ISPnet and Java. This is dependency checker. And there is a RETIRE.js that helps to find a visible LIB for the frontend. But they only find a part of lib. They don't find anything else, because there is a library base and a database of the

information. And there is no direct linking between them. So you won't be able to create a very simple autotool that will check for these sites, whether there is information in your libraries. So we use these and these and other buttons. Who knows what it is? What I said before, there are features. For example, Apache and other web servers have features like What is it? It's for example, if you want to go to FTP, it's very convenient to go through the tags and files, for example, to load something. There is such a web interface. You go to the folder, site.com/ Shared files, and it's all good, you don't need to code anything, just open the directory, you can go through the files, load them, it's very convenient. Very convenient

when it's not your configuration files that for some reason remained open in this format. This was a default feature of many servers before. Now it should not be default, but it can be opened through the handle. Your output code, configuration files, passwords that someone keeps in the open config file form can be opened in this way. How to check it? You can first google what server you have, see what default folders are there, try to go to them. There is GearBuster, which just takes all known default folders, passes them, but sometimes puts a server, so use it in staging environment, not production. Burp Suite has a lot of plugins. One of them checks if there is no browsing directory somewhere.

Click-jacking. We said there is iFrame. Everyone knows what is iFrame, right? I hope so. iFrame is a thing that allows you to insert a piece of your site into another site. If you used a payment on some sites, it is almost always iFrame of some payment system. There is a rule that if you have a payment on the site, that you don't have to be inserted into another site, you add headers like iframe, it's forbidden. Because what can happen? For example, you have some bank add-on, right? And there are some Any other add-on, it can be a game or a form of registration on the left site. We take the left site, some community gate, we take the site, some form

of registration, and since there is iFrame on your banking application, we take the banking application, insert it into iFrame, on the top of the site and make it transparent. So you go to the site, click on the buttons, for example, enter some login and password that does not correspond to one resource. Enter the login and password and you think that you are doing it on the site. On the top of the site there is a transparent iFrame bank. And you click something. Another variation of this thing is when we have a game on the background. Some flipping bird or something like that. You need to click buttons, check your reaction, share it with your friends on Facebook. You need to quickly click buttons, drag something. And in

fact, there may be some kind of banking application or something else. You remember when you go to Facebook and there is a public that you definitely didn't subscribe to. Or VKontakte, it doesn't matter. You definitely didn't subscribe to it, because it's some news. You don't know what happened. What happened was that you went to some site, and there are buttons on top, like "I agree to continue", "No, I don't want to subscribe to you". And there was actually this Facebook plugin, like "Subscribe". You thought you didn't have to make this ad, but you really didn't have to subscribe to the news. How does HTTP work? I think everyone knows HTML. There is a simple form. On some bank site,

change the email. We have a new email that we are running and we press save. Here is the HTML form that gives the bank site, input email, value email, input ID user, and value ID user. What can be done wrong here? Who knows? I'll teach you. How HTTP works. I think everyone knows what HTML is. There is a simple form. We will replace the type with another. What will it be? Here is the handle. What can we do? We have new emails. Yes, we can replace the ID. There is a possibility that developers will not check on the backend what ID is being submitted. We have it written that we have ID 123, we press F12 in the browser

and change ID to 124. If the backend is not checked, or there is an input of the user, you can change the email to another user. But we have smart developers, they made JavaScript, which checks that you haven't changed anything. It would seem secure, but here we have an email, we have an ID of the user, and we have JavaScript that permits him to change something. And here? Well, how does it look? You know, we have a question in the feedbacks, what happens when you click on, like, Searching in Google. You can remember it next time. The user clicks on the button. But from this output form, where we have two inputs, this is an email and an

ID, there are many more pieces, because the browser adds to all requests, adds some of its own service headers, adds headers that are needed for the server, adds cookies, including authorization cookies that allow you to find out if it's a user or not. And there are other things, and it makes a request. And, in short, from this, yes, it It looks like this. We have HTTP protocol, post request, host, cookie, content length, connection and all the parameters we submitted. This is what was in the form and what was added to the browser. The thing is that everything that is displayed on the browser or the user is not important. If a programmer or someone else tries to make

a security validation on the frontend, validation on the user's browser, it doesn't work. I think some of you know this, some don't. Never do validation on the frontend. It doesn't matter because then we take our burp suite, overhanging proxy, modify what we had with JavaScript, checked that there was no modification, JavaScript worked on the browser, we take burp suite, redirect the request to burp suite, modify 123 by 124 and change the password to another user. It's a very simple bug, even stupid, that is, you can't check which ID's will be submitted to your server. You can't check which users you are changing email, password. Who does this? It's a stupid mistake. Hey, where is the slide?

Aha. Who does this? These guys do it. On Yahoo! there were about a million comments and posts, because you could just type an ID to the post and then delete. Apple had 300,000 personal data of third party developers because of the same thing. Facebook, VK, Instagram had a real random, you know, there is a link to a photo, and there is some random.png. It was not very random, firstly, and secondly, it did not check whether the user is a user. And just if you guessed the sequence, you got a photo. We had a case when guys stole their accounts from a company called Fortune 10. They started sending scam emails saying "Look, we have an account, here's your

CEO's signature, pay me one more." And you see that the accountants in the companies we contacted did not receive money only because the date was extended for two days. They say that here we have a contract on March 1, and already the third. We need a new contract. CFO, what about the contract? Have we finished it? Do we need a new one? If the date was the same, if she opened the list on the same day, she would send the money without any questions. And there are big money, because it's a big supplier of something. And we found out the names of all the companies that sent this scam, because these hackers, when they generated their

PDFs with accounts, they just made some ID's, and we just copied all the ID's, got the names of all the companies that were exposed to this kind of data, and then informed the developer of this software, that look, here is the problem. You have lost your data and you are not being sent any emails. And the same problem, you know, we have a captcha to check why a person is there. And everyone submits a captcha, they press "register", but there is such a thing when the captcha is checked, but it is checked only on the frontend. And after you have taken the captcha from me, it says, "Yes, he is not a robot", a normal request is sent to the client, only without the

captcha. So, we can just take this request, generate it and run it again. This way we break the anti-automation that was on the site. Another problem is related to the previous one, the mass parameter assignment. If everyone knows, there are MVC frameworks, who knows? Wonderful. In short, if you don't know, imagine that not all sites are written on PHP. PHP also has MVC frameworks. The idea is that we make a model of database separately, make some view, like our HTML files and generation of HTML files to frontend, and make some controller that processes user requests, does something with them, takes something from database, takes a template of frontend and sends something back to the user. And here we

have a problem, for example, we have a database model, we have a model where there is a user, and the user has an ID, the user has an email, for example, there is some status, whether the user is blocked or not. Here is such a database model. We have a user request, the user changes the email, we remember our previous form, the user just changes the email. Email equals email, dog email dot com. And sometimes, to save time, developers, instead of submitting just an email, say, "Here's an email, here's a user, let's find out who this user is, let's take a cookie, let's see what a cookie ID is, let's see what a user is

from the database." They just say, "Well, we take everything that the user submitted to us, we throw it into this model, and the model will figure out who it is, what kind of user it is, what ID it has, whether it is hacked or not." And sometimes we can also find an ID through this thing. If you work with MVC frameworks, you will understand that sometimes if you just go to the site and there is an email, it does not mean that there is no ID or anything else. If you hack a site and see some fields, you can add and invent some other ones that might exist and test this visibility. It can be difficult

if you've never used this thing. Let's move on. So, this is... Who knows what this is? Oh, come on, guys. Yes, this is a tale about the red hat. There was also a tale about the wolf and seven goats. A tale about the fact that you can't trust the frontend. They say, "You saw your grandma and you say, 'Something's wrong with grandma'" "No, everything's fine, honestly" And you say, "Well, okay" You can't do that. We learned that since childhood, but then programmers grow up and do it. They weren't taught fairytales. Well, we don't do decision making on the frontend. We never trust any user input. Anything that comes

Here, we as developers or security engineers think that everything that is here can be bad. You can put a quote everywhere, you can put some ID everywhere, you can put some amount everywhere. Everything that comes to the server we consider unsafe. We validate the parameters, that the phone number is similar to the phone number, the email is similar to the email, there are no quotes, and only then we process. This is the general rule. Why does it turn out that someone is trying to check the ID of a sub? Because, first of all, we are all people and we make mistakes. We can forget something, make something easier, we can be a genome and just not know that we can't do it. That's the first problem. The second

problem is that there is a management that says: "No, guys, we need a deadline, our customer should be happy, please, let's do it, and we'll get there as it is." Friday night, for example. This is a classic situation. That's why it's a stressful environment, mistakes happen, someone forgot something, someone didn't know something. It's normal. Even companies that have a lot of developers who do something, a lot of security engineers who check everything, even they have mistakes. We saw Apple, we saw other companies. It's normal. Everyone has mistakes. Even if You think that there is some cool project, you go to some HackerOne, see some cool project and think: "No, all bugs have been found, I will not find anything"

Not true. There are always bugs, you can find them, because people write programs. People make mistakes. That's all. A little bit of other phrases. This thing is called CSRF - Cross Site Request Forger. What is it about? We have already said that the browser to our request, adds a heap of everything else. We have control, as users of mouse clicks, we have control over only a certain part of information. Everyone knows what a heap is, right? It's a part of information that is stored in your browser, which you sent to the site. Cookies are used for authorization. Almost everyone uses cookies for authorization. There is some authorization token which is sent to the browser. So,

how does the browser work? To every request that comes to the site, the browser adds cookies on its own. Without asking you. It's normal. Everyone does it like that. This means that if we force the user, somehow force the browser to accept the form, then it will add cookies to it. If it will be a form of transferring money from one bank account to another, and we can force the browser to create it and click on it, then the browser itself will add cookies to it and authorize this request. Right? Is that clear? In short, the browser sends cookies, cookies allow to authorize users. If we force the browser If we create a form on another site, for example,

there is a bank site, it has a change email, an email and a save button. There is an HTML form. We take this HTML form from the bank site and copy it to the funnycats.com site. And on the funnycats.com site we take JavaScript that says getElement and click. We press submit forms. And it will work. And the bank's website will change to email. Because we take, like, the site is there, it is there. The input is there, it is there. The click is happening, it is happening. The browser adds cookies. And this is an authorized request to the bank's site. And the bank's site does not always understand, like, where the request came from. And all that. For this there is... No,

back. For this there is such a thing as anti-CSRF tokens. These are such random tokens that together with this email, where is it here, with this email, are submitted to the bank site and the bank gives out these tokens and says, "Okay, I made a random token and put a random token here as a hidden input." Only I and the user know about it. If KUKA, email, and a secret token that I haven't issued are submitted to me, I can conclude that someone who made this request has seen the bank page for a specific user. And no one else. Okay. Yes. Who knows what XSS is? For those who don't know. Yes, everyone knows what JavaScript is, right? It's a

programming language used in browsers. You can do something with the help of JavaScript. XSS is when you do something with JavaScript, but not as developers wanted. Let's imagine a very simple example. XSS is JavaScript syntax that somehow appears on our site, and we didn't want that. The most classic example is a site. We have a form of search in the site. We say, "Search, please, ASD." And at the end we put in quotes, script, alert, hacked script. If developers didn't try, they just take what the user has sent, like ASD, and say, "Here, please, the results for your ASD." And then they make quotes, "Yes, yes, script, alert, blah, blah, blah," and in this way they put JavaScript on

our site. Those who know it, know it. Those who don't know it, understand it. Good. There are different types of XSS, for example, users come to us for a link and they get something. We have a board with comments, with some feedback about the product. And we say: "The product is very cool, alert, hack it." And if the input is not processed, it gets into HTML and somehow gets into the user. The second and third types are when we somehow submit something directly to JavaScript frontend. For example, JavaScript frontend is somehow processing part of your input, and you choose it and break the syntax not from HTML, but from JavaScript itself in HTML, and do something

bad. What does it mean? As I said before, the entire input from the user is bad. Everything that the user submits, we either check that it is as we want it to be, and even better, before we check, we additionally sanitize the input. If there are any quotes, we make them with quotes, not quotes, but HTML entity quotes. End, blah blah blah, dot comma. And we filter the whole input and never, never, never use the filters we wrote ourselves. Because, in practice, filters that developers write themselves are bad. In 99% of cases. Because, like, developers see, "Okay, there's a text script, we need to delete all the text scripts." It takes, in short, deletes all the text scripts, and what remains of it? because

it did it not recursively, but once. It says, "Okay, we take it and recursively remove all the tags and scripts because we don't want JavaScript. And we don't need JavaScript to execute JavaScript, as it would sound strange. We can put JavaScript, for example, in the tag image. Make an image, onError, alert1. That is, the image of the srk.x does not have such a resource as x, so the onError scenario is performed. There is alert1 or there are my cookies. He says, "Okay, everything is forbidden except for links, hrefs. We can insert JavaScript into hrefs." In fact, if someone ever hears that someone has written their own filter or someone asks to write their own filter, never do it. Never. Because, in short,

what filter do you write on this? All these scenarios throw out alert.xss. All of them. And you can't sanitize it properly, really. As a proof, the last XSS I found looked like this. No tag. The conclusion: Nikola doesn't use his own filter. All the input that comes from the user, we sanitize it with HTML entity. Who knows what a SQL injection is? Who knows what a SQL map is? Does it work? Very briefly, we have a database. One of them is SQL database. You can send requests there. For example, when you look at a photo from Instagram, it does something like this. You know, photos from Instagram have some secret name of this photo, randomly generated. And it does select, where the name

is secret, equals the name of the user. Injections are very easy to use. Instead of this ID, we say: "Please, give us a photo where the name equals the name we submitted and true". Since the condition is either true, it will throw all the photos out to us. Because it looks like either our unique ID or true. True equals true, so let's submit all the photos. I see that almost everyone knows what SQL injection is, but who knows how to deal with it? Let's start from the hands. Screening through SQL parameters. Screening through SQL parameters. Okay, what else? Parameterized queries, there are also ORMs, right? So, there is this thing. If you go to, for example, a Microsoft SQL Server

or some Microsoft or other ORM, you go to the developer's site of this ORM and there will be something like: "Everything is safe except this, this and this." Not everywhere I-square or ORMs sanitize data. There are several parameters, like like parameters or others, where they do not sanitize it. There are cases where the sanitizer breaks. If we use some parametric queries or ORMs to avoid the user submitting us quotes, we read on the developer's site where it doesn't work. And where it doesn't work, we check the parameters additionally. In short, SQLinux is not often used in new projects. It can be found in old enterprises that have money on security. In new projects, SQL injection is very

rare, but it happens because even if smart developers use parameters like SQUARE and ORM, there are several local scenarios where it doesn't work. That is, the search scenario in the visibility, if you know what is SQL syntax, if you have access to the code, you look at the developer's site where the sanitizer doesn't work, look for it in the code and see if user input is submitted there. If user input is submitted, we do SQL injection. Yes, that's what I said. OS command injection. The idea is the same as with SQL injection, but a little different. For example, we have a website that processes video. We, for example, submit some mp4 video there, and it returns a gif. It would be a very cool

service, right? And all these videos, photos, whatever else, it's processed not on the frontend, of course, it's processed somewhere on the backend, and To simplify the life of the developers, they take a command line and submit it there. There is such an utility, ffmpeg, which processes the video. And instead of somehow twisting in the code and connecting libs that process the video, they just take a command line, take ffmpeg and say, "Do zmp4, do a gif for us." And what if we do, like, ff... The command will be, like, ffmpeg, parameters, parameters, parameters, user... user-video.mp4 and we create a file user-video.mp4 and delete the entire file system. So, there is such a thing, I've encountered it with ffmpeg, I've encountered such a

thing with ImageMagick, it's a tool for processing requests and it's often used to simplify your life. If you have access to the core code, you take the code, you google the programming conditions, how to call the command line, Search the code of this command, if you find it, check if there is no user input. If there is, try to do something bad. Everyone knows what DDoS is, right? Where a lot of botnet attacks someone and just kills him with the number of requests. But smart guys do not only DDoS, but also the thing called Application DOS. DOS Denial of Service. Our goal is to make sure that the application is in place and does what we want without sending too

many requests. For example, a long time ago in Java you could submit %00, which is 0 byte. 0 byte, if I'm not mistaken, is the ending symbol of a file. A line or a file? Pythonian. I'm Andriy, I'm a Pythonian, I'm not ashamed of it. So, this is the ending symbol of a line that was once there. in the programing of readymove and when your java compiler sees such an input get_page_0byte it tries to process it and "Op, 0 byte" the line is over and what to do is unknown this is a syntax error, it drops, the whole server breaks This is almost non-existent, it only happens if you connect some kind of libs in your Java and submit a user input. Maybe the server will just fall

from one symbol. Other examples that I've seen in real life, by the way, not once, we have a site that gives us a picture of a cute tits. And the site asks you to tell it what width and height you need to take this picture to give the picture we asked for. For example, we have a request: "cute images" - give us an image of a cute puppy with a width of 100 and a height of 100. And the site generates from its lib this "sutseniatka" with a width of 100 and height of 100. Obviously. And we say, "Please give us a "sutseniatka" with a width of this and height of this." If the developer has escaped, then the backend starts to generate an image of such an

expansion. And it, for example, ends the operative memory after 10 requests. And it falls. For example. Another case, almost the same as the one I've seen, is a website where you can insert an avatar. You insert an avatar and they ask you to cut it as you want. You cut the avatar and click OK. And an input is sent to the site. Like, width 100, cut, save image, cut, width 100, height 100. And we say, we have an image that we will submit to our avatar, please, cut it with a height of this and a width of this. And in this case, as the image is stored on the server, we can not only save RAM, but also disk space. That is, in such a case,

the guys could just put the server, save a hard disk, save RAM, just submitting a dozen of such requests. There are some other things like that. If you see some logic and you see that you can put something that the app can not expect, do it. If it's legal. Open redirect. Who knows what open redirect is? Okay. For example, we care a lot about our users. We want users to go to to our site, page 1234. But the user has unlogged. He needs to log in again. We will redirect him to the login page. But through UX, to make it comfortable for the user, we redirect him to the login page. He inserts a login password. And

then we redirect him to where he came from. So that the user does not come back to all the scenarios on the buttons. It looks like this. For example, user example.com login redirect to page 1234. What if we insert something else instead of page 1234? For example, if we insert a redirect from example.com login to example.com. We press it and see that the user has logged in and redirected to example.com. What if instead of the letter L there is a large letter I? No, in short, instead of the letter L, the letter I. It looks the same, the user redirects to the site exampleie.com. And we bought the domain exampleie.com, copied the design of the site and say, you have a wrong password, please

enter it again. That is, it looks like this, the user clicks on the link we gave him, he goes to the real site, for example, a bank site. and then they enter their data and get redirected to the action they were on before. But we crafted this link a bit and put our link and redirect it to our site, which is very similar to the site of the bank. And we say, user, login and password are wrong, come back again. User clicks again, we remember the login and password and then redirect it back to its site. So, from the user's side, he just forgot the password, made a mistake with the key, sent it again and found himself on the site. From our side, we deleted his

password. Pass traversal. User wants to get his image, a photo in Instagram. Sometimes, if developers forgot, they do something like: "Please open the file that is in the folder name, for example, user images." And there is a file name, some "my favorite picture.png" If the developer opens this image, we can do something called "past reversal" Past reversal is if you know, maybe you know, the sequence of "./" If you change the folder to "./" in the command line, you will go to the higher folder, right? And also, for example, in Linux you can infinitely go to the higher folder and you won't go further than the root catalog. That is, you can do dot dot slash a hundred times and you will

end up in the root catalog. Right? And then, that is, the user submits a picture. Give me, please, a picture called dot dot slash dot dot slash dot dot slash add hash_parolev. That is, in this way, if there is some dangerous command like this, where you just take the user input and submit it to the name of the open file, we can get not any file on the server, to which the user has access, from which the web application is created. I'll finish very quickly. The basic idea is how to test all this stuff. You just select and submit any input, like quotes, brackets, such brackets, such brackets, and wait until it falls. That is, your idea is to screw up with symbols, and

it made a mistake. If you screwed up with symbols and it made a mistake, then there is some kind of a lager in developers, you can continue to twist and think what exactly can be submitted there to give some other result. That is, XSS, which is a simple XSS test, such a line, If there is an XSS on the site, then create a syntax. You will see that the line created a syntax, you know that there is an XSS. Then you scroll it and think that you can do something bad. SQL test is like that, but it doesn't work, it doesn't matter. Just submit quotes, something like that. Make the application behave differently, not like

it was designed by the developer. If you succeeded, then there is some kind of similarity. If you have access to the core code, select the "Avast Code Review Guide" and look at the very beginner, choose OWASP testing guide, code review, look at your programming language, look at which keywords are dangerous, just search for source code on dangerous keywords, see what they do, if they somehow submit user input and specify, for example, folder name and user image, then it's bad. Or specify SQL query, or insert user input into HTML. For the frontend, if you use innerHTML, eval, jQuery, HTML or other parameters, then there is some flexibility with high visibility, because you insert raw HTML, render it to the user. If there

is a user input, it is XSS. This is all bullshit I'm telling you because there are a lot of auto-frameworks that you run, you press a button and it will scan your application and say "here you have such errors" But it doesn't work because you can't Automation can't understand frameworks Automation can't understand that to transfer money you need to do one click, click there, click there, click there, enter the amount, enter the code with SMS and make a transaction Automation just goes to the link, looks at the content, if it sees some HTML forms, it's very cool If it sees some ajax and additional fields, it breaks and nothing works It's very general, something works, but not very much So, if someone tells

you to do autotest at work, you can say that it's bullshit. And secondly, if you have to do it, you can do what we did for the experiment. We took autotools that scan web applications, We threw them on proxy, took attack strings from proxy, which you can't submit to servers, took server, applications, made some popular Ajax, React, Angular 4, just made HTML form, We read and rendered it in the browser, read how Ajax was rendered, how Angular was rendered, and so on. We made it simple HTML form so that it understands the scanning framework, because they don't understand anything. And the efficiency has increased by 10 times. From 1% to 10%. That is, still very little, still shit, but it can be used on large

applications that can be covered where you need to do something. How to understand everything I've just said? There is Google.

I thought that everyone would watch my presentation later. I made it so obvious, I made a link. This is our company, which I work for, an internal knowledge base for interns. That is, when a guy comes to us, I say: "I'm a programmer, I'm interested in security. What should I do to become a security engineer?" I say: "Dude, here I am, Docs, which Vova put down." There are 10 pages, 5 of them are just keywords to google, and the other 5 are platforms where you can legally break something.