Web 2.0概念盛行之後,由於強調使用者為中心,連帶地,互動性也受到重視,因此JavaScript前所未有地大規模應用在網站上,許多動畫特效、互動介面都採用JavaScript開發。

但是質疑JavaScript的安全性問題一直不絕於耳,尤其是XSS(Cross Site Scripting)的攻擊手法,更是讓許多人對JavaScript產生不信任感,造成有些網站平臺禁止使用JavaScript,也形成網站開發人員為了究竟該不該用JavaScript而感到困擾。

了解JavaScript安全設計,是降低風險的第一步
其實JavaScript在設計之初,便是以「沙箱」(sandbox)的概念來保護用戶端電腦,讓程式的活動範圍只局限在瀏覽器的範圍中。

例如JavaScript沒有設計「檔案物件」,因此它無法讀寫、刪除用戶端的檔案。另外像是JavaScript也無法指定值給HTML的檔案上傳語法,以避免任意修改檔名,造成無法預期的檔案上傳到伺服器端。

另外一個重要的設計是同源法則(Same-Origin Policy),它限制JavaScript只能存取、操作同一網域名稱的文件。

如此看來,JavaScript應該是相當安全才是,那些甚囂塵上的風險警告又是從何而來?

風險的來源之一,是因為瀏覽器的本身的問題,像是IE的ActiveX控制項以及其他覽器內的外掛程式,都提供了JavaScript有機會獲得本身所沒有的能力,進一步增加了用戶端系統的攻擊面。這個部分必須仰賴使用者更新瀏覽器的安全漏洞來防止。

另一個風險來源,就是利用JavaScript的呼叫遠端腳本程式功能,可藉機注入惡意程式。這是撰寫JavaScript必須特別注意的地方。

拒絕XSS攻擊的前提:需要謹慎過濾傳輸內容
應用JavaScript時,最需注意之處就是過濾來自用戶端或伺服器端的內容。舉例來說,eval函式是JavaScript將文字字串轉換成物件的程式,如果沒有檢查輸入字串,一旦eval執行到惡意語法,就可能對其他使用者造成攻擊行為。

而Ajax應用常見的JSON格式,也需要透過eval讓伺服器傳回的字串轉換成JavaScript的物件,雖然它來自伺服器端,但也難保不會有問題。

即使只是一般的文字上傳行為,例如留言板,使用者也可能藉機上傳帶有JavaScript的字串,載入其他網站的惡意程式,由於是在同一網站呼叫,沒有違背同源法則,因此就有機會發動XSS攻擊手法。像這種情況,便是要過濾使用者上傳的字串,剔除具有風險的標籤、語法。

Cookie也是必須特別注意的一環,由於HTTP是一種無狀態的通訊協定,因此會透過Cookie來記錄個人資訊,方便使用者下次瀏覽網站。由於JavaScript也能存取Cookie,如果Cookie中藏有像密碼或金融資訊,這時網站又有第三方惡意的JavaScript,那麼無異將機密資訊拱手讓人。因此解決之道便是別用Cookie儲存敏感資訊,必要透過伺服器端的程式,採用Seesion傳遞資訊將更安全。文⊙黃天賜

iThome歡迎讀者提問,請將你所遇到的各種企業IT疑難雜症,寄至iThome編輯部:QA@mail.ithome.com.tw


熱門新聞

Advertisement