#Front-end

前言

之前已經介紹過 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/

閱讀更多

(原文發佈於 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」的前提下,試圖去防禦這些攻擊。

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

閱讀更多

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×