4

Security Flaws Prevention in JavaScript

 1 year ago
source link: https://blog.bitsrc.io/security-flaws-prevention-in-javascript-98b0c0af52dc
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Security Flaws Prevention in JavaScript

0*DKIepn5KIzcQMe0h.png

Introduction

JavaScript is the most popular programming language for web development. In my opinion, developers must remain defensive in securing their JavaScript applications to keep the web safe. This post will go into common JavaScript vulnerabilities and how to fix them.

DOM updates should not lead to cross-site scripting (XSS) attacks

DOM-based cross-site scripting (XSS) occurs in a web application when its client-side logic reads user-controllable data, such as the URL, and then uses this data in dangerous functions defined by the browser.

Should avoid:

const rootEl = document.getElementById('root');
const queryParams = new URLSearchParams(document.location.search);
const input = queryParams.get("input");

rootEl.innerHTML = input; // Noncompliant

The Element.innerHTML property is used to replace the contents of the root element with user-supplied contents. The innerHTML property does not sanitize its input, thus allowing for code injection.

Do this instead:

const rootEl = document.getElementById('root');
const queryParams = new URLSearchParams(document.location.search);
const input = queryParams.get("input");

rootEl.innerText = input;

The HTMLElement.innerText property does not create DOM elements out of its input, rather treating its input as a string. This makes it a safe alternative to Element.innerHTML depending on the use case.

DOM updates should not lead to open redirect vulnerabilities

Open redirection occurs when an application uses user-controllable data to build URLs used during redirects.

An attacker with malicious intent could manipulate a user to browse into a specially crafted URL, such as https://trusted.example.com/redirect?url=evil.com, to redirect the victim to their evil domain.

Open redirection is most often used to trick users into browsing to a malicious domain that they believe is safe. As such, attackers commonly use open redirect exploits in mass phishing campaigns.

Phishing

Suppose the attacker creates a malicious website that mirrors the interface of the trusted website. In that case, they can use the open redirect vulnerability to lead the user to this malicious site.

Due to the similarity in the application appearance and the supposedly trustable hyperlink, the user fails to identify that they are browsing on a malicious domain. From here, an attacker can capture the user’s credentials, bypass Multi-Factor Authentication (MFA), and take over the user’s account on the trusted website.

Should avoid:

const queryParams = new URLSearchParams(document.location.search);
const redirectUrl = queryParams.get("url");
document.location = redirectUrl; // Noncompliant

Do this instead:

const queryParams = new URLSearchParams(document.location.search);
const redirectUrl = queryParams.get("url");

if (redirectUrl.startsWith("https://www.example.com/")) {
document.location = redirectUrl;
}

Most client-side frameworks, such as Vue.js or React.js, provide built-in redirection methods. Those should be preferred as they often provide additional security mechanisms. However, these built-in methods are usually engineered for internal page redirections. Thus, they might not solve the reader’s use case.

In case the application strictly requires external redirections based on user-controllable data, the following should be done instead:

  1. Validating the authority part of the URL against a statically defined value (see Pitfalls.)
  2. Using an allowlist approach in case the destination URLs are multiple but limited.
  3. Adding a dynamic confirmation dialog, warning about the imminent action and requiring manual authorization to proceed to the actual redirection.

Cookies

XSS Attacks

Like I said above, local storage is vulnerable because it’s easily accessible using JavaScript and an attacker can retrieve your access token. However, while httpOnly cookies are not accessible using JavaScript, this doesn't mean that by using cookies you are safe from XSS attacks involving your access token.

If an attacker can run JavaScript in your application, they can just send an HTTP request to your server which will automatically include your cookies; It’s just less convenient for the attacker because they can’t read the content of the token although they might don’t have to.

CSRF Attacks

Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform.

However, this can be mitigated easily using sameSite flag in your cookie by including an anti-CSRF token.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK