27

Despite the blatant title of the question, this is actually for a genuine purpose.

My site uses PHP code like this:

    $select="select id from tableA where user_id='".$_SESSION['sess_user_id']."'";

I'm really trying to think like a hacker and figure out how I can alter this value. I've read articles talking "about" session hijacking, but being vague about how that can be done...

AviD
  • 72,138
  • 22
  • 136
  • 218
Steve
  • 469
  • 1
  • 6
  • 6
  • what you're asking about is not "hijacking", it's poisoning, manipulation, injection... it does have a lot of names, but hijacking is something else: that is when you steal someone *else's* session. – AviD Feb 10 '11 at 08:26
  • Wait, my previous comment may have been jumping the gun... What is it you're trying to do? Get access to someone else's record, or go for the bigger SQL Injection vulnerability there? – AviD Feb 10 '11 at 08:28
  • 10
    What's you website address? that sql query looks like a lot of fun. – WalterJ89 Feb 10 '11 at 08:51
  • 2
    Wow talk about a bad design. I can use sql injection to obtain the session id and then just login as that user. I don't even need to crack a password. – rook Dec 06 '11 at 19:04
  • 1
    I don't think this question provides enough details to answer the question. Sample ambiguities: What kind of control does the attacker have over the value of `$_SESSION['sess_user_id']`? Is this part of the session state derived from an attacker controlled value, such as the username entered on a login form? How is the value `$select` used subsequently in the code? – D.W. Dec 07 '11 at 05:37

4 Answers4

11

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.

Community
  • 1
Chris Dale
  • 16,119
  • 10
  • 56
  • 97
  • 1
    very interesting to learn about manipulating _my own_ cookies... In the above / the code that I have, how are you assuming that the value is being retrieved from a cookie? (is that an assumption you made, or something about $_SESSION)? – Steve Feb 10 '11 at 10:14
  • @Steve, *Usually* the sessionID is distributed via cookie. You can also transfer the session in GET or POST, but the end result is the same. The client can always modify this value and you need to sanitize it. – Chris Dale Feb 10 '11 at 10:51
  • NEVER ever trust anything coming from a client. note sure if thats rule #1 but its in the top 10 – WalterJ89 Feb 10 '11 at 13:05
  • 1
    -1 No, I'm sorry but its probably not vulnerable to sql injection. If any other query in the application was vulnerable then the results would be disastrous, because the attacker could login without needed to crack a password hash. Also your injected query would error out. – rook Dec 06 '11 at 19:08
  • @Rock, please stop insulting people. If you have a point, it is likely that it will be taken much more seriously, if you use proper arguments to support it, instead of insults. – Hendrik Brummermann Dec 07 '11 at 09:07
  • 3
    `$_SESSION['sess_user_id']` is probably not the session ID but the user ID. – Gumbo Dec 07 '11 at 09:18
  • I fixed your clearly incorrect sql injection payload. (which would never be an attack pattern anyway...) – rook Sep 25 '12 at 04:58
  • Thanks. Forgot to comment out the rest of the query. This query would also work: asdf' OR '1'='1 – Chris Dale Sep 25 '12 at 05:15
  • @ChrisAndrèDale : Cookie stores session_id, which is retrieved by the server which accesses the the member of `$_SESSION` array, so, changing cookies to `asdf' OR 1=1--` or something like that should not probably work because it would not be a valid Session ID. – cipher Mar 04 '13 at 15:29
  • In this very example, putting my sample sql injection into your cookie would hijack someone elses session – Chris Dale Mar 04 '13 at 17:50
8

If you're interested in a hands on demonstration, Twitter is a very good example of how easily it's done. You'll need:

  • Two Computers
  • Firefox with Firebug (obviously there are other options, but these are popular and easy to get)
  • A Cookie Editor, like Advanced Cookie Manager (again, easily installable add-on through Firefox)

