安全與加密

無論是開發Web應用的開發者還是企圖利用Web應用漏洞的攻擊者，對於Web程式安全這個話題都給予了越來越多的關註。特別是最近CSDN密碼泄露事件，更是讓我們對Web安全這個話題更加重視，所有人都談密碼色變，都開始檢測自己的系統是否存在漏洞。那麼我們作為一名Go程式的開發者，一定也需要知道我們的應用程式隨時會成為眾多攻擊者的目標，並提前做好防範的準備。

很多Web應用程式中的安全問題都是由於輕信了第三方提供的數據造成的。比如對於用戶的輸入數據，在對其進行驗證之前都應該將其視為不安全的數據。如果直接把這些不安全的數據輸出到客戶端，就可能造成跨站腳本攻擊(XSS)的問題。如果把不安全的數據用於資料庫查詢，那麼就可能造成SQL註入問題，在使用第三方提供的數據，包括用戶提供的數據時，首先檢驗這些數據的合法性非常重要，這個過程叫做過濾，過濾輸入和轉義輸出並不能解決所有的安全問題，與安全加密相關的，能夠增強我們的Web應用程式的強大手段就是加密，CSDN泄密事件就是因為密碼保存的是明文，使得攻擊拿手庫之後就可以直接實施一些破壞行為了。不過，和其他工具一樣，加密手段也必須運用得當。加密的本質就是擾亂數據，某些不可恢復的數據擾亂我們稱為單向加密或者散列演算法。另外還有一種雙向加密方式，也就是可以對加密後的數據進行解密

預防CSRF攻擊

什麼是CSRF

CSRF（Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。

那麼CSRF到底能夠幹嘛呢？你可以這樣簡單的理解：攻擊者可以盜用你的登陸信息，以你的身份模擬發送各種請求。攻擊者只要藉助少許的社會工程學的詭計，例如通過QQ等聊天軟體發送的鏈接(有些還偽裝成短功能變數名稱，用戶無法分辨)，攻擊者就能迫使Web應用的用戶去執行攻擊者預設的操作。例如，當用戶登錄網路銀行去查看其存款餘額，在他沒有退出時，就點擊了一個QQ好友發來的鏈接，那麼該用戶銀行帳戶中的資金就有可能被轉移到攻擊者指定的帳戶中。

所以遇到CSRF攻擊時，將對終端用戶的數據和操作指令構成嚴重的威脅；當受攻擊的終端用戶具有管理員帳戶的時候，CSRF攻擊將危及整個Web應用程式。

要完成一次CSRF攻擊，受害者必須依次完成兩個步驟 ：

1.登錄受信任網站A，併在本地生成Cookie 。
2.在不退出A的情況下，訪問危險網站B。
看到這裡，讀者也許會問：“如果我不滿足以上兩個條件中的任意一個，就不會受到CSRF的攻擊”。是的，確實如此，但你不能保證以下情況不會發生：

• 你不能保證你登錄了一個網站後，不再打開一個tab頁面並訪問另外的網站，特別現在瀏覽器都是支持多tab的。
• 你不能保證你關閉瀏覽器了後，你本地的Cookie立刻過期，你上次的會話已經結束。
• 所謂的攻擊網站，可能是一個存在其他漏洞的可信任的經常被人訪問的網站。
  因此對於用戶來說很難避免在登陸一個網站之後不點擊一些鏈接進行其他操作，所以隨時可能成為CSRF的受害者。

CSRF攻擊主要是因為Web的隱式身份驗證機制，Web的身份驗證機制雖然可以保證一個請求是來自於某個用戶的瀏覽器，但卻無法保證該請求是用戶批准發送的。

確保輸入過濾

過濾用戶數據是Web應用安全的基礎。它是驗證數據合法性的過程。通過對所有的輸入數據進行過濾，可以避免惡意數據在程式中被誤信或誤用。大多數Web應用的漏洞都是因為沒有對用戶輸入的數據進行恰當過濾所引起的。

我們介紹的過濾數據分成三個步驟：

1、識別數據，搞清楚需要過濾的數據來自於哪裡
2、過濾數據，弄明白我們需要什麼樣的數據
3、區分已過濾及被污染數據，如果存在攻擊數據那麼保證過濾之後可以讓我們使用更安全的數據

數據過濾在Web安全中起到一個基石的作用，大多數的安全問題都是由於沒有過濾數據和驗證數據引起的，例如前面小節的CSRF攻擊，以及接下來將要介紹的XSS攻擊、SQL註入等都是沒有認真地過濾數據引起的，因此我們需要特別重視這部分的內容。

避免XSS攻擊

隨著互聯網技術的發展，現在的Web應用都含有大量的動態內容以提高用戶體驗。所謂動態內容，就是應用程式能夠根據用戶環境和用戶請求，輸出相應的內容。動態站點會受到一種名為“跨站腳本攻擊”（Cross Site Scripting, 安全專家們通常將其縮寫成 XSS）的威脅，而靜態站點則完全不受其影響。

什麼是XSS

