Web Application Security and OWASP - Top 10 Security Flaws with Examples

welcome to this video from in 28 minutes thanks for helping us provide awesome learning experiences to more than 300,000 learners across multiple platforms udemy Safari and fact let's welcome our lead instructor Ranga Rao Khurana welcome back in this series of videos we would start talking about web application security security is one of the most important non-functional requirement whenever we build applications a chain is only as strong as its weakest link and same is the case with security you might be having a very strong application you might be having very strong infrastructure but one small flaw can break security and that's where it's very important that architects developers testers and business the functional users are aware about security in the next few steps we would be talking about something called over ASP top 10 west and for open web application security project West is a non-profit security organization which does analysis into security and provides a list called the OWASP top 10 which kind of gives you an overview of what are the major security flaws that are present in an application we would be looking at a specific list from 2016 10 OS top 10 things that we'd be looking at right now are injection broken authentication and session management cross-site scripting we'd be talking about insecure direct object references security miss configuration security data exposure missing function level access control cross-site request forgery CSRF using components with known vulnerabilities and we will talk about unvalidated requests and forwards for each of these we will discuss what it is and how you can prevent it how you can build applications which don't have that specific flaw let's start with the first one injection and SQL injection is one of the biggest vulnerabilities that are present in typical web applications now let's focus on what is SQL injection let's look at this piece of code what are we doing in here we are taking an input from the user and we are directly appending it to our SQL statement what would happen if the input from the user is something like name is equal to Rangga + 1 is equal to 1 or it actually should be or 1 is equal to 1 what would happen this query would become what does it become select start from person where name is equal to Ranga or 1 is equal to 1 what would happen every row from the database from every row from the person table would be returned back and that's not good this is what is called SQL injection in a way this method is protected because we are using a beam property row mapper and we are trying to map it to one person but if you are mapping it to a list of persons then this would have had a serious security flaw what is happening in here is we are taking input from the user and directly using it in a query without validating it now huh what's the best way to do that as far as SQL is concerned the best way to do that would be to use parametrized queries use question mark and make sure that this value in its entirety is passed in to the name so how does this query get executed it would be something like this name is equal to Rangga or 1 is equal to 1 so this will check for this as the name and obviously you will not find that specific name so what we are looking at is one of the possible types of injections which is called SQL injection of the matter is SQL is only one of the types of injections there are a wide variety of other things that can be part of your injection attack your LDAP your XML experts so whatever input from the user if you are making it as part of the XPath for an XML then it can be abused as well log if you are taking whatever data is coming from the user and putting it to the log that also can be one of the kinds of injections whose commands if you are asking users to input some data and you are using it to execute a specific OS command that can be abused as well and we'll also look at another kind of injection called cross-site scripting which is basically related to the Java Script which is basically related to the front-end a little later what are the base of preventing SQL injection we said parameterised queries but in general the way you can prevent any of the injections is by validating the data which is input by the user have a safe list of characters and only allow those kind of characters in don't let user enter anything and then use it and execute a voice command or use it to execute a SQL query make sure that any input that comes from user is validated against a whitelist the next thing we would want to talk about is broken authentication and session management now what is broken authentication broken authentication is what happens when your user takes a user ID and password and uses it in multiple sites including yours what would happen somebody who has access to another site can check take the user ID and password and start accessing the users content on your site now how do we prevent that one of the ways you can prevent that is by randomly adding something to the username so make the user enter something but had a little bit of content let's say one two three or something random to the username so that makes sure that the username which is used on your specific site is unique this prevents users from having the same username on multiple websites this is especially important if you are having a banking website or a financial website the second important thing is when a user enters invalid ID and password give us less information as possible just say unable to validate your data or just say invalid credentials do not provide more information do not say invalid username invalid password or things like that just provide the least information that you can provide on authentication failure the last thing you can do to prevent a use of authentication especially in case of reusing sessions is have a auto log off feature so have a maximum session of 10 minutes 15 minutes and indecision right then and there one of the features you can try and prevent that credit one of the features you can try and implement is whenever user closes the browser button try and do a log of these are some of the things you can do to fix broken authentication whenever we talk about web applications we talk about sessions and the thing is the way Internet is designed is around HTTP protocol hypertext Transfer Protocol and HTTP is stateless so the question is how do I identify that the request is coming from the same user what do we do we have a number of mechanisms you all rewrite basic authentication and cookies let's look at them and let's look at what are the flaws they might be having and how you can fix them let's start with the most basic one which is URL rewrite what do we during the URL rewrite whatever session ID is created for a user we try and put it in the URL so in the URL of the browser you'd be able to see this session ID when an application is using URL rewrite you'd be able to see the URL containing this session ID what is the problem with this the problem with this is since it's part of the URL it can easily be snipped somebody who is actually listening to what's happening in your computer or what's happening in your network knows the URL to which you are sending the request and he knows your session ID the other important thing is any requests from your browser to the server actually goes through a number of intermediate systems and there's a possibility that your URL might be logged in the logs of multiple systems the other possibility is that whenever you are used using a third-party site what could happen whenever I go I'm in a specific URL and I type in an URL what could happen the earlier URL can be sent in as a referral URL in the request header so these are all the possibilities of abusing this session ID in the URL and how do you solve it one of the most important things is to make sure that you use HTTPS by using HTTPS you would make sure that every part of your request is encrypted let's talk about the second possibility of session management the second possibility is by using basic authentication what do we do in basic authentication we send the user ID and password which is encrypted it's encrypted by using base64 actually it's encoded by using base64 in every request thing as basic authentication is not recommended at all it is having severe security flaws so never use basic authentication to handle sessions the last one which is frequently used is cookies you set a cookie in the browser and you use it to identify a specific session when that cookie comes back from the user you use it to identify that that specific user the thing is cookies also can have problems one of the most important thing with cookies is make sure that you're setting the domain on the cookie don't just set the value but also said did domain say this is the URL to which this cookie has to be sent to so that this cookie will not be sent to other URLs the second important thing is setting the path you can also say only this part of the website the cookie should be sent to don't send it to other parts the third thing is to make sure that you are setting an expiration date on the cookie that would ensure that the cookie expires within a few days or within few hours the last important thing on cookies is to make sure that you said it as secure if you are running an HTTP site then make sure that you are setting your cookies as secure that means these cookies would be sent only to hatch TT PS websites in the last few minutes we looked at the variety of options for session management URL rewrite basic authentication and cookies and have you can prevent security flaws in each of these what we recommended was not to use basic authentication at all when you use URL rewrite make sure that you are using HTTPS website when you're using cookies make sure that you are setting the domain you are setting the path and you're making your cookie a secure cookie now let's turn our attention to it cross-site scripting cross-site scripting is actually one of the kinds of injections we talk about SQL injection as being one of the types of injection cross-site scripting which is also called XSS is one of the forms of injection as well now let's look at what is cross-site scripting and how you can avoid it so what is it cause what are the different types what can happen if a cross-site scripting happen and we look at solutions the major cause of cross-site scripting is invalid data the invalid data can be coming from user so that's where injection happens so a user typed in some invalid data with the intention of hacking the system or the invalid data can come from a database so you have a database where some data is being stored and it is used at a later point in time to show something on the screen that's invalid data coming from databases the other kind of invalid data also can come from external services they might be a flaw in your external services that you are accessing and it might be providing data which is invalid which is intended to cause a security problem so these are all the possibilities of getting data which is invalid now what are the different types of cross-site scripting the first one is this stored cross-site scripting basically what happens is invalid data is entered from the user you take it and you store it into the database the problem really happens at a later point in time when the data is fetched from the database and shown to the user on a different page the reflected excesses happens when you take the data from the user and directly show it on the screen at a later point in time the third type of exercise is Dom document object model exuses this happens when we take the data which is entered by the user and do some processing around it in JavaScript try and process that data inside the document object model now let's look at what could happen with cross-site scripting one of the things a hacker can do is steal your session cookies he can buy Java Script which will steal your cookies and send them out the other thing you can do is because you have access to JavaScript you'd be able to rewrite the content on the page you can change the content of the page you might be able to change the balance to something else the other thing you can do because you have access to JavaScript we start logging the keystrokes maybe you'd be able to identify a user ID and password from there now what are the possible solutions to preventing exercise cross-site scripting number one and most important one is to validate untrusted data make sure that you validate it against a vitalist allowed list of characters the second thing is to encode all the data so don't use less than so if it's data encoded use and lt semicolon this would prevent tags being parented out this would print this would prevent things to be treated as HTML the other important thing is this encoding should be very contextual depending on where the data is going to so if it's if the data is going to be part of CSS they it should have CSS specific encoding if it's going to be part of HTML it should have HTML specific encoding if it's going to be part of JavaScript it should have JavaScript specific encoding one of the best things that you can do is to make sure that your frameworks are built to do the contextual encoding the other things which you can do is to look up the content security policy and also look up the XSS prevention cheat sheet these two things should help you to get an of best practices to prevent cross site scripting from happening in the last few minutes we looked at cross-site scripting we discussed the fact that invalid data from user databases and external services is the major cause for cross-site scripting we discussed about the three types toward reflected and Dom cross-site scripting we discussed what a hacker would be able to do if he is able to do cross-site scripting he can say steal your session cookies he can rewrite the content of the page or he can see what keystrokes are being logged and captured user IDs and passwords we discussed the solutions validation encoding and contextual encoding other than that we said content security policy and the charoset scripting prevention cheat sheet are the best references to find solutions for cross-site scripting the next security flaw that we would be discussing is unsecure direct object references what is insecure direct object references all about let's consider a simple example let's say I am trying to log into a web application and the web application shows a link to some web server comm slash account slash 1 2 3 now what I would do is change 1 2 3 2 1 2 5 so what is happening here is user changes the link on the browser from the resource he has access to 2 1 which he has no access to so I am owning the account 1 2 3 I have no access to account 1 2 5 would the system I love me to access it that's what if the system allows me to have cat cricket if the system allows me to access that then it's having the flow of insecure direct object references the important thing here is that the direct reference let's say my account ID is 1 2 3 the direct rack reference to that is being shown in the URL and it's easy to man you plate you can easily change it and if there is a flaw in the system then I would be able to access the details of a system account which I don't really have access to the way you can prevent insecure direct object references is to implement proper authorization so make sure before providing access to the account check that the user has access to that don't just go by the fact that user has requested 4 1 2 5 so he should have access to it and give him access to that before providing access check that he really has access the other important thing is to stop using direct IDs like one two three inside the URLs use some kind of object reference do not use readable IDs do not use things like one two three one two five one two seven try and use something obscure so that it's very difficult to predict the URL its bits it's very difficult to predict the URL of another account until now we looked at the insecure direct object references this happens when I have values in the URL which I can modify and try and access something else which I don't really have access to and the way we can prevent that is by implementing proper authorization as well as making sure that the values in the URL are obscure and not easily predictable the next thing we'll be looking at is security miss configuration a5 one of the important things that developers might say about security miss configuration is it's not really in my hand it's in the hands of an administrator it's in the hands of the operation team it's in the hands of the team which is using which is configuring the web servers which is configuring the app servers which is configuring the operating system the deployment environment but one of the important things is you should be aware of it and you should take whatever steps that you can take to prevent it you should make sure that the operations team is aware of any flaws that you are aware of regarding the web servers app servers operating system and make sure that you are patching up the systems in the right way one of the common configuration errors which can happen is with respect to admin consoles a lot of these applications have like WebSphere provide an admin console which have default accounts all right first things you should do in all the environment whether it's dev QA stage or production is to delete all the default accounts make sure that the admin console is not a available outside the enterprise it should be available only within the intranet so make sure that all the administrative stuff is only accessible from within the intranet they are not really outside accessible outside the intranet now how do you prevent security Mis configuration the first thing is to make sure that you are using the loft latest version so make sure that you are using the latest version of software installations latest version of WebSphere make sure that you are aware of all the admin things and make sure that there are no default accounts present on them the other thing is have the same security measures across all environments dev QA stage and production the next security problem that we'll be talking about is sensitive data exposure for example let's say I have a user ID and password directly stored in the database without any encryption what would happen anybody who has access to database knows all the user IDs and passwords or the other thing which could depend is the algorithm we are making use of is not sufficiently strong anybody can use it to decrypt back now how can you prevent that one of the ways you can do that is by using one-way functions what is a one-way function a one-way function is such that if you have some data and once you encrypt it a one-way function is something where if you have some data and if you encrypt it from the encrypted value you will not be able to get the original data back every time you would want to check a password what you need to do is to encrypt it and check if the encrypted values match you'll never be able to decrypt and get the original password back the other important thing which can be done is to add some salt salt is like if a user enters password as abcdefgh which is not really a good password what we would do is you would randomly generate some salt saying 1 2 3 4 and we would store it in the database as well as we would use this salt to append to the password and encrypt the entire thing encrypted password + salt what would happen now is in the database we are storing the salt for a user we are storing the encrypted password after adding the salt whatever encrypted thing we got we would store those two things the advantage of this is the fact that this encrypted thing will not be reusable on other websites because this contains the salt even though this is the typical password the user might be entering in all the web sites the encryption will be different because we are adding a salt in the next security program we would want to discuss is the missing function level access controls what does that mean whenever we talk about security whenever we talk about users and IDs and passwords we talk about authentication and authorization authentication is is this the right user is this who he's pretending to be authorization is does this user have the access to this resource in applications no you should have both authentication and authorization missing function level access controls happens when you don't have proper authorizations now how do you prevent it the way you can prevent it by having complete mediation principle what does that mean it means that before providing access to anything you should check whether that specific user has access to resource and this should be implemented in a centralized place so every request should check whether the security is clear whether user has the right access to that specific resource the second important thing is to have well-defined roles so have well-defined roles defined there accesses that would be the first step to prevent missing function level access controls the next security problem is insufficient transport layer security what would happen if this request you are sending is not really secure things like secure session ID is things like passwords and all the sensitive data on the page is sent in an unencrypted way and that's not good this is typically a problem in websites which have a secure part and the unsecured part part which can be accessed by anybody and paths which can be accessed by only specific users who have access now how do you prevent this one of the most important things is to make sure that you use HTTPS Everywhere you use transport layer security everywhere use security on pop-ups use h2 redirect only to http web sites don't send don't redirect request to a non HTTPS web site the other thing you can do is to mark all your cookies as secure make sure you use trusted certificates one of the other things you can do is to terminate this session and create new session IDs whenever somebody is switching between the secure and non-secure parts now let's look at another security flaw called the cross-site request forgery what does that mean let's say I have already logged in to my banking website and from there I am going to a forum what would happen if the forum uses this session that I already have to fire in Ajax requests or send a request to an unauthorized URL the important thing is my session is already active in my browser my banking website session is active I am not logged out so my session cookie is actually in my browser and other sites can abused it this thing is called cross-site request forgery now let's look at ways of preventing the cross-site request forgery one of the ways you can prevent it is by generating a unique token with every request so every time you record gets a request send a response back with a unique ID and only when that unique ID comes with the next request I'll of the request to be successful otherwise do not execute the request this token which is sent is called the CSRF protection token and this is actually a hidden form field so typically inside the form you create a hidden field and set a value so what happens is inside the response which comes back from the server you would have a hidden form field with a specific value unless you send that form field back the next request will not be successfully executed now what's the second approach the other thing you can do is to make sure that whenever there are important actions that are present in your application let's say transfers of more than $50,000 or more than thousand dollars or significant actions that user can perform make sure that you really Kate the user so even though user is logged in ask him to enter the password once again one of the important things is to make sure that you're using frameworks like spring security or over ASP CSRF guard which help you in automating all this kind of stuff in last few minutes we talked about cross-site request forgery this happens because you have an active session on a website and go on to another website which tries to make use of your active session and does unauthorized operation the only way you can prevent this from happening is by having a CRF protection token we can also supplement this by making sure that the user is authenticated again whenever significant operations are performed one of the common security flaws is to use known vulnerable components whenever we build applications we use a lot of frameworks external frameworks you might be using Java libraries or JavaScript libraries and these libraries can have flaws in them and if a hacker knows that there is a flaw in a specific framework and you he knows that you using that specific framework then they can exploit it now how can you avoid it one of the most important things is to make sure that you're using the latest versions so it's very important that you keep track of the versions make sure that you are upgrading the versions of all the frameworks all the liabilities you are making use of with every new release the second thing is also to have a approved list so your security team needs to have a food list of software that you can use and make sure that you are only using the software which is present in that approved list the third thing you can do is to create proper services so instead of using the libraries or components directly you might want to create a vapor around it and not really expose everything that the library provides but only expose specific parts that you would want to make use of [Music] the last security flaw that we would want to talk about is unvalidated redirects and forwards lot of pages have these redirect URLs so trusted site comm / redirect dot JSP and the URL you can direct to could be any URL and it can be a hacker URL as well the problem with this kind of stuff is that a hacker can exploit it the link the original link would look as if it's being sent to a trusted site let's say this was a bank site so the link would look as if it was a bank link but what would happen at the end it would redirect to a hacker URL the user thinks that the you site is secure because he's trying to connect to let's say a google.com or he's trying to access amazon.com oh so he would think that the site is secure but eventually what would happen he's actually redirected to the hack URL now how do we prevent it whenever you expose these kind of redirect facilities make sure that you are validating the redirect URL 1 another option is not really a love a URL in here but have a mapping have strings so have a string and have internal mapping so based on the string redirect to other URLs which you trust the other thing which can also be done is to make sure that you show a message to the user you pause the page and say you are being redirected to this particular page this has got a lot of good web sites do as well in the last few steps we looked at number of security flaws we looked at injection broken authentication and session management cross-site scripting indirect object references security Mis configuration sensitive data exposure missing function level access control CSRF or cross-site request forgery and using components with known vulnerabilities and unvalidated redirects and forwards this is a list from 2016 and this list keeps changing every year so I would recommend you to spend some time with the OWASP later cat litter I would recommend you to spend some time with the OWASP latest risk will be the top 10 security flaws from 2016 one of the important thing is to get your principles the security principles right once you get these security principles right you could try and avoid most of the security flaws that happen so what are these security principles it's principle of least privilege is complete mediation defense-in-depth trust nothing economy of mechanism and openness of design so what are these now let's start with least privileges what does it say basically whenever we start a new project start with security in mind start thinking about what are the resources that would be part of the application and start thinking about what kind of users you would want in the system and what kind of fuses should have access to what kind of pages so start with building a security model from day one of the application security should not be a afterthought it should be something which you should do from the start of a project so start thinking about user roles user accesses and different things every user should have the least amount of privilege that he can live with this should be true for not just your applications but for example access to databases he should have the minimum access to the database to do his role the next principle is complete mediation this means that everything should go through the security component so all requests should first be authorized by the security component and only then go into the application the security component should check the authentication and the authorization before letting the user perform the action this is called complete mediation this is just like building a fort around a town in the medieval period what would happen is you have a small city what you you'd build a big food around it and you just have one entrance one gate and everybody should go through the same gate that helps us to put good amount of security in there the next principle is defense-in-depth have multiple security levels don't just have one level of security have multiple levels of security and make sure that you have three parts how to prevent how to detect and how to react so how do you prevent people from accessing it how do you prevent unauthorized users from accessing the application or being an unauthorized action the next important part is have great detection things also in place it's not just a vision if you are trying to protect your application if an unauthorized access happens are you able to detect it very fast that's an important question too and the third part is how do you react if a security violation is detected so have all these three ready and make sure that you have multiple levels of security the fourth principle is trust noting any data that comes in the system is a potential security problem so make sure that you have a whitelist and validate it do not let any data into the system without validating it make sure that you're sanitizing all the data that comes on to the system the fifth principle is to keep it very very very simple designing security is very very difficult if the architecture of a system is very very complex so keep your architecture simple keep your design simple simple systems are the ones which are the easiest to protect the last principle sixth one is openness of design over the last few decades people found out that being open about the design discussing openly about the design is the best way to find security flaws rather than depending on obscurity in the last few minutes we talked about and principles and have your thought process should be around security we talked about the principle of least privilege s making sure that every user has the least amount of privileges to make sure that he is able to perform his role making sure that every request is going through a security component complete mediation defense-in-depth have multiple levels of security trust nothing validate every piece of data and sanitize it economy of mechanism build simple systems and don't really make it complex openness of design rely on communicating your design and discussing it and finding flaws rather than trying to have a secure design and trying to end cut cut and trying to get security because of obscurity in this video we talked about the 10 OS top 10 violations and we looked at different security principles I hope you had a lot of fun in 28 minutes is providing awesome learning experiences to 300,000 learners across platforms like udemy Safari online and pact we have clogged million hours of learning in the last few months the question is what do you want to learn next we are building solutions to help programmers at all levels you can learn programming with our awesome courses on Java Python and JavaScript you can learn full stack development with REST API sand micro services with a wide range of frameworks like Springwood no J's react angular and spring cloud we have 200 plus videos to help you start your journey from a programmer to a Software Architect we have videos to help you learn frameworks industry trends including things like microservices learn the best practices in architecture design and code quality thanks for watching keep learning in 28 minutes you

Channel: in28minutes - Get Cloud Certified

Views: 118,974

Keywords: microservice best practices, in28minutes, in28Minutes Course, OWASP, Web application security, in28Minutes, in28minutes tutorial, Security, microservices architecture

Id: j5PuYFCS0Iw

Length: 41min 15sec (2475 seconds)

Published: Mon Dec 03 2018