Huli's blog

在 idekCTF 2024 中，由 icesfont 所出的一道題目 srcdoc-memos 十分有趣，牽涉到了許多 iframe 的相關知識。我沒有實際參加比賽，但賽後看了題目以及解法，還是花了好幾天才終於看懂為什麼，十分值得把過程以及解法記錄下來。

由於這題牽涉到不少與 iframe 相關的知識，我會盡量一步一步來，會比較好理解。

前陣子有個讀者分享給我他自己做的 Chrome extension：JP NEWS Helper，能夠摘要、翻譯 NHK News Easy 上面的文章，幫助學日文。

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

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

前陣子收到一封讀者來信，問我能不能寫一篇來講解 XSS without parentheses and semi-colons 這篇文章，說是這裡面的 payload 看不太懂。

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

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

身為每天都要與網頁打交道的前端工程師，熟悉 DevTools 的使用是相當合理的。每當接 API 出問題時，就按下快捷鍵打開 DevTools，切到 Network 分頁，找到紅色的那一行，右鍵複製成 cURL 貼到群組裡面，讓後端自己找找問題。

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

應該不少人都有跟到三週前 VS Code 上的知名套件 Material Theme 被微軟主動下架的新聞，那下架的理由是什麼呢？根據你得知這件事的消息來源以及自身個性，可能會有兩種回答：

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

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

當你想在網頁上向 server 發送一些 tracking 相關的資訊時，比起直接用 fetch 送出請求，有另一個通常會被推薦的選擇：navigator.sendBeacon。

為什麼會推薦這個呢？

因為如果是用一般送出請求的方法，在使用者把頁面關掉或是跳轉的時候可能會有問題，例如說剛好在關掉頁面時發送請求，這個請求可能就送不出去，隨著頁面關閉一起被取消了。

雖然說可以利用一些方法嘗試強制送出請求，但這些方法通常都會傷害使用者體驗，例如說強制讓頁面晚一點關閉，或是送出一個同步的請求之類的。

而 navigator.sendBeacon 就是為了解決這個問題而生的。

久違的筆記，想寫很久了但一直拖延，像是 CTF 這種東西的 writeup 其實速度滿重要的，因為賽後討論大部分都在 Discord 裡面發生，時間久了訊息比較難找，而且很有可能忘記，要趕快寫成 writeup 才能把那些實用的資訊記錄下來。

這篇一次帶來三個 CTF 的 writeup，有些我沒有打，只是純粹看著別人的筆記重新記一遍而已。

關鍵字列表：

1. bfcache
2. response splitting
3. Service-Worker-Allowed
4. gunicorn script_name
5. socket.io disconnect
6. socket.io JSONP CSP bypass
7. performance API
8. streaming HTML parsing
9. content-type ISO-2022-JP

這半年左右因為有其他事情在忙，有段時間沒有好好打一場 CTF 了，這次為了 GoogleCTF 2024 騰出時間，跟隊友一起把所有 web 都解掉了。

然後題目依舊很有趣，這次有三題有參與到，另外兩題比較簡單的隊友都先解掉了，沒機會看，但還是會稍微做個紀錄。難得有這種幾乎都是 client-side challenge 的 CTF，我是滿喜歡的。

關鍵字：

1. URL parser 繞過
2. parseInt 後面可以帶字串
3. [a-Z] regex 會包含特殊字元
4. cookie tossing
5. CSS injection

Polyfill.io 是一個能夠自動提供前端 polyfill 的服務，使用方法相當方便，只需要選擇想被 polyfill 的功能，再引入一個 JavaScript 檔案即可：

<script src="https://polyfill.io/v3/polyfill.min.js"></script>

Server 端會自動根據 user-agent 來判斷是不是需要回傳 polyfill，所以只會引入真的需要的程式碼，聽起來方便又好用。

但這幾天應該有人收到 Google Ads 的通知，說這有 security issue，這又是爲什麼呢？

以前當我想要部署一個簡單的服務時，我會去 Heroku 上面，因為簡單而且免費，雖然說還是有些使用限制，但整體而言還是很方便的，甚至還有一些簡單的 DB 可以用。如果是靜態網頁，會選擇 Netlify 或是 GitHub Pages，也都是簡單方便的選擇。

