[PHP Series] Minimising Exposure and Minimalist Privileges

[Byte-ul]

Minimising Exposure

Exposure of data that need not be seen (especially sensitive data) can come in many forms. When building your Web applications, it is important to be conscious (if not, then outright paranoid) of these potential exposure points and to ensure that you're properly preventing them from leaking such data.

HTTP GET Method Exposure

• The HTTP GET method passes data via the query string of a URI. The openness of this makes it unsuitable for passing sensitive information, such as using it for login forms where passwords are involved. This type of exposure threat may seem insignificant, but given that your web browser most probably logs your history, you password will be kept in plain text there until you decide to clear your browsing history. Given how easy it is to avoid this (by simply using the right HTTP method - POST in this case), it's something you should definitely be aware of when requesting sensitive data from your users.

Cookie Exposure

• Exposure of data in cookies is usually done through either browser vulnerabilities (very rare) or through cross-site scripting attacks (XSS) (much more common). Given how common XSS attacks are on the Internet today, it is important that you ensure the cookies you're creating for your users cannot be accessed by client-side languages (namely JavaScript). The

setcookie() function has a seventh parameter of being able to specify whether the cookie can only be accessed via the HTTP protocol - this should always be set to true unless you specifically need to access your users' cookies through JavaScript (which is unlikely). This still leaves the potential problem of browser vulnerabilities, and so you should still avoid storing sensitive data (like a user's password) inside of their cookie. There's still the unavoidable storage of the session identifier, which can lead to session hijacking if a user's cookie is compromised, but that's a far lower risk with the impediment of client-side access to cookies.

Session Exposure

• Sessions are stored on the server-side (by default in the file system, though that can be easily overridden for database storage). This means that we don't have to typically worry about the exposure of their contents - but that doesn't mean you can simply ignore it completely. You can minimise exposure of session data as it is sent to and from the client and server through enabling SSL, protecting HTTP requests and responses. You can also

store your sessions in a database and encrypt that database for additional security (though that is perhaps getting a little too paranoid).

Database Credentiasl

• In order to access to your database, you must store the database credentials somewhere in your file system. This is particularly worrying because of the plaintext, out-in-the-open nature of these sensitive details. There are a couple ways to minimise this type of exposure, depending upon the authority you have over your environment at hand.
  If you only have a public document root (common on shared hosting environments), then setting up some

Apache directives to block HTTP access to such files is a good start. If you are allowed to place content outside of the web root, then moving your configuration (or in general, any included) files outside of direct URI access would be a good step to take. Both of these methods, however, are still vulnerable to Local File Inclusion.
This is where using Apache's environment variables comes in. We can use the SetEnv Apache directive to setup variables to hold our database's access credentials (the username and password), and then access these variables through PHP's superglobal array, $_SERVER. (For more information about this, look on the official Apache website.)
(I wrote the above with the assumption that an Apache web server is being used. I don't, unfortunately, have enough knowledge on other web server setups (like ones using Nginx) to be able to write about them too. If anyone would like to contribute a paragraph with respect to the above that covers a different server environment, then let me know and I'll update this post and give credits where they're due.)

Application Errors

• Outputting application errors to userland both degrades user experience and gives out unnecessary information about your website. These can (and most probably will) be used against you by web application exploiters when they're pen-testing parts of your website for breakages. It is therefore important that you log all errors in a production environment, and ensure that you fix all warnings and errors in your development environment (by ensuring that you have the highest level of error reporting turned on when building your web application).

Minimalist Privileges

You should always give out the minimum required privileges to perform actions you are looking to carry out. This is something that is often overlooked by web developers, which makes it all the more important to stay aware of. If you don't require a file to have read, write, and execute permissions for all three groups (owner, group, and world) then don't give the file those permissions.

It's a lazy habit, just like giving a database user full privileges to access your database. If those details are compromised, then anything can be done to your database. Many applications commonly only require INSERT, UPDATE (with the WHERE clause specified), and SELECT statements (things aren't usually DELETEd from your database via an application request, and we rarely use DDL statements either). As such, the user account accessing your database should only be given these (minimal) privileges.

Credits: http://www.hackforums.net/showthread.php?tid=4238146

Edited August 9, 2014 by Byte-ul