I imagine that you have already heard about many data leaks that have been leaked recently by malicious actors. Most of the time, several vulnerabilities are used in the chain to exploit and obtain data as much as you want. But sometimes a simple injection is enough and it allows you to access the entire database. This injection is the SQL injection and that's what we're going to see today. Well hello everyone. So today, as you saw in the intro, we are approaching a relatively well-known vulnerability. Maybe one of the best known on the web is the SQL injection. But before talking about SQL injection, you have to understand what the SQL language is and also understand web architectures. So, little intro, let's go. So, first of all, a little point on the SQL. What is the SQL? SQL for structuring query language is a programming language that allows you to interact with relational databases. So it will allow you to store, manipulate, recover data that are stored in a structured manner. Relational databases contain a set of tables and so these are the last tables that will allow you to store data. For example, for my blog site, I have a database called Franso. On this database, there are several tables. For example, there is a table called blog with a set of fields, the title field, the image field, the description field, and we also have a comment table with a set of fields, typically the name of the person who posted the comment, the comment ID, and what was written in the comment. Storing data is good, but consulting it is still a little better. There is therefore the SQL select request, which actually allows you to simply retrieve information. For example, the select all from the user that we see on the screen, it actually allows you to retrieve the entire user table. Of course, to refine the selects, there are many things like clauses, logic operators, application functions, that's what we're going to see now. First of all, the clause where, quite simple, quite basic, which is very used, it simply allows you to add specific conditions. For example, select all from user where age is greater than 18, well you guessed it, we will therefore obtain a result, the data of the user table which is over 18 years old, quite logical. Then we have logic operators which allow you to combine conditions, as we can see on the screen here, select all from user where age is greater than 18, end, city, equal to Paris, gold, city, equal to Marseille. Here we use end and gold which allow you to combine several conditions. We also have aggregation functions such as sum, as average, as count, which simply allows you to calculate the values from data from a table. For example, select average salary from employee, we will just select the average salary that comes from the employee table. There is also the union operator, do not forget this one because it will be very important for the future. It is used to combine the results of two select requests, distinct, in a single list of results, and it is necessary to know that the two distinct select requests must have the same number of columns so that it works, otherwise it is not possible. To finish, it is necessary to know that other instructions exist, there is not only select, there is for example update which allows you to update a table, to update data in the table, there is also insert which allows you to insert data, there is also delete which simply allows you to delete the data. Now that you have a good knowledge, a small point on web architectures. Most web sites, I think you know, work with a database on a server, often third, what we call backend, we have the frontend and the backend, it is what we call a two-level architecture . There are also several types of other architectures such as three-level architecture, micro service architecture or service oriented architecture. We will not come back on each architecture but the important thing is to remember that the web site sends requests to the database in order to exchange information, for example to recover all the comments on a blog page. Now that the base is set, we will directly move on to the subject, SQL injection. So in a fairly basic definition, SQL injection is a web vulnerability that allows an attacker to interfere with the requests that a web application addresses to its database. So this allows an attacker, for example, to display data that is not normally able to recover. It can include data belonging to other users or other data that the application itself cannot access. In many cases, an attacker will be able to delete and modify these data, causing changes that are persistent in the content and or the behavior of the application. So the question I think you are asking is how does it work? Well, we're going to do a little lab to better understand. We find ourselves directly for the explanation of how an SQL injection works. So I went to get a little lab that I found on GitHub, very nice from OXNinja, a Frenchman in addition, so do not hesitate. If you ever want to train yourself, the GitHub will be in description, even if there are a lot of labs that exist on the internet. But here what I wanted was to have the source code since it's super interesting and that's how we can understand how it works. So we can see that on this page we have a form, we can put a little whatever we want. We are going to click on get password. What is going to happen at the level of the request? We are going to send that, we can see that the parameter suddenly in post, so if you watched the HTTP video, you know what it is, no problem, that's what we entered here. And we can see that in the page code, it will take $ website posts, so it is the website parameter, so it will recover this value. What is it going to do? Well, it's going to do a select all from level 1, so the level 1 table, where site equal dollar a. Why is there a vulnerability here? Because in fact we do not netize, we do not use prepared requests, we will directly use the $ post of website in the SQL request. So what happens if here suddenly we put test, we will just have a select all from level 1 where site equal test, but if we ever make a parameter a little more tricky, so for example quote or one equal one and suddenly here we will put comments, that's how we put comments in SQL. What is it going to do? It will do select all from level 1 where site equal nothing at all, since suddenly here we put something that is null, we have suddenly added or one equal one, so that's always true, and then we put the small comments to suddenly escape all that and that we ignore all that, finally that the request ignores all that. We will do this request at the database and we will suddenly have the answer. What happens if we suddenly add this payload to the website? We will see that right away, we can put it there, we will encode it, that's it, ctrl u, send, and suddenly what happens? Well, we have access to the entire database since suddenly we made or true in fact quite simply in SQL, suddenly for SQL it must select everything that comes from the level 1 database, not only where site equal something, since here we have nothing at all, but suddenly the site must display everything, the request must display everything, so that's how we can easily make an SQL injection. So here I just want to say that now it's a little clearer for you, we will advance a little bit on the Union-based SQL injection. So you have to know that there are many kinds of SQL injections, here we have seen a fairly basic SQL injection, we will now move on to reviewing SQLs, so SQL injections, often I would say SQLs, it's a little faster, the most common in this video, I had talked about the Union operator in the intro, well we will start directly with a SQL based on the Union. So it's good to have a basic SQL injection, nevertheless a problem arises, the problem is the following, how to recover data from other tables? Normally you will understand a little bit and potentially have the answer, quite simply we will use the Union operator which will allow to make a SQL injection to recover data from other tables since the Union operator allows you to do that. The question now is how do we proceed? For a Union request to work, two essential conditions must be met. I said it before, first of all, individual requests must send the same number of data, it is super important, and secondly, the types of data of each column must be compatible with individual requests, that is to say that we do not have the right to have format differences, so no hint against a string, it will not work. So to lead to a Union-based SQL injection, it is necessary to determine how many columns are sent by the original request, using a methodology for example of error-based, so that is to say we will submit a list of Union select and we will each add a column, until we have a different answer from the base of the data, it will mean that we will have reached the number of columns of the first request and therefore that afterwards we can go a little further. Of course there are other techniques to do this kind of thing, I just gave you a little technique that is quite easy to understand. Then, the second part to lead a Union-based SQLi is which columns sent by the original request are appropriate for the type of data to contain the results of the injected request. So it's a bit complicated like that, but we will simply test column by column, which column will be compatible with the type of data that we have on the first individual request to pass our second individual request. Here we see on the screen, we try on each column, since we have to finish the number of columns that allowed to match our Union SQL injection. And so we're going to do that until we have an error from the base of the data as before, and suddenly there we will have our Union-based SQLi. Now that the theory is somewhat understood, we will directly move on to practice. Hop, let's go, suddenly we find ourselves for the lab on the Union-based attack. So here the goal is to find the username and password columns to connect as an administrator. We are therefore on the lab, we can directly take into account that we can sort and that we suddenly have a category parameter which is potentially injectable. So what we're going to do is we're going to intercept the little request, we're going to hop on the GIFT, we're going to throw that in the repeater and suddenly we're going to quietly make a little Union-based because we know that's how it's called in the lab, so it's pretty simple in any case to know the type of attack to use. So Union-select and here suddenly we have to determine the number of columns. So we're going to start with a first zero, we don't forget to put everything that follows in the comment to ignore it. Here we can see that we suddenly have an error, we're going to add one to see how far we go to have a 200. So there suddenly the first request, the first individual request, has two columns since we have two zeros. So now all we have to do is determine which type of data we have for which column. So if we have ints, varchars, etc. So here we will start with the first one. We have a 200, so that is to say that in fact we already have a varchar in the first individual request and for the second one we also have a varchar. So we can say that we have two varchars in the first one. So what we can do is potentially recover from the user table because it is often a user table, the username and password. So we're just going to try with username and here hop from plus users and we'll see what it looks like. Ok we can render that, normally we will have the answer somewhere on the page. We have username here, we have a a a a a, ok. Small problem because I put it between the codes so necessarily it works less well. So if we do username we see that there is Carlos and administrator. So we can potentially also add a password field because generally the databases have passwords and usernames so we're going to do that quietly. We have a small internal error because I forgot a plus, I will have to encode it. So here we have administrator, winner, Carlos and everyone with their password. So we can easily recover it right here if we type administrator. Normally we will have the administrator, we will copy and paste the password, we will go to the lab, my account, I am in proxy intercept, we will remove that, we will add administrator and ctrl v and we are not connected as an administrator. So the lab is solved super great. Then we will move on to another SQL injection, it is the blind SQL injections or BLIND SQLI. They are quite common since we rarely have results in the HTTP response of our SQL request and therefore most of the time we will use BLIND SQLI. In this kind of context, there are several solutions that will exist to continue to use an SQL injection. I will not go into all the BLIND SQLI, the BLIND SQL injection methods blindly, but we will go over some of them in review, let's go! First of all, we have the BLIND SQLI timebase, so based on the response time. Quite simply, everything is in the title, we will use timing techniques to cause significant delays in the response of the application. So for example by using SQL instructions such as wait for delay or specific timing functions at the database. So if we have our SQL injection that works, it would mean that we will have a response time that will be much higher than normal. So there it means that it's ok, we have a good payload. Also depending on the response time, it is possible to brute force the columns and tables. So brute force is just brute force. For example, the next request on the screen, we try to brute force the name of the database, we start with A% and we will then do all the letters of the alphabet one by one until we have a response time higher than the other letters of the alphabet. And suddenly it means that in fact the table will start with the letter where there will be the greatest response time and we will be able to move on to the second letter and so on. So of course you must tell yourself that it is a bit tedious and a bit long, but many tools do that for pen testers, there is no need to do that by hand and therefore fortunately. And so thanks to that, we can determine the name of a table, the name of the columns and thus dump, extract a database. Of course it is a little longer than a classic method, but it is quite viable. The SQL injections based on conditional errors are easier to understand. We will directly take an example with a web application that uses cookies, like all web applications currently. But this web application uses it to make a SQL request that we can see on the screen. So on the screen, normally you want to tell yourself that there is potentially an SQL injection. The problem is that we do not have a return of results of the SQL request in the HTTP response. So we will still have a blindsqli to do. Here, how are we going to deal with it? Well, quite simply, when the SQL request user is true, we will have a welcome message on the website page, quite simply. In this behavior, it is enough to be able to exploit a SQL blind based on conditions. Since if we ever have a payload that will work, we will have our welcome message on the page. And if our payload does not pass, so return false, we will not have this message on the page. So it is simply enough to be able to have an SQL injection. For example, we take the two payloads here. The first payload, since we have end one equal one, it will send true. So we will have the welcome message on the page without an HTTP response, but suddenly we have another response with a condition, while the second payload which does end one equal two will send false, so false, and we will not have the welcome message. So in the same way as the time based, we can brute force tables or passwords, etc., as we can see on the screen, and always based on the answer we have, but not on the result of the SQL request, but on what will condition this request. So here the welcome message on the website. Then we have the out-of-bend SQLs, because in fact if we do not get results from the server directly, why not send the results to a server that we control? This is the goal of the out-of-bend SQL injection, of course online. Here you take the payload on the screen, we filter the data from the user table or the username and administrator to a domain name, so here it is a collaborator because it is with burpsuite, but it can also be a domain name of the attacker. Always favor the DNS because there are small problems sometimes with IPs, so here is for the small example of out-of-bend, quite simple to understand. Now we get SQL injections blindly, we go to another type of SQL injection, it is the second-order SQL injections. So for the moment we have just seen the first-order SQLs, since in fact the application takes the entry of the user from an HTTP request and during the treatment of this request, incorporates the entry into an SQL request in a non-secured way and we get the result in the HTTP response. The second-order SQLi is a little different, I thought I was going to take a little diagram to explain it to you. So here we will directly inject a payload, we can see it here, we will create an account with the username of the badguy user, but again little pot.vergule and we will suddenly put our SQL payload, so here we put user update and we put the letmin password or the user and administrator and then you know double shoot to make a comment and to ignore the rest. Once we are going to put it in place in fact, we will store this request in our user name, but it will not directly be usable since there in fact it will just be stored temporarily in the user table, so no problem. The problem, when we go to our profile, the website will do a select all from user option where user equals badguy and suddenly here we will have our payload which will be executed since we will have the update user etc. And so if this payload is executed then we can connect as an administrator with the letmin password. So I think you understand a little bit the difference between the first-order SQL injection which is direct and the second-order SQL injection which is indirect since in fact there we go through a temporary step, through an intermediate step, that's all the interest. So it's a little longer but sometimes it's quite possible to do a second-order SQL injection since in fact we will be able to bypass the security of the first order in fact and generally the developers are completely confident in what is happening once the payload has passed the first order, the developers are sure that the request is well secured and therefore they no longer check afterwards so we can easily have an SQL injection by bypassing the first order. I hope you understand. Now that we have seen the different types of SQL injection, we will move on to the impacts even if I think that through the apps you have been able to see a little bit several examples. First, we have unauthorized access to data of course since we can bypass authentication mechanisms with the SQL injection. We can have access to sensitive data, data normally where we do not have access. We can therefore extract or dump a database which contains passwords, financial data, etc. So it's quite scary and in addition to being able to dump and extract all that, we can also potentially manipulate data so add, delete, change the password of an administrator typically so that we can connect as an admin. So all this will completely alter the database and it will create functional problems within the application. We also have the command execution which is possible since in fact in some cases the attackers can exploit SQL injections to execute system commands on the server which therefore houses the web application without a problem, which therefore allows us to go a little further to be able to pivot and have access not only to the database but to the server which houses the database and therefore be able to go even further to compromise the initial information system. Of course we will also have a performance degradation since SQL injections are quite greedy in resources so if an attacker starts to send a lot of payloads it will directly deteriorate the state of the server so it's a bit problematic. And finally an interesting point to address is the reputation and confidence that are damaged since many companies sometimes get dumped and completely extract their database. There is a big leak that falls on the deep web but beyond the fact that they can suddenly go back up their database with backups. So in itself we will say the functional aspect is not so serious. The problem is also at the level of reputation and confidence since suddenly the customers who trust this solution, this web application, if it is compromised it will be really complicated to regain confidence that was lost following an attack because an SQL injection can do very very bad and we saw it during the labs. It is a very interesting aspect to address when we are attacked, the aspect of trust and reputation. But do not worry there are not only bad things, fortunately there are remedies that are possible. First, use the prepared requests or parameters provided by your programming language and your framework. Nowadays we still have a lot of frameworks that are used and which allow to separate the SQL code from data from user entries which really greatly reduces the risk of SQL injection. So there is, I want to say that there is almost no excuse for having an SQL injection in web applications even if there is still nowadays. A remedy that applies to a lot of things but here also to SQL injection, we talked about it during the video on the XSS, is to make sure to validate and rigorously filter all user entries. In fact, the entry point for attackers is where we will be able to put data to try to be able to modify server behaviors and therefore make sure all the time to validate to filter, to sanitize, to do all this kind of things to limit the special characteristics, to filter potentially dangerous entries, etc. to really limit SQL injections. Then we have the aspect of the principle of the least privilege, really only give the privileges necessary to the account of access to the database of the application. In this way, we avoid using accounts that have high privileges such as administrative privileges for access to the database because if ever the web application has these administrative rights and that an attacker arrives before an SQL injection, he will directly have the administrative rights on the database which can be very problematic and it is really always to apply this principle of the least privilege both to SQL injections and in all aspects of an information system. Then we have the principle of defense in depth, I think it speaks to you, but in addition to protecting the web applications, always make sure to secure the infrastructure that is underlying. So update the servers that host the databases, update the databases versions, apply updates on firewalls, filter external connections, etc. To really complicate the task for an attacker, put several layers in fact, it is really the principle of defense in depth, it is to really put a set of layers that will really make life difficult for an attacker, he will really say to himself, I have already gone through a step, what do I have after, I still have this, that, that, bypass, it's impossible, and suddenly he will completely discourage himself. So it's really super important to put that in place. Then two last things, we have the regular security tests, it is true that now we still have devices that allow to automatically audit SQL injections, it really allows to greatly reduce risks since these days we still mainly have bots who will scan the world internet all the day to find vulnerabilities of SQL injection, and behind use fairly basic payloads to exploit them. So if on the other hand, before going into production, you put in place this kind of security test related to a tool, it's still better to have skills, but a tool is already not bad, to just a little bit enlarge, well it's already a very good thing, and I really advise you to do it. Finally, we have the awareness and training of the developers, I think it's really one of the most important aspects, since even today we have developers who are not necessarily very sensitive to web security, and who develop all day the backend, the frontend, and so you really have to train these developers at the risk of cybersecurity, SQL injections, XSS, XXE, that kind of thing, to really limit the risks. In any case, I hope you enjoyed the video, feel free to give me feedback in the comments, to subscribe and put a little green thumb, a little green thumb, I am in 2012, a little blue thumb of course. It was François, see you next time, ciao ciao!
