This paper appears to describe a solution in which XSS attacks stealing cookies are made pointless by having the server send clients a cookie with a hashed name. Whenever the user sends the cookie back to the server, the server will take the hash and regenerate the original name of the cookie. Thus, supposedly, even if attackers stole the user's cookie "they wouldn't be able to use it".

I don't understand how this would actually render the cookie useless to the attacker. As long as the real user hasn't logged in/out of the website and caused the server to generate a new hash for the cookie name, couldn't the attacker simply send this hashed cookie name to the server and still retrieve the same information? The server would simply take the hash, regenerate the original cookie name as usual, and return another cookie/proper info.

I'm new to the area of information security, so it might be because of my novice knowledge in the field that this isn't making sense to me. But the paper also does not seem to convey the idea very clearly.

If anyone could shed light on whether/how this would actually be a feasible method in preventing XSS, it would be much appreciated!

  • 2
    Doesn't make any sense to me whatsoever. It's written in a very weak and confusing English. Moreover, this "paper" seems to have been published in something called "International Journal of Advanced Computer Research" which is, surprise surprise, doesn't seem to have any credibility outside India. You'll also see that there are only very few papers published there, and all of them are horribly formatted and, with only a quick glance, seem to be devoid of actual content.
    – Adi
    Commented Mar 13, 2014 at 9:38
  • Thanks all for your input! Yeah I thought this paper was somewhat strange and a little sketchy. I was not sure if I'm being trolled or if I just didn't understand because I'm a novice. I agree, it seems all their papers are just troll papers -- I looked at other papers in the journal and some just copy and paste from legitimate papers. I'm relieved by your responses. Thanks! Commented Mar 13, 2014 at 18:49

2 Answers 2


I agree with you that the approach which is suggested in this paper does not make any sense. An attacker could steal the hash and use this one to access the victim's account.


If I read the paper correctly, they authors seem to be proposing replacing the cookie with a separate value passed as either POSTdata or concatenated with the URL of a POST or GET request. While it is technically true that removing the cookie and doing something else for session management makes attacking the cookie useless, the attacker will simply attack the replacement session identifier - just like you expect.

The approach attempt comes down to obfuscation. At best, this approach will be useful if implemented on a small number of extremely low traffic sites. If it becomes commonplace, attackers will just automate their attack to go after this value as well.

It's worth noting that session identifiers have always been possible to transmit appended to the URL or in the postdata. This was originally implemented as a way to support web browsers that didn't support cookies. It's likely automated tools already look for values like this, and it won't fool a manual tester.

  • Why do you think the authors suggest to replace the cookie with a separate value passed to POST/GET requests? I don't find any clues in the paper which would confirm this.
    – DanielE
    Commented Mar 13, 2014 at 7:46
  • @DanielE The paper doesn't appear to say, so it seems a reasonable assumption which would be as good as any (or as bad since it is still vulnerable). Commented Mar 13, 2014 at 12:25
  • @DanielE, The paper talks about giving the client a hash of the cookie instead of a cookie, and it talks about putting the cookie in the submitted data. While this is not explicit, I saw no better interpretation of the proposal.
    – atk
    Commented Mar 13, 2014 at 12:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .