I'm just learning right now about different analysis tools and I came across something in a nikto scan last night on a VM server I own. It said something along the lines of:

Cookie ASPSESSIONIDSACSARTD created without httponly flag.

At first I dismissed it because it's a vulnerable server so there's like a million other things to look at also. But the more I think about it though the more it bugs me.

What could be done with custom cookies? I have tried googling this but it's possibly the most ambiguous search terms ever. My guess is that you could inject commands into cookies.

Any metasploit modules that I could look at or sites for reference would be greatly appreciated.

  • Is there no (OWASP) code listed? Aug 29, 2016 at 12:38
  • @YorickdeWid there might have been. This is way after the fact that I thought to ask. I can run the tests again tonight and add more to this question if that helps. I was just curious if anyone knew off the top of their head. If it was something common that I hadn't heard of before. Aug 29, 2016 at 12:39
  • I have never seen this output, nor can I find it anywhere in the documentation. Aug 29, 2016 at 12:41
  • @YorickdeWid okay no biggie. I will take a look tonight when I get home and add on to the question. Thanks for taking a look Aug 29, 2016 at 12:42
  • @YorickdeWid see updated output message. There was no OWASP Code Aug 29, 2016 at 13:36

3 Answers 3


With the update, I see the problem. The HTTP only flag the browser only lets the server set this cookie. This prevents scrips from altering the cookie data. It is a quite commonly reported by Nikto.

For more info see the OWASP topic


After Question Edit:

A cookie with the HttpOnly flag cannot be read by client-side scripts like Javascript (note that the client handling the HTTP response must support the HttpOnly flag).

A page vulnerable to XSS may steal the session information in cookies and send them to an attacker.

If the HttpOnly flag is set the Javascript cannot read the cookies even if XSS is present. This prevents things like session hijacking.

  • So you're saying it isn't the that you can create your own cookies thats the problem but the payload you put in them? My first thought when I saw this was CGI scripts and shell shock. Aug 29, 2016 at 12:58
  • 1
    @AnthonyRussell Almost all times, when you use a cookie on the server side in applications, you essentially take it as a data(string) and not as some executable code. So, the cookie content is never executed. Unless it is executed explicitly via some eval (leads to code execution)or in a sql query string construction(leads to Sql injections).
    – Sravan
    Aug 29, 2016 at 13:04

I hate to be that guy but I also hate being the guy that wastes peoples time with easily googlable things. After I went back and found the actual output from NikTo I was able to easily find the OWASP documentation

"HttpOnly - OWASP"

If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

If a browser does not support HttpOnly and a website attempts to set an HttpOnly cookie, the HttpOnly flag will be ignored by the browser, thus creating a traditional, script accessible cookie. As a result, the cookie (typically your session cookie) becomes vulnerable to theft of modification by malicious script

  • 1
    Yes indeed, I was too late. Good you found it anyway. Aug 29, 2016 at 13:41
  • 1
    @Sravan no problem, point is you found it :) Aug 29, 2016 at 13:42
  • 1
    I think convention is to delete stupid questions however, I wont be the last person to ask this one so might as well document it and take my lumps haha Aug 29, 2016 at 13:44

You must log in to answer this question.

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