2013年12月6日 星期五

你知道你的網站是怎麼被入侵的嗎?

你知道你的網站是怎麼被入侵的嗎?

一個網站的威脅可能來自伺服器作業系統、Web Server(Apache/Nginx)、程式語言(php/Java/.Net)、網頁應用程式。今天我們來談談看你的網站及網頁應用程式有可能有哪些弱點,了解被入侵的原因,以及如何防護你的網站?

如何防護你的網站

在WWW剛開始創立的時候,還沒有互動式網頁的年代,攻擊的方法集中在攻擊作業系統與網頁伺服器(Web Server),而目前之所以有這麼多漏洞的產生,就在於我們會需要與使用者互動,取得使用者的輸入,並將某些資料存入資料庫,在前端則會顯示各種處理過的資訊,不管是使用者自己輸入的,資料庫讀出的。只要這些資料處理與判斷後輸出的任何一個環節有漏洞或者沒有進行適當的過濾,就會造成預期外的結果,造成損失。

以下簡單列出目前最常出現的攻擊手法,最後以我們的經驗告訴大家如何設計系統來阻擋攻擊以及提高網頁應用程式的安全。

1.跨網站指令碼(Cross-site scripting,通常簡稱為XSS或跨站指令碼或跨站指令碼攻擊)XSS攻擊通常指的是透過利用網頁開發時留下的漏洞,透過巧妙的方法注入惡意指令代碼到網頁,使使用者載入並執行攻擊者惡意製造的網頁程式。這些惡意網頁程式通常是JavaScript,但實際上也可以包括Java、VBScript、 ActiveX、Flash 或者甚至是普通的HTML。攻擊成功後,攻擊者可能得到包括但不限於更高的許可權(如執行一些操作)、私密網頁內容、會話和cookie等各種內容。

2.CSRF(Cross-site request forgery跨站請求偽造,也被稱為“one click attack”或者session riding,通常縮寫為CSRF或者XSRF,是一種對網站的惡意利用。盡管聽起來像跨站腳本(XSS),但它與XSS非常不同,並且攻擊方幾乎相左。XSS利用站點內的信任用戶,而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比,CSRF攻擊往往不大流行(因此對其進行防範的資源也相當稀少)和難以防範,所以被認為比XSS更具危險性。

3.SQL隱碼攻擊(SQL injection,中國大陸稱作SQL注入攻擊,台灣稱作SQL資料隱碼攻擊),簡稱隱碼攻擊,是發生於應用程式之資料庫層的安全漏洞。簡而言之,是在輸入的字串之中夾帶SQL指令,在設計不良的程式當中忽略了檢查,那麼這些夾帶進去的指令就會被資料庫伺服器誤認為是正常的SQL指令而執行,因此遭到破壞。

4.session劫持 惡意的第三者透過某些方法取得使用者的session ID後,冒充使用者的身分進行各種行為。取得的手法可能為推測、竊取或是強制設定session ID。

5.重新導向攻擊 有些web應用程式會重新導向到外部指定的URL,透過攻擊更改重新導向的URL或是在參數中加入換行符號進行HTTP標頭注入,使得網頁重新導向到惡意的網頁。

舉例來說,上個月(2013年11月)發生的新加坡總理官網疑似被置換畫面,就是因為官網隱藏了漏洞,造成使用者如果透過Facebook或是Twitter裡面的特殊連結連到該官網後,就會執行惡意的語法,看到駭客更改過的網站畫面,導致使用者以為官網被駭客入侵,這就屬於XSS攻擊的一種。

了解了攻擊的手法後,我們要用甚麼方式來防禦呢?

首先我們要先知道資安強調的是縱深防禦,透過層層的關卡來達到更安全的防護。整個面對攻擊的最佳方法,就是如何正確的產生HTML,如何確保輸入輸出的資料都是符合我們規範的。一個好的網頁應用程式在開發前就要做好相關的安全設計,在資料的輸入處理輸出階段都要定義好相關的準則,系統也需要可以針對log去做各種紀錄與後續的處理。實際的執行可以從幾個面向來看:

1.從設計上開始進行防範
使用者身分確認 – 是否要加入簡訊或語音配判斷使用者身份?
密碼原則 – 密碼最短長度幾碼?大小寫或特殊符號限制?
雙因素驗證 – 除了帳號密碼驗證外是否搭配動態密碼(One-Time Password)?
帳號鎖定原則 – 帳號密碼輸入錯誤幾次要進行鎖定?
資料儲存保護 – 密碼儲存時是否有用MD5/SHA1加密?是否還要再加入額外的SALT值加強保護?是否有其他需要加密的資料?
變數與欄位的資料類型與大小 – 所有資料欄位的資料是否預先定義好是數值或是文字?所允許的最大值為多少?
網頁編碼 – 是否有固定網頁編碼?輸入輸出是否進行統一的編碼轉換?
黑名單/ 白名單 – 是否有黑白名單機制鎖定使用者或是IP使用?
cookie防護 – 是否有防止cookie被竊取的設定?是否設定Cookie為HttpOnly?
使用者存取記錄 – 如何紀錄使用者的正常或惡意行為?

2.從使用者的輸入進行防範
前端與後端均進行防護 – 前端網頁輸入是否先用JavaScript進行過濾?資料進入後端的應用程式是否有進行第二次的判斷防止駭客跳過前端頁面直接進行入侵?資料輸入是否搭配圖形驗證碼?
字元過濾 – text或是textarea是否過濾掉不正常的控制字元?
sql 多語句執行 – 是否有可能讓系統執行一段以上的sql語法?

3.從畫面輸出進行防範
HTML正確性 – 產生正確的HTML才能避免使用者受害,任何變數進行輸出時是否有經過再過濾與判斷?
JavaScript正確性 – 使用JavaScript編碼程式處裡輸出的變數?
CSS正確性 – 使用CSS編碼程式處裡輸出的變數?

4.監控資源與log
存取分析 – 系統能否自動反映大量連線或是資源異常被存取?重要資料被更改是否可以需要經過審核?
log篩選 – 是否針對使用者的存取行為進行過濾與篩選?發現可疑的行為如密碼嘗試甚至是執行惡意語法,是否有辦法立即反映處理?

結論:
如果我們可以針對上述的項目都進行有效的處理,相信已經可以過濾掉95%以上的攻擊了。所有的安全規劃與防禦都沒有辦法做到100%的安全,但透過一個有計畫有系統的防護行為,可以大大降低入侵事件的發生的機率和事件發生時造成的損失。這邊我針對最需要考慮的部分點出來給大家參考。

轉載自《匯智部落格》