Top 5 Web Attacks and Ways to Handle Them — Part 1

With web attacks pouring in right and left, the topic of web application security is hotter than ever. The web is growing with unprecedented speed, and so does the number of risks and vulnerabilities that accompany it. After all, WWW, otherwise known as the World Wide Web, is, in a way, a wilderness governed by the law of the jungle — threats can be waiting right around the corner so being ready to fight is paramount for survival.

You hear about tech giants suffering from cyber attacks every other day, and in June 2021 LinkedIn was one of them. Reports suggest that because of a powerful cyber attack, the platform witnessed data leakage from as many as 700 million profiles — all of that personal information ended up on a dark web forum.

In this article by Yuriy Myrosh, Head of JavaScript Development at LS, you will get a detailed overview of 5 common types of web attacks and web application security risks as well as the most effective ways to safeguard your projects from them. Forewarned is forearmed, so to say.

Web attacks: general overview

OWASP, which is short for the Open Web Application Security Project, is the largest and the most reliable source focused on web security. It is an online community that features various methodologies, tools, documentation, free articles, and technologies in the field of web application security. According to the latest installment of the OWASP Top 10 2021, there are ten major web application security risks you need to know about: 

• Broken access control
• Cryptographic failures
• Injection
• Insecure design
• Security misconfiguration
• Vulnerable and outdated components
• Identification and authentication failures
• Software and data integrity failures
• Security logging and monitoring failures
• Server-side request forgery

Let’s get more detailed on the first set of five risks from this list and ways to tackle them.

Broken access control

What’s broken access control?

Broken access control is the most common and usually critical type of web attack. It means that a user can access something in a web system they shouldn’t be allowed to access, such as a certain piece of information or a business function. As a result, hackers can exploit this vulnerability to disclose, change, or destroy sensitive data altogether. Here are some of the most typical scenarios illustrating access control vulnerabilities:

• Access is available to any user instead of being granted to specific roles, i.e. violation of the principles of least privilege or deny by default.
• An attacker can view or edit someone’s account because they can see its unique identifier (insecure direct object references).
• Modification of the URL, internal application state, or the HTML page, or use of an attack tool that can modify API requests to bypass access control checks.
• Missing access controls for POST, PUT, and DELETE lead to API being easily accessed.
• Privilege escalation: anyone can act as a user without logging in or as an admin while logged in as a user.
• Metadata, cookie, or hidden field manipulation.
• API access from unauthorized origins through a cross-origin resource sharing (CORS) misconfiguration.
• Accessing authenticated pages as an unauthenticated user or privileged pages as a standard user by means of force browsing.

How to prevent broken access control?

Here are a few basic ways to secure your web system against access failures:

• Stick to the deny by default principle (except for public resources).
• Apply access control mechanisms once and reuse them throughout the application.
• Log broken access control cases, alert admins in the event of repeated failures.
• Make sure file metadata and backup files are not present within web roots by disabling web server directory listing.
• Reduce the harm from automated attack tooling by rate limiting API and controller access.
• Ensure that stateful session identifiers are invalidated on the server after logging out. Minimize the window of opportunity for attackers by making stateless JWT tokens short-lived. For longer-lived JWTs, follow the OAuth standards to revoke access.
• Include functional access control unit and integration testing as part of the regular QA process.

Injection

What’s an injection?

This type of web attack is about an injection flaw, i.e. NoSQL, OS, SQL, and LDAP injection, where a piece of untrusted data makes its way to an interpreter as a constituent part of a query or a command. As a result, the interpreter might get tricked into executing unintended commands or give access to sensitive data with no proper authorization in place.

Considering the fact that there are many types of injection flaws, there are also quite a few explanations as to where they usually come from. Here are some of them to give you a general idea of the problem: 

• Hostile data gets used as a part of ORMs, or object-related mapping search parameters, with the goal of extracting an additional dose of sensitive records.
• Non-parameterized calls or dynamic queries get used right in the interpreter with no context-aware escaping.
• User-supplied data doesn’t get sanitized, filtered, or validated by the application.
• Hostile data is directly concatenated or used in a way that the command or SQL contains hostile data as well as structure in stored procedures, dynamic queries, or commands.

How to prevent an injection?

Here are some actionable tips that will help you forestall various injections: 

