Part 3

See Part 1 (debug, error pages, back-ups, config encryption)

See Part 2 (passwords, sensitive data, updates and patches, basic authentication)

This part concentrates on the user’s privacy, authentication, authorization and validation.

1. Privacy is extremely important for web application, where all the data transfer is public. It is a tall order to make private data actually private. Developers shall always assume that the web is:
   • Unreliable - packets get lost, delayed, received in messed-up order etc.
   • Insecure - packets travel via different countries and potentially are recorded
   • Cacheable - any GET requests are possibly cached by servers and routers,  thus only public data can  be requested via unprotected channel
   • Subject to various attacks (spoofing, denial-of-service, cross-site, man-in-the-middle and many others)
   Therefore private data must be protected via encryption using only standard time-proved algorithms of layered security such as TLS (SSL), SSH, IPsec, Kerberos and others. This includes communication between client, web server, data storage, and any combination of those. Encryption certificate must be issued by a valid authority and have a valid expiry date. Sertificates shall not use compromised hash algorithms (MD5, SHA-1). Access to private keys (if used) must be strictly controlled and audited (fail).
2. Authentication serves the purpose to verify that you are who you claim you are. Communication between client and server must be encrypted to prevent hijacking of user name/password/security token. Encryption must include the loging page, the authentication POST destination, and the landing page. Audit of all login attempts shall be persisted to a safe protected place. Athentication can be delegated to one of the OpenID providers.
3. Authorization is a process of checking if the user, process, context have permissions to perform the requested action. There are various approaches to implement authorization in a web application. Authorization always occurs on the server side and shall operate in a whitelist mode - deny all operations unless allow is explicitly specified. Database users shall have a very limited amount of privileges and must not have privileges to drop a table or database. Never use a system account, such as sa for MS SQL server.
4. Validation for the whole web application shall be central, any income document shall get validated on the server side, e.g. XML schema verified before any processing.  Server side validation is mandatory, whereas client side one is a nice optional feature to have. Failed validation shall be logged and monitored by the system administrator.  HTTP verbs that modify the state (POST, PUT, PATCH, and DELETE) must be treated with additional caution. Here is a validation guidelines.

This post could not have been published without the help of Niall Merrigan

If you enjoyed this post, make sure you subscribe to my RSS feed!