| Derick Rethans 2004-12-31, 3:55 pm |
| derick Fri Dec 31 08:37:29 2004 EDT
Modified files:
/phpweb index.php
Log:
- Add security statement
http://cvs.php.net/diff.php/phpweb/...5&r2=1.656&ty=u
Index: phpweb/index.php
diff -u phpweb/index.php:1.655 phpweb/index.php:1.656
--- phpweb/index.php:1.655 Tue Dec 28 17:20:35 2004
+++ phpweb/index.php Fri Dec 31 08:37:28 2004
@@ -145,6 +145,62 @@
// DO NOT REMOVE THIS COMMENT (the RSS parser is dependant on it)
?>
+<h1>A Note on Security in PHP</h1>
+
+<p>
+ <span class="newsdate">[31-Dec-2004]</span>
+ 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>
+ A recent 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 or safemode problems
+ on shared virtual hosts. These two features are 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 these directives. 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 safemode
+ and open_basedir are 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>
+
+<hr />
+
<h1>Function list suggestions available</h1>
<p>
<span class="newsdate">[27-Dec-2004]</span>
|