4 ways to improve your web app’s security

Web applications are now an essential part of business and daily life, enabling businesses and individuals to accomplish more with fewer resources and achieve goals much faster.

Because we use web applications for so many things and transfer sensitive information through many different types of online channels, we should be obligated to take a strong stance on protecting and securing that information.

Attackers use lists of known issues and easy wins, which apply to almost every web application.

Knowing and fixing these issues during the development stage should prevent these attacks from compromising your code and your client’s personal information.

In this post, I’ll go over 4 easy wins for attackers and how we can avoid them.

1. Tampering with object value

Explanation

An attacker will always try to find a way to track down unique object keys that are already in use and will attempt to create objects that already exist in order to rewrite the data.

A direct object reference exposes an internal object to the user, such as a file or database key. The problem is that the attacker can provide this reference, and if authorization is not enforced (or broken), the attacker can access or take advantage to perform actions he is not supposed to do.

For example, the code includes a download.php module that reads and allows the user to download files by specifying the file name with a CGI parameter (e.g., download.php?file=something.txt). If the developer left authorization out of the code, the attacker can use this to download any system files that the user running PHP has access to, such as the application code itself or other data left on the server, even backups.

How to prevent?

Perform proper and consistent user authorization, and create an allowlist. However, most of the time, the entire problem can be avoided by storing data internally rather than relying on it being passed from the client via CGI parameters.

2. Business logic

Explanation

Most applications implement business logic through defined rules, constraints, and user workflows to manage communication between an end-user interface and a database.

In the business logic flaw, an attacker can track the request/response. The attacker can manipulate a currency-related parameter in the HTTP header of a POST request. As a result, the attacker can exploit this logic flaw for his own purposes such as reducing the price of a product on an online shopping website.

How to prevent?

• Avoid making implicit assumptions about user or application behavior
• Ensure that the value of any input is reasonable before proceeding
• Ensure that both developers and testers fully understand these assumptions and how the application is supposed to behave in various scenarios
• Business logic should always be enforced on the backend. Never rely on the frontend to enforce business logic
• Note any references to other code that uses each component. Think about any side-effects of these dependencies if a malicious party were to manipulate them in an unusual way

3. SSRF on Webhook

Explanation

Webhooks are “user-defined HTTP callbacks”.

They are typically triggered by an event, and when that event occurs, the source site sends an HTTP request to the webhook’s configured URL.

Users can set them up so that events on one site trigger behavior on another.

Server-side request forgery (SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing.

From the attacker's point of view, webhooks are tools to try and deliver an SSRF attack.

How to prevent?

Always make sure to test the webhook URLs services permissions and if possible, isolate the webhook machines from the rest of your servers.

4. Dom XSS

Explanation

This type of attack was previously known as “self XSS” or “0 XSS,” and it occurs entirely on the client side, affecting only the browser and not the server.

This was not considered a real issue until a few years ago, but as browsers progress and begin to do more than just display websites (keeping passwords, managing accounts, etc), this has become a real issue.

DOM-based XSS vulnerabilities usually arise when JavaScript takes data from an attacker-controllable source, such as the URL, and passes it to a sink that supports dynamic code execution, such as eval() or innerHTML.

To deliver a DOM-based XSS attack, you need to place data into a source so that it is propagated to a sink and causes the execution of arbitrary JavaScript.

The most common source for DOM XSS is the URL, which is typically accessed with the window.location object. An attacker can construct a link to send a victim to a vulnerable page with a payload in the query string and fragment portions of the URL.

How to prevent?

Protecting against DOM-based XSS attacks is a matter of checking that your JavaScript does not interpret URI fragments in an unsafe manner:

• Use a JavaScript Framework — Frameworks like Angular use templates that make the construction of ad-hoc HTML an explicit (and rare) action
• Do not evaluate JSON to convert it to native JavaScript objects — for example, by using the eval(…) function. Instead, use JSON.parse(…)
• Set text content within tags wherever possible and avoid using innerHTML, outerHTML, and document.write
• Don’t use URI fragments at all
• Implement a content security policy (CSP)

The web security landscape is constantly changing, and so should your strategy for navigating it

I hope this post has raised your interest and introduced you to website security vulnerability awareness.

One more piece of advice — try to think like a hacker and perform penetration testing on your code. This will allow you to test and audit your web application in real-world scenarios. Security protocols assist you in writing correct programs, which is something that all programmers should strive for.

For more information and more known web-app attack, have a look at OWASP top 10.