小朱® 的技術隨手寫

網路上有些文章會教學員在安裝完 SQL Server 後，一併打開 TCP Port 1433，但若主機有對 Internet，且系統和 SQL Server 同一台，這反而是個很危險的行為。

在標題上連續寫三次，實在是因為太多人把雜湊當加密看待，不只是錯得離譜，還有可能會害到客戶。

資訊安全雖然產業界喊了很久了，網路上也有很多安全防護的資訊，但是為什麼還是有一堆常見的漏洞被發現？那就不是缺乏知識，而是個人習慣問題。

這是今天有位朋友在 MSN 上問的一個問題，因為我也是第一次看到這個名詞，所以我也上網查了一下，在 Arshan Dabirsiaghi 於 2008 年所發表的 "Bypassing Web Authentication and Authorization with HTTP Verb Tampering" 論文中提到這樣的弱點，但早在 2004 年 Kernelpanik Lab 就已經有研究報告提出這個弱點，主要的原因是在 Web Server 或 Web Application 或 HTTP Endpoint 中，沒有針對 HTTP 動詞 (verb) 去做存取控制所致。

在前一篇文章中，我簡單的說明了 DACL 的資料結構組成，以及簡單的存取方法，如果資料長度愈長的話，可以設定的權限就愈多，也可以有更多的組合，但資料量仍然可以控制在很小的長度，這是因為在 DACL 中，每個權限都是一個旗標值 (flag)，而一個 bit 就代表一個旗標，所以 bit 多的話旗標就愈多，一個 byte 可以容納 8 個 bits，也就是可以有 8 種旗標，之所以會選擇位元來作為旗標，是因為 bit 的值不是 0 就是 1，單純有力。

OAuth 的服務實作 ... 動念中。

在前一篇文章中，已經大略的介紹過 OAuth 所使用到的各類參數，這些參數的產生與使用將會決定 OAuth 的程序是否順暢，因為在每次針對服務的 private API 呼叫，都會用到 OAuth 的認證標頭訊息，所以怎麼樣產生正確的訊息就是用戶端程式最重要的課題。

OAuth，一個讓人又愛又恨的驗證協定，它讓許多主流的社群網站與網路服務打開了封閉已久的驗證大門，它也是在網路上公開個人或私人資訊 (private data) 前最主要的驗證管道之一，重要的是，在這個協定下，所有公開給外界的私密資料會受到兩個階段的保護，OAuth 保障使用者可以在應用程式要求資料前由使用者做明確授權，只有授權過的資源才會開放給應用程式存取用，而且 OAuth 公開的特性，可以讓應用程式在極少量程式碼的變更下，移植到不同的服務繼續使用，而 OAuth 協定也讓服務端精確的控制要開放的服務，並且提供使用者授權的管道以讓使用者能自由控制授權與否，而且用戶端應用程式只要利用 HTTP 協定即可使抈 OAuth 服務。