Chrome 將不會在 HTTPS 頁面上載入 HTTP 資源...

現在 Google Chrome 的穩定版是 77,到了十二月會推出的 79 的時候,就會有一連串的避免 HTTPS 頁面使用 HTTP 資源的措施:「No More Mixed Messages About HTTPS」。

首先是 79 的時候會有新的界面,讓使用者可以修改阻擋類的設定。

到了 80 的時候會試著將 HTTP 的影音 <audio><video> 升級到 HTTPS 連線,如果 HTTPS 讀不到的話就當作讀取失敗。但圖片 <img> 的部份則是會讀進來,只是安全性上會顯示 Not Secure。

到了 81 就是這系列的最終階段,包括 <img> 也會一使用 80 時影音的邏輯,沒辦法在 HTTPS 上讀到就當作讀取失敗。

imgproxy:自動處理圖片的工具

看到「imgproxy: Resize your images instantly and securely」這篇文章,介紹「DarthSim/imgproxy」這個專案,想起很久以前的同事在 PIXNET 弄的 *.pimg.tw 系列服務...

imgproxy 可以 resizing,也可以 croping,然後也支援 signature token 機制,感覺是每個大一點的站台都會自己刻一次的服務 XD

整個專案以 Golang 為主,效能應該是不錯... 不過一般前面還是會放 cache 機制 (像是 CDN 之類的服務),而不會把 loading 直接打進來,避免同樣的圖片一直重複計算。

利用 Facebook Notes 對圖片 cache 的特性發動 DDoS 攻擊

在「Using Facebook Notes to DDoS any website」這篇文章裡提到了利用 Facebook Notes 允許使用者嵌入 <img> 標籤時的特性,利用 Facebook 的 server 進行 DDoS...

在 Notes 一般的 <img> 會被 Facebook 的伺服器 cache 起來,但如果是帶有 query string 的 <img> 就不會 cache (因為不同的 query string 表示不同的 url 是合理的),於是就可以利用這個特性打出超高的流量:

這個問題被 Facebook 認為不是問題,不會也不打算修正...

文章後提到的指令還蠻有趣的,要抓出某個 AS number 有哪些 IP address,可以用這樣的指令抓出來:

whois -h whois.radb.net — '-i origin AS32934' | grep ^route

試著抓了 AS9916 與 AS18185,的確是蠻有趣的東西 XD