Home » Posts tagged "content" (Page 3)

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.

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

Netflix 與 Comcast 的恩怨

其實就是商業公司之間的勾心鬥角,在包裝後搬到檯面上 :p

Netflix 在美國固網裡吃的流量比 YouTube 還多,可想而知當然就變成各 ISP 找麻煩的對象...


出自 Sandvine 的「Global Internet Phenomena Report 2H 2013」。

Netflix 有多種方式將影片傳遞給使用者。除了早期自建機房外,後來跟不少 CDN 有業務往來 (包括了 AkamaiLimelightLevel3),另外也有 Netflix Open Connect Content Delivery Network 計畫,直接在 ISP 內部機房放設備提供服務。

使用 CDN 的作法成本太高,而 ISP 又不一定會接受 Open Connect 方案 (因為不一定收的到錢),在這種情況下,如果走 transit 線路的速度通常都不會太好。而 Netflix 與 Comcast 之間的狀況就是如此:

在付給 Comcast 錢後速度都都解決了...

除了付錢解決外,上個禮拜 Netflix 就丟出一篇說明的文章發難了:「The Case Against ISP Tolls」,這篇文章除了提到上面的事情外,另外還極力反對 Comcast 與 Time Warner Cable 的併購案 XDDD

然後最近又炒熱的網路中立問題,看起來也這件案子應該會很熱鬧 XDDD

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 usingap_set_content_length」,不過因為 mod_fastcgi 一直沒出新的正式版,所以大家都還是拿到舊的版本。

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

Archives