 Well, you can learn more about this industry. So I have prepared in advance a short summary of the conclusions we get to in a typical secure development course. Since we focused most of our resources here on mitigating issues in hacking methodologies rather than mitigation of exposures, I created something that will serve as an optimal page. Let's see. No, that's not it. There it is. In general, in order to mitigate applications, or mitigate exposures in applications, we have to include various security controls in our application. Now, those security controls can be placed under categories. But in general, instead of trying to mitigate past traversal and design injection and SSRF and RFI, trying to figure out what's the exact signature of each attack, that's a job for web application firewall, not for a developer trying to protect its application. Going for the blacklist approach and trying to figure out what's the exact method each attack will use is counterproductive to an extent. The best method is to use mechanisms that prevent the infection vector. I'm trying to use some sort of analogy here, but no. Think about it. You don't want to get infected from somebody who's sick, don't drink the water he's drinking, don't eat the food he's eating, don't get too close to him. Handle the infection vector. There's airborne viruses, the viruses that are delivered, no, true unknown. You got the point, okay? Instead of focusing on the attack, we're going to focus on the infection vector. So, past traversal, RFI, SSRF, these attacks are being delivered through input. So, we'll validate the input to mitigate them. Forced access attacks, those are attacks that, you know, they're abusing the lack of control or authorization enforcement. So, we'll enforce authorization. Parameter tamper attacks, those attacks, you know, they exist because there's too much control to the client side. So, we'll reduce concern of controls. We'll use mechanisms, generic mechanisms, that handle the infection vector that the various attack categories are using. So, instead of mitigating one type of injection attacks, we'll mitigate 80, okay? Instead of mitigating one type of access control attacks, we'll mitigate 70. The point is to mitigate the method, the infection method, the attack will be based on, okay? To make things simpler, I have prepared a seemingly perfect webpage. A webpage that's supposed to do all the validations one step at a time. I even prepared it in two different technologies, Java and Node.js, okay? Just to give you a glimpse. So, I'm going to go over the various control that you should see in your rest service, web service, webpage, and in each and every one of them, at least the authenticated ones, and if you're missing one of those controls, it probably means you either lack a certain functionality or are vulnerable to specific vulnerability, one of those we discussed, or another one, okay? One of the ones we didn't discuss. So, initially, a webpage should begin by verifying the authentication and authorization that is in access control of the accessing user. It doesn't matter how you do it. A flag in the session, verifying a cryptographic token, verifying a necessary token in a header, it doesn't matter. JWT tokens, as long as you initially, when the module starts immediately before everything else, verify user is authenticated, and that is authorized to access that specific module, okay? That's the first phase. It doesn't apply for public pages, you know, the login page or the help page, but it does apply for every internal component except whitelist models that are unauthenticated. As opposed to using a blacklist approach, which is, in my opinion, counterproductive, I would even split content which is public to a different server. I really recommend using the white box approach in authentication and authorization, okay? As much as possible. As in, you can't access any page without authentication except the login page, the password recovery page, and the help page, okay? That's the best way to define it. However, technology has its own method to define it. In Java, you can use various security constraint instructions in the WebXMR files. You can do the same for WebConfig and Azure, you can do it in any technology, and I won't get into the technology-specific path. That's more appropriate for the technology-specific secure development course. That's the basic, okay? That's the first phase. If you're afraid from automated attacks, okay? And from, we haven't covered that type of attacks in our course, third-party attacks, click-jacking CSRF attacks in which other website abuse users using them simultaneously while they're authenticated to your website, you need an anti-CSRF mechanism, anti-click-jacking mechanism, and anti-third-party mechanism as the second phase, okay? If I would have implemented a page or a module as long as it's a web module, web module, not test module, you probably need a validation that makes sure that there is an anti-CSRF token which is valid and that the domain access in you is a permitted domain, a domain that is allowed to fair users to you, okay? You can check the referral, handle yourself or use the X-ray options element for the browser or C-spreaders, there's various methods, but that's the second checks. If it's a REST service and you don't have it, you know, in most cases, you're okay. If it's a web page and you don't have it, you'll probably vulnerable to the click-jacking CSRF or various attacks you haven't covered in our course, okay? The third validation, and you know, people think of it as the first validation, it's actually the third, at least in my opinion, is input validation. And you would typically use the white list approach whenever possible in input validation. Instead of validating if there's a quote and double quote and dot and dot dot slash, we would go for validating whether or not the input has only permitted characters or artists. It won't work in every possible input like free text fields, that will be hard. Let's say I'm a user, and I want to create a devil smiley, you know, with the special, the tag brackets and you know, those, you probably won't be able to limit me without me being really annoyed with your application. So it won't work for every field, but for the vast majority of fields, you can implement very efficient white list approach. Like, if this is a numeric field, only numeric values. If this is a string field, only lacking characters and numbers and spaces. And so on and so on and so on. Get to a list, it includes as less characters as possible, and it should mitigate on its own. Many of the injection attacks out there, okay? That's the third validation. There's also, these days, especially for Java.NET, Node.js, a bunch of prepared validations for you. All has the fantastic ESAPI validator classes that are able to validate file, pass, and a bunch of other elements. NPM, you know, I'll just skip to the Node.js sample below. There's the NPM validator methods in Node.js. It does something very similar. It validates the values and email, pass, or no. Whatever you want. Just check what the available options are. You can really save up A, a lot of development time, and B, a lot of unnecessary mistakes and prevent your code from being attacked for simple injection attacks. The fourth mechanism I would verify is that we have secure data repository access. I'm intentionally avoiding the world database because there's various data repositories. Doppleting system is a data repository. An internal file share is a data repository. Mongo is a data repository. The protocol being used by the server, the frontend server, to access the internal data repository may change. It can be SQL, it can be LDAP, it can be operating system access, it can be JSON when you're accessing Mongo, okay? It doesn't matter. Use classes that embed syntax escaping as much as possible while accessing the data repository. In SQL, and that's an example, search for similar classes for other protocols, I would use parameterized queries, which are elements that prevent syntax. We didn't get to SQL in our course, it's a very short course, but we used quote war one equals one. It's an SQL injection type. We kind of effected query. I would prevent the effect both by input validation and by using classes that access the SQL which are not vulnerable to the injection, that ignore syntax character, trying to affect the pass of the file or trying to affect the pass of the SQL query. Node.js, for example, there's classes that actually prevent syntax character from affecting the pass of the file being accessed or the command being executed, okay? You can use those, just as an example. So, we covered authentication, authorization, we covered anti-automation, anti-CSRF, in general, anti-click checking, we covered input validation, we covered secure data repository access. The first place would be information disclosure prevention, okay? All of the data that you're presenting to the user that can assist an attacker, even though you're trying to help, okay? Like an exception telling the attacker, the user, hey, the file isn't found where you found it, it's actually in C.slash.slash, disclosure the entire pass, or an exception that tells us, hey, the user name is invalid, or hey, the password is invalid. Helping him enumerate the valid username and password instead of the combination, okay? Reducing consumer control. This one isn't the phase. Up until now, it was one, two, three, four, those were phases. Five, information disclosure prevention is kind of like a guideline for the entire page. Six is the same, reducing consumer control. I'm trying to be gentle here. Don't do stupid stuff like letting the user control every possible element in the application. Reduce his control to the minimum necessary to function properly. That's it. Like the least privileged element we use in tele-linear organization, apply the same concept to the user and what he's able to send to the client, what you're accepting from the user. And avoid hidden parameters or secret parameters or all of those things. Minimum, the less the user will be able to affect the server-side calculations, the less problems we'll have, okay? So if there's a possibility to get certain amount of content from another source instead of users, prefer that, okay? So cryptography is just a guidance. We haven't gotten to cryptography at all here. We haven't even gotten to cryptography attacks, but these days we recommend in terms of protocols of communication with the client to use TLS 1.2 or above for assistant implementations. It's more configuration issue than development issue these days. We recommend using AES-256 for local data calculations. And if you're storing hashes, okay, of passwords or whatever, we typically recommend SHA-256 with salt, okay? I'm not getting into the details. Those of you who will need to implement it can take that line as a reference of what we should or shouldn't have. There's going to be debate, we don't know if we should have, use be-crypt or SHA-1 and even into the debaters. That's my recommendation, okay? Context-specific output encoding, unlike everything I said so far, is a phase in the process. So if you had a couple of phase, authentication, automation, validation, escaping, okay? Or more accurately, secure data repository access. Output encoding is a phase primarily for web modules, not for any module, not for WEST, more for web in which we neutralize the effect of malicious input embedded into the output. We haven't discussed those attacks in our course, but it's a typical phase. Anything the user that's, user is sending us, which we embed in the output and the response may affect us the wrong way. Or it includes content from another location or whatever that attack is. We typically tend to encode user-originating input before embedding it in our output. There's various methods to encode methods in Java. It's typically the encoder classes in ESAPI. They're a bit slow, but they work and they're also context-specific. You can encode using HTML encoding or JavaScript encoding, depending on what you need for the moment, okay? At the moment or at the specific scenario. Node.js has similar classes. I'll just search for them. Actually, I've used a Node.js API here in our example. There's other Node.js libraries that's just the same. You can use them as well. And that's pretty much it. That's the baseline. I mean, I'll just go over the benefits. The authentication authorization validation should handle most of the access control issues. It won't handle backup files. You have to make sure that they could upload it to the web server. It really includes the files necessary, but it will handle other forceful browsing incidents. At least most of them, okay? Third-party access protection is a subject who haven't covered at all, but anti-CSRF flags and anti-click-jacking, by-setters against click-jacking, you know, ex-film options and a bunch of other things that you may have heard. Those are necessary in web applications these days. Very necessary, okay? So if you have a web application that hasn't seen them, you probably need them, okay? The input validation, actually, that's a known issue. It's kind of key. These days, you don't have to write it on your own. There's prepared classes to help you out with it. Why not use them? ES API and validator. You want something in .NET or you can find something. There's content for almost every development language to use for validation, so for custom or pre-packed validation, pre-configured validation. Secure data repository access. You have classes that enable secure access to Mongo, to databases and to file systems, depending on the technology. Those can prevent attacks, even if you failed the input validation. Even if you didn't do a valid input validation, just by using a secure class to access data repositories, you can prevent that attack. It's another layer. It's a more effective one, okay? So I highly, highly, highly recommend it. All the rest, kind of basic, okay? Other than that, questions? Questions about mitigations? Yes. What is ES API? ES API, Enterprise Security API is a project by OS for various development core technologies. I think it's really mature in Java. I don't know about the status in other technologies, but it's really mature for Java. Pretty much whatever you want there. Any almost any security mechanism that you can think of, you probably have some classes, funcars, libraries that can assist you. And Node has, there's projects of OS for Node.js, but it's not comprehensive enough. It doesn't have enough fits. There are other projects in the NPN library that doesn't have that. I give examples as the validator class. If you would have undergone a secure development course, specifically for Node.js, you would get a bunch of other classes that can assist you, okay? NTCSRF libraries and some of the others. Other questions? Yes. Any other questions with a slightly available? Of course. I will charge you all for every download. I'm getting it. I have to feed my children somehow, but don't worry. Then the giveaways, which are like summaries of the entire course in like one pages like that, that's the purpose. Like a one page summary of the course for both payloads of attack and for mitigation techniques will be available in addition to the course presentation. Okay? Other questions? Because I want to give you like the finale of where to learn from. Yes. Encrypted cookies? Oh no. You can use encrypted cookies which there's the whole model to use like a digitally signed cookies, like in JWT tokens or stuff like that. That makes sense. Encrypting cookies for what? Because attackers will be able to decipher their own cookies. If an attacker stole a cookie from somebody, it'll be able to replay it. It doesn't need to decipher it. So it won't help you in terms of whether or not the cookies were stolen. The only reasoning in encrypting a cookie or signing or something like that is they want to use a certain portable class model. If you want to reduce the amount of validations in the server side, you want to provide a cookie that contains a tonization of information and you're afraid the user will manipulate it. So you encrypt the cookies and the user won't manipulate something. It's a dangerous pass to take unless you're using prepared classes. Okay? Now JWT pretty good these days. If you're using other platforms, investigate a little bit. Okay? There was somebody down? Yes? Oh, I don't know. Three months, four months, couple of days. It will be available in the OSP website that describes this conference. Like the same website that includes the agenda. I mean, the presentation will be available in the website, this agenda, right? No, just get the order. And on the OSP cookie. Whatever you said. And you will all get a notification in your email about it. And if you only get one... Yeah, you know, we won't notice it because you go back to your normal life and you know, we'll do other stuff. And then there will be a spam from OSP. You know, they'll just delete it. So don't worry, it will be available in the website. You can remember three months from now or three years from now. Unless OSP decide to go commercial, you'll be able to download it. Okay? And other questions? Yes? I noticed that most of this is server-signed. Yes. Yes, once upon a time, I would have said no. I mean, you would have asked me six years ago. I would say no, client-side security is simply irrelevant. In most cases, relying on client-side security is sheer stupidity. But these days, some client-side controls, especially because of the client... Well, the client dependency of... The tendency to cause clients to pass more and more information, like in platforms such as Angular, React, mobile applications, read mobile applications, the clients are doing much more these days. So they're becoming more server-like. So, for example, these days, mobile applications pass SMS. So, if you send an SMS with malicious input from one user to another, they will be able to affect his application. So these days, you probably need to embed some validations in client-side applications, specifically rich client applications. It's not necessarily as important as the server-side. It doesn't affect the whole lot of users. It may affect the specific user, but it has importance. So, as an answer to this question, I have a great slide that I've prepared in advance. I just predicted your questions. I didn't know what it has to mean. So, if those are the server-side controls, that's like a sample of client-side control. Those are the elements I would need to embed in a client-side application. You get that. Not sure of charge of profit, not profit. So anyway, enough with the jokes. Seriously guys, any other questions about the content? Okay. Some very good, relatively free resources to learn more about application security, hacking, secure development. I'm going to show you a couple of fantastic projects by all of us. I don't know why, you know, people don't use them as much as they should. A, if you want to learn more hacking methodologies, there's, of course, the OSP testing guide. Okay, I really, really, really recommend that you start reading at least the various attacks that's found out there, okay? It's a nice website. It includes a load of content, methodologies, payloads on, I won't say every attack possible, but you know, a lot of attacks, okay? I typically use that, I won't say on a regular basis, but every time I forget a payload, I refer it here, okay? OSP testing guide. Just Google it. Be, tick, tuners, okay? Be, if you want videos of various attacks, I want to learn a specific attack. There's a website called TechAPI. I admit I'm the owner, but I don't earn any money on it. It's free of charge. You can actually access attacks and see and learn about the attacks using videos or references to various other websites, such as OSP testing guidelines, okay? It enumerates, you know, it kind of like connects OSP testing guides with other resources, such as CWE and the CAPEC and other resources that attempt to explain or enumerate attacks, and also refers to various videos online that explain the attack, okay? Either videos from conferences or just, you know, videos from volunteers that are uploaded into YouTube. It currently lists about, covers about 288 different attacks, so try not to consume it in one day, okay? But anytime you want to learn about a specific attack, you can go there and it will also refer you to the rest of the resources or testing guide or attacks and differences, CAPEC, CWE and so on and so on. And finally, finally, a good set of videos to get started and just refresh yourself, you know? To figure out some basic concepts if you forgot about them is OSP ActSec Tutorials. Although it's just covering basic videos, it, you know, after you go home and, you know, get back to your normal life, some issues may need to be refreshed. There's, it's a set of a couple of short videos. You can get, you know, reminder of the basics, proxies, SQL injections, CSRF, even attacks you haven't covered. You'll get a very simple and graphical explanation in the form of short video, okay? OSP ActSec Tutorials, a nice place to get started with. Those of you who want to get formal educations, you can get them in colleges these days, degrees these days, I don't know why, but I heard about it. Overline, YouTube, Udemy, you know, hands-on exercise, phones, news groups, okay? That's pretty much it. Anything else? Questions, requests? Can I have the card number? No? Okay, I hope you enjoyed. I did enjoy very much.