5 Ways Hackers Will Attack Your Website Online (and what can you do about it)

third and probably the most important thing you will find in this video is this point right here now i know this is something which is you know not considered as a good statement to say in this video we'll be discussing about my top five findings in my top five things which i recommend for you as a back-end developer to keep in mind to keep your web applications secure i believe web security is one of the most important things you can learn as a back-end developer and if you're not if you're somebody who's writing insecure code you are a bad developer it does not matter how many design patterns or whatever you follow so it is extremely extremely important to be aware about these top five things which we'll discuss in this video also if you're new here make sure you like the video and subscribe i'm putting out a lot of awesome and daily content on this channel so if you want to receive more knowledge nuggets from goddamn make sure you subscribe to the channel and hit the bell icon this video is a part of code dam's t-shirt giveaway program for the month if you want to take part and win an amazing go damn t-shirt all you have to do is leave a comment on this video about what you think and that's it you are eligible if your comment gets a heart from code damn you will win a t-shirt for absolutely free the first thing which i want to discuss is about rate limiting your applications and this is super important why because attackers for the most part would look at a weakest link in your application whether it's cpu bound task or whether it's something which adds rows to your database for example a registration form and they would try to exploit the rate limiting side of that thing does that end point even has a rate limit associated with it or not so the rate limiting can work in the following way for example let's say this client starts originating a lot of requests at the same time and this is your server what you want to do is you want to have a limiter sitting in front of the server right now this depends on what context you have in terms of serverless or server full so it could be radius space limiter it could be based on let's say nginx implementation it could be anything custom it could be even inside your app logic a bit but your task is to protect sensitive operations which require a lot of dbe operations right or may even maybe just computation also the way you can limit it is i think with a couple of criterias the first one being the most common is the ip address and the second one is which is also i think is a common approach is based on the account limit right so if you have a service which requires people to sign up then you can have a rate limiter based on account this i believe is a better approach why because a lot of times for example if you are running your application in a school or in a college-based setting then a lot of times a single ip address a single public ip address i should say is bound to a lot of computers or to a lot of clients right so you more or less don't want to bind your rate limiter with an ip address when you have the information available on an account based level right so your first priority should be rate limiting on an account based level and the second priority should be on an ip address the second point which comes to my mind is about upload limits so if you have an application where you require any sort of uploading functionality and if you are doing it yourself that is the uploaded files go somewhere in your ec2 directory or some computer then you are in trouble because if you don't have an upload limit set then it could be easily exploited to just bring down your whole server let's say you have 256 gb hard disk connected to your ec2 instance right and if you don't have an upload limit for example set on this ec2 instance then if this is publicly exposed and somebody just uploads you know a large file for example which just fills in your whole disk then your server will go down right and this is less relevant for people who are using solutions like s3 or anything because they virtually have no upper bound as such on the limit but it's still a good practice to have upload limits now this does not mean just files for example it also means stuff like limits on the size of message on websocket for example so if you have a websocket connection from a server then you don't want this client to send an arbitrary large amount of message over this websocket right because this message passing would very well crash the server right so this upload limit verification that if you have a message which which is exceeding for example two megabytes right just kill that message right and again solutions like nginx for example have inbuilt functionalities where you can specify the maximum upload you want and if any tcp connection which exceeds the amount of data transferred it'll just kill that connection right so it's much better to enforce this on a network level compared to an app on an application level like you know inside your code itself third and probably the most important thing you will find in this video is this point right here repeat with me all user data is evil again repeat with me all user data is evil this is probably the root cause of i believe most of the vulnerabilities you will see on the web that back-end developers trust user data in some way this is probably the root of most vulnerabilities what do i mean by this let's say you have an end point a rest endpoint which is something like get an id right where you take this id parameter and you do a sql query select star from wherever you want where id for example is equal to whatever the user has entered now what what are you doing here what's the problem the problem is that you're trusting the user this id parameter which gets from the user from the front end is evil you always have to assume that this data is evil right that means you can never trust something like this because this will result in a sequel injection right a user can very well just specify an id as an empty code for example if you had this in course and would write probably or one equal to one and comment out the other query and they will probably get a sequel dump off your table right so you don't ever ever want to trust user data always make sure you sanitize it properly always make sure you're expecting the right data type the right content which you expect the right signature whatever it is the second example i can give off if is the following for example people think that nosql means nosql injection as well this is actually wrong because you can have sql like injections you can have no sql injections for these queries as well so let's say if you have a get user as a post method and then then let's say you have something like this where you are specifying this id right away and what can what someone can do is instead of passing this as a string they can pass this as a json object from front end right so what this json object could look like is an object which says like not equal to an empty code for example right and this will match the condition for every user and you would be in trouble more or less so you don't want anything which is unsanitized to go into something which you never want your users to execute directly that is the punchline make sure you sanitize each and every aspect inside your servers logic code itself before you make use of that data to interact with either database or any other external service or even store it in a lot of cases right the next important point which i have in mind is security by obscurity now i know this is something which is you know not considered as a good statement to say in the security world that you should not make secure applications by obscuring the logic but this is also important especially in case of web applications for example you don't need your graphqls introspection query for example enabled on production right this introspection query can pretty much return all the resolvers and mutations and all that fun stuff to your client side you don't want that access on the production for the users right it's kind of obscurity because you're not telling them what resolvers you have but this is important because even if you have a vulnerability which you might patch later down the line this thing right here would probably just expose a lot of details about you and if somebody's black hat they might just exploit that right so important to follow these practices disabled development mode on production i mean kind of obvious but you would still see a lot of django applications for example having all sorts of dev mode enabled on production spitting out all sorts of errors you want to disable sequel errors for example this again limits the attack scope of attack to blind sql injections i mean this is not a solid security guideline but this is more of a just buying you more time right if you have other systems in place which monitor these endpoints correctly which have alerts and flags set up then this could probably just save your company one day if you have a critical vulnerability just sitting so security by obscurity is fine i mean as long as you are also following other good practices right so it's not a bad thing to have all right my fifth important point which might upset a lot of people here is that dumb services should not be exposed on internet and what do i mean by dumb services exactly these services are examples of databases most commonly like you know your sql database for example or for example like exposing your memcache or redis stuff like this a lot of people what they do is they set up this redis instance for example on an ec2 and then they would have a public ip address from where they would connect either over the internet or through internet and just leave it open the internet right this is bad again similar for databases i'm gonna get a lot of hate for this for example firebase is an insane way to do database programming if you have not set up the rules correctly firebase exposes your full database on the client side which is which sounds like a bad dream and if you don't have the rules set up correctly you pretty much give read write access to anyone on the internet right so similarly i think ost there's also something where you know the the trick is in the rest thing super bass which is the firebase alternative so uh bass is also like you know just like firebase they allow you to use postgres to expose the whole database this thing right here is a super nightmare because you pretty much are just giving your access to anyone on the internet and if you don't have the right authentication or authorization setup it is a terrible terrible choice right so make sure i mean in my opinion i would probably never use firebase or postgrest on client side i would always use even if i'm using these services i will always use the authentication with the db with the server right your database ideally should never be allowed to talk directly via client there should always be a logic layer sitting in between any sort of service which stores other people's data should be routed to a logic layer and should not have this communication this communication is bad right and you won't believe a lot of services do provide you the ability to do so just because it makes it easy doesn't mean it is also secure so make sure you are following this practice so these were my five important pointers for you what do you think about these five things and do you have anything you want to add to this list let me know in the comments below that is all for this video i'm gonna see you in the next one really soon [Music]

Channel: Mehul - Codedamn

Views: 13,407

Keywords: codedamn, internet security, web security, how to secure your website, how to secure your website from hackers, how to protect yourself online, how to protect yourself from hackers, how to secure a website, how to secure a website address, how to secure a website for free, how to secure a website url, how to secure my website source code, secure your website from hackers, how to fix your website is not secure, 5 MUST KNOW Web Security Tips To Protect Your Web Apps From Hackers

Id: lrvVf7sl394

Length: 11min 56sec (716 seconds)

Published: Thu Sep 02 2021