Now let's talk about these HTTP flood response challenges that I briefly mentioned previously. Basically, we will be covering two types of HTTP response challenges in this lecture. The first one is going to be 302 redirect challenge. And the second one is JavaScript cookie challenge. Now for the sake of clarity, I would like to mention that 302 redirect also involves a sort of cookie. The only thing is it is not embedded in JavaScript.
In other words, this redirect this whole process that I'm going to describe you in most setting cookies, the only thing is, they are embedded as HTTP cookie headers. Whereas in JavaScript cookies case, the cookie is embedded as a JavaScript object in the page that is retrieved by the client. Let me start off with the first one and demonstrate to how it looks like Basically, this is like the whole process. And we have the proxy again here. This first part of the challenge series is actually a TCP challenge. And I can say, is not mandatory from application layer perspective.
So even though I decided to depict it here, you can just omit this part and start with the layer seven challenges. And how this challenge looks like is first we verify TCP cookie, which is this step. Then after this TCP challenge, when we received the first GET or POST request, we reply with L seven, which is a layer seven cookie here. Here the server presents the OSI layer. So you can consider it as an application layer cookie. In our case, it does apply to the 302 redirect.
And after answering with that, we just terminate the connection After that, we can again apply a TCP challenge, the same challenge that we discussed earlier in network layer section. However, at this part, we actually After establishing the connection, here, we actually expect the client to send the GET or POST request with the previously set and seven cookie, the application layer cookie that was set up in the previous stage. And if we received that, we again send the 302 redirect request. And we here also suddenly terminate the connection to only difference of the stage we are declined to http authentication table. So if the same client passes both stages, in other words, both the redirects, then we just let the traffic flow through directly between client and server, and we don't interfere with the rest of the traffic anymore. As I already briefly mentioned, you don't even have to use TCP challenge parts.
You can just Start of both stages directly with the application layer challenges. In other words, the application layer redirects. Basically we are here checking whether the clients remembers the cookies that we set for it after closing the connection, because if it is an attacker, it's quite unlikely that attacker will keep the trace of the cookies that we set on application layer. And he will just continue to send the same packets without the cookies that we set. Therefore, after verifying the cookie and redirects twice, we ensure that this is a real client. And we can just let the traffic flow.
Know when we investigate the packets. This is like an example package of we get requests in this example. This is how it looks like. As you can see, we encounter 302 redirect and cookies set as an additional HTTP header when it comes to JavaScript cookies We just set the cookie under descript bracelets, as you can see here. And we just direct the page to itself. It relies on the fact that the attacker is not using an emulation of JavaScript.
And therefore, if it is a real user, it's quite likely that he will be able to answer our JavaScript cookies, because most of the bots do not use JavaScript, although recently it is changing. So this JavaScript cookie might not be the best option all the time. However, this is a much more straightforward method than the previous ones, as we just set the cookie, and we redirect page itself here. And basically that's all we don't do any other complicated redirects, as we described previously. Now these challenges are fine. However, when it comes to POST requests, as opposed to get, we need to consider a few things while applying those response challenges.
The first thing is the data sent in the post request Google lost in most cases. And when it comes to 302 redirect method, some browsers will convert the post request to a get request. So please bear that in mind while designing your for defenses. And as part of JavaScript redirect methods, some browsers may warn the users about this redirect to itself, which might cause an unnecessary panic on client side. And that's all matters that I would like to discuss. If you also know other matters, related to challenging the traffic's, you can mention in comments.
I will be waiting for your feedback on that.