HTTP Header 裡與安全相關的 Header 的分析...

還是在 Zite 上看到的,對最大的一百萬個網站分析與安全有關的 HTTP Header:「Security Headers on the Top 1,000,000 Websites: November 2013 Report」。

數字大致上都有增加,不過對我來說的重點在於有列出所有與安全有關的 HTTP Header...

可以看到有這幾個:

  • Access-Control
  • Content-Security-Policy
  • Strict-Transport-Security
  • X-Content-Security-Policy
  • X-Frame-Options
  • X-Webkit-CSP

剛好可以拿來 review 設定...

Amazon CloudFront 上 Protected Content 的 URL Sign...

Amazon CloudFront 也可以設定要簽名才能抓檔案,只是 URL Sign 設計的觀念跟 Amazon S3 完全不一樣,這不一致的調調很... 詭異...

大致上有這些差異:

  • Amazon S3 用的是 HMAC-SHA1 的機制簽名 (shared secret,也就是 Amazon S3 與你都有同一把 key),而 Amazon CloudFront 則是用 RSA key 簽名 (public key,也就是 Amazon CloudFront 存放 public key,你自己存放 private key)。
  • 也因為是使用 RSA key,有人會誤解跟 Amazon EC2 用的 RSA key 相同。但實際上需要在 Security Credentials 頁裡設,有專門對 Amazon CloudFront 用的 RSA key 的段落。
  • 自己對 Base64 編碼再處理,避開使用 += 以及 /。但不是有標準可以用嗎,為什麼要自己發明呢...
  • 引入 Policy 的彈性機制,不僅可以對時間控制,也可以對 IP address 控制,但 Policy 這是帶在 URL 裡傳進去的... 你可以看到我的程式碼內產生出 $json_str 後簽完名帶到 URL 內了。

官方的 CloudFront Signed URLs in PHP 這篇的範例程式碼其實很清楚了,要直接拿去用其實也沒麼問題。我自己整理後是這樣:

<?php

$key_pair_id = 'APKA...';
$pem_file = '';
$resource = 'http://test2-cdn.gslin.org/test.txt';

$expires = time() + 3600;

$json_str = json_encode(
    array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array(
                        'AWS:EpochTime' => $expires
                    )
                )
            )
        )
    ),
    JSON_UNESCAPED_SLASHES
);

$buf = file_get_contents($pem_file);
$key = openssl_get_privatekey($buf);

openssl_sign($json_str, $signed_policy, $key, OPENSSL_ALGO_SHA1);

openssl_free_key($key);

$signature = str_replace(
    array('+', '=', '/'),
    array('-', '_', '~'),
    base64_encode($signed_policy)
);

echo "${resource}?",
    "Expires=${expires}&",
    "Signature=${signature}&",
    "Key-Pair-Id=${key_pair_id}\n";

反正你搞不太懂 Amazon 為什麼要這樣設計的... =_=

Amazon S3 上 Protected Content 的 URL Sign...

Amazon S3 可以在上傳時設定為 non-public,這種檔案如果要讓使用者讀取,就必須透過 URL 簽名的方式...

官方的文件是「Authenticating REST Requests」這篇,不過官方文件把所有細節都寫上去,如果第一次接觸的人反而不知道要怎麼辦...

Thomas Riboulet 給了一個 Quickstart 的範例:「Signing Amazon S3 URLs」,裡面雖然是 Ruby code,不過 code 的邏輯很簡單...

以 test.gslin.org 為例,想要產生出從現在開始 3600 秒內有效的 url 可以這樣寫,用過一次後再回去看官方文件,就會發現其實就是官方文件的「REST Authentication Example 3: Query String Authentication Example」這段,如果以 PHP 寫會長這樣:

<?php

$access_key = "";
$secret_key = "";

$timestamp = time() + 3600;
$data = "GET\n\n\n${timestamp}\n/test.gslin.org/test.txt";

$sign = urlencode(
    base64_encode(
        hash_hmac('sha1', $data, $secret_key, true)
    )
);

echo "http://test.gslin.org.s3.amazonaws.com/test.txt?" .
    "AWSAccessKeyId=${access_key}&" .
    "Expires=${timestamp}&" .
    "Signature=${sign}\n";

接下來來研究 CloudFront 的部份...

同時用 mod_deflate 與 mod_fastcgi 所產生的問題...

今天花了不少時間找到的問題...

問題是使用 mod_fastcgi 以及 mod_deflate 時,Content-Encoding 會是 gzip,但 Content-Length 會是未壓縮的長度。

也就是說,伺服器端在 header 提供的 Content-Length 可能寫 8KB,但實際上只丟出 2KB (壓縮後的大小),於是瀏覽器讀完這 2KB 後會停下來一直等,等到 Keep-Alive timeout 斷線 (在我機器上預設是 5 秒)。

在 timeout 斷線後 browser 會就抓到的資料直接解開執行 (因為這 2KB 都有抓到,於是都正確執行)。如果用瀏覽器這邊的 debugger 觀察,就會發現從 first byte 後 5.00 秒才 document ready。

解法有人在 2008 年給過:「Content-Length header should be set using ap_set_content_length」,不過因為 mod_fastcgi 一直沒出新的正式版,所以大家都還是拿到舊的版本。

所以,與之前修正 multi-threading 的問題一樣,往 ports 本身丟 patch:「Update www/mod_fastcgi to fix mod_deflate issue.」,修正後再測試就正常了。

Google 調整參數處罰 Content Farm 的進度

Slashdot 上有人提到 Google 最近調整的情況,繼續調降 low-quality site (這次是 eHow) 在搜尋的排名:「Google Tweaks Algorithm; EHow Traffic Plummets」。

最近用中文版的 search 發現愈來愈找不到想要的東西了,把語系切到英文版試一陣子看看...