Guidelines for PHP Writable Web Space

In the current web locker model, any space can be writable, but for reasons of security, no space is writable by default. The decision to make a space writable is up to the locker's owner and administrators. To make the space writable, one of these users must make a request to eoshelp@ncsu.edu and specify the locker and path that need to be writable.

The appropriate space to make writable depends on your needs and the precautions you are prepared to take to keep your site safe. Below are guidelines for methods you can use to protect yourself and some potentially dangerous PHP code you can look out for.

Securing information with WRAP

If you want to write sensitive data that should not be found by Internet search engines but should be accessible to some or all users with a Unity ID, you can use NCSU WRAP to protect your data. Files protected by WRAP can still be accessed by users in AFS who have access to read and write in your web locker, regardless of the list of users allowed or denied access via WRAP. WRAP access rules only apply to web access.

Securing information with _data

If you want to write data that is sensitive and should not appear on the web, it should be stored in a folder named _data. All subfolders of _data are also protected. Even users logged into WRAP cannot see information in the _data folder from the web. Files protected by _data can still be accessed by users in AFS who have access to read or write in your web locker.

Protecting your Website by Restricting PHP Script Access

The College of Engineering has PHP configured so that PHP scripts are only allowed to read (and write if enabled) in the folder they are in and its subfolders (sometimes referred to as open_basedir(./)).  You can use this to your advantage to segregate PHP scripts from each other.  As an example, if you want a calendaring application at the root of the site, you could have it named site/calendar.php or put it in a subdirectory (site/calendar/index.php) since both options will work using site/calendar. But by putting it in a subdirectory, the calendar does not have access to read (or write) to any other portions of the site. Any PHP scripts in the main (root) folder of your web locker should be carefully scrutinized with the list of potential dangers below.

Protecting files by obscuring them

A common practice to protect information on the web is to not publish the URL to it. A common misconception is that if a page is not linked into a site, it cannot be found. This is not an acceptable security measure! If information is sensitive, it should be protected by WRAP or in the _data folder.

Implications of write access

It is possible to make an entire web locker writable, but that probably is not desirable. It could be dangerous to give a PHP script the ability to write in the same directory it is run from. If certain types of bugs exist in the program, it would be possible to delete the script or alter it from the web. The same type of bug might also allow other PHP files to be created in file space that is accessible from the web. For this reason, the _data folder is recommended as a place to write. Even with this precaution, the vulnerabilities in include and eval below should be considered.

Bugs in PHP scripts might also allow web users to delete or alter your web content if they are in folders that the web server has write access to. In general, it is recommended that write access be used as little as possible and only in folders that specifically need them. It is the vhost administrator's responsibility to make sure scripts running the root of the site do not pose a danger to other web lockers.

PHP code to watch out for

include - By itself, include is a harmless function. There are two pitfalls to watch out for, however. Do not let the path of an included file confuse you with regard to Open Base Dir rules. Open Base Dir applies to the script that the web user requests, not any files it happens to include. If you include a PHP file in a subdirectory, it has access to everything the main script has access to.

The other precaution that should be taken with include is what you include.

include("afile.html");

include($file);

The first line includes a specific file, afile.html, which is likely the programmer's intention. The second line includes whatever file the variable$file is. With the second line, it is important to consider all possible values for $file. If the value for $file is derived from user input on the web, it should be very carefully scrutinized. Thorough testing is required to make sure $file is always what you expect it to be.

Other functions that should follow these rules include: include_once, require, require_once, readfile

eval - The eval function can be the single most dangerous function allowed on Eos web servers. It is an important function but must be used with extreme caution. Just as with include above, if you eval code from another file, Open Base Dir rules are based on the file requested by the web user. You should also be careful about using eval with a file specified with a variable ($file in the include example above).

eval introduces an additional danger because it executes code, as in the lines below:

eval("print('Hi');");

eval($code);

In the first line, the code that can be executed by eval is hard coded, so it will act as a programmer predicts. The second line can be dangerous unless the programmer is certain of where the value of $code comes from and that it is safe. Evaluating PHP code for safety on the fly is nearly impossible. Instead, care must be taken to make sure no portion of $code is specified directly by user input.

Another function that is not quite as dangerous but should be monitored is call_user_func.

fopen, file, file_get_contents, etc. - Almost all other file functions simply give PHP read and/or write access to a file. PHP does not follow WRAP rules when opening files. WRAP can prevent a web user from accessing a PHP script. However, if access to a PHP is granted to a user, that PHP script has access to everything the web server has access to following Open Base Dir rules. This means that if you want to limit access in your PHP script to a WRAP-authenticated user, you must check the value of $_SERVER["WRAP_USERID"] and keep your own list of allowed users for any given script.

shell, exec, passthru - These functions are not allowed on Eos web servers. The reason they are disabled is that once a process is created outside PHP, Open Base Dir rules are no longer in effect. The socket_ family of functions is also not allowed because once a connection is made to a remote machine, the PHP script may have access to information not intended to be displayed on the web.