Welcome to HBH! If you have tried to register and didn't get a verification email, please using the following link to resend the verification email.

Injecting session cookies

  1. Home
  2. Forum
  3. Web hacking
  4. Injecting session cookies

ghost's Avatar

ghost

0 0

I'm having some problems using the cookies I stole with XSS, for example I get a PHPSESSID cookie, logout of the site i'm testing, and clear my cookies. I prefer to use JS then a cookie editor, so I use:

markupjavascript:void(document.cookie="PHPSESSID=<myvalue>");

And that seems to work (a cookie is created), but when I try to go back to the index of the site, it redirects me to the login. Is this just the way the site is coded, or am I doing something wrong?


ghost's Avatar

ghost

0 0

I'm not too sure, I dont know too much about sessids but I think it is probably being changed when you/they logout to prevent Session hijacking.

Again im not too sure.

if its not then I suppose you could try using a <script> and post it through to the server

&lt;html&gt;
&lt;form method=&quot;POST&quot; action=&quot;http://example.com/loginarea.php&quot;&gt;
&lt;script&gt;void(document.cookie=&quot;PHPSESSID=&lt;yourvalue&gt;&quot;;&lt;/script&gt;
&lt;/form&gt;
&lt;/html&gt;

ghost's Avatar

ghost

0 0

Normally, I would inject every cookie in the person's cookie. It just makes it so that you definitely have the same thing as the user. Also, he could've already been logged out and his session destroyed.


ghost's Avatar

ghost

0 0

How would you do that?


ghost's Avatar

ghost

0 0

The same way he did it with just the session. You just have to do that for every cookie name. Like if you have the cookie:

PHPSESSID=randomness;whatever=blah

You would do: [code] javascript:void(document.cookie="PHPSESSID=randomness");void(document.cookie="whatever=blah");


ghost's Avatar

ghost

0 0

Ahh Yeah I see :)

Ty =]]


ghost's Avatar

ghost

0 0

The PHPSESSID cookie was the only one set, thats the thing. It probably destroyed the session when I logged out. Might try it with 2 machines, no logout.


ghost's Avatar

ghost

0 0

jjbutler88 wrote: The PHPSESSID cookie was the only one set, thats the thing. It probably destroyed the session when I logged out. Might try it with 2 machines, no logout.

Yes, it destroys the session when you log out. Trying it while you're still logged in sounds like a good try.


ghost's Avatar

ghost

0 0

It worked :D


yours31f's Avatar

yours31f

Retired
10 0

session ids are updated frequently on most sites


ghost's Avatar

ghost

0 0

yours31f wrote: session ids are updated frequently on most sites

Dude, just shut up. You don't know what you're talking about. They're not "updated frequently"… they're generated at random when a session is created, stored on the server in the tmp directory and, when the session is destroyed, the little session file in tmp disappears.


ghost's Avatar

ghost

0 0

If you install the web develop firefox plugin , you can create cookies through it and edit cookies, and view them..

Just a tip ;P

And also, alot of sites now store the session_id(); in a db , so that the cookies cant be hijacked.


ghost's Avatar

ghost

0 0

I know about the ff plugin, I have it, I said previously in my posts that I wanted to use JS.

Also, how does storing session ID's in a database make them less easy to hijack?


ghost's Avatar

ghost

0 0

Because the ID is unique, so you cant create one as it will need to be the exact same ID as the one stored in the DB, learn about php security.


ghost's Avatar

ghost

0 0

But once you have done an XSS, you will have the session id, so its exactly the same isnt it? Someone with some actual knowledge plz respond…


ghost's Avatar

ghost

0 0

I'm asuming you got the cookies from a cookie logger so perhaps you could help me. Basically ALL the cookies loggers I coded did'nt work because I tell it to write the cookies to x.txt then it says: Cookie:(This is blank) IP:(The IP) Referer:(The referer) etc. And I was wondering why. Thanks P.S I use t35.com


spyware's Avatar

spyware

Banned
0 0

jjbutler88 wrote: But once you have done an XSS, you will have the session id, so its exactly the same isnt it? Someone with some actual knowledge plz respond…

The thing is, a website can bind an IP to a session ID. So, lets say Alice visits google.com, her ip is 23.23.23.23, and her session ID is ABCDEFG.

Now, Bob comes along, exploits google.com and steals Alice's cookies. He now injects her session ID (ABCDEFG), but, what happens? Google.com checks the database for an IP match, but, Bob's IP is not 23.23.23.23! Google.com won't let Bob login with that session ID, because his IP isn't correct.

Btw; the server can also check for user-agents, IP-range, you name it. IP is most frequently used though.


ghost's Avatar

ghost

0 0

@SamTHG - Its because you dont know php (its a very simple job), or your XSS isnt propperly formatted.

@spyware - Thanks, I didn't realize more than the session ID was stored.


ghost's Avatar

ghost

0 0

Yea that's good to know. So could you root Alice's computer and use it as a proxy and inject the cookie. Because the cookie is in the database would it be reused? I don't see why a cookie would be reused unless if it were authenticate by the IP, which it would be. And then the cookie changes every so often.


ghost's Avatar

ghost

0 0

