# Business Logic Vulnerabilities - Lab #8 Insufficient workflow validation | Long Version ## Метаданные - **Канал:** Rana Khalil - **YouTube:** https://www.youtube.com/watch?v=k1huNEOy2SQ ## Содержание ### [0:00](https://www.youtube.com/watch?v=k1huNEOy2SQ) Segment 1 (00:00 - 05:00) hi everyone welcome back to another video in the web Security Academy Series in today's video we'll be covering lab number eight in the business logic vulnerabilities module titled insufficient workflow validation all right before we continue with the video I'd like to announce that this video is part of a course that I offer on my Academy now you might be wondering why would I buy a course that is made available for free on YouTube well there are four reasons why you might want to do that number one is that you gain early access to recorded material as soon as I record new videos I make them available through my course right away whereas on YouTube they'll only be released on a weekly schedule reason number two is that you gain access to a Discord Channel where you can ask questions the Discord channel is divided into topics that we cover in the course and if you run into any issues you get to ask questions about anything related to the course material reason number three is that you no longer have to deal with YouTube ads or sponsor messages and last but not least reason number four is you get to support me any revenue generated from this course will go back into maintaining the academy and creating more videos and courses that will be made available for free on my YouTube channel so if you're interested in buying the course make sure to check out the link in the description and that is it let's go back to our video if you do not have an account on the web Security Academy you can get one by visiting the URL ports. net websecurity and clicking on the sign up button I already have an account and I am logged in so to access the exercise I'm going to click on Academy select all labs and then do a search on business logic vulnerabilities and go to lab number eight titled insufficient workflow validation all right let's get started this lab makes flawed assumptions about the sequence of events in the purchasing workflow to solve the lab exploit this fla to buy a lightweight lead leather jacket you can log into your own account using the following credentials and they give us the credentials right over here so the target goal over here is to exploit the logic flaw in the purchasing workflow and be able to purchase the lightweight lead leather jacket for less than the price that is listed in the application all right let's get started now notice over here this is the built-in browser in burp and so all my requests are already passing through my burp proxy the first thing that I'm going to do is log in using the credentials that we were given and it looks like it's a little bit slow today here we go so the password was Peter hit login and we get the same page that we've seen in previous Labs so we've got $100 in store credit and we need to purchase a leather jacket which is this item over here again the application is a bit slow today so we click on view details go down add it to the cart and then go to my cart and look at the price of the jacket so you could see over here the price of the jacket is 1,337 and you've got an ability to add a coupon and then you click on place order to place the order for the item now I've intercepted all the request in burp just to see the exact parameters that are getting passed in the back end what we're going to try to do is see if any of these parameters are vulnerable so that we could potentially buy this jacket for $100 or less so when we added an item to the cart it perform this post request right over here let's make that a little bit bigger it takes in the product ID the redirection parameter and the quantity of the item and then when we checked out the item it made this post request over here and it only takes in the csrf parameter so far let's assume that we tested everything that we've tested in previous labs and it doesn't work and it didn't work and so it looks to me that these two requests might not be vulnerable so what we're going to do is we're going to remove this item over here go to home and then try to purchase an item that we can afford just to see what the positive path looks like so if you have an item and you have the money to purchase that item what request does the application exactly uh perform in the back end in order to purchase the item cuz those requests could be vulnerable and there's no way of seeing them unless you actually go through what we call the positive path or the uh correct use case um of purchasing an item so let's add this one to the cart and then view our cart and it costs $657 cents and we have $100 so let's place the order and see exactly what requests are performed ### [5:00](https://www.youtube.com/watch?v=k1huNEOy2SQ&t=300s) Segment 2 (05:00 - 10:00) so we've got our post request which we saw before it takes in the csrf parameter now this is a classic uh request it doesn't take in any parameters that could potentially alter the back end so this one is definitely not vulnerable the next request is a get request so this is new we didn't see it when we were purchasing the leather jacket because um we didn't have sufficient funds to purchase a leather jacket so notice over here the request is to SLC card SL order confirmation and it takes in a parameter called order confirmed and it sets it to true and then from there it purchases the item and displays the store credit that is left in your account and it displays the information of the item that you just bought all right so there is a parameter over here that does talk to the back end so we need to test to see if this parameter is vulnerable so what I'm going to do is I'm going to actually put in the leather jacket in my cart and then I'm going to perform this request over here maybe if there's a logic flaw in the application what the application could be depending on is if this parameter is equal to true that means we have enough store credit to buy the item and if it's equal to false that means we don't have enough store credit to buy the item so I'm going to send this to repeater and see if that flow of requests will work so let's go to home and then add the leather jacket again to our card and the application is really finicky today all right add to card go to the card and from over here what I'm going to do is perform the requests so hit send and here we go so we get a congratulations you sol the lab and if we reload the page it should tell us that we bought the item and it doesn't so it just tells us that our cart is empty and we actually bought the item all right so we successfully completed the exercise by exploiting it manually now let's script it in Python and actually before we do that the idea over here is there's a certain business flow in the application that the application is uh dependent on in order to make decisions um on whether the user purchased an item or not and one of them is uh this request over here which is only displayed to you if you actually have the funds to buy an item however what we did is we called this request before we actually purchase the item and so the application because it has a business logic flaw in it what it did is it assumed that we do have the funds and it allowed us to buy the item okay now let's script our exploit the first thing that we're going to do is import all the libraries that we need so the request Library the Cy Library the URL lip 3 library and then we're going to say from bs4 import beautiful soup and we're going to import the RX Library as well and then we're going to disable insecure request warnings so disable warnings and we're going to say URL lip 3 do exceptions do insecure request warning and I'm wondering if this is two underscores and it is it's supposed to be only one underscore all right next we're going to say proxies is equal to http so all HTTP traffic should be sent to where my bur proxy is running which is on local hosts so 127. 0. 0. 1 cord 8080 and then same goes for http PS traffic it should be sent to where burp is installed which is also HTTP 127. 0. 0. 1 C 8080 and it's not where burp is installed it's where burp is running all right this looks good let's remove the extra two over here the next thing that we're going to do is create our main method so we're going to say if name is equal to main then call the main method and we'll Define the main method right over here so def main if the length of the command line arguments is not equal to two then print the usage instructions so that the user knows how to run the program so usage name of the program and URL and we take the name of the program from the and line argument so it says. ### [10:00](https://www.youtube.com/watch?v=k1huNEOy2SQ&t=600s) Segment 3 (10:00 - 15:00) arv Z and then we also print the example instructions so percent s www. example. com sis. r Fe and the name of the program we take from the command line argument and then we're going to exit the program because they use user ran it incorrectly all right so this assumes the user ran it incorrectly let's assume that the user did run it correctly the first thing that we're going to do is create our sessions object so request. session and then we're going to create a variable called URL and it'll be equal to the second command line argument and then we're going to call a function called buy item that takes in the session object and the URL and this is a custom function that will Define right over here so def by item again takes in the session object and the URL and in order to buy an item this is an authenticated exploit and so the first thing that we need to do is log in using the credentials that we were given and so we're going to have to go to the Post request that was responsible for login which is this one right over here and if we go down it takes in three parameters the csrf parameter the username and the password username and password we know now the csrf parameter changes every time and so what we're going to do is we need to extract it from the previous request which is this one over here so if we search for csrf you could see that it's extracted from over here and so the first thing that we need to do is really retrieve the csrf token and to do that we're going to create a variable called login URL and that's equal to the URL of the application plus the path SL login and then we're going to create a variable called csrf token and that's going to be equal to the return value of the function G csrf token that takes in the session object and the login URL now this is a custom function that we need to create ourselves but before we do that I'm just going to say rest of code here and let's create the function so we'll say def get csrf token again takes in session object in the URL now uh to obtain the csrf token we need to perform the request so it's R is equal to s. get because it is a get request it takes in the URL set verify to be equal to false because I don't want to verify TLS certificates and proxies to be equal to proxies because I want all my requests to be sent to burp just in case I need to de plug them and then we're going to use the beautiful soup library in order to parse the response which is r. text and extract the csrf token and to do that we're going to set it to html. parser and then we're going to extract it from the request so we'll say soup. find um and the idea over here is that the csrf token is in an input element that has the name csrf and the value that we want is in the value attribute so what we're going to say is find the input element that has a name attribute and the name is equal to csrf and then from there I want the content of the value attribute okay this looks good actually we're missing one more thing which is returning the csrf token and now this looks good all right so this Returns the csrf token and it gets saved in the variable csrf token so now we have all the parameters that we need in order to log in and so the next step is to log in as the user that we were given so we'll print a statement saying that we're logging in as the user and then we'll Define the parameters in the login request so data log is equal to and if we go back to the post request over here the parameters are csrf username and password so we'll set those right over here csrf is equal to the csrf Token that we just extracted and then username is equal to the username that we were ### [15:00](https://www.youtube.com/watch?v=k1huNEOy2SQ&t=900s) Segment 4 (15:00 - 20:00) given and password is equal to the password that we were given and then next all we need to do is perform the request so it's a post method s. poost it takes in uh the URL to login which is login URL and then we're going to say data is equal to data login which we just defined verify is equal to false and proxies is equal proxies and then we need to verify that uh we successfully logged in and to do that we're going to parse the response and check if the response has the logout string if it does that means we successfully logged in if it doesn't that means we didn't properly log in so if we get if we find the log out string we're going to say successfully logged in as the user that we were given otherwise I'm going to print could not log in as the user that we were given and because this is an authenticated exploit if we can't log in that means our exploit filled and so we're going to exit the program now let's assume we did log in the next upep is to add the item to our cart so we're going to say add item to cart and to do that we need the cart URL so if we go back over here and we look through the requests it's this one right over here this added the item to the cart so it's to the SLC card endpoint and of course it's URL of the application plus the slash card next we've got the parameters that the request takes so we'll name that data cart and we'll say that's equal to and it's this parameters right over here so the product ID and that was equal to one the quantity which was also equal to one if you want to add an item to the card and then you've got the redirect and that's equal to cart so this looks good just to confirm that we did this correctly I'm going to look for the item that we did actually add an item instead of remove an item okay so the redirect was to product not to card although I'm not sure this makes a difference all right this looks good now all we have to do is perform the request so s. poost takes in the cart URL data is equal to data cart verify is equal to false and proxies is equal to proxies and then the last step is just to confirm the order so let's say confirm order or really purchase item and the request that was responsible for that is in repeater so it was this request over here it's a get request and it doesn't take in any body parameters the parameter is in the URL itself and so we'll create a variable called confirmation URL and that's equal to URL plus the path to the confirmation which is this one right over here and then we just perform the get request so R is equal to S dog get and that's the confirmation URL verify is set to false again and proxies is equal proxies and then to confirm that we really properly exploited the vulnerability what we're going to say is if congratulations is in the response so r. text then print successfully it exploited the business logic vulnerability otherwise print could not exploit the vulnerability and we'll exit the program because the exploit filled all right this looks good let's ### [20:00](https://www.youtube.com/watch?v=k1huNEOy2SQ&t=1200s) Segment 5 (20:00 - 21:00) save it go to terminal new terminal and before we run it this likely timed out and so we're just going to open a new instance of the lab and then review our code all right so if we look at the code right over here in the main method we call a function called buy item in buy item it essentially performs three requests the first one is logging in as the regular user that we were given from there it adds the jacket item to the cart and then it calls the confirmation URL in order to exploit the business logic vulnerability and buy the item without having the proper funds to buy the item all right so let's go Python 3 business logic flaw lab 08 and copy the URL of the application let's paste it here and remove the trailing slash and hit enter hopefully there's no errors and so far so good and here we go it says we successfully exploited the business logic vulnerability and over here you could see it says congratulations you solv the lab all right so we successfully completed the exercise by exploiting the vulnerability manually and then scripting it in python in the next Lab we'll look at a more complex case of a business logic vulnerability if you like the video hit the Subscribe and share button so that the video reaches a wider audience also make sure to check out my course if you're interested in seeing more videos like this one thank you and see you in the next video --- *Источник: https://ekstraktznaniy.ru/video/38680*