You may have already guessed that I am a big proponent of the proxy interceptor tool(s). They make me feel as if time stands still, and it does in terms of the breakpoint(s). So I was at another site today, this time a retail store. I was interested in testing the durability of this shopping cart. Here we go. Upon my first breakpoint. Lets back up a bit. A proxy interceptor is a tool that allows you to control the submit and response of a web application by allowing you to set breakpoints (defined URLs tagged as the point to halt the submission or response so that you can modify the text that would normally be unmodifiable) . This should be obvious but in case its not, the proxy tool sits between your browser and the application, allowing it to control the flow of execution. OK, so I engage my proxy, navigate to the site and put an item into my cart. At this point you go back to the proxy and select the corresponding URL in which to set the first breakpoint. I set the breakpoint and refresh the page, the proxy halts the submission (I set the proxy to break on a submit first) this allows you to see if the server is going to validate the data that I change when it comes back from the server. I altered a bunch of stuff here to test many potential vulnerabilities. Make note of the "referrer" field as this will allow you to spoof the session and go right to the URL you want by naming the expected URL referrer, kind of a short-cut. Anyway, this site used some type of obfuscation which I did not follow at this point (using an x=n;y=n equation) to hide the price of the item in plain text by using a product code instead of a dollar/numeric value. So the submit was not overly viable at this point. My proxy of choice allows me to break on the response at this point so I will do that and review the response. This actually halts the response before it presents in your browser so you still have the ability alter data. I was able to alter price, logic and quantity to my liking on the response. However, as a credit to the site, I am in HTTPS (443) mode at this point by the way, and the process of transversing to the check out thwarted all of this effort as the data is sanitized and is reset to the correct denominations. No worries right? Right. I will just change the values at the check out. Here is where it gets fun. They employ a nice validation of the session on this specific page so the token changes upon every refresh of the page, causing my breakpoint to fail as I do not have it set correctly because the token is dynamically changing as I refresh the page. I set it to the last time I was there, which is not what the next time I am there will be. Pretty good, although I am able to view all of this data during the failing breakpoint (it allows me to view but not edit the data presented) and I can clearly see that if I do find the correct breakpoint I will in fact be able to alter the numeric data as I did previously and change the price. As a side note I also checked to see if I would be able to enter a negative number for my price as I would like very much to be paid for my effort by way of a refund to my chosen method of payment. Ha Ha..! But that didn't work, they did account for negative integers, at least in decimal format, I did not try a hex or base64 conversion here (I have a nice browser based converter for this that I will post up at some point unless you enjoy manually processing these conversions!), but that would be an option in the future..Moving on..now I have the option to test out my skills as an algorithm predictor...Or better yet I can continue this process several times, noting the change in the algorithm and try to deduce the pattern and predict accurately the next token. I basically stopped here for today as I was side tracked... The point is that this entire process took me less than 10 minutes to get to this point. I know my tools, but this is much more about understanding what you are looking for than being a speedy tool wielder....Spend the time to really understand what each aspect of the application means and you will be rewarded in the end. It is more about finding an over looked aspect of code or logic than it is about speed of execution. Slow down grasshopper, slow down.
1 comment:
Just a thought...how about a book entitled "Actual Attacks" that walks you through a real attack...kind of like what is being contributed here currently. As an example, take this to the next level by including the information on how to get the stolen property back to you without a trace... How does that actually work...? This is an important step... Great you broke the application, now what? Unless you are good with just knowing that you did it, what really was the point? Or was that the point?
Post a Comment