Same site 跟 same origin 雖然看起來有點像，但其實差別不小，而這個差別也會影響到瀏覽器如何看待這兩個網站的關係還有給予的權限。

這篇文章將會談到：

1. Origin 是什麼？怎樣是 same origin？
2. Site 是什麼？怎樣是 same site？
3. same origin 跟 same site 的差別是什麼？
4. 如何把 same site 變成 same origin？

事不宜遲，就讓我們開始吧！

（開始之前先回答一個疑問。是的，標題的靈感來自於忍者哈特利）

2022-01-20：修改「細究 same site」段落，補充 scheme 相關歷史，感謝 @littlegoodjack

閱讀更多

我認為想要真正認識 JavaScript 的話，要從歷史開始。為什麼？因為從它的歷史，可以知道為什麼某些部分是這樣子設計，為什麼會有這些看似奇怪的行為。雖然有些古早的知識可能沒什麼實際用途，但對我來說是很有趣的。

學習它的歷史，並不是死背它出現的年代或是當初花了幾天開發設計，而是要去理解它出現的脈絡，去理解為什麼需要它，又為什麼它是這樣子被設計的。

想了解 JavaScript 的歷史，我最推薦的是這個資源：JavaScript: The First 20 Years，因為 JavaScript 之父 Brendan Eich 也是作者之一，想看中譯版的話在這邊：JavaScript 二十年。

這本書紀錄了從 1995 年到 2015 年，一共二十年的 JavaScript 歷史，如果有時間的話我強烈建議你把它全部看完，會對 JavaScript 有不同的體會（還會知道很多冷知識）。

底下我會挑一些我覺得比較重要的東西來寫，資料來源沒有特別講的話，都是來自於上面提到的那本書，所以若是覺得似曾相似是正常的。

由於我跟 JavaScript 差不多時候出生，因此這些早期的歷史我並沒有親身體會過，若是寫得好像我有親身參與的話，全都是想像而已。

閱讀更多

前言

之前已經介紹過 Intigriti 的 XSS 挑戰很多次了，這次就不再介紹了，有興趣的可以直接翻我之前的文章。這一篇文章的重點會放在他們十月份的挑戰，難度不高，我花了大約一兩天的時間解出來以後就放著沒動，會想寫這篇是因為挑戰結束以後，看到許多超乎我想像的解法，因此特地寫一篇文章記錄一下。

閱讀更多

此文章是我在 Modern Web 2021 的分享：《接觸資安才發現前端的水真深》的文字版，當時的演講影片尚未釋出，想看簡報的話在這邊：slides

我自己覺得影片加上簡報的效果應該會比文字好，但想說用文字留一份紀錄也不錯，因此還是寫了這篇文章，內容會有些許與影片不同，有點像是再重新寫了一遍。

閱讀更多

我以前有寫過一些關於 XSS 的文章，主要在談的是實作面的防範以及防禦的各個細節：

1. 防止 XSS 可能比想像中困難
2. 淺談 XSS 攻擊與防禦的各個環節

這篇原本想寫的是 XSS 的基礎，就大家都聽過的那三種類別：Stored(Persistent)、Reflected(Non-Persistent) 以及 DOM-based XSS，但當我正要開始寫的時候，腦中突然浮現了幾個問題：「XSS 是什麼時候出現的？這三種類別又是什麼時候開始被分類的？」

因此，我花了點時間找了一些資料，這篇文章會跟大家談談 XSS 的歷史，讓我們一起更了解 XSS 的前世今生。

閱讀更多

前言

身為一個前端工程師，或是一個會寫 JavaScript 的人，你一定多少有聽過 prototype 這個名詞，甚至面試的時候也會考到相關的題目。

但你可能沒聽過的是，在 JavaScript 中有一種攻擊手法跟原型鏈息息相關，利用原型鏈這個功能的特性來進行攻擊——Prototype pollution，通常翻做原型鏈污染，就是這麼有趣而且破壞力十足的一個攻擊手法。

閱讀更多

前言

在許多網站中都有個很常見的功能，就是重新導向。

舉例來說，如果要觀看的頁面需要權限但是使用者還沒登入，就會先把使用者導去登入頁面，登入完之後再導回原本要去的頁面。

例如說今天有個社群網站，想要看個人檔案的話需要登入，而小明的個人檔案網址是：https://example.com/profile/ming，那我身為一個訪客，點進去之後就會跳轉到登入頁面，並且帶上我原本要去的網址當作參數：
https://example.com/login?redirect=https://example.com/profile/ming

登入成功之後，網站就會根據 redirect 的值，把我導去原本要前往的頁面。

雖然看起來是個小功能，但其實背後有不少安全性的問題要考慮。

閱讀更多

前言

在針對前端的各種攻擊手法之中，我覺得 clickjacking 是相當有趣的一個。它的中文翻譯通常翻成「點擊劫持」，實際上的意思是你以為點了 A 網頁的東西，其實卻是點到了 B 網頁，惡意網頁劫持了使用者的點擊，讓使用者點到意料之外的地方。

只是一個點擊而已，這樣會有什麼危害嗎？

假設在背後的是一個銀行轉帳頁面，而且帳號跟金額都填好了，只要按一個按鈕就會轉錢出去，這樣的話危害就很大了（不過這通常不太可能啦，因為轉帳還需要輸入 OTP 之類的，這只是舉例）。

或是舉個更常見的例子，例如說有個乍看之下是取消訂閱電子報的頁面，於是你點了「確定取消」的按鈕，但其實底下藏著的是 Facebook 的按讚鈕，所以你不但沒有取消訂閱，還被騙了一個讚（因為劫持的目標是讚，所以又稱為 likejacking）。

這篇文章我會介紹 clickjacking 的攻擊原理、防禦方式以及實際案例，讓大家更了解這個攻擊手法。

閱讀更多

前言

Supply chain attack，中文翻成供應鏈攻擊，這個手法瞄準了上游的漏洞進行攻擊，因為只要污染了上游，下游也會一併被污染。

以前端為例，你使用的 npm 套件或是程式碼中引入的第三方 script，這些就叫做「上游」，在使用這些第三方資源的同時，你有意識到這也伴隨了一定的風險嗎？

這篇文章會以 cdnjs 為例，帶大家看看前端的供應鏈攻擊與防禦。

閱讀更多

前言

Intigriti 這個網站每個月都會有 XSS 挑戰，給你一週的時間去解一道 XSS 的題目，目標是成功執行 alert(document.domain)。

身為一個前端資安混血工程師，我每個月都有參加（但不一定有解出來），底下是前幾個月的筆記：

1. 解題心得：Intigriti’s 0421 XSS challenge（上）
2. Intigriti’s 0521 XSS 挑戰解法：限定字元組合程式碼
3. Intigriti 六月份 XSS 挑戰檢討

每個月的挑戰都相當有趣，我覺得難易度也掌握得不錯，沒有到超級無敵難，但也不會輕易到一下就被解開。而這個月的挑戰我也覺得很好玩，因此在解開之後寫了這篇心得跟大家分享，期待有越來越多人可以一起參與。

挑戰網址：https://challenge-0721.intigriti.io/

閱讀更多