As a front-end engineer or someone who knows JavaScript, you must have heard of the term “prototype” and may even have encountered related questions during interviews.
However, you may not have heard of a type of attack technique closely related to the prototype chain in JavaScript, which utilizes the characteristics of the prototype chain to carry out attacks - Prototype Pollution. This is an interesting and powerful attack technique.
There is a very common feature in many websites, which is redirection.
For example, if a page requires permission to view but the user has not logged in yet, the user will be redirected to the login page first, and then redirected back to the original page after logging in.
For instance, suppose there is a social networking site and to view a personal profile, one needs to log in. If Ming’s personal profile URL is https://example.com/profile/ming, then as a visitor, when I click on it, I will be redirected to the login page with the original URL as a parameter:https://example.com/login?redirect=https://example.com/profile/ming
After successful login, the website will redirect me to the original page based on the value of redirect.
Although it seems like a small feature, there are actually many security issues to consider behind it.
Among various attack methods targeting front-end, I find clickjacking quite interesting. Its Chinese translation is usually “click hijacking”, which actually means that you think you clicked something on website A, but in fact, you clicked on website B. Malicious websites hijack users’ clicks, making them click on unexpected places.
Just a click, what harm can it cause?
Suppose it is a bank transfer page in the background, and the account number and amount are filled in. Just press a button and the money will be transferred out. This is very dangerous (but usually unlikely, because transferring money still requires entering OTP and the like, this is just an example).
Or take a more common example. There is a page that looks like a page for unsubscribing from an email newsletter, so you click the “Confirm Unsubscribe” button, but actually, there is a Facebook Like button hidden underneath, so you not only did not unsubscribe, but also gave a Like (because the target of hijacking is Like, it is also called likejacking).
In this article, I will introduce the attack principle, defense methods, and practical cases of clickjacking, so that everyone can better understand this attack method.
When it comes to writing technical blog posts, most people’s first choice is still the combination of hexo and GitHub Pages. In fact, the blog you are currently reading is also built using this technology stack.
However, I recently built two other technical blogs, not using hexo, but another static site generator called eleventy. I am extremely satisfied with the results, so I wrote this article to recommend it to everyone.
If you want to check out the two blogs I built, here they are:
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.
I was recently tasked with generating a PDF report. There are many ways to create a PDF, such as using Word and then converting it to PDF. However, my first thought was to write it as a web page and then use the print function to convert it to PDF.
At my previous company, I saw a project that used JS to generate PDFs using PDFKit. While it had a high degree of flexibility, I found it difficult to maintain. The reason is that using this tool is like drawing a PDF, and you have to specify (x, y) coordinates to draw something. Changing a small part may require changing many lines of code.
At the time, I thought, why not just use the simplest HTML + CSS, cut the layout, and then convert it to PDF? If you don’t want to convert it manually, you can also use headless chrome to convert it. Because it is a web page, it should be easy to maintain. Moreover, because the layout is done using HTML and CSS, it should be much simpler than drawing.
It wasn’t until I later encountered web-to-PDF conversion that I realized things weren’t as simple as I thought.