0

As I was reading the session fixation article on OWASP, I was thinking that the only way for my server to refuse a cookie set by a rogue script would be for my server to know that the browser sent a request without the HTTP-Only flag. Only cookies sent to the server do not include anything more than the cookie name and its value... All the meta data is lost.

What prompted this question are their examples #2 and #3 where they show URLs that look like this:

http://website.kom/<script>document.cookie=”sessionid=abcd”;</script>
http://website.kon/<meta http-equiv=Set-Cookie content=”sessionid=abcd”>

Personally, I don't understand how that could even remotely work. Are there any browsers or servers which are that broken? Why would a tag in the URL be accepted by the browser or the server?!

So I think that knowing that the browser had the cookie as HTTP-Only would be useful, but I currently fail to understand how a hacker could set a cookie (which would not be HTTP-Only) assuming that there is no possible breach in my server code.

I would imagine that the only way it could work is if the hacker was to find an XSS in my client or server code. Would that be correct?

Improve this question
2
  • 3
    As an aside, it's not the browser that accepts the tag... it's the web page. The specific example you are showing is often used as an attack against 404 pages that show a fragment of the URL in the page body without sanitizing for HTML content. owasp.org/index.php/Cross-site_Scripting_(XSS)
    – nbering
    Commented Aug 5, 2018 at 1:40
  • @nbering Ah, yes! My server does that too, although it does it properly and transforms the angle brackets to entities as expected.
    – Alexis Wilke
    Commented Aug 5, 2018 at 3:15

1 Answer 1

Reset to default
1

Given the type of attack you're referring, to... XSS would be the most likely vector for exploitation.

As I've mentioned in my comment, the specific example you are showing is often used as an attack against 404 pages that show a fragment of the URL in the page body without sanitizing for HTML content. So yes... this is a perfectly normal type of XSS attack, but it's not the browser that's broken.

Would XSS be the only way for a session fixation attack? Probably not. If an attacker managed to first execute a Man-in-the-Middle (MITM) attack, and inject their crafted sessionID before login, it would allow them to continue to use that session from their remote machine after the attack occurred.

MITM is harder to execute than XSS... but it's still possible. And if the vector for establishing session fixation were MITM, checking HTTP-only on the cookie would be ineffective, since the cookie could have been modified over the wire.

The best protection against this vector would be TLS, and user education to keep them from clicking through certificate errors.

Improve this answer
2
  • 1
    I'l also concede that if MITM is the initial attack vector... you have a lot more to worry about than session fixation. I just wanted to illustrate that there's more than one way to inject a cookie into a victim's browser environment.
    – nbering
    Commented Aug 5, 2018 at 2:10
  • Yeah, my server can't really do much about the MITM type of attacks. I can test the Agent, but unless the MITM is stupid, he would already be using the same agent anyway... But I did not see the XSS attack in that URL + 404 and bad code to generate said page. That makes sense now.
    – Alexis Wilke
    Commented Aug 5, 2018 at 3:17

You must log in to answer this question.

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