跳到主要內容區塊

計資中心電子報C&INC E-paper

技術論壇

網站程式安全寫作一(Secure Programming for Web Applications)
  • 卷期:v0003
  • 出版日期:2007-12-20

作者:張傑生 / 臺灣大學計算機及資訊網路中心作業管理組


透過網路進行網購、網拍、賣買股票、基金或其它線上交易的網站安全嗎?攸關個人資料與財務金融相關的網路安全,設計人員該如何進行程式撰寫?這些都是相當值得探討的課題。必須提醒各位讀者的是,本文所敘述之各項範例,僅提供程式設計人員自我檢查並加以防範,切勿用在犯罪行為之上。

 

前言

隨著網際網路日漸普及,可以透過網路的服務也越來越多:從日常購物到銀行轉帳,甚至連違規罰單繳納也在服務之列。然而在使用這些便利服務的同時,卻不得不令人擔憂輸入的帳號密碼、信用卡號是否有可能遭到竊取,以及提供服務的網站的安全性是否值得信賴。身為網路服務提供者,如何提升網站安全性,保護使用者免於恐懼,乃是攸關服務提供者聲譽的首要任務。

 

根據SANS網站每年所公布的Top Security Vulnerabilities統計[1],我們可以發現過去幾年所發生的資訊安全事件,許多都是肇因於作業系統(Windows、Linux)本身,或者是網站伺服器(如IIS)程式的安全漏洞,造成駭客有機可乘,進而入侵破壞。然而經過無數次的挑戰與磨練,大部分能夠存活下來的軟體,都已經具備相當程度的安全等級。再加上Firewall與IDP等硬體式防護設備的盛行,因此近幾年所發生的資訊安全事件,反而多是網站本身的程式設計缺失所造成。由此可見,決定了網站未來對於惡意攻擊的防禦能力,取決於發展者是否具有良好的安全程式寫作觀念與技巧。

常見程式漏洞

以下我們將介紹幾種常見的網站程式安全漏洞:

 

(一)危險的參數傳遞方式

由於HTTP protocol先天設計的限制,所有的連線都視為彼此獨立,這也被稱為所謂stateless的特性。因此當頁面與頁面之間需要傳遞資料時,方法之一就是利用FORM裡面的INPUT欄位。如果遇到一位新手程式設計師,利用GET方式傳遞參數,撰寫一套學生資料管理系統,那麼可能會發生以下狀況:

    登入網頁: http://test.ntu.edu.tw/login.php

    詢問帳號密碼,通過認證後,列出系統功能列表。

    1. 加退選:   http://test.ntu.edu.tw/course.php?id=b96123456

    2. 成績查詢: http://test.ntu.edu.tw/query.php?id=b96123456

    3. 地址修改: http://test.ntu.edu.tw/address.php?id=b96123456

 

於是聰明而又好奇的學生,馬上就會開始更改網址,查詢全班同學的成績。只要系統沒有針對使用者權限更進一步檢查,很容易就讓這種伎倆得逞。事實上,過去許多購物網站,也常犯此種錯誤,只要你猜得到別人的帳號,也可以用類似技巧,翻閱他的購物清單,滿足偷窺樂趣。

 

即使是有幾年工作經驗的工程師,也可能誤以為只要將參數傳遞的方式,由GET改為POST,即可解決此類問題。然而實情卻是,只要使用者安裝了Firebug[2]或是Fiddler[3]這類Debugging Tool,所有的參數傳遞全都一覽無遺,甚至使用者還可即時恣意修改參數內容。因此,只要程式端沒有做好應有的權限檢查,這種情況根本無法徹底解決。

 

(二)檔案上傳功能所衍生的諸多漏洞

為了提供網路硬碟、相簿或者是檔案分享、交換等功能,許多網站提供使用者上傳檔案的功能。然而這種功能通常就是另一個災難的開始。以上傳來說,如果網站沒有特別指定專門存放暫存檔案的區域,那麼很有可能造成使用者有意或無意覆蓋掉既有檔案,或是其他使用者的檔案。例如當大家都同時上傳homework.doc時,就很可能發生這種情況。更糟的情形是,如果系統以較高權限的帳號執行網站程式,而上傳的功能又沒有做檢查或限制,一旦使用者上傳設定檔或或密碼檔覆蓋原有檔案,將會造成系統停擺外或更嚴重安全漏洞。

 

除此之外,如果系統提供使用者瀏覽既有檔案的功能,又沒有做好權限控管與輸入參數檢查,就可以藉由參數置換方式,取得別人的資料,例如http://test.ntu.edu.tw/viewfile.php?filename=homework.doc

 

