SQL Injection Hacking Tutorial (Beginner to Advanced)

Hit send and we get a 200 okay that's a good  indication that our exploit work. I love it   that you didn't choose a simple password or  I mean this lab isn't a simple password it's   great to see like a complex password being  being broken like this. Where we logged in   as the administrator user cookies are a great way  for you to potentially cause a lot of harm to the   application you could actually use a SQL injection  vulnerability to try and brute force a password   by the SQL injection vulnerability because a  cookie will never have some kind of lockout   and here we go we get the account page and  it says congratulations you solved the lab. Hey everyone it's David Bombal back with Rana.  Rana welcome. Hi everyone thanks David for having   me. So for everyone who hasn't seen our previous  videos I've put links below where Rana did some   demonstrations spoke about the best certifications  that you can get in cyber security but I've got a   really exciting announcement Rana is going to  be collaborating with me by putting courses on   Udemy. Rana is so excited about this your  first course is going to be SQL injection   is that right? That's correct um so I'm very  excited for the collaboration we're going to   start off with the SQL injection course  which essentially kind of talks about the   technical details it goes into a deep type of the  technical details of SQL injection vulnerabilities   um and then it talks about the different types of  SQL injection vulnerabilities we have over 17 Labs   um poor SQL injection where you get hands-on  experience not only exploiting them manually   but also scripting the exploits in Python and  then we also talk about different prevention   and mitigation techniques to prevent SQL injection  vulnerabilities. So it's a really exciting course   that is over 9 hours long. That's amazing  but I need to tell everyone because a lot of   people complain about you know courses on Udemy  and so forth Rana brief what's the difference   between those three platforms because you've got  YouTube you've got your Academy and you've got   Udemy I'm assuming like YouTube's free but you get  ads and stuff like that right? Yeah absolutely so   YouTube you can watch it for free however you  will end up with having to watch sponsor ads   and also YouTube ads and there's for some of the  videos there's no Auto transcription which a lot   of people ask for the second option is to buy it  on Udemy, so over there there's no ads there's no   sponsor messages and there are auto transcription  features so there is an auto transcription feature   there which is really useful for other people and  I believe there's also a Discord channel so David   Bombal Discord Channel where you gain access to  his team and the support of his team and I'll   also pop into that Discord Channel every once in a  while to help out as well now the third option is   my Academy that's where you gain access to the  entire web Security Academy series content not   just the SQL injection content it's a little  bit more expensive than Udemy but over there   again you gain access to a ton of vulnerabilities  instead of having to purchase individual modules   on their own on Udemy and and you gain access  to my own private Discord Channel where you   can ask me questions. Yeah Rana I think what's  fantastic about that is you know it's different   options for different people if you're struggling  financially go and watch the content for free   on YouTube but I know a lot of people preferred  paying $10 or $20 whatever the course price is on   Udemy whether it's discounted or not and then they  can watch it sequentially in a platform that's   built for courses with no ads and I will say this  as Rana mentioned my team are providing support   Udemy has its own support system so a lot of  support is done that way but the best place   to go is my Discord where there's a whole bunch  of people that can help you if you're struggling   and obviously you don't necessarily get that on  YouTube the ultimate option is to buy the course   from Rana's Academy where you get access to her  where she provides the support and you get access   to a whole bunch of other content so different  options for different people hopefully one of   these options is great for you who's watching but  Rana let's give people a taster you have got a   demo I believe with a SQL injection but perhaps  you can like take us down this road what is SQL   injection? Why do we care and you know how does  it actually work practically? Yeah absolutely so   um like David said uh today we're going to be  covering SQL injection vulnerabilities so SQL   injection for the longest time fell under the  number one most critical security risk-facing   web applications today it only changed to  number 3 about a few years ago so today   um we're gonna get a taste of that of course we  can't learn everything it's a 9 hour plus course   so today we're going to go over uh the technical  details behind SQL injection vulnerabilities we're   going to learn about the different types at a high  level overview of SQL injection vulnerabilities   and then we're gonna do some hands-on experience  so um we're going to gain some experience manually   exploiting uh SQL injection vulnerabilities  but we're also going to automate one of the   exploits in Python and then we'll learn  different medication techniques for SQL   action vulnerabilities. All right so we'll start  off with talking about what is a SQL injection   vulnerability so SQL injection is a vulnerability  that consists of an attacker interfering with   the SQL queries that an application makes to the  backend database let's take an example to better   understand this imagine you have an attacker a  web server and a database now the application is   similar to pretty much every application that you  interact with it has some kind of authentication   mechanism and in this case it's a username and  password so form-based authentication it asks   you for your username and password if you enter  the correct username and password it makes a query   to the backend database with that username and  password if they exist in the backend database it   logs you into your account, if they don't exist in  the backend database that means you're not a user   of the system or you entered them incorrectly and  so it'll give you an error saying you have entered   either an incorrect username or an incorrect  password. That's essentially how kind of web   applications work when it comes to form-based  authentication now the issue over here is that   if this client supplied input so the username and  password that you as a client put in if this goes   directly into the query and it's not validated  in any way in the backend database then you could   potentially inject SQL code that interferes  with the SQL database and when you do that   there could be catastrophic results it could be  authentication bypass it could gain full-on remote   code execution you could be able to read certain  content from the database and so on and we'll see   many examples of that. But as an attacker  right now what I want to do is gain access   to the administrator's account however I only  know that the admin user has the username admin   and I don't know the user's password so what am I  going to do in this case? I'm gonna try to see if   the application which uses a SQL Server so a SQL  database in the back end I'm going to see if it's   vulnerable to SQL injection and the way I do that  is again I inject SQL code that could potentially   interfere with the backend database. So over here  let's say the query that the application makes to   the database is Select star so select everything  from the users table where username is equal to   the username that you put in here and password is  equal to the password that you put in here. Now   once again you put in the username and password  it checks is this a valid username and password   if it is it returns a user's profile otherwise  it gives you an authentication error. Now in   this case what happened is that we added as an  attacker we added admin and then single quote and   then dash dash over here and so if this query is  not parameterized or not validated in any way in   the back end any character that is also a sequel  character will be interpreted as SQL code so over   here the single quote is a SQL character what ends  up happening is this single quote over here closes   off the single quote for this string over here so  it closes off the admin string and then the dash   dash represents a common character in SQL and so  it says comment out the rest of the query so what   ends up happening is the entire query becomes  something like this so select all the entries   from the users table where username is admin. Now  the query is no longer asking for a password and   so the database checks is admin a username in the  database the database response yes it is and so it   returns the admin profile and the user gets logged  in as the admin user and it's as simple as that.   And Rana what I really love about you know what  you do in the real world is you you are working   with app developers and you're doing this stuff in  the real world right? Yeah absolutely so I started   off in my career as a pure pentester so I used to  find these vulnerabilities all the time however I   realize that when I do find these vulnerabilities  depending on how critical the vulnerability is   and the timelines that the developers have they  usually then fix a vulnerability just because as   a for pentest we do it at the latest stage of the  software development life cycle so I was kind of   tired of um the developers and the team deciding  not to fix vulnerabilities and accepting the risks   just because they don't have the time to push it  in production in time and so what I ended up doing   is I actually switched into application security  so now not only do I pentest applications but I   also work with developers at earlier stages of the  software development lifecycle to make sure that   they find these vulnerabilities earlier and so  they have time to fix them. So I mean on YouTube   I always get these comments um David this is dumb  it's too simple so this example that you've given   us is this actually real world that you've that  you've found in your experience? Absolutely so   I found this exact vulnerability in a previous  application location now frameworks have built-in   defenses right now that and everyone is using  parameterized queries and so it's less likely   that you find this specific vulnerability where  you could just bypass authentication however I   still continue to this day find different types  of SQL injection vulnerabilities they're just a   little bit more advanced and what we're going to  do in the presentation today is have this exact   example so gain some hands-on experience and  that would be the simplest one and then with   each lab it increases in difficulty of course  we're going to do just 3 laps just because of   the limited time that we have however in the  course we have again about 17 or over 17 labs   where each one goes from practitional levels so  the easiest and simple cases of SQL injection   which you could still definitely find today but  each one increases and level up until you get to   expert level which are definitely ones that I  find in applications that have been developed   in the past couple of years. I love it I love  that you're sharing you know with the community   um your experience and that it's real world  but Rana I don't want to take you too much on a   tangent you've got more more demos is that right?  Yes yes I do so if we move on um at the beginning   of that presentation I mentioned that for the  longest time uh this vulnerability category fell   under the number 1 most critical security risk  facing web applications today so the OWASP top   10 is essentially just the list of top 10 most  critical security risks facing web applications   and it's compiled every year now 2010 is not  included on the slide however in 2010 in 2013 and   in 2017 injection was considered to be the most  critical security risk facing web applications   uh today in SQL injection falls under that  category and again the reason is because injection   vulnerabilities usually allow you to perform  variety of things and specifically SQL injection   it allows you to bypass authentication it allows  you to read the content of the database which   usually leads to bypassing authentication and then  depending on the Privileges that your database is   running with it could even potentially allow you  to gain remote code execution and so it's a major   vulnerability that you should definitely test for  if you're a pen tester and if you're a developer   you should definitely be on the lookout board to  make sure that you're using proper secure coding   practices to make sure that you don't introduce  that vulnerability into your code. Alright so   this is the first lab I've got the link to the  lab on the slide and we'll also include it in   the description of the video so over here you've  got a regular shopping application that allows   you to shop online and essentially buy items  however in order to purchase an item you need   to log into your account now me as an attacker I  don't have any funds to buy any items and so my   main goal is to gain access to the administrator's  account which can buy any item that they want now   the assumption that I'm making over here is  I have the administrator's username so we're   going to assume that through let's say awesome  techniques or open source intelligence I figured   out that the username of the administrator user  is administrator but I wasn't able to gain his   password through password dumps and now I'm stuck  trying to find a vulnerability in the application   that will allow me to bypass authentication and  gain access to the administrator's account without   knowing the password of the administrator so the  first thing I'm going to do is try and figure out   if the application could potentially leak a SQL  query just so that I don't have to guess it on my   own so to do that you just enter SQL characters  which could potentially break the backend query   and then generate an error so I'm just going to  enter a bunch of characters that will be viewed   as SQL code hit login and see if it generates an  error, now right away you see that the error is   suppressed and it just gives you an error saying  that it's an invalid username or password and if   I look at it through my proxy right over  here you could see that the error is also   so we could send this to repeater to see it a  little bit better but you could see over here   that the error is also suppressed at the um at the  client level as well so in the proxy um and so I'm   out of luck it's not going to tell me the SQL  query so I'm stuck kind of guessing it so based   on previous experience my guess is that SQL query  looks something like this so let's say select star   from the users table where username is equal  to whatever username you give it and password   is equal to whatever password that you give it and  so just like with the example now I need to figure   it out a way to um change up the query so inject  SQL code to change up the query a little bit so   that it's no longer asking for my password and  to do that I'm just going to take the username   that I've enumerated put it in here and then  now I need to close off this single quote so   I'm going to close it off and then comment out  the rest of the query if you don't comment out   the rest of the query you're going to have a  quote over here that is essentially just like   a lost quote that doesn't close off anything and  so it'll end up generating an error and then also   you have the Clause of what's the password  as well and so by commenting it all out you   essentially remove this entire uh string right  over here and so I'm going to copy my payload   and hopefully that's going to allow me to log  in as the administrator user so I'll just add   any random characters for the password it  doesn't matter because it'll get inputted   over here and this entire part is commented out  so we hit login and here we go we were able to   log in as the admin user and you could see it  says congratulations you solved a lot it's as   simple as that. This was a practical demonstration  of what you just showed in the slide and Rana just   um because this question people always ask  when when they take courses on Udemy or other   platforms you've got these kind of labs in your  course right? Yes um so these are Labs that are   provided by PortSwigger so the same organization  that created um the burp Suite tool which everyone   uses and the same authors of the web application  hackers handbook which is considered to be the   Bible of web security personally in my like in my  opinion I think these this is the best resource   in order to teach web security and so what I do  is I use the labs in my course and in fact my   videos my YouTube videos are integrated also  in the PortSwigger Academy itself under each   Lab. You know that's what I love about the way you  teach it's um and I'll just have anyone who hasn't   watched Rana's videos go and have a look at them  on YouTube you have this amazing ability to take   complex topics and explain them very very simply  but also give us a whole bunch of like practical   examples of that so this is fantastic. All right  um let's move on to talking about the different   types of SQL injection vulnerabilities okay  so there are overall 3 different types of SQL   injection vulnerabilities the first one is called  In-Band or Classic SQL injection that's where   um the communication Channel where you send the  payload is the same channel where you receive the   response so in the previous example we sent our  payload administrator single quote dash dash in   the application and we were able to automatically  receive the response in the browser itself where   we logged in as the administrator user that's a  type of In-Band SQL injection now Inferential SQL   injection or also Blind SQL injection is a little  bit different so when you send your payload you   don't receive the exact response in the same  Communication channel so you're kind of stuck   asking the question true and false questions  instead of asking the application to give you   the result of your payload you would have to ask  the application hey is so and so true and if the   application responds in a certain way then you  can infer that it's true and if it responds in   a different way then you can infer that it's  false. So it's a little bit more difficult   to exploit than um embed SQL injection. The last  type is Out-of-Band SQL injection that's where you   definitely don't receive the response in the same  Communications Channel you would structure your   payload in such a way where um where you send your  payload and then um the response of your payload   will be sent to you in an attacker controlled  server so you would have a server that is out of   band and set up that you control and the response  of the payload that you send in the application   gets sent to your server itself. Again this one is  also a little bit harder to exploit than In-Band   SQL injection now for today we're not going to be  able to cover all the different types and subtypes   of SQL injection vulnerabilities and so we're just  going to cover 2 more examples the first one is   union-based SQL injection and then the second one  is going to be Boolean based blind SQL injection   and we'll move on to the second exercise which is  a SQL injection using the union attack to retrieve   data from other tables. Rana we obviously don't  have the time to go through them here but in your   course you cover a whole bunch more right? Yeah  that's correct so um in today's demo we're just   going to cover uh 3 Labs of varying difficulty  levels however we're going to end up having to   make a bunch of assumptions because for example  the third lab on its own takes about 40 minutes   to kind of be able to explain how to exploit  that SQL injection vulnerability just because   it's more on the expert level where you need to  know certain pieces of information in order to   be able to do it however in the course what we do  is we have a video for each lab and we have again   I believe over 17 labs in the SQL injection  module where we go in depth and in detail on   each lab we'll start off with a practitioner Labs  which are considered to be easy and then we'll   move on to your intermediate labs and then we'll  reach the expert Labs where um we'll exploit kind   of really intricate SQL injection vulnerabilities  that can be found by automated tools because you   need to keep going back and forth between the  application until you figure out what this SQL   query is and then keep going back and forth with  the application until you actually exploit the SQL   injection vulnerability. All right so this is the  second lab again it's a shopping application I've   got the link on the screen but will also include  the link in the description of the video so in   this case the SQL injection vulnerability is not  in the login page so we're not going to try and   attempt to bypass authentication by exploiting the  login page of the application instead we're going   to try and see if the application has any other  SQL injection vulnerabilities in other parameters   that talk to the back end. So in a real world  application the first thing that you would do   is figure out all the different parameters in the  application that potentially talk to the backend.   So let's say over here we're gonna say corporate  gifts so let's click on that and see the request   that is being made by the backend and we'll  make that a little bit bigger and send this   one to repeater now over here you could see it  takes in a parameter called category and then   it takes in that category that you selected and  then based on that it displays the different uh   products in that specific category. Now for sure  I know that this parameter over here is talking to   the back end because it needs to tell the backend  that I selected this specific category in order   for it to show me these specific items under this  category and so the first thing I'm going to do   is test this for a SQL injection vulnerability  so I'm going to click Send right over here and   see if it generates an error so it does give me an  internal server error however it looks like it's   suppressing the error and so again I'm out of luck  in this lab and I can't uh and I can't output the   query itself so I'm stuck guessing it. So based  on my previous experience my guess is the query   is going to look something like this so let's  say select star from let's say category table   it'll be slightly different but the idea is the  same so select star from category table where   category is equal to the category that we give it  right over here so in this case it was corporate   gifts so let's add that right over here and then  uh once the SQL database receives that query it   queries the database and then it'll output all  the items that are under the corporate gifts   category. So right now we have a different type of  SQL injection and this one is specifically called   Union based In-Band SQL injection and the reason  it's called Union based is because it uses the   union operator so the union operator is spelled  like this and essentially what it does is it   allows you to combine two queries together so my  aim right now as an attacker is not only to get   it to run this query over here but I want to use  the union operator in order to get it to perform   a query of my liking and the query that I'm  interested in is the password of the administrator   user and so what I'm going to do is make sure  that this is a valid query and the first thing   I'm going to do is add a single quote because  I need to close off this single quote over here   and then I'm going to add my dash dash to comment  out the rest of the query and then from there I'm   going to use the union operator in order to add  my query so we're making a few assumptions in   this lab again in the course what we'll do is  we'll actually teach you how to enumerate the   fact that there is a user's table in the back end  and the fact that the username and the password   are columns exist in the users table but right  now we're going to assume that we already know   all of that and so in order to exploit the SQL  injection vulnerability we're going to say Union and we want to say select the username and the  password from the users table however before we   do that we need to actually follow the rules  of the Union operator and there are two rules   in the union operator the first one is that  the two queries so this one right over here   and whatever query you write have to have the  exact number of columns so we'll write that down   we need to figure out the number of columns  and two the columns have to have the same type and so if you don't follow these rules you'll end  up erroring out and as we saw over here you'll   just get an internal server error and you won't  know why you ended up erroring out. And so the   first thing we're going to do before actually  writing up our query is we're going to try and   figure out the number of columns and the way we're  going to do that is using the order by clause.   What that does is when you order by a column  if you don't get an error that means the column   exists but if you try to order by a column that  does not exist you end up getting an error and so   you can infer that the column does not exist. So  we'll start off by ordering by the First Column   which we know for sure exists because if you just  look at the application right over here you could   see that there's at least a column for the name of  the item and then there's also at least a column   for the description of the item now there might be  a third column like an ID column that doesn't show   but is used by the database just to keep track  of the different items but we don't know that   for sure so we need to kind of figure that out on  our own and again we'll do that using the order by   cause so control U to URL encoder hit send and  we get a 200 okay so that means it ordered by   um the column so we definitely have one column we  start off by ordering by two we still get a 200   okay and so we definitely have two columns we  order by three hit send and we get an internal   server error so that means there's no third  column so we've deduced over here that there   is two columns in the database now the next  thing that we need to do is figure out the   data type of each column because again if we  output something of a different data type in   this query that is different from this query  we're going to error out in our SQL injection   is not going to work. So the way to do that is  to use the UNION operator and say select and   then put the data type over here so my guess is  they're both strings so sets of characters just   because you can see over here it's a character  and over here it's alphabets at least it   could potentially be alphanumeric with certain  characters as well so I'm just going to say a and   a and see if that works if it doesn't work that  means one of them is incorrect so let's copy this put it in here and URL encoder hit send and we get an internal server error  meaning that something must be wrong so if we   go back to the query right over here I can  immediately tell what's wrong it's because   I added this for some reason and I don't know why  I added that. So it's nice if you make a mistake   and troubleshoot it so that's great actually. Yeah so um in the course you'll see a lot of   that and the reason I've decided to keep that in  the videos is because I've had a lot of comments   um saying that people learn that way and so I've  decided to every time I make an error I actually   include it in the course just so that people  learn how to debug um their code as well so   hit send and now we get a 200 okay meaning that  both columns except strings. So now I know that   I can output my information in those columns so  I'm going to say select username and password from the users table again we're making the  assumption that we know that there's a user   table um in the course I will start off in a  few first few Labs making that assumption just   because we want it to be simple for the user to  kind of get the hang of exploiting SQL injection   vulnerabilities before we get into more technical  details and more difficult Labs but we will teach   you in the course how to identify that it is  using a user's table and there is a username   column and a password column in the users table.  So let's copy this right over here put it in here and then again we need to URL encoder   or the request won't be valid hit send and  we get a 200 okay that's a good um that's   a good indication that our exploit worked so  now what's going to happen is because we use   the UNION operator it's going to run this query  over here which will output this entire content   over here but it'll also combine that query  with this query over here so it should output   the content of this query over here which is all  the users in the database. So if we go down right   over here we should see users and here we go so  you could see it right right away that we've got   an administrator user and this is the password of  the administrator user and if we go down here's an   yeah and if we go down here's another user here's  another user and these are all their passwords now   in a real world scenario most applications right  now um will hash their passwords in the back end   they won't save them in clear text in which case  what you would do is extract the hash that's still   a pretty useful piece of information to help  so you extract the hash and then from there   you try to perform a dictionary attack on the  hash and retrieve the plain text password but   again for simplicity over here it just in plain  text so we're going to copy that go to my account go to administrator and then paste the password over here and  hit login and here we go we logged in as the   administrator user. What I love about what you're  doing though and I think something that everyone   who's watching can can see is that you give us  the this is the the way to learn because when   you learn you have to keep it simple and then  you give us like okay here's the real world   um stuff that you need to need to be aware of and  I love that that you're giving us both because   the problem if you know I always say this it's  a curse of knowledge some people who have too   much knowledge forget that people who start don't  have enough knowledge to you know go to the full   production level you've got to start slowly you  know you've got to you've got to crawl before you   can run so crawl walk run and I love that you're  doing that Rana taking us from you know here's   some simple examples to at the end of the course  like here's the expert level. Yeah absolutely so   that's how I learned myself and I always try  to teach it in the way that I would have wanted   to learn it if I was just getting started right  now.Rana that was a brilliant demo and what I   love again with what you're doing here is you're  taking us from a very simple to a more complex   one and I believe you've got a third one that's  even more complex right yes I do so here's the   third lab over here again I've got the link on the  screen and we'll add the link in the description   of the video as well so it's the same shopping  application that we've been dealing with with the   exception right now that both the login page is  no longer vulnerable and also the search field for   the category is no longer vulnerable anymore and  so now we need to look for even more parameters   that talk to the back end that could potentially  be vulnerable so this is one of those labs which   is more on the difficulty level because we're no  longer dealing with embed SQL injection where you   receive the response in the same channel as uh  the one that you inserted your payload on now   you have to kind of infer the response and that's  why it's called inferential or Blind SQL injection   by just asking two on false questions so first  of all um if we look right over here you could   see you've got the home page you've got the my  account page and now we're going to visit a page   the application and view the request just to  determine how the application functions. So   let's make this a little bit smaller and let's say  we go to accessories all of a sudden I see that   there's a welcome back message so my guests over  here there's some kind of cookie or there's some   kind of tracking mechanism that is being used  to determine that this is not my first time on   the application because when I first visited it I  didn't see that we'll come back but when I visited   another page I see the welcome back message. So if we look at the request right over here   let's go let's make this bigger you could  see and actually we'll send this to repeater   and hit send and if we search over here you'll see  there's a welcome back message so if we look at   the request again this is just the category field  that we exploited in the previous lab and in this   lab it's no longer vulnerable the other parameters  that could potentially be talking to the back   end are the cookies. So most people will not test  cookies for injection vulnerabilities just because   they assume that they can be vulnerable however um  cookies are a great way especially custom cookies   are a great way for you to potentially cause  a lot of harm to the application it's usually   missed by novice pentesters or pentesters that  don't have much experience and so today for this   lab what we're going to do is we're going to  exploit the tracking ID cookie to essentially   bypass authentication in the application uh  so right now um I see that we have two cookies   there's the session cookie which is generated by  the framework so it's quite unlikely that there   is back-end code that extracts this cookie and  then uses it somewhere else so the session cookie   which is generated by the framework usually  does not have any injection vulnerabilities   however tracking ID is definitely a custom cookie  so my guess is that it is definitely used in some   kind of custom code and if there's no proper  validation it could be vulnerable to a variety   of injection vulnerabilities and SQL injection  is just one of them so again what I'm going to   do is just insert a single quote over here see if  I could break the application it's a 200 okay so   it does not tell me that it's actually vulnerable  um so we're gonna have to kind of guess what the   query looks like in the back end and then based on  that and based on the response of the application   um figure out if that query is actually what it  looks like and then how to exploit that query but   before we do that there's one thing that we need  um to kind of like notice over here and that's   the fact that no matter what you change this to  it's not like you could output the content of your   SQL injection in the response and that's why it's  called the Blind SQL injection because you can't   just use a UNION based injection because like we  said with UNION based SQL injection the query has   to have the same number of columns as the original  query however this one doesn't actually output any   content in the page and so this is definitely  going to be a blind SQL injection vulnerability   if it's vulnerable and so we need to figure out  a way of how to tell if when we ask it a true   and false question if it's responding with true  or it's responding with false and the way we're   going to do that is essentially we're gonna see  a variation of the response depending on whether   it's true or false so if we hit send right over  here this is a tracking ID that we know exists in   the backend database and you see over here we get  the welcome back message however if we add another   character we know that this tracking ID no longer  exists because we've changed it up and we hit send   and we no longer get the welcome back message and  so that's what we're going to use in order to ask   the application true and false questions if it's  true the application will respond with a welcome   back message if it's false the application  will not have a welcome back message in the   response of the request and this is why I said  these ones are a little bit harder to exploit   um so a few assumptions again we know that the  database has a user's table and the user's table   contains a username and a password column and the  username that we want to enumerate the password   for is the administrator user so um we're gonna  try to kind of figure out what the query is and   then try to exploit it so let's say the query is  Select star from let's say tracking ID table where   tracking ID is equal to this tracking ID right  over here and we'll remove the X because we added   them so now we should see them we'll come back  message let's copy that and paste it in here so   this is the regular query now I need a way to make  the query output a true statement and see if it   still gives me the welcome back message and then  make the query output a false statement and then   see if I don't get the welcome back message and if  that's how it works that means this is definitely   vulnerable to SQL injection. So over here I'm gonna  say single quote to close off the string right   over here and then I'm going to say and 1 is  equal to 1 and comment out the rest of the query   so over here what I'm asking it is does this  tracking ID exist in the tracking ID table which I   know it definitely exists because the application  gave it to me so this will report as true and then   I'm asking it and is 1 equal to 1 and 1 will  always be equal to 1 and so true and true will   evaluate to true so this is where math the very  few cases that math is actually useful in life   um. How come math is easy for Sheldon and not  for me? So let's copy this paste it in here   and see if we still get the welcome back message  if we do then this is definitely vulnerable to a   Blind based SQL injection okay hit send and here we go. So you can see we do have a match on the welcome   back message so the application was actually able  to evaluate the and operator and then evaluate   that 1 is equal to 1 and then respond with the  true case. So now let's test it out for the false   case and see if the application does not respond  with a welcome back message so we're going to say   1 is equal to 0, so again we know that this  will evaluate to true because this tracking ID   exists in the database but 1 will never be equal  to 0 so this should evaluate to false so true   and false should be equal to false. So we shouldn't  get the welcome back message so let's copy that   and then Ctrl U to url encoder hit send and  here we go okay so now it's done correctly um so   0 matches over here meaning that when we force  the application in a true use case it responded   with a welcome back message and when we force the  application in a false use case it responded back   with ah with a lack of a welcome back message so  now that means we can ask the application true   and false questions so for someone who kind  of doesn't have experience in this the first   thing that they'll maybe suggest is why don't  we ask the application if the administrator's   password is let's say password one exclamation  mark so it would look something like this so we have to put that in kind  of uh brackets so select password from users table where the  username is equal to administrator and and we have to put that in single quotes and the password oh actually we don't ask for the password over  here because it's a true and false question so   we're going to say and select the password  from the users table where username is equal   to administrator and we're going to ask the  application is the password let's say password   one exclamation mark. So now we're asking the  application again a true and false question   we're asking it I want you to extract the password  from the users table where the username is equal   to administrator and I want you to tell me if  it's equal to password one if it is equal to   password one it'll respond with a welcome back  message but if it's not equal to password one   it won't respond to a comeback message  so intuitively this might be like the kind of   thing that you would suggest that you should  do however it's not the smart thing to do and   the reason is because why go through all the  trouble of building a SQL query and actually   um exploiting the SQL injection when you could  just simply do it by going to the my account page   and literally brute forcing the password over  here right so you would just put password one   over here and if it logs you in that means you're  the correct user and if you're not uh and if it   doesn't log you in that means um you put in the  incorrect uh password so this is not very smart   we're going to say not smart um the smart way to  do this is to actually be able to enumerate the   password with a finite number of characters so  over here it's infinite number of possibilities   a password could be anything but we were going  to structure our query in such a way that with   a finite number of operations we're going to  be able to enumerate that password and the way   we're gonna do that and it might seem like it's an  infinite thing but it's actually something that we   could easily automate is we're going to ask the  application Is the first letter of the password a? and if the application responds with the welcome  back message that means yes the first letter is   a and we could move on to the second letter but  if it responds with no welcome back message that   means we're going to ask the application  is the first letter of the password b   and then we're going to do that for c and  so on until it responds with a welcome back   message and that's where it gets a little bit  tedious and you no longer can do this using   um using um manual techniques and that's why  I've actually written a Python code for that   um so if you look right over here I'm just going  to make this a little bit bigger if you look right   over here this is a Python script that is a really  a really good example of the Python scripts that   you'll see in the course and we actually write  them from scratch in the course so we don't just   give you the script we'll actually build it  together but the idea yeah but the idea over   here is that it just takes in a URL it also takes  in the correct tracking ID and a valid session ID   and then from there it asks the application to run  false questions and you can see over here there's   2 for Loops because it'll Loop through each  letter and actually each alpha numeric character   and until it gets a welcome back message it'll  move on to the next position in the password so   it'll move on to the second character and then the  third character and so on and depending on how big   your password is it could take um some time so the  password over here is actually 20 um 20 characters   in length so we're going to say terminal a new  terminal and we're gonna run it but before we do   that we just need to put in the correct uh  tracking ID so if we go to right over here   and just copy the tracking ID paste it in here  and we'll also include the link to the Python   code in the description of the video alright  so we put in the correct tracking ID and the   correct session ID so now it's as simple as just  saying python3 and then we're going to say example   three code.py and add in the URL of the vulnerable  application so let's copy that paste it in here and it's just the main URL and then we're just  going to hit enter right over here and essentially   what it's trying to do right now is to retrieve  the admin password and you could see over here   it's trying all the different um alphanumeric  uh characters also a bunch of other characters   until it enumerates it and the first one is  actually the number five and now it's trying   to guess the second uh character of the password  which is b and now the third character and so on   and I love this because you said it's a 20  character password right? Yes that's correct   so um it's essentially trying all the different  letters and all the different numbers and all the   different characters for each position of the  password so for each character of the password   and if we go to prep right over here the way we  the way I write my scripts is by actually sending   all my requests to my proxy just in case I need  to debug a script if it doesn't work. So you can   actually see all the requests being performed  right over here in the tracking ID with like   the character that it's trying. I love it that you  didn't choose a simple password or I mean this lab   isn't a simple password because that's also you  know people something people always complain about   on YouTube is like oh these passwords are too  simple it's great to see like a complex password   being being broken like this. Oh yeah and the way  the Portswigger labs are is that each individual   will have a randomized password and so even if  you copy the password that is on the screen you   won't be able to stop the lab you actually have  to enumerate it yourself because it's going to be   a different password for your instance of the  lab. So one thing I wanted to ask you you said   previously but you know you could enter the  password into the um like the the UI and try   and like guess what the password is and the same  thing here isn't there like a password lockout so   um is that just a weakness in the way that  the the website was written or something   or is it just like this is a vulnerability  in SQL? That's actually a really good point   um so over here I said you could just log into the  account or attempt to Brute Force the password on   the login functionality now um this would not be  possible if there is some kind of soft lockout   to some kind of firewall or rate limiting that  doesn't allow you to actually Brute Force the   password and that's where where you could  actually use a SQL injection vulnerability   to try and Brute Force the password and not go  through you know the trouble that we did by the   SQL injection vulnerability because that cookie  will never have some kind of lockout on it and   that's that's actually an interview question  that I had um uh back when I started out in my   interviews if you were to Brute Force let's say  the login page versus a cookie that contains the   password which it should not contain but in this  case it does contain the password where would you   run your Brute Force mechanism would it be on  the login page or the cookie? And the answer is   always the cookie because usually there's no rate  limiting or lockout on the cookie whereas there   is like limiting a lockout on the login page. yeah  cookies just seem to be a nightmare I mean this   whole thing where YouTubers including me that way  someone's cookie was stolen and they were able to   log in to their session and like do stuff on the  on the YouTube channel it sounds like cookies are   just an absolute nightmare sometimes. Yeah so um  while we're actually on that topic um a cookie is   essentially just your short-lived password  it's a randomly generated depending on the   application but it's usually a randomly generated  number or set of characters that represents your   uh password it's a short-lived password so it's  not your password itself but it represents your   password and so what you need to do is ensure  that the cookie has the HTTP only Flags set   on it if it has the HTTP only flag set on it that  means that JavaScript including the JavaScript of   the application itself can't access the cookie  so it makes it really difficult for it to be   stolen unless the user actually compromises your  computer itself now that's not your responsibility   that's the responsibility of the developers they  should include that flag on the cookie to make   sure that it can't be stolen at least remotely  by an attacker. Already that's great yes yeah   so it already cracked it so let's copy that and  then try to log in with the administrator user   hit login and here we go we get the account page  and it says congratulations you solved the lab   so Rana what you've done in previous videos is  you've told us or shown us the the vulnerabilities   and how to exploit them but then you you showed  us how to prevent it do you have that kind of   information here as well? Yeah absolutely um so  when it comes to SQL injection vulnerabilities   the primary defense is the use of prepared or  also called parameterized queries and we'll go   more into that into depth on that as well um but  there's also additional defenses that you could   do to make it extremely hard for me as an attacker  to exploit these SQL injection vulnerability and   that's through enforcing the least privilege  and having a whitelist input validation or an   allowed list input validation as a secondary  defense but like I said the primary defense is   the use of prepared statements so if we look at  this code right over here you could see that the   state that the query itself takes user supplied  input directly from the request so you can see   over here it says request.getparameter and takes  in the customer name and then it automatically   injects it in the query and so in this case you  could apply all the different methods that we   learned about today in order to exploit this SQL  injection to perform malicious actions however if   you were to use prepared or parameterized queries  what essentially happens is that you separate the   client supplied input or data from the structure  of the query itself so essentially by the backend   database it's performed in 2 steps the first  one is that the application specifies the query   structure with placeholders for each user input so  the structure is kind of set in stone and it has   placeholders for the user's input and then your  input is put in that placeholder now no matter   what your input is whether it has a single quote  or a dash dash or the union operator or whatever   now it's only viewed as a string it can no longer  be interact with the SQL query itself because the   structure of the SQL query is already set in  stone and defined and that's essentially how   prepared statements work they make it impossible  for SQL injection vulnerabilities to exist   um if you were to use that secure coding technique  and this is an example of how you would prevent   SQL injection in the example that we saw in  the previous slide so over here the query   is defined and then it sets a placeholder  for the username and then you use prepared   statements or parameterized queries in order to  define the structure of the query and then add   um add the user supplied input which is the  customer name to the query itself. So this is the   primary defense for a SQL injection it'll always  be the go-to defense it's definitely the one that   you should use however there are additional  defenses that would make my life harder as an   attacker and the first one is the use of least  privilege. So making sure that the application   uses the lowest possible level of privileges when  accessing the database and the reason is this is   important is because if you do for whatever  reason have a SQL injection vulnerability   the impact of the SQL injection vulnerability  will largely depend on the Privileges that you   use in order to access the database. So certain  functions that give your remote code execution   on the database are only available for privileges  like sys admin privileges and if I have CIS admin   privileges MySQL injection vulnerability is going  to have such admin privileges and so I'm going to   be able to gain remote code execution on the  server so make sure you run it with the lowest   possible level of privilege the second one is any  unnecessary functionality in the database should   be removed or disabled so the more functionality  I have the more um the more my attack factor is   going to be and the third one is Ensure your CIS  Benchmark for the database in use is applied so   the CIS benchmarks are essentially just sets  of configuration that you could use in order   to ensure that you're either secure by default or  you add a layer of security to your system or your   database or your server and so on and there is one  for each different database type that you could   use in order to ensure that again it makes my life  as an attacker a little bit harder if I were to   find the SQL injection vulnerability and then the  third one is pretty obvious so all vendor issued   security patches should be applied in a timely  fashion now the second additional defense that you   should use which I really hesitate putting on my  slides but because I see it everywhere I have to   um it's an allow list of input validation so  have an allow list or also known as a whitelist   of characters that are allowed for this specific  field now the reason I hate to put this on the   slide is because let's say a single quote you  would say that's not a lot and so you wouldn't   put it in the allow list however if it's a  name field then my name is let's say O'Reilly   I need that single coat in my name yeah and so  what happens is that usually customers complain   and the developers go like oh okay that's fine  we'll just add it to the allow list or the white   list and then this will happen for essentially  every character and the in the alphabets and every   every character that there is because people's  names are different and depending on the field   it's different then you might need characters and  so even if you weren't vulnerable to SQL injection   in time you will be vulnerable to a SQL injection  because you need to accommodate user experience   um and so I definitely don't recommend  this it's just an additional defense   um to the use of parameterized queries and that's  essentially it when it comes to how to defend or   mitigate against SQL injection vulnerabilities. I love it I love it that you show you know the   the problem and then you show us how to solve  it and I mean people watching this video might   be interested more on the red team side some  people may be interested in like the secure   coding side so I really appreciate that you show  both and in the course you do both as well right? Absolutely um so in the course we have  uh what we call a theory video where we   actually go over the technical details behind  the vulnerability the different types of SQL   injection vulnerabilities and then the prevention  techniques also explained in more detail and   then we have all the lab videos which give you  hands-on experience in exploiting SQL injection   vulnerabilities. Rana in your experience are  developers making a lot of these basic mistakes   or is it getting better? um it's definitely getting  better so SQL injection vulnerability is used to   find them in pretty much every application now  and it would be on the login page and it would   be as simple as the first example that we saw so  with admin single quote dash dash you immediately   find you immediately bypass authentication  however right now they're getting a little   bit harder so it would be more to the difficulty  level of this lab than the difficulty level of   lab number 1, so they definitely still exist it  just as a pentester you just need to get better   um at finding them in kind of those odd places  like the cookie and so on so definitely still   see them in real world. But in your course I mean  that's what I love what you've done you've taken   you're taking people from the very basics so they  can understand and then you're taking them to like   this crazy expert level which is more real world  right? Correct um so if I were to kind of go over   this code right away I from the beginning most  people will find this very daunting and would   think oh hey hacking is for only like the  smartest of the smartest people and so on   um however when you kind of do things um like  in order and like from really simple up until   to expert level you realize it's just a matter of  understanding the concepts and once you understand   the concepts this becomes really simple. And just  for everyone watching Rana I really appreciate   you sharing your knowledge by making it freely  available on YouTube so for those of you who   can't afford to buy the course in Udemy or can't  afford to buy it on Rana's Academy just use the   link below and go and watch the videos for free on  YouTube but for those of you who you know want a   structured course with some support go and buy it  on Udemy to support Rana and me really appreciate   you for you know buying the courses this to  support both of us to create more content and   if you really want to support Rana go and buy  it from her Academy where she gets the full   funds lots of options here so Rana again thanks so  much for sharing on this video thanks so much for   creating all of this content make making it freely  available on YouTube but I'm really excited once   again to collaborate with you on Udemy and share  your content with more people thanks so much Rana. No problem happy to help and I'm also very excited  about this collaboration so please check it out   um if you're interested in  the courses. [Music]

Channel: David Bombal

Views: 195,300

Keywords: sql, sql injection, cyber, cybersecurity, moveit, hack, hacking, hacker, pegasus, MOVEit, otw, occupy the web, spyware, malware, iphone, android, infosec, information security, wifi, linux, tails, privacy, cyber security, ethical hacking, online privacy, kali, kali linux, sql hack, database, moveit breach, breach, moveit hack, real world, real world hack, udemy, hacking course, cyber course, cybersecurity course, real world hacks, move it, move it hack, rana, rana khalil, oscp

Id: yusJWttsD5o

Length: 61min 4sec (3664 seconds)

Published: Fri Jul 21 2023