服務器除了以上提到的那些大名鼎鼎的漏洞和臭名昭著的攻擊以外,其實還有很多其他的漏洞,往往也很容易被忽視,在這個小節也稍微介紹幾種。
越權操作漏洞
如果你的系統是有登錄控制的,那就要格外小心了,因為很有可能你的系統越權操作漏洞,越權操作漏洞可以簡單的總結為 「A 用戶能看到或者操作 B 用戶的隱私內容」,如果你的系統中還有權限控制就更加需要小心了。所以每一個請求都需要做 userid 的判斷
以下是一段有漏洞的后端示意代碼:
1 |
// ctx 為請求的 context 上下文 |
以上代碼是任何人都可以查詢到任何用戶的消息,只要有 msg_id 就可以,這就是比較典型的越權漏洞,需要如下這么改進一下:
1 |
// ctx 為請求的 context 上下文 |
嗯,大概就是這個意思,如果有更嚴格的權限控制,那在每個請求中凡是涉及到數據庫的操作都需要先進行嚴格的驗證,並且在設計數據庫表的時候需要考慮進 userId 的賬號關聯以及權限關聯。
目錄遍歷漏洞
目錄遍歷漏洞指通過在 URL 或參數中構造 ../
,./
和類似的跨父目錄字符串的 ASCII 編碼、unicode 編碼等,完成目錄跳轉,讀取操作系統各個目錄下的敏感文件,也可以稱作「任意文件讀取漏洞」。
目錄遍歷漏洞原理:程序沒有充分過濾用戶輸入的 ../
之類的目錄跳轉符,導致用戶可以通過提交目錄跳轉來遍歷服務器上的任意文件。使用多個..
符號,不斷向上跳轉,最終停留在根 /
,通過絕對路徑去讀取任意文件。
目錄遍歷漏洞幾個示例和測試,一般構造 URL 然后使用瀏覽器直接訪問,或者使用 Web 漏洞掃描工具檢測,當然也可以自寫程序測試。
1 |
http://somehost.com/../../../../../../../../../etc/passwd |
防御 方法就是需要對 URL 或者參數進行 ../
,./
等字符的轉義過濾。
物理路徑泄漏
物理路徑泄露屬於低風險等級缺陷,它的危害一般被描述為「攻擊者可以利用此漏洞得到信息,來對系統進一步地攻擊」,通常都是系統報錯 500 的錯誤信息直接返回到頁面可見導致的漏洞。得到物理路徑有些時候它能給攻擊者帶來一些有用的信息,比如說:可以大致了解系統的文件目錄結構;可以看出系統所使用的第三方軟件;也說不定會得到一個合法的用戶名(因為很多人把自己的用戶名作為網站的目錄名)。
防止這種泄漏的方法就是做好后端程序的出錯處理,定制特殊的 500 報錯頁面。
源碼暴露漏洞
和物理路徑泄露類似,就是攻擊者可以通過請求直接獲取到你站點的后端源代碼,然后就可以對系統進一步研究攻擊。那么導致源代碼暴露的原因是什么呢?基本上就是發生在服務器配置上了,服務器可以設置哪些路徑的文件才可以被直接訪問的,這里給一個 koa 服務起的例子,正常的 koa 服務器可以通過 koa-static 中間件去指定靜態資源的目錄,好讓靜態資源可以通過路徑的路由訪問。比如你的系統源代碼目錄是這樣的:
1 |
|- project |
你想要將 static 的文件夾配成靜態資源目錄,你應該會在 server.js
做如下配置:
1 |
const Koa = require('koa'); |
但是如果配錯了靜態資源的目錄,可能就出大事了,比如:
1 |
// ... |
這樣所有的源代碼都可以通過路由訪問到了,所有的服務器都提供了靜態資源機制,所以在通過服務器配置靜態資源目錄和路徑的時候,一定要注意檢驗,不然很可能產生漏洞。
最后,希望 Web 開發者們能夠管理好自己的代碼隱私,注意代碼安全問題,比如不要將產品的含有敏感信息的代碼放到第三方外部站點或者暴露給外部用戶,尤其是前端代碼,私鑰類似的保密性的東西不要直接輸出在代碼里或者頁面中。也許還有很多值得注意的點,但是歸根結底還是綳住安全那根弦,對待每一行代碼都要多多推敲。