RE: [PHP] isset
-Message d'origine-
De : Robert Cummings [mailto:[EMAIL PROTECTED]
Envoyé : lundi 16 avril 2007 20:28
À : Edward Vermillion
Cc : php Lists
Objet : Re: [PHP] isset
On Mon, 2007-04-16 at 13:16 -0500, Edward Vermillion wrote:
On Apr 16, 2007, at 12:30 PM, Robert Cummings wrote:
[snip]
Bleh, my mistake... I'm so adverse to empty() I forgot it doesn't
generate notices.
Strings only containing only spaces are not empty. Strings
containing a 0 are empty. It's crap for almost any kind of
validation routine. It's one of those useless, magical, shoot
newbies in the toes functions. But then I guess to each their own :)
What about in the following context?
$arr = array();
If (!empty($arr)) { }
This is where i have found it to be the most usefull...
tim
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Session Authentication
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ólafur Waage Envoyé : lundi 9 avril 2007 14:40 À : [EMAIL PROTECTED] Objet : [PHP] Session Authentication Lets say i have a login system. This system authenticates the user via mysql, when the user is authenticated, i set a session variable to let the system know the user is authenticated. ie. $_SESSION[authenticated] = true; Lets also say i know that's how the system works, that a session variable within my browser is set to true. Could i do this if i knew all this info and authenticate myself by setting the variable from the client side? $_SESSION['variables'] are stored server side and can only be set during script execution, not by the browser. If it is possible, what can i do to prevent this or increase security? What is possible here is called session hijacking, imagine this scenario: You are an innocent tourist, and go into a cyber café to check your mail, let's assume when you authenticate to your mail system, it is not encrypted. The owner of the cyber café is sniffing all incoming, and outgoing data, and just happened to know that you logged in. The SESSION_ID that is stored in a cookie on your computer is what links you to your authenticated session on the server. So the owner manages to sniff that SESSION_ID, knowing you are still logged on, he goes to the same site you are on, and edits the cookie that was generated by that site, to have the same SESSION_ID as the one he sniffed over the network. The owner has now owned/hijacked your session and is authenticated as yourself. Depending on the logoff mechanism involved he may or maynot be able to continue using your session when you logoff. So, to conclude on how to optimize your security, your authentication system should be encrypted, as in log in using https:// . Hope this helps, P.S You can try this at home by opening your same siteon two different computers and editing the session cookie on the one your not authenticated on with the session_id from the one you are authenticated on. It's quite suprising how it just logs in without credentials ;) Regards, Tim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Session Authentication
-Message d'origine- De : Tijnema ! [mailto:[EMAIL PROTECTED] Envoyé : lundi 9 avril 2007 17:55 À : Peter Lauri Cc : Martin Marques; Ólafur Waage; [EMAIL PROTECTED] Objet : Re: [PHP] Session Authentication On 4/9/07, Peter Lauri [EMAIL PROTECTED] wrote: -Original Message- From: Tijnema ! [mailto:[EMAIL PROTECTED] Sent: Monday, April 09, 2007 5:38 PM To: Martin Marques Cc: Ólafur Waage; [EMAIL PROTECTED] Subject: Re: [PHP] Session Authentication On 4/9/07, Martin Marques [EMAIL PROTECTED] wrote: Tijnema ! escribió: On 4/9/07, Martin Marques [EMAIL PROTECTED] wrote: Yes: Don't use transparent session id, or even better, save the authentication in a cookie on the client (seperated from the session array). And then the user would crack the cookie I know they are encrypted, but trust me, cookies can be edited. So what? The user authenticated himself, so what is he gonna crack? Yes, but i guess you're not only storing if the user has authenticated, also storing a username? And if that's not the case, then you could authenticate by creating a cookie where it says authenticated = yes, and you're authenticated... Tijnema -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php [Peter Lauri - DWS Asia] If cookies were that unsecured so you could create your own cookies that easily, then would cookies exist? Best regards, Peter Lauri Cookies are old, so in the time they were introduced, today it is possible to create and modify cookies with some good tools. These tools are illegal, but every cracker is 99% illegal right? But that means i can't give you these tools to proof it, but it is possible. Tijnema Whatever, really your bosting for nothing IMO, ethereal is available to everyone for sniffing cookie info, so is firefox cookie editor, and http live headers... What is so hideous about these tools? I use all of them to trouble shoot my websites while under developpment... Really the way to securing web application is learning to hack them or learning what hacks are possible.. And stop feeling superior sir! Regards, Tim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
