Introduction

In the previous articles, we learned that the CORS protocol is essentially a security protocol. In addition to CORS, there are actually a series of things related to cross-origin, such as:

1. CORB (Cross-Origin Read Blocking)
2. CORP (Cross-Origin Resource Policy)
3. COEP (Cross-Origin-Embedder-Policy)
4. COOP (Cross-Origin-Opener-Policy)

Doesn’t just seeing this series of similar terms make you dizzy? Yes, me too. In the process of organizing this information, I found that the security issues related to cross-origin are more complicated than I thought, but after spending some time organizing them, I found that there is still a logical sequence to follow. Therefore, this article will explain why these things appear in a context that I think should be easier to understand.

In addition to the various COXX things mentioned above, there are other cross-origin related security issues that I want to mention in this article.

Before we continue, I would like to remind everyone that this article is about “security issues of cross-origin”, not just “security issues of CORS”. The things protected by the CORS protocol and their content have been introduced before. What this article is going to talk about is actually somewhat deviating from the main title “CORS” complete guide, because this is not very related to the CORS protocol, but rather raises the level again and talks about “cross-origin” itself.

So when you read the following things, don’t confuse them with CORS. Except for the first thing to be discussed later, the others are not very related to CORS.

Read More

Introduction

After acquiring knowledge, how can you determine whether it is correct or not? In the field of programming, this is actually a relatively simple question. You just need to check how the specification is written (if there is one).

For example, various language features of JavaScript can be found in the ECMAScript Specification. Why [] === [] is false, why 'b' + 'a' + + 'a' + 'a' is baNaNa, all of these are explained in detail in the specification, using what rules to perform the conversion.

In addition to JS, almost all HTML or other related specifications in the Web field can be found on w3.org or whatwg.org, and the resources are quite rich.

Although the implementation of browsers may be different from what is written in the specification (such as this article), the spec is the most complete and authoritative place, so it is correct to come here to find information.

If you search for the CORS spec, you may find RFC6454 - The Web Origin Concept and W3C’s Cross-Origin Resource Sharing, but these two have been replaced by a document called Fetch.

At first, I was puzzled and thought I had read it wrong. What is the relationship between fetch and CORS? Later, I learned that the fetch here is different from the fetch in the Web API. This specification defines everything related to “fetching data”, as written in its outline:

The Fetch standard defines requests, responses, and the process that binds them: fetching.

In this article, let’s take a look at the CORS-related specifications together, proving that what I said in the previous articles is not nonsense, but based on facts. Since the specification is quite long, I will only pick some key points that I think are important. If you want to understand all the content of the specification, you still need to read it yourself.

Read More

Introduction

In the previous article, we mentioned the common solutions to CORS errors and the solution that should be chosen in most cases: “Ask the backend to add response headers.”

However, “cross-origin requests” can actually be further divided into two types: simple requests and non-simple requests. Simple requests can be solved using the solution in the previous article, but non-simple requests are more complicated.

In addition, cross-origin requests do not send cookies by default, and an additional setting is required when using xhr or fetch, and the backend also needs to add an additional header.

There are actually many headers related to CORS, some of which you may not have heard of. Originally, I wanted to list these things one by one and explain them, but after careful consideration, I felt that this would be a bit boring, and everyone would probably forget after reading it.

So what would be a better way? Everyone likes to hear stories, so in this article, let’s start from the perspective of a story and tell you a story about love and CORS.

The protagonist’s name is well known, yes, it’s the unoriginal Xiaoming.

Read More

Introduction

In the previous article CORS Complete Guide (Part 1): Why CORS Error Occurs?, we understood why the browser has a same-origin policy and that the blocked cross-origin request is actually the response, not the request. After clarifying some misconceptions and having a basic understanding of CORS, we can now talk about how to solve CORS issues.

First of all, I want to let you know that the methods mentioned in this article are not complete solutions. In fact, cross-origin requests are divided into two types: simple requests and non-simple requests. The fact that “the blocked cross-origin request is actually the response, not the request” basically only applies to simple requests, and this article will only focus on “simple requests”. As for how to distinguish between simple and non-simple requests, and how to handle non-simple requests, these will be discussed in the next article.

There are actually many ways to solve basic CORS errors. Let’s first introduce a few “palliative” methods:

1. Turn off the browser’s security settings.
2. Set the fetch mode to no-cors.
3. Do not use AJAX to fetch data.

After discussing these three methods, we will talk about the last and most correct method: “Add CORS header to the backend”.

Read More

Preface

Three years ago, I wrote an article: Easy Understanding of AJAX and Cross-Origin Requests, which mentioned API integration, AJAX, same-origin policy, JSONP, and CORS. At that time, I put everything I wanted to say into it, but looking back now, it seems that many important parts were not mentioned.

Three years later, I am challenging this topic again and trying to express it more completely.

The reason why I want to write this series is that CORS is a frequently asked topic in programming-related discussion forums, and both front-end and back-end developers may ask related questions.

So I thought: “Okay, then I’ll write a series. I want to try to write this topic so that everyone who encounters CORS problems will come to see this series, and after reading it, they will know how to solve the problem.” This is my goal for this article. If the quality of the article cannot achieve this goal, I will continue to improve it.

This series consists of six articles:

