安全與加密

無論是開發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應用，
前面小節介紹了如何存盤密碼，但是有的時候，我們想把一些敏感資料加密后存盤起來，在將來的某個時候，隨需將它們解密出來，此時我們應該在選用對稱加密演算法來滿足我們的需求，

標籤：Go

上一篇：goweb-web服務

下一篇：Jaeger容器化部署