tags:

views:

457

answers:

5

We have created a database driven website using PHP with set cookies and now need to prevent HTTP spoofing, any ideas on how to do this? we are beginners with this so any help would be greatful

+2  A: 

Spoofing of what? HTTP is just a protocol for transferring data, it's not really something itself would be spoofed.

The thing to do is not to prevent spoofing of information, but to simply never trust the client. In terms of cookies, store a hashed pseudo-random value that you compare against the database before accepting the cookie data.

UPDATED:

Given that it is specifically cookies that you're concerned about, I'll go a little more in-depth. There are two main things to concern yourself with when storing cookies.

  1. Do not store the actual data
  2. Validate against the database

So let's say you want to have a site with users where you store personal data. In the cookie, you can store the username or user ID and a hashed security token that is also stored in the database when the user logs in. The security token is not going to be knowable, and will change with each login. Any personal information stays in the database, never in the cookie.

Some more reading on best practice: http://jaspan.com/improved_persistent_login_cookie_best_practice

Zurahn
we need to detect attempts to spoof HTTP messages if that helps ?
Jermain
Perhaps you could describe a specific example of what you think could happen.
Zurahn
If someone finds out the cookie that PHP uses to manage a session, what is to stop someone on a different machine manually setting the cookie to the same value and pretending to be you?
Jermain
+2  A: 

If you want to prevent man-in-the-middle eavesdropping, you may want to use HTTPS, which creates a secure channel over the network, provided that adequate cipher suites are used and that the server certificate is verified and trusted.

Note: The original question was ambiguous. It is now clear that the question is about cookie spoofing.

Daniel Vassallo
The question is actually nonsense, so this answer offers good advise to *one* interpretation of it.
deceze
yeah well i did mention i was a novice, so take that into consideration, got to start somewhere
Jermain
@Daniel: You are right, I therefore removed my -1.
Andrew Moore
@Andrew: Thanks for the edit.
Daniel Vassallo
+3  A: 

You cannot "spoof" HTTP requests. You send a request to the server, and the server responds appropriately.

I think what you are trying to prevent is cookie spoofing. Considering that cookies are stored on the client-side, there is nothing you can do to prevent users from modifying theirs contents.

Do not store sensitive information in your cookies. They are not secure and easily read and modified by the client.

Use PHP sessions instead. The full explanation on how sessions work and how to keep them secure can be read in one of my previous answers.

Essentially, securing sessions is done on two fronts:

  • Preventing session fixation
    Regenerate a new session_id every X number of requests in order to reduce the amount of time an attacker has to steal the id.

  • Uniquely identify the client
    Use the IP and/or the User-Agent to uniquely identify the client and check that value on every page load against the ones stored in the session. This is really the only two choices you have to uniquely identify the client.

Even with that in place, no solution is fool-proof and once your session_id is compromised, you are pretty much done for.

Again, for an in-depth explanation, please see my previous answer.

Andrew Moore
okay thankyou seems helpful
Jermain
@Jermain: then feel free to make the answer your accepted answer by clicking the checkmark on the left of my answer.
Andrew Moore
i am not yet registered but once registered i will
Jermain
@Jermain, You are already registered. All you need to do is to click on the green checkmark to the left of the answer, if this answer was helpful.
Daniel Vassallo
sorry new to this, just did it though
Jermain
just a quick comment about point 2 'Uniquely identify the client' This is likely to cause problems. some clients will come from different ip's on every request forcing them to have to constantly sign in. This is caused by common proxies and load balancing systems. in secure situations I wouldnt trust x-forwarded for and other headers such as user agent. So I would not use point 2 at all
DeveloperChris
@DeveloperChris: All the drawbacks of method 2 is explained in my longer answer. Yes, `User-Agent` isn't secure, but its still a step forward than nothing at all...
Andrew Moore
sorry perhaps I should have read your previous answer. the main point I wanted to make is its a mistake to *even consider* using IP's for this function. I remember one major company (now gone) who used this technique for "extra security" It was so frustrating being logged out every second page request. The purpose of placing the comment here was to warn other readers of the potential issues. they may not read your other article either.
DeveloperChris
@DeveloperChris: It always depends on your target market. And if your load balancer switches you every second request, that's one misconfigured load balancer.
Andrew Moore
hugh that's what a load balancer does. every second it decides where to send the load. every second or every five or ten minutes if you are in a session and suddenly kicked after submitting that long and arduous article. you have a right to be pissed. the point is unless you *know* the ip wont change don't use them.
DeveloperChris
@DeveloperChris: A good load balancer configuration assigns a pipe to a particular client/port combination, and sticks with that pipe unless there is a need to switch. A bad load balancer configuration (unfortunately too common) randomly selects a pipe on each connection request.
Andrew Moore
That's understood, but as neither the application writer nor the surfer can control how the load balancer or proxy is configured AND there is enough out there that break "good practices" I still argue for the sake of your customers and your own sanity when dealing with the strange complaints that will arise don't do it. Unless you are sure your customers/clients are *all* on fixed IP's
DeveloperChris
A: 

Spoofing? The only real problem with compromised identity is cookie theft.

What you could do is, whenever a cookie is sent over the HTTP headers, to check this against the IP address it was issued to. For instance:

<?php
session_start();
$rec = db_query('select count(*), ip from session where session_id = "' . session_id() . '"');

list ($last_count, $last_ip) = $rec[0];

if (! $last_count) {
    # add it into the database
    db_query('insert into session (session_id, ip) values (' .
        '"' . session_id() . '", ' .
        '"' . $_SERVER['REMOTE_ADDR'] . '"' . 
    ')');
} else {
    if ($last_ip != $_SERVER['REMOTE_ADDR']) {
        print "user has stolen a cookie!";
    }
}
?>

But this can have a negative effect on people whose ISP issues them a dynamic IP address.

amphetamachine
A: 

I know this has been answered but I want to add another technique which I use, its particularly useful for administration logins. Use sessions as usual but add directory protection to the mix.

That way if a session is hijacked the hijacker must also be able to get the directory login.

I use this technique for forum administration. certain forums are readily hacked and this reduces the chance of a hacker getting in and causing serious issues.

DC

DeveloperChris