前言

之前已經介紹過 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 的攻擊原理、防禦方式以及實際案例，讓大家更了解這個攻擊手法。

閱讀更多

前言s

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

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

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

閱讀更多

（原文發佈於 Cymetrics Tech Blog：Intigriti 七月份 XSS 挑戰：突破層層關卡）

前言

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/

閱讀更多

前言

六月份的挑戰沒解出來，這篇透過兩篇公開的 writeup 來學習一下其他人的做法，順便檢討一下自己哪邊可以再加強。

閱讀更多

（原文發佈於 Cymetrics Tech Blog：淺談 XSS 攻擊與防禦的各個環節）

前言

談到 XSS（Cross-site scripting），許多人可能都只想到「就是網站上被攻擊者植入程式碼」，但若是仔細去想的話，會發現這之中其實還有很多環節都可以再深入探討。

而我所謂的這些「環節」，也可以理解成不同的「關卡」。

舉例來說，第一關當然就是盡可能防止自己的網站被 XSS 攻擊，不要讓攻擊者在網站中能夠植入程式碼。而「讓攻擊者在網站中植入程式碼」這件事，又可以往下再細分成不同地方的植入，例如說 HTML 的植入，或者是 HTML 元素屬性中的植入，又或是 JavaScript 程式碼中的植入，這些都有著不同的攻擊以及防禦方式。

而除了防止被植入程式碼以外，防守方應該還要進一步去想：「那如果真的不幸被植入程式碼了，可以怎麼辦？」

這就是第二個關卡。雖然說第一關我們已經盡可能做好準備了，但難保不會有漏洞產生，因此守好第一關是不夠的，也要對第二關進行防守。

假設今天攻擊者真的找到一個地方植入程式碼，那我們是不是可以想辦法阻止它執行？這就是 CSP（Content Security Policy）出場的時候了，藉由設定一些規則讓不合法的程式碼無法執行。例如說可以讓 inline 的 JavaScript 無法執行，那 <img src=x onerror=alert(1)> 就會變得無效。

若是攻擊者真的很厲害，連 CSP 的規則都繞過了呢？這時就進入到第三關了，第三關的假設是攻擊者已經能夠在網站上執行任意程式碼。

這時候還可以防守什麼呢？那就是試圖把損害控制到最低。

以 Medium 這種部落格的平台來說，若是可以利用 XSS 把別人的帳號奪走（account takevoer），就是個嚴重的漏洞；或是因為 Medium 有付費牆的功能，因此若是能透過 XSS 把錢轉到攻擊者的帳號，也會是一個很嚴重的問題。

而我們要在「網站已經被 XSS」的前提下，試圖去防禦這些攻擊。

接著，就讓我們來看看不同的關卡有哪些不同的防禦方法。

閱讀更多