How to prevent HTTP Spoofing?

Question

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

Cryptozoic

its being uploaded once we have completed the security issues – Cryptozoic

Answer 1

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.

Capablanca

@Jermain: then feel free to make the answer your accepted answer by clicking the checkmark on the left of my answer. – Capablanca

i am not yet registered but once registered i will – Cryptozoic

@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. – Penury

sorry new to this, just did it though – Cryptozoic

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 – Hogback

@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... – Capablanca

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. – Hogback

@DeveloperChris: It always depends on your target market. And if your load balancer switches you every second request, that's one misconfigured load balancer. – Capablanca

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. – Hogback

@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. – Capablanca

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 – Hogback

Answer 2

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

Cupcake

we need to detect attempts to spoof HTTP messages if that helps ? – Cryptozoic

Perhaps you could describe a specific example of what you think could happen. – Cupcake

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? – Cryptozoic

Answer 3

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.

Penury

The question is actually nonsense, so this answer offers good advise to one interpretation of it. – Tree

yeah well i did mention i was a novice, so take that into consideration, got to start somewhere – Cryptozoic

Answer 4

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.

Ansela

I'm not sure how useful this "advice" is. This doesn't just catch those with a dynamic IP address but also those using a mobile device like a laptop. Moving from one office to another may be sufficient for you code to identify them as cookie theives. I don't recommend this one. – Otway

Answer 5

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

Hogback