Common Web Application Vulnerabilities

Attacker takes over the account of a victim. There could be a variety of entry points, but the result is the attacker now owns the credentials and the victim does not.

Enforce multi factor authentication on all accounts.

Make sure password change page is protected from CSRF and that it requires the old password to validate the user

Require user to enter pwd when changing their email address

Review for XSS and CSRF vulnerabilities that can subvert these functions (for example, CSRF that allows mail forwarding to be set up on a victim’s email account).

Attacker gains access to administrative interface.

Require unique credentials to log in to the interface.

Limit access by source IP.

Put interface into its own subdomain with its own user management.

Enforce multi factor authentication on the Admin account.

This vulnerability covers a lot of ground - basically any way in which an attacker can subvert the authorization logic to gain access to an asset they should not.

Think through an application’s access control requirements and capture it in a web application security policy - use an access control matrix to define the access control rules. 

The policy should document what types of users can access the system, and what functions and content each of these types of users should be allowed to access. 

The access control mechanism should be extensively tested to be sure that there is no way to bypass it. This testing requires a variety of accounts and extensive attempts to access unauthorized content or functions.

Protect by centralizing access control code mechanisms, using standard framework mechanisms when possible, creating simple idioms for developers to follow, and deploying continuous testing to assure that access controls are in place and effective.

Enforce server-side checks, not on the client.

Deny by default.

Log access control failures, alert on repeated failures.

Attacker repeatedly attempts to guess credentials in the hopes of getting one that works. This is generally not a totally random approach, but instead is done by some combination of common passwords and/or side-channel information to reduce the search space. 

Be careful with error messages to not give away when a username is correct.

Limit number of attempts allowed.

Require users to pass CAPTCHA after a number of unsuccessful attempts.

Require strong passwords.

Require multi-factor authentication.

This is possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers, etc.) to a system shell where it may be interpreted as a command.

Avoid invoking system commands from your code.

If not possible use allow-list validation. Only allow certain verified commands to pass to the system. Deny all others.

Use safe APIs.

This is a variation on command injection where an application passes user input to a command line interface.

Same mitigations as above.

Additionally Use system(command, parameters) to separate parameters from the command itself. Hard code the command.

Large numbers of stolen credentials are automatically entered into websites until they are potentially matched to an existing account which the attacker can then hijack for their own purposes.

Multi-Factor Authentication.

Security Questions or Pin.

CAPTCHA.

Request Fingerprinting.

Force less predictable usernames (for example, not email address).

Warn users when passwords are leaked/breached (for example, Apple and Google do this).

Notify users of strange logins.

A type of injection attack in which user input is interpreted as javscript code and executed during website render. 

Persistent - the attack is persisted in the data store to effect other users.

Reflected - the attack is immediately executed in the context of a single user.

DOM - the attack is used in the construction of a dynamic document object model.

XSS source examples: HTTP request parameters, user controlled data in persistent stores, JSON data (stringify blind rendering), cookies

XSS sink examples: HTTP response in HTML, DOM innerHTML.

Encode untrustworthy data, according to context, immediately before echoing back to the page. 

Encode untrustworthy data before use in DOM.

Validate input to only to the necessary character set. Ex. a username should not contain “<,!,%” etc. However be careful as it may need to contain ‘ for names like O’Toole

Use CSP to restrict from where scripts can run

Use HTTPOnly so that cookies cannot be accessed by script

Use inherently safe APIs: wrap injection prone APIs with ones that protect against XSS. Some platforms (for example, React) have this build into the platform.

Coding guidelines: specify which APIs to use and when further review is necessary.

Occurs when a maliciously crafted link is used to issue commands to a web application/service to which the user has already authenticated. 

Use an unguessable token and require that in the request. Token is only known by the application/domain so if link is coming from outside, they will not have it and the request will fail. Keep in mind that XSS can be used to steal the token and create a chained attack.

This is really JavaScript injection, since some browsers allow JS in CSS. Occurs when untrustworthy input is placed blindly into CSS.

Only allow input into a property value and nowhere else.

CSS encode before adding the input to the CSS.

Occurs when Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code when the data is deserialized by the application.

Examples of where deserialization could cause a problem:

Don’t accept untrusted serialized data.

Use digital signatures to check integrity/authenticity.

Enforce type constraints on deserialization.

Happens when attacker-controlled data enters an EL interpreter.

Avoid putting user data into an expression interpreter if possible. Otherwise, validate and/or encode the data to ensure it is not evaluated as expression language. Use framework protections if they exist.

Difficult to protect from, best step is to keep frameworks up to date and continuously monitor.

Occurs when a user can modify file name or path of a file being uploaded. Can be used to replace an important existing file or create a file that will then be deserialized by the application. Or in some cases the uploaded file can contain a payload that is part of an attack chain. 

File download attacks are similar to above but could allow an attacker access to files they shouldn’t have. Mitigation is the same (permissions and file validation).

Use permissions to restrict what directories the web application can write into.

Use a allow-list approach to validate filenames. Or better, generate random file names.

Set maxium file size and terminate upload as soon as the file size is reached.

Synchronous file upload architecture can also be attacked to perform a DoS attack, so perform file uploads asynchronously instead. 

HTTP headers should be untrustworthy data. Header injection occurs when this data is echoed back to the page and could be interpreted as script.

Encode HTTP headers.

Relies upon inconsistency between the interpretation of Content-length and/or Transfer-encoding headers between front-end and back-end servers. This is a growing problem in large-scale cloud-based applications behind load balancers and/or CDNs.

This can be used for malicious redirect for users or to redirect a restful api call.

Variant 1: The front end processes the request using Content-Length header while backend processes the request using Transfer-Encoding header

Variant 2: The front end processes request using Transfer-Encoding header while backend processes the request using Content-Length header

