Web application security is a never ending game of cat and mouse. As soon as the latest threat is mitigated, a new threat emerges. However, there are some common threats on which everyone from the most experienced hacker to your run-of-the-mill ‘script kiddie’ will focus. TDK Web & Mobile Team Lead, James Dickman, offers suggestions to prevent your web application from falling victim to any of these threats:
Threat: SQLi – SQL Injection. The application constructs SQL queries but allows the query to be changed by attackers.
Countermeasures: Avoid dynamically generated queries. Use vetted libraries and frameworks for database interactions. Escape special characters, quote arguments, and sanitize database inputs in general.
Threat: OS Command Injection. The application constructs OS commands but allows the command to be changed by attackers.
Countermeasures: Use vetted libraries and frameworks. Run your code in a jail. Rely on strict input validation.
Countermeasures: Use vetted libraries and frameworks. Restrict user input which will be outputted to other users by limiting it to only those HTML tags which are required (e.g. do not allow <script> tags).
Threat: Classic Buffer Overflow. The application allows the copying of input buffers which are greater than the size of the output buffer, leading to buffer overflow.
Countermeasures: Use a language like Java which performs its own memory management. Use vetted libraries and frameworks. Always check that the destination buffer is large enough to accommodate the source buffer.
Threat: Path Traversal to Restricted File/Directory. The application uses inputs to construct pathnames for accessing a restricted directory, but allows an attacker to use special elements such as “../” to access unintended files or directories in the restricted area.
Countermeasures: Use vetted libraries and frameworks. Store sensitive files outside of the webroot or otherwise secure them, such that even if someone were to discover the directory path they would be denied access. Rely on canonical pathnames.
Threat: Missing/Incorrect Authentication. The application lacks sufficient authentication for critical functions. If you don’t know who is using a critical function, how can you secure it?
Countermeasures: Identify all communication channels and authenticate all necessary channels. Never rely on client side authentication. Try to keep authentication and authorization tasks separate. Avoid custom authentication routines whenever possible, as they may make authenticating all necessary channels more tedious and difficult. Use vetted libraries and frameworks.
Threat: Missing/Incorrect Authorization. The application lacks sufficient authorization checks for users attempting to access certain resources.
Countermeasures: Use both user and role based access controls. Ensure that ACLs cannot be bypassed by navigating directly to a page or file. Set ACLs to default deny and grant access only to authorized users and roles. Use vetted libraries and frameworks.
Threat: Missing/Incorrect Encryption. Sensitive data being transmitted outside the control of the web application is not encrypted.
Countermeasures: Use vetted encryption algorithms. Determine what data is valuable enough to encrypt and, using threat modeling, identify the weak points and where encryption will be most effective. Understand that you will be sacrificing resources and performance for security. Never assume that you can secure highly sensitive data while cutting resource-intensive steps to increase performance.
Threat: Hard-coded credentials. The web application uses hard-coded credentials.
Countermeasures: Whenever possible, store credentials outside of the webroot and the application code in highly protected areas. Store credentials as hashes to add a layer of protection in the event the configuration files or database end up in the wrong hands. Protect the credentials with strict ACLs.
Threat: Uploading dangerous files. The web application allows attackers to upload dangerous files which may be processed in the production environment or downloaded by other users and processed in their local environment.
Countermeasures: Use a whitelist of acceptable input file types. Rename files to avoid the inadvertent execution of a malicious program. Store user uploaded files outside of the webroot.
You may have noticed some recurring themes in the above countermeasures. Never trust your users or their inputs. Never assume there is only one way to access pages, files or data. Never try to reinvent the wheel: a lot of thought, experience and testing has been put into well vetted frameworks, libraries and encryption algorithms. Use them whenever possible.