Appendix B: Security

Security principles you need to be aware of when making your website "mildly dynamic" with PHP are:

Don't trust user input! (XSS)

Any data that comes from a user, whether you find it in $_GET, $_POST, $_COOKIE, or even e.g. their browser's name and version number ($_SERVER['HTTP_USER_AGENT']) can not be trusted. It can always be tampered with by a malicious user. So:

• If you're sending (e.g. echo) user input back to the user, or to another user, you should escape it first:
  • htmlspecialchars() is the best solution in almost all circumstances if you're outputting to a web page, e.g.:
    Thanks for visiting my site, <?php echo htmlspecialchars( $_GET['name'] ); ?>!
  • If you're outputting into a HTML element, you must also make sure that the element's value is properly wrapped in quotes, e.g.:
    <img src="<?php echo htmlspecialchars( $_POST['profile_pic_url'] ); ?>">. If you miss the quote marks, a user could submit both the image file name and an extra attribute like myfile.gif onload=..., adding their own JavaScript to your site.
  • If you want users to be able to submit HTML code, consider requiring them to use a safer language like Markdown or BBCode and then convert that to HTML for display.
  • If BBCode/Markdown isn't an option, you'll need to sanitize the HTML you're given by users. Note that while strip_tags() can remove non-allowlisted tags, it can't remove attributes or attribute values and so it's still vulnerable to attacks: if you're handling user HTML, consider a library like HTML Purifier.
• If you're expecting user input to be one of a set of values, you should validate it before use. For example:
  • If you're expecting one of a set of values, in_array() is helpful, e.g.:
    if( in_array( $_POST['fave'], [ 'Rumi', 'Mira', 'Zoey' ] ) ) { $fave_demon_hunter = $_POST['fave']; }.
  • If you're expecting a number, something like $age = intval( $_POST['age'] ); will coerce it into an integer (it'll be 0 if they put something completely invalid in).
  • If you're expecting an email address, $email = filter_var( $_POST['email'], FILTER_VALIDATE_EMAIL ); does a good job of checking it looks like a valid email address. It returns false if it's invalid. filter_var() has other helpful filters for checking things like URLs, IP addresses, and more.

Before you change anything, ensure the user intended it (XSRF)

A whole class of attacks are based on the idea that you can trick a user into doing something without meaning to. E.g. if your guestbook takes what comes from the <form> and adds it as an entry, what's to stop my site from embedding a form that submits to your guestbook? (If that's not something you care about, that's fine, but you should ask the question each time: a button that deletes a user's account might be much more-serious!)

The simplest way to prevent this kind of attack is to give the user a random "token" when they visit the form, and then check for the token when they submit it. Because two users get different tokens, an attacker's token can't be used to trick a user into submitting a form. Here's how you might do that:

1. On your form page, create a token and store it in a session variable (so it's available on the next page too), e.g.:
   
2. Put that token into a hidden field on your form, e.g.:
   <input type="hidden" name="token" value="<?php echo $_SESSION['token']; ?>">
3. When the form is submitted, check that the token is present and matches the one you stored in the session, e.g.:
   if( $_POST['token'] !== $_SESSION['token'] ) { die( 'XRSF: Invalid token. Please go back and try again.' ); }

Don't give users the files they ask for without checking first (path traversal)

In an example in lesson 5, we allowed users to choose a fruit file on the server. We kept this safe by only allowing users to choose from a pre-approved list of fruit files, by sending the ID number of the one they wanted and looking it up again by ID number once they did.

Furthermore, we used a simple <img> tag to display the fruit image, so the user can only see files that they would normally be able to, over the Web. We didn't have PHP read the file for them (PHP could potentially have permission to read any file on your server: even the ones not intended to be shared on the Web like your logs).

If we needed to allow users to specify the file name themselves, we'd need to check that the requested file is within the allowed directory. Here's how we might do that:

1. Run realpath() on both the the path the user requested and the path within which they're allowed to request files.
2. Ensure that the start of the requested path matches the entire allowed path.

You can see an example of this in the sanitize_file_path() function used on this site, which rejects any paths that are outside of the application directory of this site. To do this, it first runs realpath() on both the "allowed" path and the "requested" path, which turns them into full and absolute paths without e.g. any ../ sequences. Then it uses strpos() to ensure that the requested path begins with (i.e. is within) the allowed path; if not, it throws a 403 (Forbidden) error.

You found the green potion! Click on it to collect it! (What is this?)

How can cookies be secured?

Lesson 6 demonstrated the use of the setcookie() function to set a cookie, which can then be retrieved on subsequent requests via $_COOKIE. But cookies can be tampered by users, so you don't want to trust them blindly.

(Note that PHP's built-in session cookies (e.g. $_SESSION) are secured by default, so you don't need to worry about them.)

There are two major approaches to securing cookies:

• Keep the data on the server: come up with a long random number and give that to the user in their cookie. Store the data on your server associated with that number. When the user comes back, you can use the number to look up the data you stored. This prevents users from seeing the data or tampering with it, because it's stored on your server. To impersonate somebody else they'd need to guess the long number their victim had been given. (This is the approach used by $_SESSION for session cookies.)
• Sign or encrypt the data: a second approach is to cryptographically protect the data in the cookie. This can either be done with a "signature" (which allows the user to view the contents of their cookie, but be detected if they tamper with it) or fully encrypt it (which prevents them from even seeing its contents). In either case, the signature or encryption must be done using a key that's known only to your server.
• Both approaches are valid. Storing the data on the server is usually preferred because it's less-complex, but if you don't have a way to consistently store data or if your website is spread over multiple servers that don't share a common data store, then you might prefer signing or encrypting cookies.

Making (non-session) cookies tamper-proof goes beyond the scope of this cookery class!