Password reset is a mechanism that almost all websites have. The most common way is to send a password reset link via email, and after clicking the link, the user can set a new password for the account. Although this mechanism is common, there are some small security details to pay attention to.
This time, I am going to write about an account takeover vulnerability caused by the password reset function that I reported at the end of June this year.
The biggest news in the cybersecurity industry at the end of 2021 is undoubtedly the Log4j vulnerability, also known as CVE-2021-44228 or Log4Shell. Some even describe it as a “nuclear-level vulnerability,” highlighting the far-reaching impact of this vulnerability.
While there are many technical analyses of the vulnerability, those without technical backgrounds may only know that the vulnerability is severe without understanding why or how it works. Therefore, I want to write a more straightforward article that non-technical people can understand.
There is very little information available in Chinese about CREST, the organization, and CPSA, the certification. In Taiwan, it is considered a relatively obscure certification. I gained a basic understanding of this organization and certification after reading this article: ECSA v10 Equivalent Application CREST CPSA Security Analyst Certification Tutorial / ECSA with CPSA Equivalency Recognition Step.
In December, I took the CPSA certification exam with a colleague and we both passed. I am writing this post to share my experience.
HITCON 2021 DEVCORE organized a wargame, which can be found here: https://hackmd.io/@d3vc0r3/hitcon2021
It was stated that the game can be completed within two hours, so I decided to give it a try. However, due to my lack of experience, I got stuck in one part for a long time. Apart from that, the difficulty level was not high. This article briefly records the process and experience of solving the game.
I have introduced Intigriti’s XSS challenge many times before, so I won’t go into detail this time. If you are interested, you can refer to my previous articles. The focus of this article will be on their October challenge, which is not difficult. After spending about one or two days to solve it, I didn’t touch it anymore. I decided to write this article because after the challenge ended, I saw many unexpected solutions, so I wanted to record them in an article.
This article is the text version of my presentation “Discovering the Depth of Front-end through Cybersecurity” at Modern Web 2021. The video of the talk is not yet available, but if you want to see the slides, you can find them here: slides
I personally think that the combination of video and slides would be better than text alone, but I thought it would be nice to have a written record, so I wrote this article. The content may differ slightly from the video, as it’s like rewriting it.
I have written some articles about XSS before, mainly discussing the implementation of prevention and defense details:
Originally, I wanted to write about the basics of XSS, the three types that everyone has heard of: Stored (Persistent), Reflected (Non-Persistent), and DOM-based XSS. However, when I was about to start writing, I suddenly had a few questions in my mind: “When did XSS appear? When were these three types classified?”
Therefore, I spent some time looking for information, and this article will talk about the history of XSS with you, so that we can better understand the past and present of XSS.
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.