XSS攻擊：跨站腳本攻擊(Cross-Site Scripting)，為了不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。XSS是一種常見的web安全漏洞，它允許攻擊者將惡意代碼植入到提供給其它用戶使用的頁面中。不同於大多數攻擊(一般只涉及攻擊者和受害者)，XSS涉及到三方，即攻擊者、客戶端與Web應用。XSS的攻擊目標是為了盜取存儲在客戶端的cookie或者其他網站用於識別客戶端身份的敏感信息。一旦獲取到合法用戶的信息後，攻擊者甚至可以假冒合法用戶與網站進行交互。

XSS通常可以分為兩大類：一類是存儲型XSS，主要出現在讓用戶輸入數據，供其他瀏覽此頁的用戶進行查看的地方，包括留言、評論、博客日誌和各類表單等。應用程式從資料庫中查詢數據，在頁面中顯示出來，攻擊者在相關頁面輸入惡意的腳本數據後，用戶瀏覽此類頁面時就可能受到攻擊。這個流程簡單可以描述為:惡意用戶的Html輸入Web程式->進入資料庫->Web程式->用戶瀏覽器。另一類是反射型XSS，主要做法是將腳本代碼加入URL地址的請求參數里，請求參數進入程式後在頁面直接輸出，用戶點擊類似的惡意鏈接就可能受到攻擊。

XSS目前主要的手段和目的如下：

• 盜用cookie，獲取敏感信息。
• 利用植入Flash，通過crossdomain許可權設置進一步獲取更高許可權；或者利用Java等得到類似的操作。
• 利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻擊者）用戶的身份執行一些管理動作，或執行一些如:發微博、加好友、發私信等常規操作，前段時間新浪微博就遭遇過一次XSS。
• 利用可被攻擊的域受到其他域信任的特點，以受信任來源的身份請求一些平時不允許的操作，如進行不當的投票活動。
• 在訪問量極大的一些頁面上的XSS可以攻擊一些小型網站，實現DDoS攻擊的效果

避免SQL註入

什麼是SQL註入

SQL註入攻擊（SQL Injection），簡稱註入攻擊，是Web開發中最常見的一種安全漏洞。可以用它來從資料庫獲取敏感信息，或者利用資料庫的特性執行添加用戶，導出文件等一系列惡意操作，甚至有可能獲取資料庫乃至系統用戶最高許可權。

而造成SQL註入的原因是因為程式沒有有效過濾用戶的輸入，使攻擊者成功的向伺服器提交惡意的SQL查詢代碼，程式在接收後錯誤的將攻擊者的輸入作為查詢語句的一部分執行，導致原始的查詢邏輯被改變，額外的執行了攻擊者精心構造的惡意代碼。

很多Web開發者沒有意識到SQL查詢是可以被篡改的，從而把SQL查詢當作可信任的命令。殊不知，SQL查詢是可以繞開訪問控制，從而繞過身份驗證和許可權檢查的。更有甚者，有可能通過SQL查詢去運行主機系統級的命令。

也許你會說攻擊者要知道資料庫結構的信息才能實施SQL註入攻擊。確實如此，但沒人能保證攻擊者一定拿不到這些信息，一旦他們拿到了，資料庫就存在泄露的危險。如果你在用開放源代碼的軟體包來訪問資料庫，比如論壇程式，攻擊者就很容易得到相關的代碼。如果這些代碼設計不良的話，風險就更大了。目前Discuz、phpwind、phpcms等這些流行的開源程式都有被SQL註入攻擊的先例。

這些攻擊總是發生在安全性不高的代碼上。所以，永遠不要信任外界輸入的數據，特別是來自於用戶的數據，包括選擇框、表單隱藏域和 cookie。就如上面的第一個例子那樣，就算是正常的查詢也有可能造成災難。

SQL註入是危害相當大的安全漏洞。所以對於我們平常編寫的Web應用，應該對於每一個小細節都要非常重視，細節決定命運，生活如此，編寫Web應用也是這樣。

存儲密碼

過去一段時間以來, 許多的網站遭遇用戶密碼數據泄露事件, 這其中包括頂級的互聯網企業–Linkedin, 國內諸如CSDN，該事件橫掃整個國內互聯網，隨後又爆出多玩游戲800萬用戶資料被泄露，另有傳言人人網、開心網、天涯社區、世紀佳緣、百合網等社區都有可能成為黑客下一個目標。層出不窮的類似事件給用戶的網上生活造成巨大的影響，人人自危，因為人們往往習慣在不同網站使用相同的密碼，所以一家“暴庫”，全部遭殃。

那麼我們作為一個Web應用開發者，在選擇密碼存儲方案時, 容易掉入哪些陷阱, 以及如何避免這些陷阱?

普通方案

目前用的最多的密碼存儲方案是將明文密碼做單向哈希後存儲，單向哈希演算法有一個特征：無法通過哈希後的摘要(digest)恢複原始數據，這也是“單向”二字的來源。常用的單向哈希演算法包括SHA-256, SHA-1, MD5等。

單向哈希有兩個特性：

