security.txt

最近開始有人在討論「security.txt」這個標準了,可以在「A Method for Web Security Policies」這邊看到 draft。

想法其實類似於 robots.txt

# Our security address
Contact: security@example.com

# Our PGP key
Encryption: https://example.com/pgp-key.txt

# Our disclosure policy
Disclosure: Full

以往的方式是透過 WHOIS 或是 DNS 的 SOA 欄位來聯絡,或是直接寄到 security@domain,現在這個架構就多了一套方法,是好是壞不曉得...

利用上傳的檔案跳過 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 降低風險...

Mozilla 也在考慮對 Certificate Transparency 的掌握度

由於 Firefox 要支援 Certificate Transparency 的緣故,在「Mozilla CT Policy」這邊 Mozilla 在討論要建立自己的 CT policy 以及自己的架構:

CT is coming to Firefox. As part of that, Mozilla needs to have a set of CT policies surrounding how that will work. Like our root inclusion program, we intend to run our CT log inclusion program in an open and transparent fashion, such that the Internet community can see how it works and how decisions are made.

這樣就有個開頭了...

Mozilla 對 WoSign + StartCom 的正式處分

MozillaWoSign + StartCom 的不信任處分出爐了:「Distrusting New WoSign and StartCom Certificates」,最後處分的內容跟之前的討論差不多 (參考先前寫的「Mozilla 對於 WoSign + StartCom 根憑證的新發展:拔除」)。

Mozilla 台灣有放出中文版的說明 (差不多就是英文翻譯的版本):「取消對 WoSign 與 StartCom 新簽發憑證的信任」。

這次比較麻煩的地方在於要信任已經發出的 certificate,而且量太大無法窮舉。所以必須改增加程式碼處理,而這個方法無法對使用 Mozilla CA Certificate Store 的人生效 (因為這包套件只是一堆 pem 檔案,沒辦法放特殊的邏輯進去...)

另外現在 Firefox 是 49 版,要到 51 版才會生效,看起來還會花一陣子...

在 Google Chrome 連上因 HSTS 而無法連線的網站

Update (2018/03/15):字串改了,請參考「本來 Google Chrome 要繞過 HSTS 的 badidea 被換掉了...」。

像是把 StartCom 停用掉後造成 www.kernel.org 無法連線的問題:

前幾天在 Twitter 上看到解法:

說道 StartCom,StartCom 與 WoSign 的故事才剛要開始,前陣子在「Mozilla 在考慮移除 WoSign 的 CA Root」這邊提到的問題,最近 mailing list 上越來愈刺激了。(發現更多沒有通報的問題)

另外也發現 StartCom 被 WoSign (的 CEO) 買下來了,當初因為「Why I stopped using StartSSL (Hint: it involves a Chinese company)」而移除信任,看起來情況只會更糟糕...

強迫要求使用者改密碼反而會不安全?

在「Want Safer Passwords? Don't Change Them So Often」這邊在討論改目前 password policy 會有要求一定時間要改密碼造成的問題。原報導出自 美國聯邦貿易委員會 blog 上的「Time to rethink mandatory password changes」。

當你強制要求改密碼時,由於因為是被逼的,他們不會放太多心力:

Lorrie Cranor recently outlined, the weight of recent research agrees that when people are forced to change their passwords on the regular, they don’t put a whole lot of mental muscle behind it.

而在沒有準備的情況下產生出來的密碼將會是比較容易預測的:

Instead, Cranor notes, according to one UNC study, people “tended to create passwords that followed predictable patterns, called ‘transformations,’ such as incrementing a number, changing a letter to similar-looking symbol (for example changing an S to a $), adding or deleting a special character (for example, going from three exclamation points at the end of a password to two), or switching the order of digits or special characters (for example moving the numbers to the beginning instead of the end).”

另外你應該鼓勵使用者用 password manager 管理密碼,雖然不是完美的,但至少是目前比較合理的方案:

If for whatever reason you still can’t let go of making people change passwords as often as they turn the pages of their wall calendars, Cranor suggests that you at least encourage them to use a password manager, like LastPass or DashLane. They’re not perfect, but they can be a “very reasonable strategy” for coping, mostly because they don’t require people to balance unpredictable passwords with ones they can actually remember.

Mozilla 的人提出討論,把 Debian 上的 Iceweasel 改名回 Firefox

2006 年時因為 Mozilla 的人認為 Debian 改了太多東西 (以及其他原因),不應該使用 Mozilla Firefox 這個帶有商標的名稱,要求 Debian 改名 (事情的經過可以參考維基百科上的「Mozilla software rebranded by Debian」條目)。

而在九年後,最近 Mozilla 的人在 Debian 上開了一個 bug report,討論是否還需要維持 Iceweasel 這個名字:「#815006 - Renaming Iceweasel to Firefox」。

Debian 這邊的人也提出了很多不一樣的意見 (尤其是對 Mozilla 的商標使用規範),目前還在爭論...

PCI DSS 的更新:PCI DSS 3.1

PCI DSS 3.1 出了:「PCI COUNCIL PUBLISHES REVISION TO PCI DATA SECURITY STANDARD — PCI DSS 3.1 and supporting guidance helps organizations address vulnerabilities within SSL protocol that put payment data at risk; PA-DSS revision to follow —」(PDF)。

與 3.0 相比,修正了 SSL 與 TLS 的安全性問題。分成兩大塊討論,對於新的系統:

  • 禁止使用 SSL 與早期的 TLS (包括了 TLS 1.0 與 TLS 1.1 的某些設定)。

而對於舊的系統:

  • 在 2016 年 6 月 30 日後,禁止使用 SSL 與早期的 TLS。
  • 在這之前,不符合上述條件的設備必須修正到可以防禦已知的 SSL 與 TLS 問題。
  • 對於 POS (Point-of-sale) 與 POI (Point-of-interaction) 系統則是例外處理:確認可以防禦已知 SSL 與 TLS 問題的話,期限後仍然可以使用。

Google 的 Project Zero 修正 Policy

在之前受到批評後,GoogleProject Zero 修正了對應的 Policy:「Feedback and data-driven updates to Google’s disclosure policy」。

原先的 Policy 是 90 天強制公開,修正的 Policy 有幾個改善:

  • 如果揭露日是週末或是美國的假日,會順延到下一個工作日。
  • 如果原廠有告知需要更多時間修復,Project Zero 會延長 14 天的寬限期。
  • 在公開前會申請對應的 CVE 號碼。