從以往的經驗來講,老師助教為了批改方便,通常會要求學生上傳檔案時,必須依照固定格式編碼,例如:hw1-b96123456.doc。於是乎,機靈的同學就知道該如何取得別人的作業了,如果指定的是設定檔或是密碼檔的時候,那就更嚴重了。一般正常系統對於檔案存取權限的設定,會嚴格拒絕非擁有者修改,然而卻會允許其他使用者閱讀。因此上述技巧,很有可能讓有心使用者輕易參觀系統內的所有檔案。值得一提的是,通常網站目錄下所有檔案的擁有者,會設定成跟網站程式執行者相同,否則至少允許網站程式執行者讀取,以利程式檔及設定檔之讀取或線上修改。如此一來,寶貴的程式碼,甚至設定檔內儲存的資料庫帳號密碼,都有可能因此遭竊。

 

此外還有一種更為嚴重的情況:如果使用者上傳網頁程式檔,而系統卻讓這個檔案具有在伺服器的執行權限。那麼至此我們可以做出結論,該網站已經徹底淪陷,未來使用者可以予取予求,毫不受限。假設先前使用者已經上傳過homework.doc,並且透過猜測與觀察,得知網站都會把上傳檔案放在某一目錄,那麼我們可以試著嘗試瀏覽以下網址http://test.ntu.edu.tw/path/homework.doc,如果瀏覽器可以成功顯示該檔案內容,那麼接下來如法炮製,上傳file.php,確認瀏覽器依舊可以顯示執行結果。其後file.php的內容就可以天馬行空發揮,揮灑空間無限寬廣。提示:phpinfio(),passthru(),system()。

 

(三)SQL Injection

近來當紅的網站攻擊手法莫過於SQL Injection[4],除了許多網站都潛藏此種缺陷,易於遭受入侵破壞之外,更因為這些案例往往伴隨機密資料外洩,以及並造成影響網站未來營運的嚴重後果。

 

網站為了提供會員註冊、討論區、電子商務等雙向互動功能,通常將資料儲存於資料庫,資料庫也因此成為各方駭客關注的焦點。SQL Injection通常是利用網站程式疏於檢查的弱點,嘗試輸入資料庫控制字元(meta-characters),藉以跳過網站原本設計的檢查,進而盜取、修改資料庫內容,入侵資料庫系統。舉例來說,一般網站為了提供使用者個人化設定,大都會要求使用者以帳號密碼登入。如前面所言,這些資料一般會儲存於資料庫,在使用者輸入帳號密碼後,然後用以下的程式組成SQL 命令做確認

SELECT * FROM users WHERE username=’$_POST[username]’ AND password=’$_POST[password]’;

 

在這個例子中,使用者輸入的資料 $_POST[username] 被原封不動地採用。如果有人惡意地在帳號的欄位輸入’OR 1=1 –-,那麼SQL指令會變成
SELECT * FROM users WHERE username=’’ OR 1=1–- AND password=’’;

 

由於–-之後的字串被視為註解不會執行,也因此上述指令等同於:
SELECT * FROM users WHERE username=’’ OR 1=1;
OR 1=1會造成WHERE的右半邊條件永遠成立,所以等同於
SELECT * FROM users;

 

跳過帳號密碼檢查的身份認證畫面,只是入侵行為的開端。接下來可以利用trail and error的方式,嘗試於網頁各個FORM輸入奇怪的數字、數值與文字,想辦法讓程式發生錯誤,進而顯示包含詳細錯誤訊息的debug畫面。透過這些寶貴資訊,可以讓駭客拼湊出資料庫table schema,瞭解每個欄位名稱屬性。最後,仿照上述的攻擊方法,將帳號欄位的輸入字串改為:

‘; INSERT INTO account(username,quota) VALUES(‘john’,’1000’);
‘; UPDATE product SET price=’100’WHERE id=’5001’;

 

即可恣意新增、修改資料庫內容,獲取不法利益。如果資料庫的權限設定鬆散,甚至可能允許更嚴重的破壞行為,例如:

‘; DROP TABLE users;
‘; DROP DATABASE web;
‘; SHUTDOWN;

 

從以往的案例來看,最嚴重的情況是,網站程式師貪圖方便,以管理者帳號sa進行資料庫連線,而資料庫端(MS SQL)採用預設安裝,並沒有特別做任何限制。於是惡意駭客就可以透過SQL Injection方式,呼叫資料庫的延伸預存程序(extended stored procedures),以系統管理者身份,在資料庫主機執行程式,最常見的procedure即為xp_cmdshell。透過以下程式碼,可以輕易在資料庫伺服器新增一組badguy帳號,並允許其透過遠端連線,登入主機。

' ; EXEC MASTER..XP_CMDSHELL 'net user badguy /add'
EXEC MASTER..SP_GRANTLOGIN 'MSSQL\badguy'
EXEC MASTER..SP_ADDSRVROLEMEMBER 'MSSQL\badguy','sysadmin'--

 

儲存企業營運資料的資料庫可說是企業命脈之所繫,SQL Injection帶來的威脅實非等閒,必須謹慎正視之。

 

(下期將介紹【網站程式安全寫作(二)─Cross Site Scripting(XSS)及安全寫作建議】)