3 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

Basically when you hijack someones session you take their sessionID and pretend its your own. Usually the sessionID is transferred in the cookie, meaning that if you can access the other parties cookie you can just put it in your own cookie and you've stolen their session.

This can be done in several ways, for example by sniffing the wireless network and looking at the HTTP packets being transfered or by XSS attackXSS attack where you can tell the victims browser to reveal their cookie information to you.

I would like to mention that the example you describe in your question may also be vulnerable to SQL-Injection. If I change my cookie's sessionID to

asdf' OR 1=1-- 

I would most likely be authenticated as a valid user. To prevent this you have to make sure you have proper sanitizing on dirty data coming from your clients before you use the data for anything.

Basically when you hijack someones session you take their sessionID and pretend its your own. Usually the sessionID is transferred in the cookie, meaning that if you can access the other parties cookie you can just put it in your own cookie and you've stolen their session.

This can be done in several ways, for example by sniffing the wireless network and looking at the HTTP packets being transfered or by XSS attack where you can tell the victims browser to reveal their cookie information to you.

I would like to mention that the example you describe in your question may also be vulnerable to SQL-Injection. If I change my cookie's sessionID to

asdf' OR 1=1-- 

I would most likely be authenticated as a valid user. To prevent this you have to make sure you have proper sanitizing on dirty data coming from your clients before you use the data for anything.

Basically when you hijack someones session you take their sessionID and pretend its your own. Usually the sessionID is transferred in the cookie, meaning that if you can access the other parties cookie you can just put it in your own cookie and you've stolen their session.

This can be done in several ways, for example by sniffing the wireless network and looking at the HTTP packets being transfered or by XSS attack where you can tell the victims browser to reveal their cookie information to you.

I would like to mention that the example you describe in your question may also be vulnerable to SQL-Injection. If I change my cookie's sessionID to

asdf' OR 1=1-- 

I would most likely be authenticated as a valid user. To prevent this you have to make sure you have proper sanitizing on dirty data coming from your clients before you use the data for anything.

2 this sql injection payload would never work.
source | link

Basically when you hijack someones session you take their sessionID and pretend its your own. Usually the sessionID is transferred in the cookie, meaning that if you can access the other parties cookie you can just put it in your own cookie and you've stolen their session.

This can be done in several ways, for example by sniffing the wireless network and looking at the HTTP packets being transfered or by XSS attack where you can tell the victims browser to reveal their cookie information to you.

I would like to mention that the example you describe in your question may also be vulnerable to SQL-Injection. If I change my cookie's sessionID to

asdf' OR 1=1-- 

I would most likely be authenticated as a valid user. To prevent this you have to make sure you have proper sanitizing on dirty data coming from your clients before you use the data for anything.

Basically when you hijack someones session you take their sessionID and pretend its your own. Usually the sessionID is transferred in the cookie, meaning that if you can access the other parties cookie you can just put it in your own cookie and you've stolen their session.

This can be done in several ways, for example by sniffing the wireless network and looking at the HTTP packets being transfered or by XSS attack where you can tell the victims browser to reveal their cookie information to you.

I would like to mention that the example you describe in your question may also be vulnerable to SQL-Injection. If I change my cookie's sessionID to

asdf' OR 1=1

I would most likely be authenticated as a valid user. To prevent this you have to make sure you have proper sanitizing on dirty data coming from your clients before you use the data for anything.

Basically when you hijack someones session you take their sessionID and pretend its your own. Usually the sessionID is transferred in the cookie, meaning that if you can access the other parties cookie you can just put it in your own cookie and you've stolen their session.

This can be done in several ways, for example by sniffing the wireless network and looking at the HTTP packets being transfered or by XSS attack where you can tell the victims browser to reveal their cookie information to you.

I would like to mention that the example you describe in your question may also be vulnerable to SQL-Injection. If I change my cookie's sessionID to

asdf' OR 1=1-- 

I would most likely be authenticated as a valid user. To prevent this you have to make sure you have proper sanitizing on dirty data coming from your clients before you use the data for anything.

1
source | link

Basically when you hijack someones session you take their sessionID and pretend its your own. Usually the sessionID is transferred in the cookie, meaning that if you can access the other parties cookie you can just put it in your own cookie and you've stolen their session.

This can be done in several ways, for example by sniffing the wireless network and looking at the HTTP packets being transfered or by XSS attack where you can tell the victims browser to reveal their cookie information to you.

I would like to mention that the example you describe in your question may also be vulnerable to SQL-Injection. If I change my cookie's sessionID to

asdf' OR 1=1

I would most likely be authenticated as a valid user. To prevent this you have to make sure you have proper sanitizing on dirty data coming from your clients before you use the data for anything.