要瀏覽器不要送出 Referrer 的 Referrer Policy

在讀「The No CAPTCHA problem」這篇的時候看到的:「Referrer Policy」。

<meta name="referrer" content="never">

目前正式版本的瀏覽器中,只有 Google Chrome 有支援,而其他瀏覽器正在開發,像是 Firefox 上個月才進 trunk:「Bug 704320 - Implement <meta name="referrer">」,預定在 36 版才會納入 (目前是 34)。

還蠻新的 HTML5 標準 (還在制定),可以來定期追進度...

CSP (Content Security Policy)

Twitter 上看到 Dan Kaminsky 的 retweet:

開頭的幾篇就列出不少 CSP 常見的情況,並且說明 CSP 應該要在軟體開發時就引入:

另外提到的 CSP Level 2 也是個很有趣的觀念,像是 nonce:

以及 hash:

不過 Level 2 目前還在 working draft:「Content Security Policy Level 2」,這個功能應該還要等...

用 Content-Security-Policy 攻擊

在「When Security Generates Insecurity」這篇文章裡,介紹了如何利用 Content-Security-Policy 攻擊網站。

首先,我想要知道是不是有登入 Facebook 或是 Google

Interest piqued by the report-uri feature, I looked into abusing it to glean information about user state, my idea was this: when a user is not logged into Google Calendar, accessing calendar.google.com redirects them to accounts.google.com via a Location header. If I whitelisted calendar.google.com but not accounts.google.com, accessing that resource within my web page would break CSP, subsequently sending me a message telling me whether they were logged into Google.

也就是說,利用 CSP 的 report-uri 以及重導的特性,可以分辨出使用者是否有登入。以 Facebook 以及 Google 的例子:

The implementation was like this: I had a single image on the page <img src="http://calendar.google.com"/>, and I sent the Content-Security-Policy header Content-Security-Policy: image-src calendar.google.com. The test was a success, I was able to detect login on Google. The same extended to Facebook; apps.facebook.com would redirect to www.facebook.com only if the user was logged in.

另外,由於實務上可以偵測 path,所以可以去「猜測」使用者是不是某個特定的人,在文章裡假設的是美國總統 Barack Obama:

By using CSP to whitelist facebook.com/me and facebook.com/barackobama and embedding http://facebook.com/me as an image, I can conditionally create a CSP report only if the current user on Facebook is not Barack Obama.

很有趣的安全性問題...

AWS ELB 加強安全性...

AWS ELB 加強對 SSL 安全性的功能:「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy),愈大多數的實做相同,是使用 ECDH

第二個是 Server Order Preference,由 server 這邊決定最終的 cipher。

最重要的是第三個,也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01,把上面兩個都設進去了。

這次的升級是對安全性的提昇...

加州理工學院對於學術研究的公開公告

引用加州理工學院的「Caltech Announces Open Access Policy」開頭:

On January 1, 2014, a new open-access policy for faculty's scholarly writings will take effect at the California Institute of Technology (Caltech). According to this policy, approved by the faculty at their June 10 meeting, all faculty members will automatically grant nonexclusive rights to the Institute to disseminate their scholarly papers, making wider distribution of their work possible and eliminating confusion about copyright when posting research results on Caltech's websites.

正式決議並公告,讓研究員 (包含教授與學生) 可以很自由的在自己的頁面上放自己的研究 (論文或是文章)。

愈來愈多學術單位往這類公開政策邁進...

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 為什麼要這樣設計的... =_=