Hacker News Daily 上看到的:「[TAS] Super Mario World "Executes Arbitrary Code" in 02:25.19 by Masterjun」。
沒想到這兩個名詞會同時出現... ~_~
幹壞事是進步最大的原動力
Hacker News Daily 上看到的:「[TAS] Super Mario World "Executes Arbitrary Code" in 02:25.19 by Masterjun」。
沒想到這兩個名詞會同時出現... ~_~
Bitcoin 的安全性是利用「當整個社群夠大時,不會有單一團體擁有超過 50% 的計算能力」的假設上發展演算法及防護機制:(參考「Weaknesses - Bitcoin」)
An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:
- Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
- Prevent some or all transactions from gaining any confirmations
- Prevent some or all other miners from mining any valid blocks
不過讓人噴飯的消息出來了,即使在 Bitcoin 這麼火熱的情況下,仍然有單一團體計算能力已經超過 50%:「Largest Bitcoin Mining Pool Pledges Not To Execute '51% Attack'」。
這應該是當設計時始料未及的... XD
在 RSA Security 收了 NSA 的錢,並且使用 NSA 所偏好的亂數演算法的事情被爆料出來後 (而且這個演算法已經被認為是 NSA 埋後門的演算法),一直有要求 RSA Security 解釋的聲音。但 RSA Security 卻完全沒有解釋。
想當然的,陸陸續續開始有人退出今年的 RSA Conference。一開始是 F-Secure 的 CRO (Chief Research Officer) 宣布退出:「An Open Letter to the Chiefs of EMC and RSA」,後來也有不少資安領域的專家退出 (可以參考 iThome 的文章):「資安專家群起抵制RSA安全會議」。
最新的消息是 OWASP 官方決定取消與 RSA Conference 的合作關係:「OWASP terminates marketing agreement with RSA Conference. Board member cancels class out of protest.」,不過 OWASP 正式的公告還沒出來。
OWASP 在 Web 安全性這個領域可是赫赫有名... 這下今年二月底的 RSA Conference 還會有多少人「跟進」呢... 會不會停辦?
我本來以為這張是搞笑:
出自 2010 年的「SQL Injection License Plate Hopes to Foil Euro Traffic Cameras」
不過我開始覺得在台灣是真的有機會...
Bruce Schneier 的說明:「I've Joined Co3 Systems」,以及 Co3 Systems 的公告:「Bruce Schneier Joins Co3 Systems as CTO」。
所以跑去 Co3 Systems 當 CTO 了... 把放假的時間算進去,速度真迅速 :p
有時候我們會因為效能問題,在 HTML 內嵌入 JSON object,而不是再多一個 HTTP request 取得。
但「嵌入」的行為如果沒有處理好,就產生非常多 XSS attack vector 可以玩。
首先最常犯的錯誤是使用錯誤的 escape function:
<!DOCTYPE HTML> <html> <body> <script> var a = "<?= addslashes($str) ?>"; </script> </body> </html>
這樣可以用 </script><script>alert(1);//
攻擊 $str
。因為 addslashes()
並不會過濾到這個字串,而產生這樣的 HTML:
<!DOCTYPE HTML> <html> <body> <script> var a = "</script><script>alert(1);//"; </script> </body> </html>
而這個字串會造成 DOM parser 解讀上產生不是我們預期的行為:
可以看到在字串裡面的 </script>
被拆開了。
這是因為瀏覽器會先拆解產生 DOM tree,再把 <script></script>
內的程式碼交給 JavaScript engine 處理。所以在一開始產生 DOM tree 的時候,是看不懂 JavaScript 程式邏輯的...
正確的方法是用 json_encode()
處理,因為 PHP 的 json_encode()
預設會把 /
(slash) 變成 \/
(這是 JSON spec 裡合法的轉換):
<!DOCTYPE HTML> <html> <body> <script> var a = <?= json_encode($str) ?>; </script> </body> </html>
這會產生出:
<!DOCTYPE HTML> <html> <body> <script> var a = "<\/script><script>alert(1);//"; </script> </body> </html>
但上面這段 HTML 與 PHP code 仍然有問題,如果 $str
是 <!--<script
時,你會發現 DOM 又爛掉了:
<!DOCTYPE HTML> <html> <body> <script> var a = "<!--<script>"; </script> </body> </html>
而 escape.alf.nu 的 Level 15 就是利用這個問題,再加上其他的漏洞而完成 XSS 攻擊。
為了這個問題去 StackOverflow 上問:「Why does <!--<script> cause a DOM tree break on the browser?」,才又發現上面這段 code 並不是合法的 HTML5 (先不管 head & title 的部份,補上後仍然不是合法的 HTML5)。
原因在於 DOM parser 對 <script></script>
的特殊處理:「4.3.1.2 Restrictions for contents of script elements」。(話說這段 ABNF 差點讓我翻桌...)
解法是在 <script></script>
的開頭與結尾加上 HTML 註解:(這剛好是 HTML 4.01 建議的方法)
<!DOCTYPE HTML> <html> <body> <script> <!-- var a = "<!--<script>"; --> </script> </body> </html>
那段 ABNF 的目的是希望可以盡可能往後找到 -->
與 </script>
結尾的地方。
當然你也可以用 json_encode()
的 JSON_HEX_TAG
把 <
與 >
硬轉成 \u003c
與 \u003e
避開這個問題,但這使得呼叫 json_encode()
時要多一個參數 (而非預設參數),用起來比較卡...
這個問題會變得這麼討厭,是因為 DOM parser 與 JavaScript 語法之間有各自的處理方式,然後又有些 pattern 是之前的 spec 遺留下來的包袱 (像是 HTML 4.01 在「18.3.2 Hiding script data from user agents」裡有提到用 <!--
與 -->
包裝 <script></script>
),變成在設計 HTML5 時都要考慮進去相容...
之前會習慣用 <!--
與 //-->
包裝 <script></script>
倒不是這個原因,而是因為不這樣做的話,jQuery 在 IE 使用 html()
時遇到有 <script></script>
的字串會爛掉,所以後來寫的時候變成習慣了...
反而因為這個習慣而避開了這個問題...
超難搞啊...
GitHub 在 2013 年底的公告:「Introducing Forward Secrecy and Authenticated Encryption Ciphers」。
愈來愈多服務升級 & 調整 SSL (HTTPS) 的設定,支援 PFS (Perfect Forward Secrecy) 與 AE (Authenticated Encryption)。
PFS 要預防的事情我可以理解,但對 AE 的必要性不熟啊... 再去看看整個理論基礎與目的好了...
Twitter 上看到 gugod 的 retweet:「Identifiable Images of Bystanders Extracted from Corneal Reflections」。
#PLOSONE: Identifiable Images of Bystanders Extracted from Corneal Reflections http://t.co/CJOiQ1klAS pic.twitter.com/ZT45t1SUqN
— SebMln (@SebMln) December 29, 2013
因為硬體的進步,所以總算有辦法硬拉出來?
嗯,這張照片是可辨識的 XDDD
在 Orange 的 Facebook 上看到的,翻了一下國外的新聞,好像還沒被廣泛報導:「Openssl.org 被改首頁,只維持了幾分鐘XDDD」。
這超精彩的... OpenSSL 耶 XDDD
這陣子國外在放假,反應時間應該會比較慢,過幾天應該陸陸續續可以看到「解說」...
上一篇「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
帶進去:
這是上一篇文章提到的方法。但在上面提到的 iconv()
實做下卻是有問題的方法。原因很簡單,de-null 後沒有 \0
的字串,卻會因為 iconv()
而產生 \0
。
這邊要考慮的是最後 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,所以後者的方法會比前者好。