• You probably know how the good old adage goes: everybody lies. When looking out for potential web attacks, you can’t assume that all the data coming from users is reliable. This is why validating, filtering, and sanitizing it is of great importance. 
• Use popular ORM systems and never make queries with a concatenation of strings. In JavaScript, the most common and safest options are TypeORM, Bookshelf, Mongoose, Knex. If your application asks for a “special database query” none of these ORMs can provide, consider creating a stored procedure in DBMS and passing validated, filtered, and sanitized parameters to that procedure.
• For any residual dynamic queries, try to avoid special characters by using specific escape syntax for that interpreter.
• Filter the sources of your input data. If you know what clients you should receive queries from, it makes sense to whitelist them and skip queries from all other sources.
• Use the OWASP Injection Prevention Cheat Sheet.

Vulnerable and outdated components

What are vulnerable and outdated components? 

Think about it, users don’t manually insert all the relevant information when using most applications. Instead, they turn to third-party packages and libraries. This means that as a user, you make it easy for a vulnerable component like a framework or a software module to get exploited. What web attackers do in this case is inspect your applications to find some dependencies with well-known exploits and extract the data they seek. 

How do you protect yourself from this risk? 

• Use fewer dependencies. If there is a chance for you to avoid some small dependency — take it. 
• Continuously inspect the versions of client-side and server-side components and their dependencies with tools like versions, DependencyCheck, or retire.js. Constantly monitor sources like CVE and NVD for vulnerabilities. To automate the process, make use of software composition analysis tools. You can also subscribe to email alerts for security vulnerabilities in the components you use.
• Avoid using deprecated dependencies or dependencies that have had no security patches for a long period of time.

Identification and authentication failures

What’s an authentication failure?

The name of this web attack is self-explanatory: it means that there is someone trying to break into an account. In most cases, hackers get there by sifting through the most common combinations of usernames and passwords, brute-force, or using session tokens. Now, what helps these web attacks end in success? 

• Using a list of working usernames and passwords (credential stuffing) to perform a permit-automated attack.
• Going for a brute-force attack or some other type of automated web attack. 
• Targeting accounts with commonly used or weak passwords like “1111” or “password1.” 
• Attacking accounts with ineffective “forgot password” or credential recovery processes. For instance, “knowledge-based answers,” which have been proved to be a questionable and unsafe option.
• Working with weakly hashed passwords or plain text.
• Identifying accounts that have no or weak multi-factor authentication.
• Finding Session IDs exposed in the URL.
• Spotting no session IDs rotation after a successful login.
• Finding accounts where authentication tokens and user sessions don’t get properly invalidated after a period of inactivity or in the process of a logout.

How to prevent identification and authentication failures?

• Use two-factor authentication. From the UX perspective, it is not the best choice, of course, but when it comes to web application security, the difference is palpable. 
• Conduct a weak password validation. Validation for well-known credentials such as admin/admin1 or admin/password will reduce the number of risk cases.
• Limit the number of wrong credentials attempts. This will protect you from credential stuffing. When an attacker gets several failures in a row, your application will deactivate the account for some time and may notify the user that there has been suspicious activity in the account.
• Limit user access and permissions. The user should have access only to the minimum required information.
• Use well-known and safe solutions for session generation. Invalidate expired sessions and add the option of blacklisting suspicious sessions.

An important thing to remember if you are about to work on your web application security is that not all of these options are available in standard libraries — you might have to create them by yourself or even combine a few of these strategies simultaneously. Whatever the case, taking authorization as a given that comes with any project you develop is a mistake, and to avoid it, you need to comb through your security plan several times. Here at Lemberg Solutions, our team holds special discovery workshops where we make a strenuous effort to help our clients understand the importance of rock-hard security protocols and the threats of letting it go with the flow. After all, in this day and age, security is certainly not the area to give minimum attention to.

Security logging and monitoring failures

What are security logging and monitoring failures?

This one is not so much of a web attack but rather a precautionary measure to take in order to prevent potential threats and attacks. When you see some suspicious activity in your account, it is crucial to react right away. With no sufficient monitoring, it’s quite possible that someone is already wreaking havoc on your account, and you don’t even know it. 

How to avoid this risk?

• Enable monitoring of login attempts.
• Enable alarm notifications.
• Create backups to have an option to roll back to a “safe version.”

Web attacks come in different shapes and sizes, and so do the people standing behind them. Whether they are amateurs or a group of trained black hats, one thing is certain: security in custom web development services is not something you can afford to skip. By introducing the key web security features into your system, you can be sure that your users will have a positive experience with your platform and the integrity of your business will not get compromised. To make sure that all security protocols are followed and your systems can take whatever cyber blow comes their way, reach out to our Lemberg Solutions team.