mirror of
https://github.com/php/web-php.git
synced 2026-03-23 23:02:13 +01:00
62 lines
2.9 KiB
PHP
62 lines
2.9 KiB
PHP
<?php
|
|
$_SERVER['BASE_PAGE'] = 'security-note.php';
|
|
include_once __DIR__ . '/include/prepend.inc';
|
|
site_header("A Note on Security in PHP", ["current" => "docs"]);
|
|
?>
|
|
|
|
<h1>A Note on Security in PHP</h1>
|
|
|
|
<p>
|
|
PHP is a powerful and flexible tool. This power and flexibility comes
|
|
from PHP being a very thin framework sitting on top of dozens of distinct
|
|
3rd-party libraries. Each of these libraries have their own unique input
|
|
data characteristics. Data that may be safe to pass to one library may
|
|
not be safe to pass to another.
|
|
</p>
|
|
<p>
|
|
Long ago, a Web Worm known as NeverEverSanity exposed a mistake in the input
|
|
validation in the popular phpBB message board application. Their
|
|
highlighting code didn't account for double-urlencoded input correctly.
|
|
Without proper input validation of untrusted user data combined with any
|
|
of the PHP calls that can execute code or write to the filesystem you
|
|
create a potential security problem. Despite some confusion regarding the
|
|
timing of some unrelated PHP security fixes and the NeverEverSanity worm,
|
|
the worm didn't actually have anything to do with a security problem in
|
|
PHP.
|
|
</p>
|
|
|
|
<p>
|
|
When we talk about security in a web application we really have two
|
|
classes. Remote and Local. Every remote exploit can be avoided with very
|
|
careful input validation. If you are writing an application that asks for
|
|
a user's name and age, check and make sure you are only getting characters
|
|
you would expect. Also make sure you are not getting too much data that
|
|
might overflow your backend data storage or whatever manipulation
|
|
functions you may be passing this data to. A variation of the remote
|
|
exploit is the XSS or cross-site scripting problem where one user enters
|
|
some javascript that the next user then views.
|
|
</p>
|
|
<p>
|
|
For Local exploits we mostly hear about open_basedir problems
|
|
on shared virtual hosts. This feature is there as a convenience to
|
|
system administrators and should in no way be thought of as a complete
|
|
security framework. With all the 3rd-party libraries you can hook into
|
|
PHP and all the creative ways you can trick these libraries into accessing
|
|
files, it is impossible to guarantee security with this directive. The
|
|
Oracle and Curl extensions both have ways to go through the library and
|
|
read a local file, for example. Short of modifying these 3rd-party
|
|
libraries, which would be difficult for the closed-source Oracle library,
|
|
there really isn't much PHP can do about this.
|
|
</p>
|
|
<p>
|
|
When you have PHP by itself with only a small set of extensions
|
|
open_basedir is generally enough to frustrate the average bad guy,
|
|
but for critical security situations you should be using OS-level security
|
|
by running multiple web servers each as their own user id and ideally in
|
|
separate jailed/chroot'ed filesystems. Better yet, use completely
|
|
separate physical servers. If you share a server with someone you don't
|
|
trust you need to realize that you will never achieve airtight security.
|
|
</p>
|
|
|
|
<?php site_footer(); ?>
|