The PAVISE of Security - Privacy

(Page 2 of 8 )

When I speak of privacy I am referring to the idea of keeping server related information private from the client. In other words, nothing that a visitor of your application sees should reveal to them any clues about what is going on in the background with the server. It is the systems administrator's job to secure the server, not yours as the developer. However, it is still important to be aware of what server related information should not be leaked. If somebody takes advantage of an exploit on the server and compromises your website and it turns out that they were able to do so because of information provided to them by your application, then it's just as much your fault as it is anyone else's.

The following examples should give you a better grasp on privacy:

Do Not Have a Publicly Accessible phpinfo() File

The phpinfo() page exposes all types of information, including server configuration, the PHP version, extensions, paths, etc. If you don't think your site is a target for hacking, think again. A simple google search could expose your site's phpinfo() file and put it right at the top of a cracker's list.

Turn Off Error Reporting

PHP's error reporting should only be enabled during development, and not on a production website. These errors can provide paths, clues about the structure of your file system and server, etc. One thing malicious visitors do is insert invalid data into forms to try and intentionally trigger an error, revealing possible vulnerabilities in the logic of your application. It is recommended that you instead define your own error handler which removes sensitive information, see the set_error_handler() function. You could also log your errors to a file or database instead of displaying them.

Keep Private Files and Folders Private

Any file without a .php extension will not be parsed as PHP (unless the engine is instructed otherwise), therefore don't give your include or other files a .inc extension, but rather something like .inc.php. Additionally, files which contain sensitive information such as customer data or a database connection password should never be stored in a public folder where anyone can attempt to access them but rather in a folder below the root directory of your website, in which case the extension makes no difference. Your root directory is the folder where you would typically store your main index.html file, any folder below that is not accessible via the web (unless for some insane reason your server is configured to allow ../../ directory surfing). No matter what the contents of the file may be, you want to do your best to make sure that the code cannot be executed out of context.

File/folder permissions are also important, as are .htaccess files both commonly used to prevent people from snooping where they shouldn't be. Simply giving your files obscure names or putting them in obscure locations in an attempt to prevent users from guessing at them is not good enough, and may make development and maintenance more difficult.

Use Secure Connections

You should always use the HTTPS protocol to transmit sensitive data (be it financial, passwords, etc) in a secure/encrypted manner. Without a secure connection, anyone sniffing packets could intercept and/or possibly modify the data before it reaches its destination. In other words, even if you write a script to pull a record from your own database (where everything is sanitized) just to re-insert it somewhere else, if it is not sent over a secure connection then it still cannot be entirely trusted; make sure you sanitize the data again just to be safe. If the database server is on localhost, then an SSL encrypted connection is not only useless, but overkill and can hurt performance.

Sensitive information really should never be stored in a database to begin with. Passwords should be hashed, never store credit card numbers, etc…

For intranet applications or personal projects you may generate your own self-signed certificates using OpenSSL, but for public commercial sites, although more expensive I would recommend getting a certificate from a third party vendor such as VeriSign or Thawte. Commercial sites really do demand the extra protection of third party verification.

What About Open-Source?

With few exceptions, there is nothing wrong with making the source code of your website publicly accessible, in fact I encourage it. As an open-source developer, I do not actively practice security through obscurity. By obscurity, I am referring to code obfuscation amongst other methods of hiding code with programs such as sourceguardian, better suited in my opinion for prevention of theft. If you're a confident enough programmer, then you know that properly written and well-formatted code although revealing should not impose any real security risks to your website or application; this is the type of code that you should strive to write.

Next: Administration >>
 

More Miscellaneous Articles
More By notepad

Comments On: The PAVISE of Security

· Long awaited and worth the wait.Thanks for the effort. It is well-written,...    · It is important not to trust anything coming from the client and always validate on...   >>> Post your comment now!