程式人常忽略的一件事

談到要成為一名開發者需要知道哪些事？每個程式人的答案都不太一樣，單就書籍來說好了，你可能需要認識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。

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

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