A supply chain attack targets vulnerabilities upstream to launch an attack, as contaminating upstream will also contaminate downstream.
Taking front-end as an example, do you realize the risks associated with using npm packages or third-party scripts imported into your code, which are called “upstream”?
This article will use cdnjs as an example to show front-end supply chain attacks and defenses.
Intigriti holds an XSS challenge every month, giving you a week to solve an XSS problem with the goal of successfully executing alert(document.domain).
As a front-end security engineer, I participate every month (but not necessarily solve it). Below are my notes from the previous months:
Each month’s challenge is quite interesting, and I think the difficulty is well controlled. It’s not super difficult, but it’s not easy to solve right away either. I also found this month’s challenge very fun, so after solving it, I wrote this article to share my experience with everyone, hoping that more and more people can participate.
Challenge URL: https://challenge-0721.intigriti.io/
When it comes to website-related attack methods, XSS, SQL injection, or CSRF are the most commonly seen methods. However, today we will introduce another type of attack that you may have heard of but are not so familiar with: DoS, Denial-of-Service attack.
When it comes to DoS, most people may think that they need to send a lot of packets to the website, and then let the website server be unable to respond or exhaust resources to achieve the goal. Or you may think of DDoS (Distributed Denial-of-Service), not a single host but a bunch of hosts sending packets to a server at the same time, and then knocking it down.
DoS and DDoS actually have different layers of attacks. These layers correspond to the OSI Model that you may have learned before. For example, the attacks you remember are more like attacks on the L3 network layer and L4 transport layer. Detailed attack methods can refer to: What is a DDoS attack? and How do layer 3 DDoS attacks work? | L3 DDoS.
But the attack method we want to share with you in this article is a DoS attack that exists in the L7 application layer.
For example, if a website has an API that can query data, and there is a default limit of 100, but I change it to 10,000 and find that the server takes about one minute to respond to me, so I send a request every two seconds. As I send more requests, the website becomes slower and slower, and finally, it crashes and can only return a 500 Internal Server Error. This is an application layer DoS attack.
Any method that prevents users from accessing the website is a DoS attack. The method we found is based on the L7 application layer, so it is an L7 DoS attack.
Among the many L7 DoS attack methods, there is one that I think is particularly interesting, which is the Cookie Bomb.
When it comes to XSS (Cross-site scripting), many people may only think of “injecting code into a website”. However, if you think about it carefully, you will find that there are many aspects that can be further explored.
These “aspects” can also be understood as different “levels”.
For example, the first level is to prevent your website from being attacked by XSS, and not allowing attackers to inject code into the website. The act of “allowing attackers to inject code into the website” can be further divided into different types of injection, such as HTML injection, injection in HTML element attributes, or injection in JavaScript code. Each of these has different attack and defense methods.
In addition to preventing code injection, the defender should also think further: “What if code injection does occur?”
This is the second level. Although we have done our best to prepare for the first level, vulnerabilities may still occur. Therefore, it is not enough to defend the first level, and we must also defend the second level.
Suppose an attacker has found a place to inject code. Can we find a way to prevent it from executing? This is where CSP (Content Security Policy) comes in, by setting some rules to prevent illegal code from executing. For example, inline JavaScript can be prevented from executing, making <img src=x onerror=alert(1)> ineffective.
If the attacker is really skilled and can bypass the rules of CSP, then we enter the third level. The assumption of the third level is that the attacker can execute any code on the website.
What can we defend against at this point? It is to try to minimize the damage.
For example, for platforms like Medium, if an attacker can use XSS to take over someone else’s account, it is a serious vulnerability. Or, because Medium has a paywall feature, if an attacker can transfer money to their account through XSS, it will also be a serious problem.
We must try to defend against these attacks under the premise of “the website has already been attacked by XSS”.
Next, let’s take a look at the different defense methods for different levels.
Intigriti is a foreign bug bounty platform that releases an XSS challenge every month. Participants have about one to two weeks to think about it, and the goal is to execute alert(document.domain) on a specific website. After solving the challenge, the results are reported through the Intigriti platform, and three randomly selected winners will receive coupons for their own store.
Last month’s challenge had few winners, so I was lucky enough to win a €50 coupon. It was actually a good deal because the items in the store were quite cheap. I bought a t-shirt, two hats, and international shipping for about €45.
However, this kind of prize is based on luck, and solving the problem is more important than winning.
The challenge URL is here: https://challenge-0521.intigriti.io/
One day, while browsing the internet, I came across an XSS challenge: Intigriti’s 0421 XSS challenge - by @terjanq. Apart from the challenge itself being very attractive, what attracted me more was the author who created it.
Many of the security-related resources I found online that were more focused on front-end were maintained or contributed to by this author, such as Tiny XSS Payloads or the eye-opening XS-Leaks Wiki.
Intigriti seems to hold this kind of XSS challenge every month, and this was the hardest one they have ever held. The challenge lasted from 4/19 to 4/25, with a week to try, and only 15 people successfully solved it. In March, 45 people solved the challenge, and in February, 33 people did, so the number of people who solved it this time was indeed much less, indicating the difficulty of the challenge.
I spent about five days on it, and every time I got stuck, I thought, “I should give up and wait for the answer.” But then, from time to time, new ideas would come up, and I would try again. Finally, on the last day before the deadline, I solved it before the time limit, and when I did, I clenched my fists and shouted, “Too awesome!”
This article is about my experience in solving the challenge. I previously wrote an English version, but it was probably worse than an elementary school composition, so I decided to write a Chinese version to better express my thoughts. The title will have a “Part 1” because this article is about my solution, and the next article will be about the author’s solution, and the one after that will analyze other people’s solutions.
But it seems that my blog is cursed to break the series of articles that haven’t been written yet, so I hope I can make it through this time.
If you don’t know what XSS (Cross-site Scripting) is, in simple terms, it is when a hacker can execute JavaScript code on your website. Since it can be executed, it is possible to steal the user’s token, impersonate the user’s identity to log in, even if the token cannot be stolen, it can still modify the page content, or redirect the user to a phishing website, and so on.
To prevent XSS, it is necessary to prevent hackers from executing code on the website, and there are many ways to defend against it. For example, CSP (Content-Security-Policy) can be used as an HTTP response header to prevent the execution of inline scripts or restrict the domains from which scripts can be loaded. Trusted Types can also be used to prevent some potential attacks and specify rules, or use some libraries that filter XSS, such as DOMPurify and js-xss.
But is it enough to use these? Yes and no.
If used correctly, of course, there is no problem, but if there are incorrect settings, there may still be XSS vulnerabilities.
Recently, I just transferred from a company to a cybersecurity team, Cymetrics, and when I was researching some websites, I found a ready-made case. Therefore, this article uses this ready-made case to illustrate what is called incorrect settings and what impact this setting will have.
Recently, my interest is playing CTF, and I only play web problems inside, for a simple reason, because I don’t know anything about other fields… Currently, I am more interested in web things, so I solve problems as a leisure activity.
This article is a summary of the BambooFox CTF 2021, and I only solved three problems.
As a front-end engineer, it is natural to know a lot about front-end-related knowledge, such as HTML or JS-related things, but those knowledge is usually related to “use”. For example, I know that when writing HTML, I should be semantic and use the correct tags; I know how to use JS. However, some knowledge related to web pages, although related to web pages, is not something that front-end engineers usually come into contact with.
What I mean by “some knowledge” actually refers to “knowledge related to information security”. Some concepts commonly found in information security, although related to web pages, are things that we are not familiar with, and I think understanding these is actually very important. Because you must know how to attack in order to defend, you must first understand the attack methods and principles before you know how to defend against these attacks.