iOS App 的釣魚

在「iOS Privacy: steal.password - Easily get the user's Apple ID password, just by asking」這邊作者示範了怎麼釣魚:直接模擬 iOS 的系統視窗跟使用者要密碼。

看了只有「操」... 目前想的到的 workaround 只有在看到類似的視窗時跳回主畫面,透過 Settings 裡確認?

利用 Unicode Domain 釣魚,以及 Chrome 與 Firefox 的解法

一個多禮拜前引起蠻多討論的一篇文章,利用 Unicode Domain 釣魚的方法:「Phishing with Unicode Domains」。

由於這是幾乎完美的攻擊,所以被提出來後 (Security: Whole-script confusable domain label spoofing) 有不少討論:

This bug was reported to Chrome and Firefox on January 20, 2017 and was fixed in the Chrome trunk on March 24. The fix is included in Chrome 58 which is currently rolling out to users.

comment 8 提到:

We do have a whitelist. Essentially you're suggesting that we remove Cyrillic and Greek characters from the list. I'm not sure we want to go down that path.

在新版的 Chrome 58 已經「修正」了這個問題:

Firefox 的討論在「IDN Phishing using whole-script confusables on Windows and Linux」這邊,一開始就直接把票給關了 XDDD:

Indeed. Our IDN threat model specifically excludes whole-script homographs, because they can't be detected programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the responsibility of domain owners to check for whole-script homographs and register them.

We can't go blacklisting standard Cyrillic letters.

If you think there is a problem here, complain to the .com registry who let you register .


Last Resolved: 3 months ago
Flags: needinfo?(gerv)
Resolution: --- → WONTFIX

然後一個月前被提出來看看 Chrome 怎麼做:

Gerv/Valentin, is this something we can/should align with Chromium on?

目前唯一的解法是改 flag,把所有的 Unicode Domain 直接當作一般的 domain 來處理,列出像是 的網址。

瀏覽器 UI 的死亡線

作者 Eric Lawrence 現在在 Google Chrome team 裡,寫了一篇文章講到瀏覽器上 UI 設計與安全性的問題:「The Line of Death」。


後來有些操作跨過這條線 (左邊),於是就開始有很 tricky 的方法 (右邊):

甚至反過來利用 icon 讓使用者誤會是表示有訊息要通知使用者:


最新的方法是利用 HTML5 的 Fullscreen API 直接搞定所有事情:


利用隱藏的 form input 加上自動完成功能取得敏感資料

anttiviljami/browser-autofill-phishing 這邊示範了怎麼用隱藏的 form input 與自動完成功能取得敏感資料。在這邊可以看到示範 (把 POST 丟到 httpbin 上看 response)。

想法不算困難,但好像也不是很好防... 關掉 autofill 是比較簡單的解法 (我是裝好瀏覽器就會關掉,不過好像很多人都喜歡用這個功能),所以這個問題就丟回給這些 browser vendor 想了 :o

社交工程演練網站 CuttlePhish

Hacker News Daily 上看到的服務:「CuttlePhish」。

CuttlePhish 是個社交工程演練網站,提供演練測試 (Phishing as a Service),付費的方式也很有趣:

Twenty bucks, for up to 100 users. We charge per-batch of emails, (not per-email or per-click). You only pay if somebody clicks one of the links in our emails.

只有在有人點的時候收 USD$20... XD

擋 Open Redirect 的問題...

Open Redirect 的問題可以參考:

這兩個連結。主要是要避免 phishing 的問題上。

一開始是以「只允許 / 開頭」為條件過濾,但 protocol-relative 的 // 可以繞開。

如果變成「只允許 / 開頭,但不允許 // 開頭」,是不是就沒事了呢?

在「Evolution of Open Redirect Vulnerability.」這邊又看到新招:「/\」。

想要用 parse_url() 檢查?沒問題:

$ php -a
Interactive mode enabled

php > var_dump(parse_url("/\\"));
array(1) {
  'path' =>
  string(17) "/\"

但實際測試會發現 IE8 與 Google Chrome 都會跳到 (沃槽),其他瀏覽器就先不測了 ~_~

不過原文說的 ///www.example.comPHP 上測試應該是不會過的?

$ php -a
Interactive mode enabled

php > var_dump(parse_url("///"));

反正又冒出一堆問題要處理了 ~_~