views:

400

answers:

6

While implementing a flash-based uploader, we were faced with an issue: Flash doesn't provide the correct cookies. We need our PHP Session ID to be passed via a POST variable.

We have come up with and implemented a functional solution, checking for a POST PHPSESSID.

Is POSTing the Session ID as secure as sending it in a cookie?

Possible reason for: Because both are in the http header, and equally possible for a client to forge. Possible reason against: Because it's easier to forge a POST variable than a Cookie.

+5  A: 

It is as secure — forging the POST is equally as easy as the cookie. These are both done by simply setting flags in cURL.

That being said, I think you've got a good solution as well.

Nerdling
+1  A: 

If you are able to obtain the session ID from active content in order to POST it, this presumably means that your session cookie is not marked HttpOnly, which one of our hosts claims is otherwise a good idea for defending against cross-site scripting attacks.

Consider instead a JavaScript-based or even refresh-based uploader monitor, which should integrate well enough with everything else that the cookie can be HttpOnly.

On the other hand, if your site does not accept third-party content, cross-site scripting attacks may not be of any concern; in that case, the POST is fine.

Jeffrey Hantin
+2  A: 

I think sending it via GET would also work fine, since you fake anythink in a HTTP request (using curl or even flash). The important thing is what is encrypted in you cookie/post/get parameter and how is it encrypted and checked on the server side.

Hippo
A: 

POST data is not an HTTP header, but it is sent as part of the TCP stream which makes it just as easy to read/forge as an HTTP header. If you intercepted an HTTP request it would look something like this:

POST /path/to/script HTTP/1.1
Host: yourdomain.com
User-Agent: Mozilla/99.9 (blahblahblah)
Cookie: __utma=whateverthisisacookievalue;phpsessid=somePHPsessionID

data=thisisthepostdata&otherdata=moredummydata&etc=blah

So as others have said, POST and cookies (and GET data, i.e. query strings) are all easy to spoof, since they're all just text in the same HTTP packet.

David Zaslavsky
It is important to note that content-length would tell the server how much data to expect in the request, lest an infinite wait or buffer overflow occur.
Nerdling
+1  A: 

Really if you are worried about which one is easier to forge, you're worrying about the wrong thing. Simply put, either will be trivial to an experienced attacker. You might keep out the "script kiddies" by choosing one over the other, but those people arern't the ones you need to be worried about. The question you should ask yourself is "what defenses do you have against someone forging an id?" It will happen. If your id is unencrypted, and easy to guess, that's a problem. It will get hacked. Since you are asking which is more secure, I would say that you are concerned.

Here's another thing to consider, since your application is flash, it's susceptable to modification (just like javascript HTML code), because the compiled code is on the attackers machine. They can look through the binary and figure out how the code works, and what it needs to retrieve from the server.

Kevin
+1  A: 

I just want to reiterate that both Cookie and Post are equally insecure.

Toby Hede