1<?php 2$_SERVER['BASE_PAGE'] = 'security-note.php'; 3include_once __DIR__ . '/include/prepend.inc'; 4site_header("A Note on Security in PHP", ["current" => "docs"]); 5?> 6 7<h1>A Note on Security in PHP</h1> 8 9<p> 10 PHP is a powerful and flexible tool. This power and flexibility comes 11 from PHP being a very thin framework sitting on top of dozens of distinct 12 3rd-party libraries. Each of these libraries have their own unique input 13 data characteristics. Data that may be safe to pass to one library may 14 not be safe to pass to another. 15</p> 16<p> 17 Long ago, a Web Worm known as NeverEverSanity exposed a mistake in the input 18 validation in the popular phpBB message board application. Their 19 highlighting code didn't account for double-urlencoded input correctly. 20 Without proper input validation of untrusted user data combined with any 21 of the PHP calls that can execute code or write to the filesystem you 22 create a potential security problem. Despite some confusion regarding the 23 timing of some unrelated PHP security fixes and the NeverEverSanity worm, 24 the worm didn't actually have anything to do with a security problem in 25 PHP. 26</p> 27 28<p> 29 When we talk about security in a web application we really have two 30 classes. Remote and Local. Every remote exploit can be avoided with very 31 careful input validation. If you are writing an application that asks for 32 a user's name and age, check and make sure you are only getting characters 33 you would expect. Also make sure you are not getting too much data that 34 might overflow your backend data storage or whatever manipulation 35 functions you may be passing this data to. A variation of the remote 36 exploit is the XSS or cross-site scripting problem where one user enters 37 some javascript that the next user then views. 38</p> 39<p> 40 For Local exploits we mostly hear about open_basedir problems 41 on shared virtual hosts. This feature is there as a convenience to 42 system administrators and should in no way be thought of as a complete 43 security framework. With all the 3rd-party libraries you can hook into 44 PHP and all the creative ways you can trick these libraries into accessing 45 files, it is impossible to guarantee security with this directive. The 46 Oracle and Curl extensions both have ways to go through the library and 47 read a local file, for example. Short of modifying these 3rd-party 48 libraries, which would be difficult for the closed-source Oracle library, 49 there really isn't much PHP can do about this. 50</p> 51<p> 52 When you have PHP by itself with only a small set of extensions 53 open_basedir is generally enough to frustrate the average bad guy, 54 but for critical security situations you should be using OS-level security 55 by running multiple web servers each as their own user id and ideally in 56 separate jailed/chroot'ed filesystems. Better yet, use completely 57 separate physical servers. If you share a server with someone you don't 58 trust you need to realize that you will never achieve airtight security. 59</p> 60 61<?php site_footer(); ?> 62
