在 Mac 上快速換輸入法的方法:Kawa

三月的時候在「在 Mac 上快速切換輸入法」這邊提到了 IMEShortcuts,但有時候還是不會生效...

在「GitHub 中那些不错的免费软件」這篇裡面提到了 open source 的 utatti/kawa 這個專案,裡面有針對 CJKV 輸入法的 bug 提供 workaround,就給個機會測試看看:

There is a known bug in the TIS library of macOS that switching keyboard layouts doesn't work well when done programmatically, especially between complex input sources like CJKV.

而且最近變得可以用 Homebrew 管理了,這樣之後升級比較方便。

Linux 下 RAID1 的 SSD 會有讀取不平均問題

在「Unbalanced reads from SSDs in software RAID mirrors in Linux」這邊看到作者看 S.M.A.R.T. 數據時發現兩顆 SSD 硬碟組成的 RAID1 有很明顯的讀取不平均的問題:

242 Total_LBAs_Read [...] 16838224623
242 Total_LBAs_Read [...] 1698394290

原因是因為 Linux 對 RAID1 的 SSD 有不一樣的演算法:

The current state of RAID1 read balancing is kind of complex, but the important thing here in all kernels since 2012 is that if you have SSDs and at least one disk is idle, the first idle disk will be chosen.

2016 時演算法就更激進了,變成非 SSD 會:

In kernels with the late 2016 change, this widens to if at least one disk is idle, the first idle disk will be chosen, even if all mirrors are HDs.

加上 SSD 很快,這造成 loading 幾乎都在第一顆上... 這對 SSD 應該是還好啦 (理論上 SSD 的讀取不傷壽命),不過還是有點怪就是了。

打數學式子的工具

看到 Mathcha 這個網站,除了可以輸入 TeX 的公式外,也有 WYSIWYG 的方式輸入,而最後可以輸出成各種格式 (包括 TeX),或是直接丟連結給其他人:

輸入的部份,對於不知道的符號葉可以用畫的 XD

然後網站上的標示寫沒有支援 IE 與 Edge,不知道是真得不支援還是沒列上去而已... XD

iOS 透過無線網路的 RCE...

在「About the security content of iOS 10.3.1」這邊的說明:

Available for: iPhone 5 and later, iPad 4th generation and later, iPod touch 6th generation and later
Impact: An attacker within range may be able to execute arbitrary code on the Wi-Fi chip
Description: A stack buffer overflow was addressed through improved input validation.
CVE-2017-6975: Gal Beniamini of Google Project Zero

這描述看起來就不太妙...

利用隱藏的 form input 加上自動完成功能取得敏感資料

anttiviljami/browser-autofill-phishing 這邊示範了怎麼用隱藏的 form input 與自動完成功能取得敏感資料。在這邊可以看到示範 (把 POST 丟到 httpbin 上看 response)。

想法不算困難,但好像也不是很好防... 關掉 autofill 是比較簡單的解法 (我是裝好瀏覽器就會關掉,不過好像很多人都喜歡用這個功能),所以這個問題就丟回給這些 browser vendor 想了 :o

Google 推出 iOS 上的搜尋輸入法 Gboard

Google 推出了 iOS 上的搜尋輸入法 Gboard:「Meet Gboard: Search, GIFs, emojis & more. Right from your keyboard.」,可以在 App Store 上下載「Gboard — Search. GIFs. Emojis & more. Right from your keyboard.」,目前只有英文版可以用,其他語言還要等:

Get it now in the App Store in English in the U.S., with more languages to come.

可以參考 Google 做的 GIF 動畫,把搜尋的功能結合進去了:

John Gruber 寫了一篇「Gboard」關於隱私問題的討論,看起來還頗正面的。除了搜尋結果當然會需要傳到 Google 的系統裡以外,只有 crash log 會匿名傳回去。

關於 Non-null string 的處理...

上一篇「Filter Input & Escape Output...」有提到 Non-null UTF-8 string 的 filter,結果剛剛洗澡的時候想了想,好像寫錯了?

問題在於「到底是先 de-null 再 iconv(),還是先 iconv() 再 de-null」的問題。

這個問題其實跟 iconv() 成 UTF-8 時遇到不合法字元時怎麼實做有關,也就是 undefined behavior... 由於 \0 是合法的 UTF-8 character,所以我們假設某一種實做是當 iconv() 遇到不合法字元時會用 \0 帶進去:

先 de-null 再 iconv()

這是上一篇文章提到的方法。但在上面提到的 iconv() 實做下卻是有問題的方法。原因很簡單,de-null 後沒有 \0 的字串,卻會因為 iconv() 而產生 \0

先 iconv() 再 de-null

