Full training is available for free at:
https://hackademy.aetherlab.net/p/bur...
Website: http://aetherlab.net
Blog: / gergely.revay
Trainings:
Web Hacking: Become a Web Pentester - https://hackademy.aetherlab.net/p/web...
Reverse Engineering with Radare2 - https://hackademy.aetherlab.net/p/rad...
Video Transcript:
All right. Let’s continue with something more interesting. I don’t really want to bore you to death so we will just to the Repeater here and do a little bit of hacking so that you do something exciting. So what you can do with the Repater is to take one request and repeat it so a very clever name. You can repeat requests. And the point is if you find a request which seems interesting, then you can send it to the Repeater and start playing with it one by one. You can just change one parameter and see what’s the response. So, if you look at the user interface, I have already a request here. And what happens, you have the request here. You can go and then you get the response. You can always immediately see what the response was, and you can just go back and forth between requests. So you play with the parameter and you change it and then you get an error message, then you can just go back to the status when you still got some valuable response.
So, Repeater is very simple. You just take requests and play with it as long as you find a stable attack. What we are gonna do now is we will try to exploit a cross-site encrypting attack in the WebGoat and we will do that with the Repeater. I don’t really want to go into details on what the cross-site encrypting attack is. You can either look it up here in WebGoat. It’s actually described here. Or you can Google it a little bit. I will just quickly summarize it now, and if you don’t understand then read a little bit about it.
So, a cross-site encrypting attack is when you can manipulate an input in a request so an input parameter and then you get a response. And the input string what you gave will be built in the response, the estimate code of the response. And if the server doesn’t validate the input parameter correctly or it doesn’t escape the response or the input string in the response, then what you can do is you can put HTML code in this input parameter and as it will be injected in the response HTML, when it returns to the browser, the browser will think that it’s also part of the HTML code and it’s gonna render it. And what you can also do, you can put JavaScript code inside the HTML what you put in and then the browser will execute this Javascript code.
And why is that good? So cross-site scripting is like the buffer overflow of web applications. It’s at least as widespread as buffer overflow and it’s also as dangerous. Because what you get, you get the ability to execute any kind of JavaScript code in the user’s browser, but you can do whatever you want with that. You can try to steal the session cookies or use his credentials to get full access to the application. Or you can try to steal data from the application by requesting data from the server and then sending it to your own server. Or you can actually load other pages in the background where you can input some exploits against the browser itself. And with that, you can exploit the browser and get full access to the user’s computer. So you can do like really, really a lot of things with cross-site scripting. We are not gonna do that. We’ll just experiment with that a little bit, but I encourage you to, you know, try to imagine scenarios what you could do with the cross-site scripting, what you could do if you could execute JavaScript in the client’s application.
So what we are gonna do is come to the, in WebGoat, to the Cross-Site Scripting and then to the Reflected Cross-Site Scripting Attack. Reflected means that the input what you, the attack what you put in will be executed immediately in the response so in the next page, what you get after submitting the data. Okay. So you get this input field here. We have quite a few fields what we can exploit. I’m gonna take this nice little test string, which is like corrector [sp] what might be useful in an attack and I will just paste it here in all input fields to see whether any of them is exploitable. And then I’m gonna click on Purchase. Now you get this nice error message here and something is weird. You don’t see this part of the string, the XSSTEST error. That’s a very good indicator that something is wrong so we can just open the console with Ctrl+Shift+C to open the debugger tool. And then we come here and check it in the HTML code. Oh, yeah. All right. You can see it here actually immediately that this is the error message from the server. And you can see that although you put all of this XSS tag here, the browser thought it’s a valid HTML tag so it ended the closing tag to it. So the browser thought that it was a valid HTML and
-Cut due to length limit-