但 Heroku 從 2022 年年底之後就不再提供免費方案了，因此那時一堆人在尋找替代方案，包括 Render 或是 fly[dot]io 等等，都是很多人跳槽的新選擇。而我自己以前其實在 Heroku 上也有三四個專案，從 Heroku 改變方案之後就再也沒也動過了。

前陣子收到 Zeabur 創辦人的來信，希望有機會能跟我合作推廣這個平台，我自己試了之後發現體驗確實很不錯，因此就寫了這篇文章介紹一下。

如果有看過我的部落格的話，應該會知道我一直都是寫 React，完全沒有碰過 Vue，也沒有碰過 Angular。自從 2015 年接觸到 React 後，工作上就一直是用 React 了。

然而，最近因為工作上的需求，所以開始寫 Vue 了，而剛好也有讀者來問我從 React 跳到 Vue 的心得，因此這邊就簡單寫一篇來分享。

今年的 0CTF 一共有三道 web 題，其中一道題目是 client-side 的，我就只解這題而已，順利拿到 first blood，這篇簡單記錄一下心得。

關鍵字列表：

1. CSS injection
2. CSS exfiltration

上個月（2024 年 1 月）的 Intigriti 挑戰非常有趣，出題者是 @kevin_mizu，之前也常在推特上看到他出一些 client-side 相關的題目，而這次的題目品質也一如既往的很好，值得寫一篇紀錄。

題目的連結在這邊，沒有看過的話可以先去看看：https://challenge-0124.intigriti.io/

相比於去年跟前年，今年的 web 題難度有顯著降低了不少，變得更平易近人了，靠著隊友的努力拿下了第一名，而 web 題也只剩一題沒解出來。

這次我基本上只解了簡單的 funnylogin 跟難的 safestlist，其他都是隊友解開的，還有另一題 another-csp 有看了一下，因此這篇只會記我有看過的以及比較難的題目。

如果想看其他題，可以參考其他人的 writeup：

1. st98 - DiceCTF 2024 Quals writeup
2. 0xOne - 2024 Dice CTF Write up [Web]

官方提供的所有題目原始碼：https://github.com/dicegang/dicectf-quals-2024-challenges

關鍵字列表：

1. crash chromium
2. slower css style
3. xsleak
4. URL length limit
5. service worker
6. background fetch
7. connection pool + css injection
8. iframe width + css inection

因為最近有點忙的關係，這兩三個月比較少打 CTF 了，但還是會在推特上看到一些有趣的題目。雖然沒時間打，但筆記還是要記的，沒記的話下次看到鐵定還是做不出來。

這篇主要記一些網頁前端相關的題目，由於自己可能沒有實際下去解題，所以內容都是參考別人的筆記之後再記錄一些心得。

關鍵字列表：

1. copy paste XSS
2. connection pool
3. content type UTF16
4. multipart/mixed
5. Chrome DevTools Protocol
6. new headless mode default download
7. Scroll to Text Fragment (STTF)
8. webVTT cue xsleak
9. flask/werkzeug cookie parsing quirks

你知道嗎，當你跟朋友在討論 SSR 的時候，很有可能你們對 SSR 的認知其實是不一樣的。直接舉個例子，底下這幾種情境，你覺得哪些算是 SSR？

1. 由後端 PHP 產生畫面
2. 前端是 React 寫成的 SPA，但後端如果偵測到搜尋引擎，就會切換另一種 template，輸出專門針對搜尋引擎的模板，而非 React 渲染出的頁面
3. 前端是 React 寫成的 SPA，但透過 Prerender 先把頁面 render 成 HTML，再交給搜尋引擎（一般使用者依然是 SPA），跟上一個的差別是使用者跟搜尋引擎看到的畫面基本上一致
4. 前端是 React 寫成的 SPA，在後端用 renderToString 把 React 渲染成字串，但是沒有資料，資料會在前端拿
5. 前端是 React 寫成的 SPA，後端會針對每個 page 先呼叫 API 拿資料，拿完以後才呼叫 renderToString 輸出 HTML，在 client 端時會做 hydration 讓頁面可以互動

有一種人認為只要是由後端產生出畫面，就叫做 SSR，所以 1 ~ 5 全部都是 SSR。也有一種人認為前端必須先是 SPA，此時搭配的後端才能叫做 SSR，所以 2~5 都是 SSR；而另一種人則認為 SSR 的重點是 hydration，所以只有 5（或是 45）是 SSR。