I just realized that making usernames and passwords properties of an object creates a huge security risk because they are visible with
print_r $object;
How and where are these sensitive data stored? In my old procedural framework I had “setup.php” files which I included to get these values. I suppose I could include them in the appropriate class method. For example:
public function __construct($account) {
include "/path/to/accounts/" . $account;
$this->database = new Database($user, $pass, $name, $host);
}
Any other ideas about safekeeping usernames and passwords? (I’d rather not use a database for this.)
Surely if an unauthorised person can write their own PHP code on your server to inspect the inner workings of your app, then your security has already been compromised?
Yes but there are easier and harder places for hackers to attack. The public part (public_html) is easier to hack than the root of the server. Once an object is created it is available everywhere (kind of like a global variable) while a file in the root is local and harder to crack.
Any ideas about keeping usernames and passwords safe in an OOP php framework? (I’d rather not use a database for this.) I’d love to have a discussion about this subject. Thanks.
I’m not clear why you think you’re vulnerable in the first place. If a hacker can’t run arbitrary PHP on your site, then they can’t print_r $object. And if they can run arbitrary PHP, then you’re already hosed.
Lets look at this. This attack is called “On the other side of the air tight hatch way.” The attacker has root access to your machine and can do what every they want. Your passwords are the least of your problems now.
I don’t think there’s much to discuss here since there are really not many options and others have already exaplained why. You can encode your php files with ionCube or something similar for some increased protection but its effectiveness is limited, too.
The answer is elsewhere - keep your server secure against attacks.
captaincss, if you’re interested in how config settings can be handled in OOP, you could take a look at how it’s done in my framework of choice (Kohana). Configuration is stored as arrays in separate files under a /config directory, and in your app you instantiate a config object which reads in the setting for whichever configuration group you want.
Kohana gives you the choice of database and/or file system configuration data and provides the corresponding readers and writers. This is quite beyond anything I’m planning on now. What interested me were the properties they have. Only the directory and database locations. The config data is passed through, returned to the caller. That seems safe enough.
Anyone who has managed a website, specially a commercial one, knows that websites are constantly under attack, 24/7/365, by very sophisticated hackers using tireless robots. The attacks come in innumerable ways with the url and html forms being great windows of opportunity. An approach that is based on the idea that if they break in you are already hosed is not a good one. My approach is to think about security constantly.
For example, to connect to a database you need four pieces of configuration data (host, user, password, and database name). Once the connection is made you no longer need these data, all you need is the connection resource or connection object, and it’s best not to have the configuration data floating around in a config object that persists for the duration of the php process (Kohana does not do this).
In the grand scheme of things local scope variables are safer than global ones. php objects are super-global as far as I can tell. Once a password becomes the property of an oop object in practice it becomes a global variable even if declared as private. You can see it with var_dump() or print_r().
Paranoid? Perhaps. My point is that every ounce of prevention counts.
I don’t think anyone was suggesting that you should ignore other security measures… the point is that once someone has managed to run their own php code on your server and print_r() any of the vars from your app, then there aren’t any security measures that are going to be effective past that point. You say that your preference with procedural code is to keep the database passwords in setup.php and include it when you need it… what is to stop an attacker with write access to your public_html folder from including that file in his/her own script and gaining access to the the information?
An object has the same scope as any other variable you declare in php, and you can unset() them in the same way.
If an attacker could print_r $object, then an attacker could also readfile(‘setup.php’), which means your old procedural framework was just as vulnerable… if you can even call it a vulnerability, which no one here seems to think to it is.
We all love analogies, right? You’re worrying about a thief being able to pick your front door lock from inside your house.
To me that is so obvious that I don’t see the reason for even mentioning it.
Once dead, you’re dead.
You say that your preference with procedural code is to keep the database passwords in setup.php and include it when you need it… what is to stop an attacker with write access to your public_html folder from including that file in his/her own script and gaining access to the the information?
I thought I said that my secure files are NOT in public_html folder. I keep them in the server root.
An object has the same scope as any other variable you declare in php, and you can unset() them in the same way.
OK. Is unsetting the variable that contains object the same as destroying the object?
They had a reformed car thief on TV. They asked him which cars he preferred to steal. He replied: “The ones where the driver leaves the ignition key in place.”
You seem to be saying “A thief could get into your house so why bother with keys, locks, and other safety devices?” To try to keep the thief out or at least make breaking-in as difficult as possible.
I don’t see why you have a problem with my question. You seem to be making simplicity very complicated
In this case, the car is a web app, and the web app doesn’t work without the keys. That’s why every app, even your old procedural framework, keeps that information readily available.
I don’t see why you have a problem with my question.
I don’t actually have a problem with the question. But a half dozen people have already given you the same answer.
Do not forget there is also: hightlight_file. Once again, when an attacker can run arbitrary code on your server. Their is nothing you can do. You’ll need to have a DB password somewhere, readable by your application to connect to the DB and pull down settings.
Assuming that the attacker does not have access to the server directly then the only possibility of the code being compromised is if the page doesn’t get processed as PHP and so all the PHP displays in the browser.
The way to prevent the password etc being compromised in that situation is to place that code in a separate file that is not inside of public_html and so is only accessible when the PHP can actually run (at which time none of the PHP will then be visible to the attacker using a web browser).
