OWASP Top 10

Injection attacks are when malicious code is fed into the user interface to try and trick the interpreter into carrying out unintentional commands like accessing data without permission.

The most commonly seen attack of this type is SQL injection.

If an attacker enters the SQL expression of “KATE or 1=1 --” into the name field of a login form instead of just “KATE,” then the query will just return TRUE because of the “or 1 = 1”. The -- will truncate the original query, removing anything after it.

By doing so, the attacker could be successful in accessing sensitive data like passwords or payment details.

Injection attacks are also capable of executing OS commands, allowing an attacker to introduce new code into a system, a tactic sometimes used to obtain unauthorized admin access.

Here are a few things you can do to protect your code:

First, it’s important to validate user input for any attempt to inject code. Check for the accepted type, length, format, and so on.

Second, use Parametrized queries. This allows the database to distinguish between code and what the user input.

Or even better, use stored procedures. This is similar to Parametrized queries. They are queries that were precompiled by the database.

And lastly, avoid using administrative privileges to run queries.

Broken authentication happens when session management isn’t properly implemented. It allows an attacker to carry out credential stuffing, brute force access, and session hijacking against your web app. In the case of credential stuffing, automated tools can be used to test a list of stolen usernames and passwords in an attempt to compromise legitimate accounts. Compromises like this can open the door for fraud, money laundering, identity theft, and the loss of highly sensitive information.

There are several steps to preventing broken authentication. Multi-factor authentication can stop automated attacks such as credential stuffing and brute force attacks. Also, prevent users from using weak passwords and add rules to check password length, complexity, and how often they need to be changed. Finally, session management should be used to ensure sessionIDs are invalidated after logout or idle and a new random sessionID is generated at login and is not passed in the URL.

Sensitive data exposure is when an application doesn’t protect certain types of information from being leaked.

Sensitive information can be session tokens, passwords, banking information, health data, or really any data that could cause harm if it is exposed or leaks out.

As an example, as a developer, you may decide to use the default database encryption to encrypt credit cards, however the database automatically decrypted this data when it was retrieved. This means that if the attacker successfully uses SQL injection to retrieve credit card numbers, they will be in clear text.

To prevent this, start with identifying which data is sensitive and ensure you encrypt it at rest by using up to date encryption algorithms and proper key management. As for data in transit, secure it with protocols like TLS.

Also, avoid storing sensitive data if you don’t need it, including data in memory, or other caches within your environments, and remove it safely as soon as possible when you are done with it.

And lastly, never store passwords in clear text. Instead, use strong adaptive and salted hashing functions to prevent them from being stolen by an attacker.

XXE is an application attack that allows an attacker to inject a harmful XML that contains an external reference to entities outside of the trusted domain where the application resides.

XXE attacks can be used to retrieve a file, exfiltrate sensitive data, or perform an SSRF attack that will grant the attacker access to local machines behind the network firewall.

For example, the attacker can inject a command that will instruct the XML parser to expand the final XML with the content of the file located on the server at /etc/passwd.

Here are a few tips for preventing this type of attack:

The safest and most effective way is to just disable XML external entity and DTD processing in all XML parsers. If it cannot be completely disabled, then external entities must be disabled in such a way that the doctypes are specific to each individual parser.

Also, whenever possible, use formats such as JSON and avoid serialization of sensitive data.

Insure you patched and upgraded all XML processors and libraries.

And as always, validate all user inputs to prevent bad data within XML documents, headers, or nodes.

Lastly, validate incoming XML using XSD validation or something similar.

Access control or sometimes referred to as authorization control, is the process of granting or denying access to a specific resource or functionality.

Attackers will try to exploit the access control in order to gain administrative access or run as a user with privileges to execute functions that can create, access, update, or even delete records.

Here is an example. An attacker changes the value of a parameter in the URL, like the account number, to another account number in order to get access to a another user’s accounts.

That is why access control is most effective when enforced on the server-side code or server-less API, so that the attacker cannot simply modify the access control check or metadata.

Also, make it a habit to deny access to functionality by default and limit who has access to it instead of just ‘hiding’ functions.

And be sure to use access control lists and role-based authentication mechanisms.

Lastly, invalidate tokens, session variables, and other cached data on the server after logout.

Security misconfiguration occurs when the server or web application is not configured to optimize security.