On computer A with firefox and firebug, log in to your twitter account on the non-https site. Once logged in, open up Firebug and look at the "GET twitter.com" line. When you expand it look under the Response Headers section and find Set-Cookie. In there you'll find a cookie called _twitter_sess. Highlight and copy the value (all the way until the semi-colon).

Now open up Firefox with the advanced cookie manager on computer B and go to the twitter login page. Open the Advanced Cookie Manager and filter for twitter.com. Once you find the twitter.com domain and its list of cookies, you'll see a cookie called _twitter_sess. Delete it. Now make a new cookie with the name "_twitter_sess", path "/" and "Value" the value of _twitter_sess from the other computer. Save the cookie.

Now close the cookie manager and go back to the twitter login page, refresh the page and bam, you're in.

Now just devise some clever way to get someone else's session (open wifi, xss) and that's one way of how session hijacking is done.

Safado
  • 732
  • 4
  • 12
4

Karrax's code is an SQL Injection attack (which your code is vulnerable to - this needs fixed) not a session hijacking attack.

$select="select id from tableA where user_id='"
    .mysql_real_escape_string($_SESSION['sess_user_id'], $db_handle)
    ."'";

In session hijacking, Bob steals the value for the session id you assigned to Alice. This might have been as a result of a MITM attack on the HTML stream, network sniffing, a CSS bug which allowed him to embed some javacript onm your site, or other methods.

It's important not to loose sight of session fixation problems - even if you set the SSL and HTTP only flags on a cookie, AND set use_only_cookies that does not resolve the problem where Bob attacks Alice's computer before she accesses your site and sets a specific value for the session id. Bob can then set the same value on his computer and his requests are bound to the same session as Alice. So when you authenticate you should generate a new session id - see session_regenerate_id()

symcbean
  • 18,278
  • 39
  • 73
  • No, how about this. I find sql injection in any other query in the entire application. I use that to obtain the session id and then just login. I don't even need to crack the password. You get a D- in exploit development. – rook Dec 06 '11 at 19:05
  • That pre-supposes that you can find an injection vulnerability, that the session is stored in a database with the injection vulnerability, that the nature of injection vulnerability leads to a disclosure, and that either the session is active and there are no defences against session migration or the system is vulnerable to session fixation. Fix the big holes first. – symcbean Dec 07 '11 at 17:11
  • Defense in depth, security in layers. Its why we hash passwords. Vulnerabilities have been found in parametrized query libraries that lead to sql injection, there are classes of bugs outside of the control of your average programmer. So you must plan on failure. – rook Dec 07 '11 at 17:35
2

Session hijacking usually involves stealing a cookie from a user. For example Firesheep is a plug in for Firefox that steals sessions over unsecured Wifi. HTTP is a stateless protocol so the best we can do to authenticate people is with cookies.

The PHP code you have in your question is an example of code that is could be susceptible to SQL injection. It is usually best practice to sanitize variables before putting it in a query like that.

WalterJ89
  • 747
  • 6
  • 10
  • -1, no its probably not vulnerable to sql injection. But if there was a sql injection vulnerability in any other query in the entire application the results would be disastrous. – rook Dec 06 '11 at 19:07
  • @Rook If i was to edit my session cookie to read something along the lines of "'1' OR password = '123456'" I could possible do unintended things. It depends on error settings, MySQL version or what php is doing with that query. That input is not sanitized so yes it is vulnerable to SQL injection and it is just bad practice. there isn't enough code to show otherwise. – WalterJ89 Dec 06 '11 at 20:14
  • 1
    you are thinking of $_COOKIE[], $_SESSION[] is not an attacker controlled variable, unless he specifically setts it with the cookie value. Which would be as retarded as storing the session id in the database. Also, no you would use blind sql injection to obtain the session id (mysql error messages are useless), and then use that as your cookie value to authenticate. – rook Dec 06 '11 at 23:50
  • @Rook Yes you are right. I did have Cookie's in mind. I'll change my question to be more correct. – WalterJ89 Dec 07 '11 at 02:34