Tag: content

Amazon API Gateway 支援壓縮了...

Amazon API Gateway 支援壓縮了：「Amazon API Gateway Supports Content Encoding for API Responses」。

You can now enable content encoding support for API Responses in Amazon API Gateway. Content encoding allows API clients to request content to be compressed before being sent back in the response to an API request. This reduces the amount of data that is sent from API Gateway to API clients and decreases the time it takes to transfer the data. You can enable content encoding in the API definition. You can also set the minimum response size that triggers compression. By default, APIs do not have content encoding support enabled.

打開後傳回的資料就會自動壓縮了，然後還可以設定觸發的 response size... 依照文件 (Content Codings Supported by API Gateway)，目前支援的壓縮格式應該是最常見的 gzip 與 deflate。

這功能好像是一開始有 API Gateway 就一直被提出來的 feature request...

curl 將支援 Brotli 壓縮

在 Twitter 上看到有人提到 curl 支援 Brotli 了：「HTTP: implement Brotli content encoding」。

Brotli 對文字系列的資料比較有幫助 (像是 html)：

Unlike most general purpose compression algorithms, Brotli uses a pre-defined 120 kilobyte dictionary, in addition to the dynamically populated ("sliding window") dictionary. The pre-defined dictionary contains over 13000 common words, phrases and other substrings derived from a large corpus of text and HTML documents. Using a pre-defined dictionary has been shown to increase compression where a file mostly contains commonly-used words.

現在還在 master 裡面，之後的 release 版本應該就會支援了...

Adobe Flash 將在 2020 年 End of Life

Adobe 發出的公告，將在 2020 年中止所有對 Flash 的支援：「Flash & The Future of Interactive Content」。

Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats.

然後 Google 與 Microsoft 也來補刀講兩句話：「So long, and thanks for all the Flash」、「Saying goodbye to Flash in Chrome」、「The End of an Era – Next Steps for Adobe Flash」。

利用上傳的檔案跳過 CSP 限制

用 CSP 可以做到一些簡單的保護機制，但在設計不良的情況下還是有辦法繞過。

這次是上傳合法的 JPEG 檔案，但當作 javascript 檔案繞過去：「Bypassing CSP using polyglot JPEGs」。

開頭的「FF D8 FF E0」可以在「List of file signatures」這邊看到是「JPEG raw or in the JFIF or Exif file format」，而這四個字元在 javascript 不會出問題。接下來的「2F 2A」表示 JPEG header 長度，剛好就是「/*」，把後面的東西給包起來，後面再用類似的方式一直組合就打穿了...

這種攻擊要跳過的是「用 CSP 的 self 限制不能引用外部網站 javascript」的限制，但還是有些前提：

  • 允許使用者傳到同一個 domain 上面。
  • 網站上有 XSS 漏洞。

其中第一個問題常見的解法是另外開一個 domain 來放使用者上傳的檔案 (最好是連 top domain 都不一樣，完全隔開)，才可以透過 CSP 降低風險...

CloudFront 支援將 Query String 內的特定 Key/Value 當作 Cache Key 的一部分

Amazon CloudFront 可以指定 query string 中的某個特定的 key/value 當做 cache key 的一部分了：「Announcing Query String Whitelisting for Amazon CloudFront」，對應的文件在「Configuring CloudFront to Cache Based on Query String Parameters」這邊可以查到。

先前只能針對選擇忽略掉整個 query string，或是把整個 query string 當作 cache key 的一部分，現在可以細部調整了。

最簡單的應用可以用在 css/js 的 asset 上，針對 v=\d+ 當作 cache key 的一部分，而其他的參數可以忽略，不過這好像沒什麼特別的意義。

目前想到比較有意義的應用是針對 dynamic content 多了一些籌碼可以用，像是 Slack 把整個網站放上 CloudFront 後，應該會有很多 API 是透過 query string 傳遞參數，而這次的改變讓 CloudFront 可以細部調整。

Linode 的被攻擊報告

Linode 這陣子一直被 DDoS 攻擊，前幾天放出報告：「The Twelve Days of Crisis – A Retrospective on Linode’s Holiday DDoS Attacks」。

其中這段提到了一些數字，Linode 有個小機房有 40Gbps 的能力，但以現在的 DDoS 規模會馬上爆掉：

Linode’s capacity management strategy for IP transit has been simple: when our peak daily utilization starts approaching 50% of our overall capacity, then it’s time to get more links.

This strategy is standard for carrier networks, but we now understand that it is inadequate for content networks like ours. To put some real numbers on this, our smaller datacenter networks have a total IP transit capacity of 40Gbps. This may seem like a lot of capacity to many of you, but in the context of an 80Gbps DDoS that can’t be blackholed, having only 20Gbps worth of headroom leaves us with crippling packet loss for the duration of the attack.

另外把 DNS 整個放上 CloudFlare 讓他們來擋：

Our nameservers are now protected by Cloudflare, and our websites are now protected by powerful commercial traffic scrubbing appliances.

後續的改善應該還要幾個月？完成後應該會再看到 blog post...

Mozilla 在 iOS 上也出了自己的 Content Blocker

Mozilla 在 iOS 上也出了自己的 Content Blocker，叫做 Focus by Firefox：「Announcing Focus by Firefox, a Content Blocker for iOS」：

Today we’re pleased to announce the launch of Focus by Firefox, a free content blocker for Safari users on iOS 9 that gives users greater control of their mobile Web experience.

沒搞懂 Mozilla 跑出來弄這個的目的...

把 HTTP 站台逐步換向 HTTPS 站台的步驟

Jerry Qu 寫的「关于启用 HTTPS 的一些经验分享」這篇文章講了要怎麼將 HTTP 站台逐步換成 HTTPS 站台的方式 (以及工具)。

一開始會遇到 Mixed Content，瀏覽器預設值不會直接全部擋掉，而是會放行圖片類資源 (但是出現對應的警告)。然後可以用 upgrade-insecure-requests 來幫助邊換，讓 url 裡指定 http 的自動連到 https。

當全站把 url 都修完後，接著就可以考慮用 HSTS 強制全上 HTTPS。

做到這邊的安全性已經到一定程度了，接下來要不要進 HSTS Preload List 就看大家自己的想法了。

CloudFlare 對 Brotli 的測試

之前有提過這件事情，由於 Firefox 已經支援 Brotli 了 (Google 推出 Brotli 無損壓縮法)，所以 CloudFlare 的人整理了目前的效能比較：「Results of experimenting with Brotli for dynamic web content」。

主要還是 Brotli 拿了不少資源來換壓縮率，對於 static content 由於可以事先算好而大勝不少 (大約可以再榨出 15% 的壓縮率，從 zlib 9 的 27.7% 降到 brotli 10 的 23.3%)：

The current state of Brotli gives us some mixed impressions. There is no yes/no answer to the question "Is Brotli better than gzip?". It definitely looks like a big win for static content compression, but on the web where the content is dynamic we also need to consider on-the-fly compression.

另外對於大檔案、網路速度不快的連線來說也頗有幫助，但對於 on-the-fly 的壓縮反而會比較慢。