• CORS Complete Guide (Part 1): Why CORS Errors Occur?
• CORS Complete Guide (Part 2): How to Solve CORS Problems?
• CORS Complete Guide (Part 3): CORS Detailed Explanation
• CORS Complete Guide (Part 4): Let’s Look at the Specification Together
• CORS Complete Guide (Part 5): Security Issues of Cross-Origin Requests
• CORS Complete Guide (Part 6): Summary, Afterword, and Leftovers

It will start from the same-origin policy, then talk about why there are errors when accessing resources across origins, and then talk about how to solve CORS-related problems correctly and incorrectly. The third article will explain in detail the detailed process of cross-origin requests, such as preflight requests.

The basic part is enough to read the first three articles, and the following will be a bit deeper. The fourth article will take you to look at the spec together, proving that the previous articles were not nonsense, and the fifth article will show you cross-origin-related regulations such as CORB (Cross-Origin Read Blocking), COEP (Cross-Origin Embedder Policy), or COOP (Cross-Origin-Opener-Policy), and related security issues. The last article will be some scattered topics and thoughts.

Read More

Preface

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.

Read More

Introduction

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.

Read More

Introduction

Blogs need to display publishing time, restaurant websites need to display reservation time, and auction websites need to display various order times. No matter what you do, you will encounter the very common need to display time.

This problem seems simple, just display the time, right? But if it involves “time zones”, the problem will become even more complicated. Regarding time zones, there are usually several requirements:

1. The time on the website needs to be displayed in a fixed time zone. I want to see the same time on the website whether I am in the United States or in Taiwan.
2. The time on the website will be different according to the user’s browser settings. I will see different times in the United States and Taiwan.
3. PM did not consider this issue and only considered local users, so there is no need to worry about this for the time being.

And this is only the display part. There is another part that communicates with the backend. We can talk about this later, but in any case, correctly handling time and time zones is not a simple matter.

I have recently encountered related issues in one or two jobs, so I have a little experience in this area and wrote this article to share with you.

Read More

Introduction

Recently, my colleagues at work took a course on information security. As I was already interested in information security, I discussed it with my colleagues, which led me to research related topics for the past two weeks. These were things I had heard of before but had not studied seriously, such as LFI (Local File Inclusion), REC (Remote code execution), SSRF (Server-Side Request Forgery), and various magical filters in PHP. I also reviewed SQL Injection and XSS, which I was already relatively familiar with.

In CTF challenges, situations often arise where you need to bypass various restrictions, which is an opportunity to test your understanding of specific protocols or programming languages. You have to think about how to find at least one way to successfully bypass those restrictions under existing limitations.

Originally, I didn’t know what to write about this week. I wanted to write about the things mentioned above, but I hadn’t figured out how to organize them yet. The follow-up series of “I Don’t know React” was not yet organized, so I thought it would be fun to do a little challenge related to “bypassing restrictions” with everyone. That is:

In JavaScript, can you successfully execute console.log(1) without using letters and numbers?

In other words, no English letters (a-zA-Z) or numbers (0-9) can appear in the code. Everything else (various symbols) is allowed. After executing the code, console.log(1) will be executed, and 1 will be printed in the console.

If you have thought of any interesting services or libraries that can do this before, don’t mention them yet. Before that, you can think about it yourself and see if you can write it out, and then check other people’s solutions.

If you can write it all by yourself from scratch, it means that you should be quite familiar with the JS programming language and various automatic type conversions.

Below, I will provide some of my own thoughts and the process of solving this problem. There are spoilers, so don’t scroll down if you haven’t solved it yet.

== Spoiler Alert ==
== Spoiler Alert ==
== Spoiler Alert ==
== Spoiler Alert ==
== Spoiler Alert ==

Read More

Preface

Note: Currently, this blog has problems supporting JSX syntax, so it may not be easy to read the code. I will fix it as soon as possible.

This title pays tribute to a series of books that people who write JavaScript have heard of even if they haven’t read them: You Don’t Know JS by Kyle Simpson. It talks about many things about JS that many people don’t know.

And I don’t know React is a series of records I made for myself, recording some React that I don’t know, and these articles are summarized from my experience using React. Some of the errors I have encountered may be very basic and common (just like those written in the official documents, but I didn’t read them carefully, so I don’t know), and some may be relatively rare (I may encounter them only after writing for three or four years at work).

In other words, the spirit of writing this series is different from YDKJS. The former wants to tell you some things about JS that few people know, and it feels like “I will teach you how to write JS”. The reason why I wrote this series called “I don’t know” is because I want to use a series of articles to record the misunderstandings or omissions I have encountered when writing React, and what is the correct answer.

I don’t know how many articles this series will have. I will post an article every time I make a mistake. There is a big difference in this series that I think is quite large. I will try to provide the scene where the mistake was made at the beginning of the article, so that everyone has the opportunity to debug before seeing the answer and see if they can find out where the error is. I think this is actually the most essential part. This is not a standardized interview question, nor is it a React quiz randomly found on the Internet, but a real situation I have encountered at work.

Because I want everyone to immerse themselves in the situation as much as possible and think about the problems I have encountered, there will be a lot of space for “defining and reproducing problems”. If you are not interested in finding answers yourself, you can also skip this part and go directly to see the answer. But I personally recommend that you try to debug it yourself first, find out where the problem is, and then come to see the answer in the article, so that you can fully absorb what the article wants to express.

Anyway, let’s take a look at the case we want to talk about in this article!

Read More