SED wrote:
I've read some of the responses to your question, and I think I can possibly help to clarify some things ...When I use sessions in PHP or just plain login/password in $_POST, can 3rd parties or hackers monitor the transmission, between me and user, and somehow decode the transmission and use the variables to login other time or overtake the current session?If so, how likely is for someone to manage it (get the username/password)?
To answer your question directly, yes it is possible for people (hacker != computer criminal, by the way) to observe the transmission, but it is not very likely. Also, if someone successfully observes a user's HTTP request, they will have access to the user's data whether it is being sent via get, post, or cookies. There is no "decoding" necessary. However, though this is not too terribly difficult to accomplish, it is a lot harder than some people will lead you to believe. If you are worried about the security of your users, here are some things to consider in that regard:
1. For anyone to observe a specific transaction, they must have access to a machine that is between you (the Web server) and them (the Web client). For someone to reliably do this, they would need to have access to a machine along the path that is either very near the Web client (for targetting a specific user) or very near your Web site (for targetting a specific site, yours). Anything in between would likely have too much traffic. Needless to say, this scenario is unlikely. An example of such a thing would be perhaps if a curious systems administrator were observing outgoing traffic on a gateway that served a small office. If someone who worked in that office interacted with your Web site, it would be quite easy for the administrator to observe the transaction.
2. There are much easier ways to impersonate a user. PHP, by default, uses a single cookie to identify the Web client. Imagine if someone were to steal a cookie belonging to one of your users and then visit your site presenting the same cookie. You would mistake them for your user, right? Most attacks focus on the application itself, just like this example, because this is the usually the easiest thing to do. All versions of Internet Explorer from 4.0 to 6.0 have cookie vulnerabilities that allow any Web site to view any other Web site's cookies. So, if some of your users are IE users (very likely) and have not patched their browsers (also very likely), that cookie you use to identify them is in danger.
In general, security is a balance. There is always going to be a risk. The harder you make it for the bad guys, the less risk you have, but also (usually) the less accomodating you are to your legitimate users - shorter timeouts, requiring frequent reauthentication, extra data validation, etc. The easier it is for the bad guys, the higher the risk, but the more accomodating you can be to your users - longer timeouts, automatic features, storing payment information for easier checkouts, etc. The appropriate balance here is really best decided by you, but this can be difficult when you first get started.
Also, as others have said, SSL is the only way to reliably protect the communication from observation (it also verifies the identify of you and the user, which can be crucial), but if this is not an option, you can provide some decent security by observing the golden rule of Web development:
NTDFTC - Never trust data from the client.
This doesn't mean that you can't believe anything; it just means that your logic should be suspicious of everything you receive from the client (in PHP, this means $_REQUEST[] or all get, post, and cookie data) and validate it. Unfortunately, many people do not follow this rule (or even know about it), and this lead to many of the perceived security problems of register_globals.
Anyway, let me know if you have any other questions or would like to see some specific examples.
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
