On Wed, November 22, 2006 11:20 am, Alain Roger wrote: > Now that i finished the client side of the web application i would > like to > improve the security of my administration side of this web > application. > My web hoster support a shared SSL protocol, however i would like to > do more > than simply use the SSL... I think the amazing thing is that you just used "simply" and "SSL" in the same sentence... :-) SSL is a VERY safe way to ensure that the data traveling from the browser to the server, and data going back from server to browser, is secure in transit. SSL is pretty much the armored truck ploughing its way through the Internet, shedding bullets like a duck sheds water. > I've heard that cookies and sessions can be easily hacked...so what do > you > use to secure your web page. > which methods ? With SSL in place, you have reduced your vulnerabilities to, essentially, the "endpoints" of the communication: who has access to the browser/client who has access to the webhost/server The sentence "cookies can be easily hacked" is true in the sense that anybody who can get ahold of your laptop/desktop can add cookie files. Or, if they can run a virus on it, they can install any cookie files they like, for any site. There is very very very little you can do to secure the computers of your users, even your admin users. Probably your best bet is to EDUCATE those users, as early and often as you can, about safe computer practices. You should also be very careful to use sensible things in your Cookies -- Actually, with PHP, you should send JUST ONE cookie for your entire site, and track everything else you need in your $_SESSION data. Okay, if you've installed some "forum" software or something, maybe integrating its authentication into your main login is a Bad Idea, so you can have "extra" cookies for the forum. Though most forum software comes with its own whole new set of Security issues. :-( The sessions getting hacked generally mostly boils down to the session getting hijacked by a compromised client/browser (see above), or somebody who already can login to the webhost/server -- at which point the sesssion itself is a tiny part of a much bigger problem, which is the whole SERVER is compromised. My best advice would be to use *ONE* session_start() in a single include file, probably the same way you are doing your DB connection, and let PHP experts worry about the mechanics of sending a "good" cookie. You may want to use http://session_set_cookie_params to require the your SSL cookie ONLY go through SSL, though. You then "only" need to focus on the parts of the process that you scripted in PHP. Your authentication, for example, should be simple and straightforward enough that you can sit down and test it in an afternoon and be absolutely certain that you can't manage to get "through" to anything you shouldn't, without a valid username/password. Other things to consider: Educate users about what is or isn't a Good Password. Attempt to steer users away from using Bad Passwords. Read this site over and over until you internalize it: http://phpsec.org/ And, just a general note, not directed at the question/post/Alain: Security is not something one can just slap on to the site after one finishes it -- It has to be a living breathing process that is in symbiosis with the life-cycle of the project. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