這邊要考慮的是最後 de-null 後會不會變成 invalid UTF-8 string。答案是不可能,因為 iconv() 轉出來後保證是 UTF-8 string (不論如何處理非 UTF-8 character 的部份),而 UTF-8 string 內的 \0 一定可以當 separator,所以切下去一定還是 UTF-8 string。(可以參考下圖關於 UTF-8 character 的規則)

所以?

可能以現在的 iconv() 實做來說,兩者都不會有問題,但寫程式的時候總是要避免 side-effect,所以後者的方法會比前者好。

Filter Input & Escape Output...

維基百科上有一篇「Secure input and output handling」說明要怎麼處理 input 與 output (對資安方面的說明)。標題的 Filter Input 與 Escape Output 是 Gasol 之前提到後才知道的名詞,以前只知道要 validate & escape,沒想過一個比較好記的念法...

這邊都以 PHP 為主,其他程式語言也應該會有對應的方式...

Input 有很多管道,有可能是使用者或是 3rd party 廠商透過 Form 傳進來的資料 (在 PHP 裡可能是 $_GET 或是 $_POST),也有可能是 cookie 的資料 (因為使用者可以修改,所以視為不安全的資料)。從檔案讀資料進來 (可能是普通的文字檔,或是 XML,也可能是圖片) 也算是 input。

Output 也有很多管道,像是 HTML、JSON,或是組 SQL statement 時使用變數。

Filter Input

在處理 input data 時,一般常常忘記的是「先強制轉成 Non-null UTF-8 string」(現在一般都是用 UTF-8,所以這邊就只講 UTF-8)。

這是因為很多 PHP function 對非 Non-null UTF-8 string 有非定義行為 (undefined behavior,不保證效果與輸出結果的正確性),加上一般常見的產品需求可以用 Non-null UTF-8 string 滿足,所以在 PHP 內拿到資料時可以先 filter 過。

Update:下面說的步驟錯了,請參考「關於 Non-null string 的處理...」這篇的說明。

有兩個步驟要做,第一個是確保他是 Non-null,直接把 \0 以及以後的東西幹掉:

$str_out = preg_replace('/\0.*/g', '', $str_in);
$str = preg_replace('/\0.*/g', '', $str); // 直接取代原來字串

第二個是確保他是 UTF-8 string。這點可以直接用 iconv() 轉,而不用自己寫 regex 處理了:

$str_out = iconv('UTF-8', 'UTF-8', $str_in);
$str = iconv('UTF-8', 'UTF-8', $str);

iconv() 從 UTF-8 轉到 UTF-8 是一個特別的用法,我是在 Cal Henderson 的「Building Scalable Web Sites: Building, Scaling, and Optimizing the Next Generation of Web Applications」上看到的 (有中譯版)。

如果傳進來的值本來就假設是整數,那麼就用 intval() 轉一次。如果假設是非負整數 (包含 0),那麼就用 abs()intval()。如果是文字類的 (像是 e-mail),可以再用其他的 regex 檢查。

一般來說,白名單會比黑名單好。不過這也是一般性,很多時候還是很囧的...

Escape Output

Escape 指的是 Escape character (轉義字元)。不同的情況下會有不同的 escape character,所以保護的方式也不一樣。

以 HTML 來說,想要顯示小於符號 <,實際上要用 &lt; 表示。而在 PHP 裡面常用的 htmlspecialchars() 定義了「只 escape 五個符號」,剛好可以拿來用:

<div><?= htmlspecialchars($str) ?></div>

也有人推薦 htmlentities(),不過因為轉的比較多 (所以要考慮的行為比較多),我比較不喜歡...

對於 XML,在 XML 的規範裡規定一定要把 <& 換成 &lt;&amp; (Character Data and Markup),但 > 則可以 (非必要) 換成 &gt;。也允許把雙引號 " 換成 &quot;,以及單引號 ' 換成 &apos;

所以 XML 剛好可以直接用 htmlspecialchars() (確認完全符合 spec 要求),反過來 htmlentities() 就不保證了。

再來是 MySQL 的 escape 與 charset 有關,所以要用 mysql_real_escape_string() 或是 PDO::quote(),但更好的方法應該是使用 prepare & execute (binding variables)...

而 shell 的 escape 則應該用 escapeshellarg() 再帶入 string 裡。

每一種 output 所需要的 escape function 不同,都不能直接拿 addslashes() 來用... (這個 function 的設計就很 PHP...)

純粹 JSON 的話,用 json_encode() 就可以幫你處理好。問題是在 HTML + JSON 時會讓你處理到抱頭痛哭... 這就是另外的故事了 +_+

結論?

Filter Input + Escape Output 只是最基本的一步,不過在大多數的狀況下,這個方法就可以擋下不少問題了,算是很實用的 policy...