My question is that,is using our real username and password on phpmailer for sending message,is safe to use?,anyone can steel our username and password,from my php script.is any solution is there,except hiding view source code.
IDs and passwords for email are much the same as IDs and passwords for database connections. Generally speaking, nobody other than you (and other sysadmins on the same server) should be able to see your source code, nor these passwords. PHP code is not visible to people visiting your site (unless you have misconfigured your server).
That doesn't mean you should not take precautions; There are ways of making this information available to your application without leaving it in source files, for example by putting them into .env files which are loaded into your environment (using something like Env), but are not actually part of your code base.
This allows you to keep passwords out of git repos, and should be stored outside your web root.
Furthermore, these files can be encrypted, but that really just moves the problem further along because at some point you'll need to store the key to decrypt it with.
Related
So I am encrypting data, storing it in the database, and decrypting it, using mcrypt.
I am wondering if it's safe to store the key for encryption in a php file outside of the public_html directory?
The reason for storing it in a file is that it needs to be used for multiple encryptions, so that multiple users can decrypt some data, and I figured storing it in a file is more secure than in the database table, right next to the encrypted data.
What are ANY potential security risks? Is it at ALL possible for a hacker to gain access to this file and thus the key?
Storing it above the public_html is a good idea. Your file should have the correct permissions configured so that only the web server or users that require it can read it.
An option is to split the key up and store in different places, for example part of it in a file on the file system, and part in the database. The benefit of this is it's harder to get the full key for an attacker because they need to access both the file system and the database.
Also consider your server environment has an affect on security, for example shared hosting is less secure than a dedicated server.
No one can say that it's impossible for an attacker to access the key because that depends on your entire server setup and config. Server's are most often compromised through vulnerabilities in software such as web servers, so you should follow good security practices such as keeping your software up to date.
If your server (as in its OS) is compromised, it is "game over", no matter whether your key is stored in a file or the database. So yes, it is "at all possible for a hacker to gain access to this file and thus the key" - by breaking into your server's OS.
If apache or PHP are compromised, but not the OS, you end up in a chicken-and-egg problem: If you put your key somwhere, where apache/PHP can access it, it can be taken by whoever breaks into apache/PHP. If not, you can't use it in your webapp.
This leaves only a scenario, where your webapp is compromised, but not the surrounding infrastructure - in this case, a file might indeed be a good idea: Many break-ins (e.g. most of the SQL injection variant) gain access to the DB, but not to the file system.
For sensitive environments we sometimes chose a model, where encryption/decryption is handled via a pair of FIFOs, with the real crypto being done by an external process - this can do some heuristics and refuse decryption on suspicious patterns.
Is there a way to encrypt or enclose my code on my Linux server after deployment? I know Zend does some kind of encryption, right? Is that what people use? Is this even possible? How do I go about keeping my code secure online?
You are right, you can use Zend Encoder, Ion Cube or something like Source Guardian to encrypt your source code.
Its not really needed unless you are giving away your code and dont want people to steal it though.
What is it about your server that you think its insecure?
Periodically check the open ports on you server
Do not trust the data coming from the browser - verify it and validate it.
Periodically do an audit of the processes on your machine and who can access them
Only have files in the document root that should be accessible by the outside world. Include files etc should not exist here
Check the log files periodically to check for suspect access.
For PHP errors/warnings - find a mechanism that does not give the client (browser) any info what has gone wrong. Send that to yourself. This is true for MySql as well.
If the file-system on your server has been compromised, then all is already lost. The best you can do is restrict folders, which are writable by web-server's user.
Also keep the application code outside the DOCUMENT_ROOT. Publicly available should only be the file you actually intend to show user, or which would not show any sensitive informations: like an index.php file which contains and include ../app/bootstrap.php .
You could use Zend Guard, but this would impact owner of the code. You might not be always the one maintaining it.
I developed a php application, and I have a config.php , which store the constant use among the application, in this file, it included all the important information, such as the Mysql server address, port number, user name and passwords. I am worry about someone can get the file, and do something that I don't want, how can I protect this file? Thank you.
Practice general good password security (don't use dictionary words etc)
It is good practice to name the file with a .php extension, as you have done, because then the web server is unlikely to be tricked into serving the file as plaintext.
Make sure config.php is stored outside of web root. That means that if something were to go wrong with your server configuration and it started serving PHP files up as plaintext, you wouldn't leak your database password (because no-one would be able to request config.php).
Make sure the database credentials are appropriately-named constants, rather than variables. This makes it less likely that you might somehow use them inappropriately (for example, if the password was $password rather than DB_PASSWORD you might do something with the $password variable in the global scope, forgetting that it's in use - unlikely, but a small possibility).
Normally it is just stored in a php file, you can make if belong to the www-data user or what ever your web server is using. If someone does have access to your server they won't be able to open it
First time reader, first time poster (woo!)
So I've been implementing my login scripts for an informal website. Not likely to be compromised, but just to be safe, I'd like to ask if there's a security risk in having my MySQL database login stored in plaintext in the php code.
As far as I know, the code itself is parsed by Apache, so the end-user doesn't see it (just the output), which would mean it should be safe to keep... but I'd like a second opinion.
Summary:
Accessing database through mysql_connect, mysql_select_db, mysql_query. Login info stored in local variables defined at each iteration of the script, and (I think) dumped once script terminates.
Security vulnerability?
You could also consider moving the username/password combination to a seperate configuration file that lives outside the webroot. Make sure that place is not directly accessible from the webserver side.
That way, if for some reason the webserver decides not to execute PHP files anymore you don't lose the account information to the database server.
As an added bonus, if you use anything that makes a copy of the .php file (editors, SVN or whatever) in the webroot, you don't risk anyone getting around the .php execution.
That's very standard procedure for web applications that talk to a database.
I recommend taking read permissions away from the file for users other than the web server and yourself - if you have other users on your box that can spy on the file, they'll be able to access your mysql server.
Also, you should adjust the executable permission on the top directory as it'll prevent unauthorized users from even entering it.
Harden your mysql user's allowed host, so that only the boxes you need can connect to it.
Of course if your box is compromised and an attacker gains root access, there's little that will protect you.
You can add some additional layer of security by putting all your php files (except index.php of course) in a separate directory and protect them with a .htaccess file. This covers cases in which the php parser is not invoked and apache returns the files in clear text. One more thing that might be usefull: <?php defined('some_id_here') or die(); ?>. You can put this at the top of every php file except index.php (where you define some_id_here) so there is no direct access to your database-files.
Not having the bulk of the code within the webroot, where it is possible, however unlikely, is just the first line of defence that can be taken.
Your database should also be secure even if the database user and password was published - by the simple expedient of only allowing a small number of source machines to connect to the database anyway.
Defence In Depth
<?php // simplest /index.php, as the only .PHP file in the public-accessible webroot
require '../bootstrap.php';
I dont know how you connect to your MySQL database, but if you use PDO there is the possibility that the PDO constructor throws an exception.
If you dont catch this exception the Zend Engine will show a backtrace by default and reveal your connection details!
It is just normal to store the connection creds inside a php file/variable or, in that case you use PDO, in the DSN (Data Source Name). I would even suggest you to put it inside a php file, because it will gets parsed and not send plain into the web...
One step to more safety is to put the login details outside the www-root or protect it with an .htaccess file (this would make it impossible to access the file via the webserver).
However on my server it is impossible to connect not from localhost. So i dont care if someone reads my login details (it is not the case of course.).
Anybody who can login with root privileges on that web server (or possibly somewhat lower ones too) will be able to see your password -- but then, it's essentially impossible to defend against the super-user (wherever else you might keep your password, they could hack around and find it). Apart from this risk, you should be safe.
Edit: backups of the server could also be used (if unencrypted, or by somebody who can decrypt them) to recover your password if it's in-clear in your .php script. This possible attack might perhaps be mitigated (to great inconvenience/cost) by keeping the password on a different, secure location, and only sending it (securely) under highly restrictive circumstances. Is this the kind of attack you fear?
Scenario: a web application written in PHP utilizes an Amazon Web Service and must keep the Access Key ID and a Secret Access Key handy in order to function. Are there current recommendations and/or API's out there for storing this data securely?
My thought is to symmetrically encrypt it into a file based on a key created from local server variables. That way it's [hopefully] gibberish if someone gets a copy of the file through FTP, lost laptop with files copied, etc. The concern I have is that a skilled attacker could just upload their own script to decrypt it.
This seems like a common situation and one I've never achieved a comfortable solution for. Obviously I can't use a one-way hash, because I need the original data to create a HMAC to send to AWS. Links to related S.O. questions are very welcome.
Ah. The question of security.
I think the question you should be asking here is what do you do with say, for example mySQL passwords in your php config files?
To be quite frank, I would say that if someone managed to get a copy of your files, then your security needs rethinking anyway. For my own use, I generally only keep the passwords in one place, (on the server where they should be used) and make sure that I use a randomly generated password each time (paste it into the config file, and voila!)
To be honest, if it's not your own host, ANY sensitive data can be compromised.
If it is your own host, I'd suggest using proper permissions within Linux, and PHPSuExec to make sure that only the scripts that YOU write can access the files.
Anyway, to answer your original question, your AWS Access / Secret Keys are just the same as a MySQL password, Ok, it has the potential to let someone access your service, but it doesn't give them access to your personal details. Even with symetric encryption, if your script has a security hole, the information can be accessed.
Put simply, you take a risk when you put these keys anywhere that is accessible to anyone but you. How much do you trust Amazon's servers not to be compromised?
My suggestion would be to try and add as much security as you can, but keep an eye on your account, I'll generally have a cron job running to send me an email with changes to my S3 account (new files uploaded, new buckets etc etc) and from that I can tell what's going on.
There is no easy solution, it's a mix of securing each seperate layer of the System. I mean, if you use symetric encryption, the password for that has to be stored somewhere, right? or are you going to type it in every time ?
Hope this helps
My thought is to symmetrically encrypt it into a file based on a key created from local server variables. That way it's [hopefully] gibberish if someone gets a copy of the file through FTP, lost laptop with files copied, etc. The concern I have is that a skilled attacker could just upload their own script to decrypt it.
This wouldn't hurt, but ultimately it is just security through obscurity as somebody who can read the file can probably also read and reverse engineer your code. Short of typing in a password or otherwise providing a secret every time the server starts, encryption isn't going to help. It just shifts the problem to how will you protect the encryption key (which also needs to be accessible to the server)?
You have to harden and design your application and server (don't forget the OS, and remote access to the OS) so that nobody unauthorised can read the files on the system in the first place.
If you're worried about someone getting physical access to the box, concentrate on physical security to stop that happening.
I use symmetric encryption like you suggest. When I start my server I need to give it a key to decrypt the files containing the authentication data.
Of course a hacker could do a memory dump and read the password that way but that's quite a bit tougher than reading a cleartext file. There's no perfect solution, security is always a compromise between risk and ease of use.
So server security is still the key issue, its just a question of how much security is enough. I'd suggest looking at Bastille Linux or something like that to harden your server but that's another topic altogether.