HTTP/2 should be used for backend connections.

Use web servers accepting the same type of HTTP headers.

If your verb-based authentication mechanism doesn’t take into account all HTTP verbs, an attacker may be able to bypass authentication or authorization.

Do not rely on a security control that relies upon HTTP verbs. Just don’t do it.

If you must, then use an allow-list approach rather than a deny-list. For example:

LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it's possible to modify LDAP statements through techniques similar to SQLi.

LDAP injection attacks could result in the granting of permissions to unauthorized queries, and content modification inside the LDAP tree.

Encode all variables using LDAP encoding.

Use a safe framework like LINQ.

Use least privilege and whitelist validation as backup protections.

Developers may log sensitive information that could then be recovered by an attacker to either steal that information or as leverage for additional attacks.

Carefully reviews logs and logging functionality to ensure secrets and sensitive information aren’t logged in cleartext. 

Failure to configure permissions/users on server or cloud service.

Unnecessary features/ports/attack surface.

Overly verbose error massages or logging.

Failure to configure security features/settings.

Failure to use latest most secure/patched versions of components and libraries.

Have a consistent/repeatable hardening process.

Configure test/dev/prod identically.

Remove features/frameworks not used.

Ensure latest patches installed.

Segment network to reduce blast radius.

Use HTTP security headers: Strict-Transport-Security (force HTTPS), Content-Security-Policy (locks down where script can run from).

Similar to SQLi except the query is written in the language of the DB, which could be PHP, Script, Java, etc. 

This can allow SQLi style attacks or even worse, allow code to run on the DB server directly.

Avoid using unsanitized user inputs in application code, especially when building database queries. MongoDB, for example, has built-in features for secure query building without JavaScript. 

If you do need to use JavaScript in queries, follow the usual best practices: validate and encode all user inputs, apply the rule of least privilege, and know your language to avoid using vulnerable constructs.

Occurs when the user has the ability to influence a redirect through the URL. 

Redirection can be used for phishing (redirect to an attack site that looks like the valid site) or for XSS (redirect to script code). 

Do not ever use untrusted input in a generated URL.

Cookie containing session ID can be sniffed on the network.

User fails to log out on a shared-computer and the session doesn’t expire.

Session hijacking occurs when an attacker can steal or predict a session token.

Session fixation can occur when attacker gains a session ID and then forces victim session into using same ID (for example, session token in the URL, in a hidden form field, fix ID in victim’s cookie through XSS). Attacker can now take over the session. Fix is to force new session ID on each login or include user/machine specific information in the cookie that can be validated as well (for example, IP address). Session expiration can also help limit attack window. Expiration should be on the server, not the client.

Cookie replay attacks can occur when important state for business logic is stored in the cookie. Even if user cannot decrypt, they can re-use old-state cookies to influence business logic. Don’t store this kind of state information in cookies.

Expire sessions

Unpredictable sessionIDs

Protect session information (for example, secure cookies). Not in URl.

Strong passwords. 2FA if possible.

Use strong password recovery mechanisms

Strongly hash passwords in DB

SQLi occurs when untrusted input is used in the construction of a SQL query.

It can be used for unauthorized logins as well as for unauthorized access to DB information (e,g, using a Union).

Parameterized queries.

Use and ORM (Object Relational Mapper). Ex. SQLAlchemy for Python.

Allow-list validation can be added as backup but is only partial protection.

Do not rely on stored procedures for protection.

SSRF exploits trust relationships, since the request comes from the vulnerable application/server itself.

Allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing.

Can be used to get unauthorized access to actions or data inside the vulnerable application or from other back-end systems.

Blind SSRF is when the results of the SSRF are not returned to the user. Can be harder to exploit, but still dangerous.

Do not allow user-controlled input to be passed to another server.

If that is not possible, ensure input is properly validated.

Ensure that the data provided is a valid domain name.

Ensure that the domain name provided belongs to one of the domain names of the identified and trusted applications (the allow-listing comes to action here).

Firewall to limit access to only applications/servers it should be able to make calls to (network segregation)

This can occur when untrusted input is interpreted as template syntax and executed server side.

The attack and malicious syntax varies depending upon the template engine.

In many cases, depending on the template engine, this can result in remote code execution on the server.

Do not use template engines/versions with known vulnerabilities.

Use logic-less template engines if possible.

Do not allow users to modify templates.

Do not allow untrusted input to modify templates. Allow-list validation can help, but is not fool-proof.

Opening a new window (HTML link or JavaScript method) with target = _blank passes a back reference to the originating page’s window object through window.opener.

This object reference allows access to window.location across origins.

The result is that the newly opened page can modify window.location on the originating page - for phishing attacks - or it can monitor window.location to spy on the user’s browsing.

Use the following attribute for HTML links: rel="noopener noreferrer"

If using JavaScript window.open, set noopener and noreferrer on the windowFeatures parameter.

There has been a standards change and modern browsers set noopener by default for all target = _blank contexts. This should not be relied upon until we have confidence that our users have migrated to browsers that support this change.

URL parameters can be manipulated by the user to gain access to data or functionality they should not be allowed to access. This occurs when important business logic or security decisions are made, based on the data in a URL parameter. 

Make sure URL parameters are not used to perform sensitive actions. 

For example, do not authenticate a user based on sessionID or userID in a URL parameter.

Don’t return user records based on predictable URL-param lookup.

XXE occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser (allows doctype processing and resolution of external entities).

Allows an attacker to interfere with an application's processing of XML data.

It often allows an attacker to view files on the application server filesystem and interact with any back-end or external systems that the application itself can access. 

May lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, etc.

Disallow the use of XML parsers unless doctype processing is disabled.

Keep frameworks and libraries up to date.