談到要成為一名開發者需要知道哪些事?每個程式人的答案都不太一樣,單就書籍來說好了,你可能需要認識38項必修法則,或者是97件事,這當中可能包括了對語言、程式庫、工具、設計、錯誤處理、測試、維護等各方面的須知。

當然,每件事都很重要,不過,多半會忽略的一件事就是:安全!

安全何以被忽略?

或許不能怪開發者,畢竟要接觸、運用,仍至於熟練一項技術的相關設計或理論,花費的時間就已經十分巨大。

在開發的過程中,大家也是拼死拼活,就為了完成應用程式必要的功能,多半沒有時間還能夠兼顧安全。

況且,在學校或是在業界,無論是自學或透過教育訓練,多半也很少有安全相關主題,對客戶來說,在安全出包之前,這議題多半也不覺得有那麼重要(不知道或覺得不需要,甚至認為不會有人來攻擊這類小網站)。

另一方面,安全相關書籍與文件,相對於其他技術主題來說,也是少了許多,而且安全議題太過廣泛,開發者想基於目前能力與特定技術領域瞭解相關安全議題時,能找到的資料通常更是瑣碎而缺乏系統性。

就我個人經驗來說,最早接觸安全議題,是在2007年,為Sun訓練中心準備一門Java Web安全課程,然而,當時能同時在Java及Web這兩塊交集的安全文件或書籍很少,準備起來,著實是件難事。

當時與Web相關的安全議題,其實是有不少資料,像是著名的OWASP TOP 10計畫,這計畫2002年發起,針對Web應用程式最重大、嚴重的十大弱點進行排名,首次OWASP Top 10於2003發布,2004做了更新,之後每三年改版一次,目前最新版本為OWASP Top 10 2013。

當時談到OWASP Top 10,開發者多半還是有點概念,畢竟OWASP Top 10基本概念並不難,找個稍有經驗的開發者,多半也能就XSS、SQL Injection的原理說上幾句,問題重點是在搭配技術時的實際案例,開發者最想知道的往往不是概念,而是對於使用的這門技術來說,這些問題到底是怎麼發生的?許多書籍或文件在講述功能的同時,很少能提及相關安全概念,比方說在使用Rails的時候,最希望的是有份〈Ruby on Rails Security Guide〉這類文件存在。

不斷更新的攻擊手法

問題的重點在於,安全議題的概念有些雖然簡單或雷同,然而,攻擊手法卻往往隨著時間或使用的技術而不斷變化,SQL Injection不會一直是那個學校打電話給媽媽,問兒子的名字是否真的是「Robert');DROP TABLE Students;--」的笑話,Blind SQL Injection、Second-Order SQL Injection等,都是後來更進階的攻擊手法。

會發生Injection問題的也不只有SQL,以2013年暴發的Struts 2安全漏洞來看,就是個Expression Language Injection,這是OWASP在2013年4月15日創建的新弱點名詞,主因是Struts 2開發的應用程式在某些功能上,允許動態地執行特定運算式語言,像是Struts 2.3.15前的版本,因為可在請求參數附加action:、redirect:或redirectAction:,並提供一段OGNL運算式指定Java操作方法,而被拿來惡意運用。

新技術的運用與普及,也造成新的攻擊手法,以XSS為例,除了常見的Reflected XSS(First-order XSS)與Stored/PersistentXSS(Second-order XSS),由於使用JavaScript操作DOM產生高互動性相頁面,蔚為主流,因而衍生出DOM-based XSS,這類攻擊請求不用送至伺服端,而是在本地端瀏覽器執行JavaScript時,順勢執行了被注入的JavaScript程式碼。

Twitter在2010年時就發生過Stored XSS攻擊,使用者只要在發送的推文中含有鏈結,之後跟隨著@"onmouseover=與特定JavaScript,瀏覽推文的人,只要滑鼠掠過鏈結,就會自動發送推文,另一方面,Twitter上也有著DOM-based XSS的問題,中間還與Stefano Di Paola開發者來回溝通做了數次修正,這個有趣的過程,被記錄在〈A Twitter DomXss, a wrong fix and something more〉上頭。

缺少誤用方向的思考訓練

雖然,Stefano Di Paola並沒有對Twitter做出什麼壞事情,不過,Twitter與他溝通而來回修改DOM-based XSS的過程,也可以看成是個攻防的過程。這也反映出一個事實,身為一名開發者,當然是致力於寫出正確的功能,並有意識或無意識地認為,使用者也會以正確的方式使用應用程式,實際上,有意進行攻擊者,都是想方設法地令應用程式出錯(或說是產生開發者意料之外的行為)。

當每個弱點被爆出並造成大規模災害,並有人進行分析或公開手法之後,就會有一群人跳出來說:「怎麼會爆出這麼白痴的漏洞?」好像要是他們出來寫這功能的話,就不會有這個問題。

這感覺就有點像魔術一樣,講破了技巧,你才知道原來這麼簡單,真的是這樣嗎?問題就在於,在講破之前,你根本不知道破解的方向是什麼!

應用程式會被誤用的這類反向思考,也不是說有個概念就好了,就像寫出正確功能的軟體一樣,想知道如何誤用一個軟體,也是需要多加接觸與訓練。舉例來說,現在多數開發者都知道,密碼不要使用明文儲存(實際上還是遇到不少網站用明文),不過,就算對密碼用了雜湊演算而儲存,仍有可能因為演算強度不夠,得以使用彩虹表(Rainbow Table)來反推出密碼。

CSRF也是個常見的例子,知道攻擊原理之後,如果覺得自己不會寫出這種白痴漏洞,或者認為不要使用GET就好了,那就太天真了,透過JavaScript還是能發出POST等其他請求。

目前標準的防範做法之一,是採用Synchronizer Token,而有些Web框架會內建CSRF機制,像是Django或Rails,就是採用Synchronizer Token,不過,如果你的網站有XSS的問題,那麼Synchronizer Token也可能會被讀取。

這說明了安全問題就像鎖鏈一樣環環相扣,而會斷裂往往是發生在最弱的一環。

運用工具與安全指南

想要多做誤用方向的思考訓練,OWASP Top 10是個不錯的開始,它與Web開發者最為相關,現在資訊比我2007年接觸時又豐富許多了,更提供了各種技術的小抄(Cheat Sheet),可以從實例中瞭解攻擊模式,如果想要有些基本防護工具,OWASP Enterprise Security API提供了Java、Python、JavaScript等技術的安全API,可以下載使用。

當然,安全的議題太多了,開發者雖然平常可多瞭解以培養安全素養,不過真正要全面審視安全相關議題時,最好的方式是有份清單或指南,OWASP上提供了一份測試指南(Testing Guide),可作為全面審視安全議題時參考。

如果想瞭解更多安全問題,OWASP Top 10其中連結了不少CWE相關頁面,這是個著名的弱點資料庫,會將發現的弱點予以編號,另一個著名資料庫是CVE針對漏洞,例如去年著名的Heartbleed,就編號為CVE-2014-0160。

那麼,上頭談到的一些安全相關名詞,你看得懂幾個呢?如果有不懂的,就試著在網路上搜尋瞭解看看吧!

對平常就在重視安全的開發者而言,這些應該都只是基本安全需知而已。因此,下次又有人再問起,成為一名開發者需要知道哪些事時,可別又忘了要加上「安全」兩個字!

作者簡介


Advertisement

更多 iThome相關內容