Question re: php security

fguy64

New Member
Messages
218
Reaction score
0
Points
0
Suppose I have an html file in my public_html directory, and that html file contains a reference to a php file, call it test.php, in a different directory, call that directory dir1. That means that anyone will know that there exists in dir1 a file called test.php.

now suppose dir1 has permissions 711, which should make it possible for test.php to execute properly.

given that the php code gets parsed at the server and is not sent to the browser, is there a way for someone to actually get a look at that php code, and if so, how could I prevent that from happening?

Thanks.
 

garrettroyce

Community Support
Community Support
Messages
5,611
Reaction score
249
Points
63
I hope this paragraph helps:

Read - If the directory listing can be obtained
Write - If user or process can change directory contents somehow: create new or delete existing files in the directory or rename files.
Execute - If user or process can access the directory, that is, go to it (make it to be the current working directory)

Web server assigns the rights of the web-server-specific user, typically user "nobody", to the connected web client, as if "nobody" is connected to the web server. "Nobody" doesn't belong to your group and thus it inherits permissions that "others" have to your files.

* For generic files such as html or images, etc you usually need to set 644 permissions. It is because "nobody" needs to read the file, and thus the file should be readable by others, hence 4 (read only) permissions for both group and others. For yourself you need a right to read and write (hence 6) to the file.
* For scripts you need 755 rights. The script should be executable by "nobody". The script file should also be readable by "nobody", as the file is interpreted by an interpreter such as Perl and therefore must be readable. Thus it must combine read and execute permissions for "others", as "nobody" belongs to "others" group. For yourself you need to have also write access, getting 755 as a result.

from here: http://www.zzee.com/solutions/linux-permissions.shtml
 
Last edited:

fguy64

New Member
Messages
218
Reaction score
0
Points
0
Thanks Garret, I'll check out that link.

I'm missing something somewhere. Let me describe the situation...

I have a subdirectory of public_html that has 711 rights on the directory. within that directory are html and php files that have 644 rights.

Using my browser, I am able to load any of the htm files, and cause the scripts to be executed properly. So I have a working situation in which my scripts have lower access rights than you say are required.

AM I missing something?
 

garrettroyce

Community Support
Community Support
Messages
5,611
Reaction score
249
Points
63
711 is right for the directory. The server's programs and anyone viewing the site can be in the directory, they can't upload or view the files directly. PHP files are not executable since they're only text, they have to be read by the parser so read access is the only required.

So, you're right on :)
 

fguy64

New Member
Messages
218
Reaction score
0
Points
0
Thanks bud, so I am right on. Good to hear. I don't want to flog a dead horse, but it's still not clear to me whether it might be possible for someone to actually view my php files somehow, even though the code won't be sent to the browser they will know the files are there, and they will know the names.
 

misson

Community Paragon
Community Support
Messages
2,572
Reaction score
72
Points
48
Every file with a PHP extension will be passed through the first registered handler before being sent to the client. This means that there's no way for a visitor to view a .php file by accessing it directly when PHP is registered as the handler for .php files. If PHP isn't registered, then PHP scripts aren't working, which is a more immediate concern that security. The only other way a visitor can access the source is indirectly, which would require another script (not necessarily PHP) that opens files and sends their contents to the visitor. If you don't have such a script, then you're safe.

Permissions will be of limited utility in preventing reading the source of a script. As stated above, the server won't send the source on its own, so the only read access you need to prevent is from users on the same server. The server needs read access to the script; if the server doesn't run under your credentials, any permissions that let the server read the script will let another user read the script (as they can write a script that will be run by the web server using the server's credentials).

Edit: I just set a PHP script to mode 0600 and it still worked. It looks like the server runs under your account, so removing read access from all but the file owner will prevent other local users from reading the file while still allowing the server to access it.
 
Last edited:

fguy64

New Member
Messages
218
Reaction score
0
Points
0
Every file with a PHP extension will be passed through the first registered handler before being sent to the client. This means that there's no way for a visitor to view a .php file by accessing it directly when PHP is registered as the handler for .php files. If PHP isn't registered, then PHP scripts aren't working, which is a more immediate concern that security. The only other way a visitor can access the source is indirectly, which would require another script (not necessarily PHP) that opens files and sends their contents to the visitor. If you don't have such a script, then you're safe.

Permissions will be of limited utility in preventing reading the source of a script. As stated above, the server won't send the source on its own, so the only read access you need to prevent is from users on the same server. The server needs read access to the script; if the server doesn't run under your credentials, any permissions that let the server read the script will let another user read the script (as they can write a script that will be run by the web server using the server's credentials).

Edit: I just set a PHP script to mode 0600 and it still worked. It looks like the server runs under your account, so removing read access from all but the file owner will prevent other local users from reading the file while still allowing the server to access it.

Thanks Mission, I'm just getting started with MySQL/php It looks like your last comment addresses the issue. I guess I have some research and testing to do. This question is all about having your script establish a connection to MySQL without any intervention, without having the password visible to others in the source code. It sounds like a question everyone must deal with, I just haven't found explicit mention of the solution yet, till now.
 
Last edited:

garrettroyce

Community Support
Community Support
Messages
5,611
Reaction score
249
Points
63
Don't worry so much about people seeing your code. The server is set up to disallow this by default. What happens when a user types in the name of a .php file, the server takes this request and parses the file.

Focus instead on following good coding practices, such as not using define() or globals for connection information.
 
Last edited:

fguy64

New Member
Messages
218
Reaction score
0
Points
0
Thanks Garrett, duly noted, especially about define() and globals. will keep that in mind.
 

misson

Community Paragon
Community Support
Messages
2,572
Reaction score
72
Points
48
This question is all about having your script establish a connection to MySQL without any intervention, without having the password visible to others in the source code. It sounds like a question everyone must deal with, I just haven't found explicit mention of the solution yet, till now.

Put the sensitive information in a script with little else (that way, it will rarely be updated). Setting that script to mode 600 to prevent other local users from reading it is, indeed, a good idea.

A greater security risk comes from user input. You should sanitize all user input to prevent (e.g.) SQL injection or cross-site scripting (XSS).

Another potential issue is error messages. In computer security, there's this notion of "information disclosure". You don't want to reveal system internals to users, who can't use the information for anything benign.
 
Top