William & Mary IT provides a web hosting platform for any group affiliated with the College, including administrative groups, academic/research groups, and student organizations. The purpose of this guide is to help write an application that will run securely on top of the platform provided by IT.
Because they are limited in scope, but easier to develop on, developing on blogs.wm.edu, Cascade, and Tribe Voices is not covered here.
While this document specifies some conventions used by William & Mary, it can be summarized to say that all code should be developed in a way that it could withstand scrutiny from developers outside of W&M.
- Platform Overview
- Security Model
- Code Style
- Security Best Practices
- Shared Cluster Considerations
- Documenting your Application
- Authenticating Users
IT's general use hosting platform consists of multiple servers behind a load balancer that behaves like a reverse proxy. Application files are stored on a highly available shared filesystem that is mounted on each server via NFS.
A MySQL compatible database is available by request. The database is replicated across multiple servers. The connection endpoint may be a server or a load balancer.
Because servers are behind a load balancer, developers are reminded that HTTP is a stateless protocol. Assumptions that work on a single server must not be made when writing code for a load balanced environment.
IT's web hosting operates under a shared responsibility security model. IT will provide a platform that's designed with security in mind. The application/site owner is responsible for developing and maintaining the code to ensure the site is secure.
IT reserves the right to remove sites without notice that are compromised or threaten the stability and security of the platform.
A style guide should be followed whenever possible to make it as easy as possible for experienced developers to make sense of code that is new to them. Style refers to the layout of code, including variable, class, method naming conventions, and sometimes how some operations are handled.
If a specific framework is used, and specifies how theming, database queries, or code layout should be used, then it should be followed. For example, writing database queries by hand should be avoided in Laravel (or any framework that supplies ORM) whenever possible, and database queries shouldn't show up in the view on any MVC.
Unless a framework used has its own style guide (e.g. WordPress), standards set by the PHP Framework Interoperability Group should be used. Specifically PSR-1 and PSR-2.
Unless a framework being used has its own style guide, PEP8 should be followed. Rules that are purposely excluded should be noted somewhere obvious.
Unless a framework being used has its own style guide, the community maintained Ruby style guide should be used.
Unless a framework being used has its own style guide, the community maintained None.js Style Guide should be used.
Widely accepted best practices must be followed to prevent common web application attacks (e.g. injection attacks, cross-site scripting, data disclosure, etc.). The exact method used will vary based on the framework and language being used in your application.
While not exhaustive, the SANS Institute has published a paper titled "A Security Checklist for Web Application Design" that addresses many issues.
A number of functions are disabled on our PHP servers to protect against accidental information disclosure and avoid common security issues. They're grouped by family below.
- pcntl_*
- exec
- shell_exec
- phpinfo
- eval
- system
- passthru
- apache_child_terminate
- apache_setenv
- symlink
- chgrp
- chown
- posix_uname
- proc_close, proc_nice, proc_terminate, proc_open
User input must be properly sanitized before passing it to a database or shell. That a form or handler is behind authentication does not mean that unsanitized input may be used (See here).
If a framework has its own method for escaping input then it should be used before a custom solution is implemented.
Because there are multiple servers behind a load balancer, some common single-server assumptions cannot be made in the W&M environment. The load balancer acts as a reverse proxy, SSL is not used behind the load balancer, and files are mounted off of a highly available NAS.
Every HTTP(s) request connects to a load balancer that then makes another request to a healthy server in the cluster. A developer must not assume that a series of requests will talk to the same server in the cluster.
The load balancer will set X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port headers that indicate the IP address, protocol, and port used to connect to the load balancer.
To help keep compatibility with PHP applications that check $_SERVER['https'], the
environment variable HTTPS will be set to on if X-Forwarded-Proto is set to https.
One directory level up from the document root is shared across all servers and is available
for libraries and other persistent storage. The system temporary
directory is not, but a different temporary location is available when needed. On PHP systems
the directory returned by sys_get_temp_dir() is shared across all servers. For non-PHP
applications, contact IT to find out what to use.
As recommended in the Apache documentation, .htaccess files are ignored. IT can add any required configuration to the Apache configuration.
Even though the web server will ignore these, it's recommended that they be included with your application as a form of documentation for yourself and future developers.
Extra libraries should be installed within the document root or one level up.
On Python systems virtualenv should be used.
Projects should be documented in a way that someone intermediately familiar with the framework and language is able to fix bugs, make functional changes, and take ownership if needed.
Projects should support a widely used and language-relevant (i.e. PHPDoc shouldn't be used with Ruby) documentation tool such as PHPDoc, Sphinx, or RDoc whenever the project is sufficiently complex.
Single sign on (SSO) should be used to authenticate users. Central Authentication Service (CAS) and Shibboleth/SAML are both available as identity providers. CAS is the preferred method, and typically is the easiest to setup. SAML may not be made available in all cases.
There are a number of CAS libraries available for each supported language. There are add-ons to many popular frameworks that add CAS support to the built in authentication/authorization mechanisms.
A web search will help you identify which one is right for your use case.
IT is available for questions and consulting around web application development, and prefers to be involved early if there is any question.