What every web app developer must know about security
For developers around the world the top ten security risks and guidelines for preventing them published by OWSAP are a gold standard. Despite having these guidelines, developers tend to overlook these while implementing. Drawing from my experience at WalmartLabs working on writing and reviewing security related software I am presenting five such areas where mistakes happen and how they should be avoided.
Securing cookies
Most web-apps make use of cookies to store various kinds of information about the user session such as user preferences, last visited pages, shopping cart, authentication tokens etc. Developers often forget to set the secure and http flags on these cookies. These flags are not true by default but must be explicitly set to true to ensure that the information is only going out via encrypted messages (https) and cannot be accessed via client-side scripts thus preventing cross-site scripting attacks.
Securing application/configuration secrets
Secrets in applications include admin passwords, long-lived tokens, API keys and private keys. Storing secrets in initialisation files, in the source code or in a configuration service must be avoided. Instead developers should use enterprise-grade secret management solutions such as KeyWhiz, Vault, Knox, Confidant etc. Secrets might even leak through log files and they should either not be written to log at all or masked where required.
Preventing account spoofing and take-over
Users perform operations using their authentication token which they obtain upon login. Applications should always extract the userId from the token and compare it with the userId of the account being operated upon. This ensures that you cannot use user A’s token — though valid — to perform operations on user B’s account.
Standardising input validation and database queries
Attacks such as SQL-injection and buffer overflow can easily be prevented if both size and content of user input is validated properly. Validating against a whitelist(allowed characters) is preferable to validating against a blacklist(disallowed characters). I have seen developers invariably re-inventing these and missing out many corner cases. Hence, I recommend using a standard validation library such as ESAPI or Apache commons validator. For SQL, it is preferable to use parameterised statements and stored procedures instead of using dynamically generated queries. Parameterised statements safely treat all user-supplied input as the literal representation of those strings instead of treating them as part of a SQL query thus preventing injection attacks.
Using individual identities for better auditing
It is a common practice amongst teams managing sensitive data to share one admin account with all team members. All of them know the password and can use the credentials to update sensitive data. This is against many enterprise grade security practices. Instead of using such generic accounts, it is recommended to map member’s real and individual identity to proper admin roles/permissions. This ensures proper auditing of changes.
Hope you enjoyed reading this article and also gained some useful security insights. If yes, remember to hit the clap button :-)
