[MUSIC] All right, in this video we're going to talk about a little bit of a tips and tricks for Burp Suite and similar features exist on ZAP as well. If you just Google for interception mode for ZAP you'll find the relative posts that'll give you tutorial on how you could set this up for your particular proxy. So, one of the features that we've been using is the repeater. So, essentially we'd come here, look for a particular post. And when we found a particular post we would right click on it, send it to repeater, modify it, and then post the message and we we get some response that's in text back. And this works, especially because most of the things we've been doing didn't require a second or third or fourth step after we use the repeater to send it. There's alternative ways of doing this, and that's using the interception mode in Burp, so you can essentially say I want to intersect all the traffic. And if I come in here and try to login, it will intercept my traffic. I haven't even hit go yet, and you will notice is that there's some background communication that's happening with the model view controller. So, that traffic is essentially being intercepted and not sent back and forth. So I can turn it on and off and it will release all those traffic, and without even doing anything, there's more traffic coming. And I it makes it very difficult to find the specific traffic that you're looking for. So one thing we can do is, I turned off interception mode, so everything is going through now just fine. Under intercept client requests, I'm going to add a new type of request. And on the boolean operator I'm just going to do and domain. The match type, I'm going to choose HTTP method, and for the match relationship, I'm going to say if it matches, and post is the match condition. So essentially I'm asking Burp to only intercept when requests are made from my browser against the server that are posts. If I go and intercept and turn it on, first thing you notice is we're not getting actually intercepted on a bunch of random communication. And the second thing is when I hit this sign in, it will actually intercept that. And you'll notice my browser is actually just waiting, because as far as it's concerned, it's sent the traffic to the server, and the server has yet to respond. So if I modify the password and give it an incorrect password for instance and I forward that traffic, then the browser gets the traffic returned to it, and I'll say invalid username and password. If we go into history, this post that we just made against login, we can see the original request and the response that came back. And the response that came back was a login error. So we can still look at the traffic, and we can still even send this to the repeater. Let's try that real quick. The last post that went out was to login, and the original request was this, the edited request which we messed with, the password is this. So, I'm just going to click on the original request, and I'm going to send it to the repeater. In the repeater, I'm just going to actually submit the right username and password, and you'll notice I'll get the welcome screen here. Now, what's interesting now is if I refresh my browser, my browser didn't get that cookie and it didn't actually set anything properly. If I erase this log in error, it still doesn't set it. So even though we got the success here, that did not carry through in our browser. So sometimes it's beneficial to actually use the proxy and intercept the traffic individually. Modify it to your needs, and then forward it on so that it goes through when you're ready for it.
