Hello and welcome to the Wednesday, April 29th, 2006 edition of the Sands Internet Storm Center's Stormcast.

My name is Johannes Ulrich, recording today from Jacksonville, Florida.

And this episode is brought you by the sands.edu graduate certificate program in incident response.

Well, Diaries today is a quick write-up I did on some requests we're seeing in our honeypots

that use a little bit unusual header, the X-Vercell set bypass cookie header.

Now, this header is related to the bypass value that you can

define as a user of VERSEL that will essentially bypass some of the protection mechanisms,

like, for example, rate limiting. Now, this is not an unusual feature for any kind of application firewall or such,

where in particular for developer purposes, you have the ability to essentially bypass at least

some of the protection mechanisms. The value you would have to pass with the Versal set bypass

header is random, and it's something that

the user can define and that does not appear to be really the use here because they're using

the Expressel Set Bypass cookie header so with the additional cookie add-on and that's where it gets

a little bit interesting.

So this header is used so that the first time you send the request,

you will set the bypass value.

And then the server is responding with a set cookie header to essentially set a cookie.

And that's in particular useful for browsers that are being used here

for testing, because then the browser will automatically send the cookie, and with that,

sort of retain the bypass feature here. The value they're sending here is same site none

secure, which is not documented, but there are similar parameters,

particular same-site none, where you sort of specify that a cookie comes back with the

...