chronicburst wrote: Yea that's good to know. So could you root Alice's computer and use it as a proxy and inject the cookie. Because the cookie is in the database would it be reused? I don't see why a cookie would be reused unless if it were authenticate by the IP, which it would be. And then the cookie changes every so often.

Why would you go through that trouble? If you rooted them, you could just sniff the traffic and get their UN/PW.


spyware's Avatar

spyware

Banned
0 0

hacker2k wrote: Why would you go through that trouble? If you rooted them, you could just sniff the traffic and get their UN/PW.

Why would you go through that trouble? If you rooted them, you could just use a keylogger and get their UN/PW.


ghost's Avatar

ghost

0 0

spyware wrote: [quote]hacker2k wrote: Why would you go through that trouble? If you rooted them, you could just sniff the traffic and get their UN/PW.

Why would you go through that trouble? If you rooted them, you could just use a keylogger and get their UN/PW.[/quote]

But why would you root them if you are going to use a keylogger? You can just email them a keylogger.

Edit: And because keyloggers aren't fun. And, because keyloggers could be detected.


ghost's Avatar

ghost

0 0

hacker2k wrote: [quote]spyware wrote: [quote]hacker2k wrote: Why would you go through that trouble? If you rooted them, you could just sniff the traffic and get their UN/PW.

Why would you go through that trouble? If you rooted them, you could just use a keylogger and get their UN/PW.[/quote]

But why would you root them if you are going to use a keylogger? You can just email them a keylogger.

Edit: And because keyloggers aren't fun. And, because keyloggers could be detected.[/quote]

Why in the hell would you set up remote attacks targeting the computer you already rooted… dumbass


ghost's Avatar

ghost

0 0

stdio wrote: And because keyloggers aren't fun. And, because keyloggers could be detected.

Why in the hell would you set up remote attacks targeting the computer you already rooted… dumbass[/quote]

Yeah, that's why I said, "Why would you root them if you are going to use a keylogger?" You don't need to.


spyware's Avatar

spyware

Banned
0 0

Sniffing traffic means obtaining possibly encrypted data. Keylogging means direct results, character-per-character readouts.

Do the math.


ghost's Avatar

ghost

0 0

spyware wrote: Sniffing traffic means obtaining possibly encrypted data. Keylogging means direct results, character-per-character readouts.

Do the math.

I see, but then what's the point of rooting the box?


spyware's Avatar

spyware

Banned
0 0

hacker2k wrote: I see, but then what's the point of rooting the box?

Getting to set up a keylogger without 3rd party interaction. You don't need outbound connection in order to obtain the logs (if you can hold the box, that is).


ghost's Avatar

ghost

0 0

spyware wrote: [quote]hacker2k wrote: I see, but then what's the point of rooting the box?

Getting to set up a keylogger without 3rd party interaction. You don't need outbound connection in order to obtain the logs (if you can hold the box, that is).[/quote]

Ahh, I see. Didn't think about that.


ghost's Avatar

ghost

0 0

It could just be easier to fond a blind sql vuln in the site, get the whole list of session IDs and IPs/referers/geohashes/whatever and spoof the lot till you find admin.


spyware's Avatar

spyware

Banned
0 0

jjbutler88 wrote: It could just be easier to fond a blind sql vuln in the site, get the whole list of session IDs and IPs/referers/geohashes/whatever and spoof the lot till you find admin.

Good luck spoofing an IP.


ghost's Avatar

ghost

0 0

Okay, so, let's recap… the only thing initially contained within your cookies, from your session, is the session ID itself. I just verified this to be sure, so don't argue. The problem is preventing session hijacking… and the solution above (tracking SessID / IP in a db) works well. However, I believe there may be an even better solution by using the session_regenerate_id() PHP function.

http://us2.php.net/manual/en/function.session-regenerate-id.php

Quite simply, if you have an include at the top of your source on all authenticated pages that checks for certain session variables (not cookie variables) and regenerates the session id on each page load… you reduce the amount of time that the person holding the stolen session id has to actually use it.

Of course, this does nothing against preventing theft of credentials. Don't think there will ever be a "cure" for that one.

jjbutler88 wrote: It could just be easier to fond a blind sql vuln in the site, get the whole list of session IDs and IPs/referers/geohashes/whatever and spoof the lot till you find admin. … and this is why I'd rather regenerate sessions than store the crap in a db. The less static the information is, the less chance of it being exploited.


ghost's Avatar

ghost

0 0

chronicburst wrote: Yea that's good to know. So could you root Alice's computer and use it as a proxy and inject the cookie. Because the cookie is in the database would it be reused? I don't see why a cookie would be reused unless if it were authenticate by the IP, which it would be. And then the cookie changes every so often.

Pardon if it's a dumb question, but what exactly does it mean to root someone's computer?

Edit: New question. I'm attempting to session hijack the session of my second account, so I'm using the same computer, same IP address, changed user-agent switcher so that it would match the correct browser… and it still didn't work. Then I noticed that, possibly related, Tamper Data was showing a new request header, named "If-None-Match". The corresponding value is 32 hexadecimal digits long. I could try messing around with it, but I think the real question is why is it there? (If it's relevant.) Any ideas where to start my investigation?