1）同一個密碼進行單向哈希，得到的總是唯一確定的摘要。
2）計算速度快。隨著技術進步，一秒鐘能夠完成數十億次單向哈希計算。
結合上面兩個特點，考慮到多數人所使用的密碼為常見的組合，攻擊者可以將所有密碼的常見組合進行單向哈希，得到一個摘要組合, 然後與資料庫中的摘要進行比對即可獲得對應的密碼。這個摘要組合也被稱為rainbow table。

因此通過單向加密之後存儲的數據，和明文存儲沒有多大區別。因此，一旦網站的資料庫泄露，所有用戶的密碼本身就大白於天下。

進階方案

通過上面介紹我們知道黑客可以用rainbow table來破解哈希後的密碼，很大程度上是因為加密時使用的哈希演算法是公開的。如果黑客不知道加密的哈希演算法是什麼，那他也就無從下手了。

一個直接的解決辦法是，自己設計一個哈希演算法。然而，一個好的哈希演算法是很難設計的——既要避免碰撞，又不能有明顯的規律，做到這兩點要比想象中的要困難很多。因此實際應用中更多的是利用已有的哈希演算法進行多次哈希。

但是單純的多次哈希，依然阻擋不住黑客。兩次 MD5、三次 MD5之類的方法，我們能想到，黑客自然也能想到。特別是對於一些開源代碼，這樣哈希更是相當於直接把演算法告訴了黑客。

沒有攻不破的盾，但也沒有折不斷的矛。現在安全性比較好的網站，都會用一種叫做“加鹽”的方式來存儲密碼，也就是常說的 “salt”。他們通常的做法是，先將用戶輸入的密碼進行一次MD5（或其它哈希演算法）加密；將得到的 MD5 值前後加上一些只有管理員自己知道的隨機串，再進行一次MD5加密。這個隨機串中可以包括某些固定的串，也可以包括用戶名（用來保證每個用戶加密使用的密鑰都不一樣）。

專家方案

上面的進階方案在幾年前也許是足夠安全的方案，因為攻擊者沒有足夠的資源建立這麼多的rainbow table。 但是，時至今日，因為並行計算能力的提升，這種攻擊已經完全可行。

怎麼解決這個問題呢？只要時間與資源允許，沒有破譯不了的密碼，所以方案是:故意增加密碼計算所需耗費的資源和時間，使得任何人都不可獲得足夠的資源建立所需的rainbow table。

這類方案有一個特點，演算法中都有個因數，用於指明計算密碼摘要所需要的資源和時間，也就是計算強度。計算強度越大，攻擊者建立rainbow table越困難，以至於不可繼續。

這裡推薦scrypt方案，scrypt是由著名的FreeBSD黑客Colin Percival為他的備份服務Tarsnap開發的。

目前Go語言裡面支持的庫 https://github.com/golang/crypto/tree/master/scrypt

dk := scrypt.Key([]byte("some password"), []byte(salt), 16384, 8, 1, 32)
通過上面的方法可以獲取唯一的相應的密碼值，這是目前為止最難破解的。

看到這裡，如果你產生了危機感，那麼就行動起來：

1）如果你是普通用戶，那麼我們建議使用LastPass進行密碼存儲和生成，對不同的網站使用不同的密碼；
2）如果你是開發人員， 那麼我們強烈建議你採用專家方案進行密碼存儲。

加密和解密數據

base64加解密

如果Web應用足夠簡單，數據的安全性沒有那麼嚴格的要求，那麼可以採用一種比較簡單的加解密方法是base64，這種方式實現起來比較簡單

高級加解密

Go語言的crypto裡面支持對稱加密的高級加解密包有：

crypto/aes包：AES(Advanced Encryption Standard)，又稱Rijndael加密法，是美國聯邦政府採用的一種區塊加密標準。
crypto/des包：DES(Data Encryption Standard)，是一種對稱加密標準，是目前使用最廣泛的密鑰系統，特別是在保護金融數據的安全中。曾是美國聯邦政府的加密標準，但現已被AES所替代。

這小節介紹了幾種加解密的演算法，在開發Web應用的時候可以根據需求採用不同的方式進行加解密，一般的應用可以採用base64演算法，更加高級的話可以採用aes或者des演算法。

這一章主要介紹瞭如：CSRF攻擊、XSS攻擊、SQL註入攻擊等一些Web應用中典型的攻擊手法，它們都是由於應用對用戶的輸入沒有很好的過濾引起的，所以除了介紹攻擊的方法外，我們也介紹了瞭如何有效的進行數據過濾，以防止這些攻擊的發生的方法。然後針對日異嚴重的密碼泄漏事件，介紹了在設計Web應用中可採用的從基本到專家的加密方案。最後針對敏感數據的加解密簡要介紹了，Go語言提供三種對稱加密演算法：base64、aes和des的實現。go語言在支持防攻擊方面已經提供大量的工具包，我們可以充分的利用這些包來做出一個安全的Web應用。
前面小節介紹瞭如何存儲密碼，但是有的時候，我們想把一些敏感數據加密後存儲起來，在將來的某個時候，隨需將它們解密出來，此時我們應該在選用對稱加密演算法來滿足我們的需求。