可被跨站刪除帳號— 我是怎麼發現串流平台的點擊劫持漏洞的？
這個漏洞，讓攻擊者可以誘導使用者無意間刪除帳號（某串流平台）、無意間發文與刪除文章（某大型論壇），那麼這篇文章就來探討點擊劫持是如何發生的、我怎麼發現兩個站點的漏洞、以及這個漏洞帶來的危害。
點擊劫持（clickjacking）
clickjacking 是一種在網頁中將惡意代碼等隱藏在看似無害的內容（如按鈕）之下，並誘使用戶點擊的手段。這種行為又被稱為界面偽裝（UI redressing）。
舉例來說，如用戶收到一封包含一段影片的電子郵件，但其中的「播放」按鈕並不會真正播放視頻，而是連入一購物網站。這樣當用戶試圖「播放視頻」時，實際是被誘騙而進入了一個購物網站。
那麼在前端上的前端點擊劫持的例子：在攻擊者頁面透過 iframe 嵌入目標頁面網站，並且將引入之頁框隱藏，誘導使用者點擊、操作。
點擊劫持是如何發生的？
在古早的年代為了防止站點被任意嵌入，通常會透過 JavaScript 腳本寫入防禦腳本，驗證頁面是否被嵌入，我們稱之為 Frame Busting。這種防禦腳本通常長得像是這個樣子。
if (top.location != location)
top.location=self.location或像是
if (parent.frames.length > 0) {
top.location.replace(document.location);
}透過在頁面載入時驗證自身是否在頁框內。
X-Frame-Options
因為透過 script 去做防護可能會被一些手段繞過，後來的人們推崇另外一種防範措施，也就是透過特定的 HTTP Header 來告訴瀏覽器：我們並不想被 iframe 嵌入！
來看看 MDN 對於這個 Header 的介紹：
X-Frame-Options HTTP 回應標頭 (header) 用來指示文件是否能夠載入
<frame>,<iframe>以及<object>，網站可以利用 X-Frame-Options 來確保本身內容不會遭惡意嵌入道其他網站、避免 clickjacking 攻擊
這個標頭允許三種方式DENY、SAMEORIGIN、ALLOW-FROM uri ，告訴瀏覽器是否可以透過頁框引用。針對需求設定。
StreetVoice 帳號刪除漏洞（已修復）
StreetVoice 提供使用者刪除自身帳號的功能，且其頁面並無做上述兩者的防禦措施，可以在攻擊者站點透過 iframe 引用。
透過 iframe 引用後 調整樣式之 opacity 與 scale 將其隱藏，最後只要誘導受害使用者點擊頁面的按鈕，則會在使用者不知情（因為透明度的調整）的狀況下刪除帳號。
目前這個漏洞已經失效，因為我在 1/4 已向 StreetVoice 站方回報，且在同日下午已針對此問題做修繕。
Demo:
我怎麼發現 Dcard 的點擊劫持漏洞的？
主要是因為回報 Streetvoice 之後，我發現沒有好好截取一張圖來說明點擊劫持漏洞，實際上的恐怖畫面，但又非常手癢，挺想寫一篇文章來闡述點擊劫持有多痛。
於是我嘗試透過 curl 指令幫我看看我常逛的頁面的 Header。
好，第一發試試看大學生最愛流連忘返的網站 — Dcard
該出現的標頭跟茶渡的靈壓一樣，消失了。
那我們嘗試站在攻擊者的角度，把頁面藏起來，以及想誘導的操作定位一下，我們試著調整 opacity scale translate 等等的，把它藏起來。
沒有想到 Dcard 也有這樣子的點擊漏洞。
這個漏洞主要會造成什麼危害？
- 如同上面的例子，這個漏洞主要危害在於，使用者在不知情的情況下引入了某些特定頁面，攻擊者可以誘導使用者操作頁面元件。
- 如果攻擊者將 iframe 標籤重複嵌入，可能會造成目標的伺服器被服務阻斷，甚至在多個受害者進入攻擊頁面時，變成大量的分散式攻擊。
var iframe = document.createElement('iframe');
iframe.src = 'https://www.目標頁面.com';
setInterval(()=>document.body.append(iframe),0);也因為透過了 HTML 解析，其頁面載入的靜態資源、腳本、API 都會被不斷重新載入。
怎麼解決這個問題？
我們可以在 Web Server 設定 X-Frame-Options 的標頭。
比如 Facebook 與 Twitter 在這個標頭上都是直接設定為 deny 的。
當然某些情況下你希望同域（跨域）的使用者可嵌入的化可以再另外做設定。比如 Youtube 在可被嵌入的影片 /embed 下並沒有限制 iframe 行為，但是在 https://www.youtube.com/ 則是設有 x-frame-options: SAMEORIGIN 。
主要原因是 embed 的影片不會操作到用戶敏感資訊。
想跟各位聊聊對這個漏洞的看法
許多人可能認為這個漏洞的危害程度不大，畢竟 iframe 並沒有辦法透過腳本操作（跨域的情況下），許多時候是透過一些引誘使用者操作的方式去做攻擊，比如「恭喜你抽中一百萬了！」、「點擊我查看更多成人影片」甚至是更複雜的遊戲互動之類的方式做引誘，我們沒有辦法預估攻擊者的做法。
但身為開發者，我們能做的只有避免讓使用者在不知情的情況下操作到自己的帳號行為。
這個惡意頁面的構築仰賴前端能力
這類的嵌入與惡意誘導的頁面，需要仰賴前端能力去構築，如同上面說的透明度、伸縮位移，事實上在誘導使用者需要靈活的樣式佈局。
可以說這個漏洞的破壞程度，跟攻擊者構築的前端頁面有關。
