Most Common Web Application Threats

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 offers suggestions to prevent your web application from falling victim to any of these threats.

SQLi – SQL Injection

The application constructs SQL queries but allows the query to be changed by attackers.  

  • Avoid dynamically generated queries. Use vetted libraries and frameworks for database interactions. Escape special characters, quote arguments, and sanitize database inputs in general.  Do not rely on client-side input validation.

OS Command Injection  

The application constructs OS commands but allows the command to be changed by attackers by passing user input directly to the OS command. 

  • Use vetted libraries and frameworks. Run your code in a jail. Perform strict validation on all input values.  Do not rely on client-side input validation.

XSS – Cross-Site Scripting 

The application allows attackers to inject JavaScript or other executable code into output which is served to other users. 

  • 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>, <iframe> tags). 

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.  

  • 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. 

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.  

  • Use vetted libraries and frameworks. Store sensitive files outside of the web root or otherwise secure them, such that even if someone were to discover the directory path, they would be denied access. Rely on canonical pathnames. 

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? 

  • 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. 

Missing/Incorrect Authorization 

The application lacks sufficient authorization checks for users attempting to access certain resources.  

  • 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. 

Missing/Incorrect Encryption 

Sensitive data being transmitted outside the control of the web application is not encrypted.  

  • 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 extremely sensitive data while cutting resource-intensive steps to increase performance. 

Hard-coded credentials 

The web application uses hard-coded credentials. 

  • Store credentials outside of the web root and the application code in highly protected areas. If possible, do not store credentials in the file system at all, but use tools provided by the runtime environment or use tools that store credentials in a separate part of the network and only retrieve them when needed.  If you must store credentials in the file system, store them as hashes to add a layer of protection in the event the configuration files or database end up in the wrong hands. Protect stored credentials with strict ACLs. 
  • Never store credentials in your source code.

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.  

  • Use a whitelist of acceptable input file types. Do not store uploaded files using the name provided by the user, but rename files to avoid the inadvertent execution of a malicious program. Store user uploaded files outside of the web root. 

To Recap 

You may have noticed some recurring themes in the above countermeasures to web application threats.  

  • 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. 

Want to see what TDK can do for you?

Let's Talk