Many application security architectures do not follow security be default and it’s the programmers who must apply security measures to avoid access to private or confidential resources.

Typical flaws include having debugging enabled, using incorrect folder permissions, not changing default passwords, or failing to disable setup or configuration pages.

An example of a security misconfiguration is automatically installing the app server admin console and not removing it. If an attacker were to discover the standard admin pages were still on your server and they logged in using the default passwords, they would be able to take control.

Here are some ways to prevent security misconfigurations from occurring. Approach with a principle of least privilege, everything off by default.
Disable all administration interfaces, debugging, and use of default accounts and passwords.

Also, consider running scans periodically to help detect future misconfigurations and missing patches.

Cross-site scripting attacks or XSS is probably one of the most common web security vulnerabilities. It’s when a malicious script is injected into your web app. The attacker will use a vulnerability in your app to send “bad" Javascript or HTML to other users.

So how do they do it? They can change a value of a parameter in the url to inject a malicious script that will steal the users cookie, change a link to point to a malicious file, and so on. Then, they will use social engineering to get users to click on it. When clicked, the attacker could use the stolen cookie to login as the user. Another method is when an attacker posts a malicious script that will be saved in your database.

Let’s say they entered Javascript as a comment on a post. If you didn't validate user input, this malicious code will be saved in the database. Next time the comment is displayed to anyone, the malicious code will be executed on the user's computer.

In order to prevent this, always validate user input for any tags such as “Javascript,” “iframe,”or “source” as soon as possible to make sure it’s the type of data you expected. And always encode any output data that will be rendered by the browser to prevent this data from being executed. Also, if your web response doesn’t contain HTML or Javascript then specify this by using specific content-type in the header in order to instruct the browser not to execute any code.

Insecure Deserialization is when the attacker sends hostile serialized objects to an application. The application then deserializes it and remotely executes malicious code or bypass authentication. If the function that is responsible for converting serial data into an object assumes that the data is safe, an attacker may inject malicious data.

Here is an example. Let’s say an App uses PHP object serialization to save user info like the user ID, password, and role into a cookie. The attacker then may gain administrative access by changing the “role" attribute in the serialized object from “user” to “admin.”

The best method to prevent this attack is to not accept serialized objects from untrusted sources.

If this is not possible, then use digital signatures on serialized objects to prevent someone from tampering with the object and check the signature before beginning the deserialization process. Otherwise, it may be too late. Also, run the deserialized code within a low privilege environment. Lastly, monitor deserialization by logging any code errors or exceptions and alert if a user is constantly deserializing.

You’d expect zero-day vulnerabilities to be the biggest threat your app would face, however, it’s far more likely an attacker would exploit well-known vulnerabilities within APIs, microservices, libraries, open-source, and legacy code that may have existed for months, or even years. Now, those components typically run with the same privileges as your application. So, if any of these components have vulnerabilities and you haven’t patched them, then an attacker can initiate an attack through these third-party components.

That is why having a patch management process is really important. You want to remove any unused dependencies or unnecessary features, files, etc. There are sources like CVE and NVD where you can find known vulnerabilities in the components.

Also, have an updated inventory of your client and server-side components and their dependencies including their version. There are automation tools that can help you with this process.

And only use components from official sources and make sure they are digitally signed. This will help reduce the likelihood that someone tampered with them.

An attacker’s goal isn’t just to get in. They also need time to carry out their attack. They rely on a lack of monitoring and logging to go undetected, sometimes even for years. The longer they stay, the more damage they can do. Now, most successful attacks start with vulnerability probing, so your apps must have sufficient security logging and monitoring to detect these before a vulnerability is discovered.

For example, an attacker may scan for users using a common password in an attempt to take over any accounts using that password. For all other users, the scan leaves only one failed login behind and after a few days, this process can be repeated using a different password and not draw any suspicion. Without the correct logging and alerting in place, this type of attack could go unnoticed and be allowed to continue.

That is why it’s essential for your application’s security to be able to detect, escalate, and alert almost in real-time. So, ensure all login attempts, access control failures, and server-side input validation failures are logged with the ability to identify the suspicious or malicious accounts. And use a format that is easy to understand and can be consumed by your centralized log management solution. Also, make sure to secure the logs with integrity controls to prevent any tampering or deletion.

Finally, establish an incident response and recovery plan, such as NIST.