note 94246 deleted from class.pdo by danbrown

From: Date: Sun, 25 Oct 2009 13:07:11 +0000
Subject: note 94246 deleted from class.pdo by danbrown
References: 1  Groups: php.notes 
Request: Send a blank email to php-notes+get-162048@lists.php.net to get a copy of this message
Note Submitter: prometheus ---- Magaloman: Sorry for that but I say this is not a solution, nor a half parted. If someone accessed the code (with code injection for example), all DB connect informations can walk into his hand, its a simply var_dump() call. If we want to nobody know our DB connection info, its more secure if we use ODBC connection aliases, without any workarounds or hacks. You just need to pass an alias identifier then ODBC opens the connection in a bit securest way. To keep our passwords in our hand is a main point of security - but we cannot keeping all of that. - protect the site from XSS and injections, use strip_tags() and PDO::quote, with GPC off. - protect our users password, use salted MD5 hashes. - protect our DB connections, use ODBC aliases. This is near to maximum, keep in mind that we cannot protect the DB communication, all others are protectable. So I said that to protect from XSS and from other types of injections is more important then where we place out our DB connections - but if we choose to place out these informations I suppose that use a real solution. For example: I have a secret file and I create a folder-maze for hide that. Our mother or grandma maybe loose within, but our brother know how to use the "find file" function... this is equls to create an INI file for DB connect infos which can accessable by opening a JSON file in a secret place which stores the path to INI, then I create a class to encapsulate that JSON file path, then I create a function that hides that class, then I store that functions name in a variable and called by that... its not a way, its a joke, just our work going to hardest - then kiddie call var_dump($myUberSecretDatabaseConnectionInformationArray)... :)

« previous php.notes (#162048) next »