作者：張傑生 / 臺灣大學計算機及資訊網路中心作業管理組
透過網路進行網購、網拍、賣買股票、基金或其它線上交易的網站安全嗎？攸關個人資料與財務金融相關的網路安全，設計人員該如何進行程式撰寫？這些都是相當值得探討的課題。必須提醒各位讀者的是，本文所敘述之各項範例，僅提供程式設計人員自我檢查並加以防範，切勿用在犯罪行為之上。
前言
隨著網際網路日漸普及，可以透過網路的服務也越來越多：從日常購物到銀行轉帳，甚至連違規罰單繳納也在服務之列。然而在使用這些便利服務的同時，卻不得不令人擔憂輸入的帳號密碼、信用卡號是否有可能遭到竊取，以及提供服務的網站的安全性是否值得信賴。身為網路服務提供者，如何提升網站安全性，保護使用者免於恐懼，乃是攸關服務提供者聲譽的首要任務。
根據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)及安全寫作建議】)