Recently, during a penetration test, our team discovered an interesting SQL injection case. Due to some features, we couldn’t directly use existing tools to retrieve data. We had to modify the tools or write scripts to effectively utilize them. Therefore, this article will share two practical cases and my own solutions.
I have put these two cases on Heroku and turned them into two small challenges. If you are interested, you can try them out:
(The Heroku links are no longer available)
Although Same Site and Same Origin may seem similar, they are actually quite different. This difference affects how the browser perceives the relationship between these two websites and the permissions it grants.
This article will cover the following topics:
Without further ado, let’s get started!
(Before we begin, let’s answer a question. Yes, the title was inspired by the ninja Hattori.)
2022-01-20: Modified the “Examining Same Site” section to supplement the history of the scheme. Thanks to @littlegoodjack.
I believe that to truly understand JavaScript, we must start from its history. Why? Because by understanding its history, we can know why certain parts are designed in a certain way and why there are seemingly strange behaviors. Although some ancient knowledge may not have much practical use, it is very interesting to me.
Learning its history is not about memorizing the year it appeared or how many days it took to develop and design, but rather understanding the context in which it appeared and why it was needed and designed in a certain way.
If you want to learn about the history of JavaScript, my top recommendation is this resource: JavaScript: The First 20 Years, because Brendan Eich, the father of JavaScript, is also one of the authors. If you want to read the Chinese version, it is available here: JavaScript 20 Years.
This book records the history of JavaScript from 1995 to 2015, a total of 20 years. If you have time, I strongly recommend that you read it all. It will give you a different understanding of JavaScript (and you will also learn a lot of interesting facts).
Below, I will pick some of the more important things to write about. If there is no specific mention of the data source, it is from the book mentioned above, so it is normal if it seems familiar.
Since I was born around the same time as JavaScript, I have not personally experienced the early history. If it seems like I have participated in it, it is all just imagination.
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.