網站程式安全寫作(三)─Secure
Programming for Web Applications
作者:張傑生 / 臺灣大學計算機及資訊網路中心作業管理組
(續…「網站程式安全寫作(二)--Secure
Programming for Web Applications」)
前言
隨著網際網路日漸普及,可以透過網路的服務也越來越多:從日常購物到銀行轉帳,甚至連違規罰單繳納也在服務之列。然而在使用這些便利服務的同時,卻不得不令人擔憂輸入的帳號密碼、信用卡號是否有可能遭到竊取,以及提供服務的網站的安全性是否值得信賴。身為網路服務提供者,如何提升網站安全性,保護使用者免於恐懼,乃是攸關服務提供者聲譽的首要任務。
根據SANS網站每年所公布的Top
Security Vulnerabilities統計[1],我們可以發現過去幾年所發生的資訊安全事件,許多都是肇因於作業系統(Windows、Linux)本身,或者是網站伺服器(如IIS)程式的安全漏洞,造成駭客有機可乘,進而入侵破壞。然而經過無數次的挑戰與磨練,大部分能夠存活下來的軟體,都已經具備相當程度的安全等級。再加上Firewall與IDP等硬體式防護設備的盛行,因此近幾年所發生的資訊安全事件,反而多是網站本身的程式設計缺失所造成。由此可見,決定了網站未來對於惡意攻擊的防禦能力,取決於發展者是否具有良好的安全程式寫作觀念與技巧。
---------------------------------------------------------------------------------------------
嚴格檢查所有使用者輸入資料(input validation)
幾乎90%以上的安全漏洞,包括SQL Injection與Cross Site
Scripting等,都是來自於惡意使用者的輸入資料。為了滿足Web應用程式的互動式需求,我們不可能因噎廢食,禁止使用者輸入任何資料。因此我們唯一能夠採取的應對機制,只有嚴格檢查所有使用者的輸入資料,避免任何不合法惡意碼乘隙而入。
最常發生SQL
Injection的頁面,通常位於使用者帳號密碼驗證或商品查詢功能,然而這也是最容易防堵的漏洞。一般來說,使用者的帳號、密碼,或者是商品的名稱,通常都會有合理長度限制,以及字元種類限制,舉例來說,帳號及商品名稱,通常不會出現A-Z、0-9以外的字元(當然中文的情況需另外處理)。因此,我們可以在伺服器端的程式碼,增加輸入欄位的長度檢查,一旦發現不合理的輸入資料,可以加以拒絕或者是僅接受部分長度。當然,更高規格的作法,需要利用regular
expression進行最嚴格檢查,例如規定輸入資料必須符合 [A-Za-z0-9]{3,20}
的格式,如此一來,僅接受大小寫英文字母及數字的組合,且長度需介於3至20字元數之間。根據經驗,SQL
Injection攻擊所需要的指令碼長度,通常遠超過合理輸入值,因此,只要完成上述長度與合法字元檢查,就可以阻決90%以上的SQL
Injection攻擊。
更嚴格的方式是利用程式語言內建的字串檢查函式,將所有可能成為SQL指令參數的字串,預先過濾檢查,以求萬無一失。以PHP為例,常用的函式包括:addslashes()、pg_escape_string()、mysql_escape_string()等。
然而,防禦難度較高的情況,通常是無法限制資料長度及字元種類的輸入,例如:個人資料、留言版等。在這種情況之下,只能利用regular
expression檢查並取代敏感的字元,例如: < > ‘ “ - 等。或者利用內建的函式,如PHP的htmlspecialchars(),將特殊字元轉換成HTML格式,例如:>變成>。甚至禁止使用者輸入網址連結、Java
Script、ASP或PHP等程式碼,藉以降低被植入惡意程式碼的機會。
另外,如果程式碼涉及open、write file的情況,則務必仔細檢查使用者輸入的path與filename,例如禁止 .. / \
等字元,以避免使用者惡意開啟或覆蓋不屬於授權範圍的檔案。
總結來說,網頁程式安全守則最重要的一條,就是絕對不可信任使用者的輸入資料,必須用放大鏡仔細檢視。而負責檢查的程式務必位於伺服器端,使用者端的javascript甚至程式碼裡面的FORM
INPUT MAXLENGTH都很容易被使用者取消或者跳過,因此僅能視為輔助工具。簡單整理,如果要攔阻SQL
Injection攻擊,則必須過濾SQL meta-characters,包括:’ – ; # 以及其hex code %27 %2D
%3B %23。因為現在許多惡意程式都知道要將字元改以hex方式呈現,藉以逃避程式檢查。如果我們忽略一併檢查相對應的hex
code,很容易功虧一簣。至於Cross Site Scripting的話,過濾 < > 以及其hex
code即可應付大部分的攻擊行為。
嚴格控管使用者上傳檔案
允許使用者上傳檔案,往往開啟一扇安全漏洞大門,尤其是遇到使用者惡意上傳可執行檔或者ASP、PHP程式碼時。正確的作法是,將上傳檔案集中存放於某幾個目錄之下,並且透過網站程式(IIS、apache)的限制,禁止該目錄以下的程式執行。如此即便使用者嘗試利用瀏覽http://test.ntu.edu.tw/path/malicious.php的方式執行上傳檔案,頂多也只能看到檔案內容,不至於啟動該程式碼。當然還有一個簡單的方法,可以達到90%以上安全程度。也就是將所有上傳檔案的副檔名自動加上某一字串,例如
.txt或 .haha,如此一來伺服器就不會將之視為ASP或PHP之script檔案,也不會嘗試interpret及執行,可以算是一種短期的simple
workaround。
額外的連線來源檢查
Cross Site Scripting的惡意應用之一,可以透過執行javascript,讀取cookie檔案,並將內容送至遠方網站儲存。未來有心人士則可利用該cookie冒充使用者身份,進行網站交易。為了阻止這類盜用事件,安全的網站程式,應該加入使用者來源IP
address檢查。正常情況下,使用者在同一段時間內所使用的IP address並不會改變,因此一旦發現有其他IP
address的連線嘗試以相同cookie存取網站,則很可能發生入侵行為。這時候網站程式應該當機立斷,將使用者logout,要求重新輸入帳號密碼,甚至直接拒絕連線一段時間。
除了IP address檢查之外,更進一步的保護措施,可藉由檢查網頁的Referer欄位達成。Referer欄位通常記錄著上一頁瀏覽網頁的連結。舉例來說,一個典型的學生資訊系統的瀏覽次序,應該是login.php
-> query-grade.php -> change-address.php -> logout.php。那麼當瀏覽query-grade.php時,Referer欄位記錄的就是login.php。因此,真正機密敏感的網頁程式,可以透過檢查Referer欄位的方式,確認使用者瀏覽的順序步驟,是依照程式開發人員制訂的流程進行。換句話說,使用者在查詢成績時,理論上應該先通過帳號密碼驗證網頁,因此query-grade.php程式就可以限制Referer必須為login.php。
經過嚴格的Referer檢查之後,惡意人士就不容易藉由竊取的cookie資訊,跳過login.php直接進行成績查詢,窺探隱私。順帶一提,目前各大貼圖網站所流行的「防盜連」功能,大多就是利用Referer檢查的方式做到。
避免將敏感資訊直接寫於程式碼
網路上有許多免費的程式碼檢測(Code
Review)工具,利用這些工具掃瞄網站程式碼後,通常可以得到許多程式修改建議。除了常見的宣告問題外,必定會被列為嚴重缺失的,就屬於將帳號密碼直接寫在程式碼內。一般程式設計人員,或許因為懶惰,或許因為習慣不良,不時都會發生類似狀況,其中又以資料庫連線的IP
address及帳號密碼最常出現。未來一旦發生程式碼洩漏,則原本應該隱身於幕後的資料庫主機資訊立即曝光,有心人士即可嘗試直接存取資料庫,進而竊取及竄改重要資料。程式碼洩漏的原因有很多,除了網站遭入侵之外,有些時候如果伺服器啟動debug功能,而使用者故意迫使程式不正常中斷,伺服器就會列印出相關程式碼資訊。還有一種經常被忽略的情況,現在許多編輯器會自動將檔案備份,並且命名為filename.bak,有經驗的使用者知道可以嘗試存取http://test.ntu.edu.tw/login.php.bak,如果檔案確實存在,伺服器會將檔案內容完整輸出,於是敏感的程式碼就一覽無遺。
正確的程式寫作習慣,應該將這類設定資訊(configuration)獨立存放於另外的設定檔,如果未來需要更改資料庫主機,僅需修改該設定檔即可,無須逐一修改其他程式碼,如此可以提升程式的可移植性(portability)。以網頁程式而言,該設定檔最好能夠放置於www的目錄之外(c:\interpub\wwwroot或
/usr/local/www/htdoc),如果不幸程式碼洩漏,即便設定檔位置曝光,也無法利用簡單的 http://test.ntu.edu.tw/path/config.file
呼叫方式取得。
實體區隔一般使用者與管理者的網頁
為了進行某些特殊功能,資訊系統通常都會額外設計一套管理介面。以學生成績系統為例,除了老師輸入、學生查詢的介面之外,勢必還需要一套更高權限的管理介面,以處理老師輸入錯誤,或者是設定助教帳號等功能。然而,
我們總是會發現許多網站,竟然就在公共網頁主選單的某一項,明目張膽地加入「管理者專用」的連結。雖然點選之後一定會跳到帳號密碼驗證的畫面,可是我們認為,這就是一種「引誘犯罪」的行為。只要能夠挑起別人的好奇心,利用程式進行暴力法(brute
force)破解密碼,成功之時指日可待。
有些比較有經驗的程式設計人員,會選擇隱藏管理介面的連結,避免讓人輕易得知。然而即便他們將管理介面隱身於其他子目錄,例如http://test.ntu.edu.tw/path2/admin.php,依舊很有可能遭到暴力法嘗試搜尋成功。更何況許多人習慣將目錄取名為admin、adm、internal、private這些早已well-known的pattern,恐怕只有他們自己相信安全無虞。
我們推薦的正確作法,應該要將一般使用者與管理者的網頁,放置於不同的實體機器,例如:http://test1.ntu.edu.tw/login.php與http://test2.ntu.edu.tw/path2/admin.php,此外兩者用來連結資料庫的帳號權限,也必須分別設定。可預見的好處包括,使用者猜破頭也找不到管理網頁的主機名稱、網址路徑,大幅降低網頁遭入侵的機會。即使一般使用者的網頁遭入侵,駭客也僅能取得低權限的資料庫帳號,例如只允許SELECT,危害程度有限。最後,如果系統要求的安全等級更高,我們可以在管理者網頁加上額外控管,例如帳號密碼認證,以及來源IP
address限制,如此一來,幾乎可說是滴水不漏、萬無一失。
正式上線系統取消「顯示debug訊息」功能
在程式開發期間,為了除錯需要,往往會啟動系統的debug功能。之後程式發生runtime
error時,系統就會自動將所有相關資訊列印在網頁上,以利後續問題追查。然而這些顯示的資訊,通常包含:程式碼錯誤原因、出錯程式碼行數以及程式碼片段,如果是資料庫問題,甚至會將資料庫錯誤回應訊息、主機位置、table名稱以及所執行的SQL指令通通顯示出來。由於資訊豐富,很容易遭到有心人士覬覦。
實務上來說,惡意使用者可以在網頁的各個輸入欄位,嘗試填入各種奇怪數值(例如年齡>200、採購數量為負值、參加人數不為正整數等)、各式特殊字元或者是超長字串,甚至發動DOS(Denial
of
Service)攻擊造成系統過載,期待因此造成程式碼parsing或execution錯誤,進而列印出寶貴的debug資訊。最後藉由拼湊資訊,找到系統弱點。舉例來說,一旦得知SQL指令的查詢方式,接下來就可以嘗試SQL
Injection的可能性。
為了保障資訊安全,正式上線的production系統,建議取消所有的debug訊息顯示功能,杜絕任何可能造成資訊洩漏的機會。然而更周延的設計方法,應該要善用作業系統本身所提供的事件記錄功能,例如:syslog(),將所有debug、warning、notice訊息,集中存放於系統的記錄區(/var/log),或者是傳送到remote的log
server,避免一般使用者存取系統記錄檔案。如此可以同時兼顧debug的方便性及系統之安全防護兩種考量。
4. 結語
在可預見的未來數年內,WWW絕對是繼續穩居Internet服務的主流地位。當所有網站服務都開始強調個人化的同時,也代表著更多的使用者個人資訊會被記錄下來。如何取信於使用者,讓他們得以安心輸入資料,進行線上購物等網路交易,決定了網站日後的成長性。因此,如何規劃、建置、維運一個安全的網站服務,不但是成功的關鍵因素,也是當務之急。本文嘗試提出一些網頁程式設計的安全寫作建議,希望能夠分享筆者多年程式開發經驗,幫助新進程式設計人員,提升程式品質,強化程式安全性,共同為Information
Security盡一份心力。
[1] SANS Top-20 2007 Security Risk,
http://www.sans.org/top20
[2] Firebug, http://www.getfirebug.com
[3] Fiddler HTTP Debugger,
http://www.fiddlertool.com/fiddler
[4] SQL Injection,
http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf
[5] Cross Site Scripting,
http://www.spidynamics.com/assets/documents/SPIcross-sitescripting.pdf
(全文完) |