為了便于分析這個漫畫所要表達(dá)的含義，我們假設(shè)這個成績追蹤系統(tǒng)有一個用于增加新的學(xué)生信息的函數(shù)：

void addStudent(String lastName, String firstName) {
        String query = "INSERT INTO students (last_name, first_name) VALUES (""
                + lastName + "", "" + firstName + "")";
        getConnection().createStatement().execute(query);
}

如果輸入的參數(shù)是"Fowler"與"Martin"，那么最終構(gòu)造出的SQL語句為：

INSERT INTO students (last_name, first_name) VALUES ("Fowler", "Martin")

不過如果輸入的是上面那娃的名字，那么整個待執(zhí)行的SQL語句就變成了：

INSERT INTO students (last_name, first_name) VALUES ("XKCD", "Robert’); DROP TABLE Students;-- ")

實際上，這個SQL語句一共執(zhí)行了兩個操作：

INSERT INTO students (last_name, first_name) VALUES ("XKCD", "Robert")

DROP TABLE Students

最后的--注釋是為了屏蔽余下的內(nèi)容，保證整個SQL語句能夠穩(wěn)定執(zhí)行。類似于這樣的攻擊載荷能夠執(zhí)行任意的SQL語句，換言之，攻擊者能夠在數(shù)據(jù)庫內(nèi)像這個應(yīng)用系統(tǒng)一樣做任何事情。

對于上文描述的這種場景，如果只是依賴于簡單的清洗過濾，肯定無法應(yīng)付所有的攻擊載荷，這也不是一個正道?；旧夏軌虿扇〉姆椒ň褪撬^的參數(shù)綁定，譬如JDBC中提供的PreparedStatement.setXXX()方法，參數(shù)綁定可以將像SQL這樣的可執(zhí)行代碼與需要進(jìn)行編碼、過濾的內(nèi)容區(qū)分開來：

void addStudent(String lastName, String firstName) {
        PreparedStatement stmt = getConnection().prepareStatement("INSERT INTO students (last_name, first_name) VALUES (?, ?)");
        stmt.setString(1, lastName);
        stmt.setString(2, firstName);
        stmt.execute();
 }

一般來說，一個功能比較全面地數(shù)據(jù)訪問層都會提供這種參數(shù)綁定的功能，開發(fā)者在開發(fā)的時候就要注意將所有的不受信任的輸入通過參數(shù)綁定生成SQL語句。

有時候我們開發(fā)時會遇到一個兩難的問題，即是好的安全性與干凈整潔的代碼之間的沖突。為了保證安全性往往需要我們增加些額外的代碼，不過在上面的例子中我們還是同時達(dá)成了較高的安全性與好的代碼設(shè)計。使用綁定的參數(shù)不僅能使應(yīng)用系統(tǒng)免于注入攻擊，還能通過在代碼與內(nèi)容之間構(gòu)建清晰的邊界來增加整個代碼的可讀性，并且與手動拼接相比還能大大簡化構(gòu)造可用的SQL的過程。當(dāng)你用參數(shù)綁定來代替原本的格式化字符串或者字符串拼接來構(gòu)造SQL的時候，你會發(fā)現(xiàn)還能用全局的綁定方程來完成這一工作，這又會大大增加整個代碼的整潔度與安全性。

有一個常見的錯誤思維就是覺得存儲過程能夠避免SQL注入攻擊，但是這個只有在你是通過參數(shù)綁定的方式傳入?yún)?shù)的情況下。如果存儲過程本身也是用的字符串連接的方式，那么同樣存在SQL注入攻擊的風(fēng)險。類似的，像ActiveRecord、Hibernate或者.Net Entity這樣的框架，也是只有在用參數(shù)綁定來構(gòu)造SQL的情況下才會進(jìn)行SQL注入清洗。

最后，還有一個常見的錯覺就是NoSQL數(shù)據(jù)庫不會被SQL注入攻擊影響。這肯定是不對的，所有的查詢語言，無論是不是SQL都需要在可執(zhí)行代碼與輸入的內(nèi)容之間劃定明晰的邊界來防止參數(shù)混淆可執(zhí)行的命令。攻擊者會不停尋找能夠在運行時打破這種邊界隔離的方法從而進(jìn)行潛在的攻擊。即使是Mongodb，采用了二進(jìn)制的協(xié)議與多種語言特定的API都會存在被注入的風(fēng)險，譬如$where這個操作符。

避免直接從用戶的輸入中構(gòu)建出SQL或者等價的NoSQL查詢語句

在查詢語句與存儲過程中都使用參數(shù)綁定

盡可能使用框架提供好的原生的綁定方法而不是用你自己的編碼方法

不要覺得存儲過程或者ORM框架可以幫到你，你還是需要手動調(diào)用存儲過程

NoSQL 也存在著注入的危險

當(dāng)我們著眼于系統(tǒng)的輸入輸出的時候，還有另一個重要的店需要考慮進(jìn)去，就是傳輸過程中數(shù)據(jù)的保密性與完整性。在使用原始的HTTP連接的時候，因為服務(wù)器與用戶之間是直接進(jìn)行的明文傳輸，導(dǎo)致了用戶面臨著很多的風(fēng)險與威脅。攻擊者可以用中間人攻擊來輕易的截獲或者篡改傳輸?shù)臄?shù)據(jù)。攻擊者想要做些什么并沒有任何的限制，包括竊取用戶的Session信息、注入有害的代碼等，乃至于修改用戶傳送至服務(wù)器的數(shù)據(jù)。

我們并不能替用戶選擇所使用的網(wǎng)絡(luò)，他們很有可能使用一個開放的，任何人都可以竊聽的網(wǎng)絡(luò)，譬如一個咖啡館或者機場里面的開放WiFi網(wǎng)絡(luò)。普通的用戶很有可能被欺騙地隨便連上一個叫免費熱點的網(wǎng)絡(luò)，或者使用一個可以隨便被插入廣告的網(wǎng)路當(dāng)中。如果攻擊者會竊聽或者篡改網(wǎng)路中的數(shù)據(jù)，那么用戶與服務(wù)器交換的數(shù)據(jù)就好不可信了，幸好我們還可以使用HTTPS來保證傳輸?shù)陌踩浴?/p> HTTPS and Transport Layer Security

HTTPS最早主要用于類似于經(jīng)融這樣的安全要求較高的敏感網(wǎng)絡(luò)，不過現(xiàn)在日漸被各種各樣的網(wǎng)站鎖使用，譬如我們常用的社交網(wǎng)絡(luò)或者搜索引擎。HTTPS協(xié)議使用的是TLS協(xié)議，一個優(yōu)于SSL協(xié)議的標(biāo)準(zhǔn)來保障通信安全。只要配置與使用得當(dāng)，就能有效抵御竊聽與篡改，從而有效保護(hù)我們將要去訪問的網(wǎng)站。用更加技術(shù)化的方式說，HTTPS能夠有效保障數(shù)據(jù)機密性與完整性，并且能夠完成用戶端與客戶端的雙重驗證。

隨著面臨的風(fēng)險日漸增多，我們應(yīng)該將所有的網(wǎng)絡(luò)數(shù)據(jù)當(dāng)做敏感數(shù)據(jù)并且進(jìn)行加密傳輸。已經(jīng)有很多的瀏覽器廠商宣稱要廢棄所有的非HTTPS的請求，乃至于當(dāng)用戶訪問非HTTPS的網(wǎng)站的時候給出明確的提示。很多基于HTTP/2的實現(xiàn)都只支持基于TLS的通信，所以我們現(xiàn)在更應(yīng)當(dāng)在全部地方使用HTTPS。

目前如果要大范圍推廣使用HTTPS還是有一些障礙的，在一個很長的時間范圍內(nèi)使用HTTPS會被認(rèn)為造成很多的計算資源的浪費，不過隨著現(xiàn)代硬件與瀏覽器的發(fā)展，這點計算資源已經(jīng)不足為道。早期的SSL協(xié)議與TLS協(xié)議只支持一個IP地址分配一個整數(shù)，不過現(xiàn)在這種限制所謂的SNI的協(xié)議擴展來解決。另外，從一個證書認(rèn)證機構(gòu)獲取證書也會打消一些用戶使用HTTPS的念頭，不過下面我們介紹的像Let"s Encrypt這樣的免費的服務(wù)就可以打破這種障礙。

對于網(wǎng)站的安全認(rèn)證依賴于TLS的底層的支持，如果客戶端只是根據(jù)網(wǎng)站說它自己是誰就是誰，那么攻擊者可以輕易的使用中間人攻擊來模擬站點，從而繞過所有協(xié)議提供的安全機制。在使用了TLS協(xié)議之后，一個網(wǎng)站可以用它的公鑰證書來證明它自己是誰。在某些系統(tǒng)中客戶端也需要用公鑰證書證明自己是誰，不過大部分情況下受限于為用戶管理證書的復(fù)雜性，這個并沒有廣泛使用。除非一個網(wǎng)站證書的真實性已經(jīng)經(jīng)過了驗證，不然客戶端在收到一個證書的時候也要通過一定的手段來驗證證書的真實性。而在Web瀏覽器或者其他的應(yīng)用中，往往是通過一個第三方的稱作CA的機構(gòu)來管理證書并且提供驗證功能，包括驗證這個證書與證書所屬網(wǎng)站的真實性。

如果我們通過其他渠道已經(jīng)能夠提前得知某個證書是否可信，那也就沒必要再經(jīng)過第三方機構(gòu)進(jìn)行仲裁。譬如一個移動APP或者其他應(yīng)用在分發(fā)的時候就會內(nèi)置一些證書從而在使用時來驗證站點是否真實可信。大部分關(guān)于HTTPS是否可信的指示會在瀏覽器訪問某個HTTPS的站點的時候顯示出來，如果沒有的話瀏覽器會顯示一個告警信息來警告用戶不要訪問不可信的站點。

在測試的時候我們可以自己創(chuàng)建配置一個證書用于HTTPS認(rèn)證，不過如果你要提供服務(wù)給普通用戶使用，那么還是需要從可信的第三方CA機構(gòu)來獲取可信的證書。對于很多開發(fā)者而言，一個免費的CA證書是個不錯的選擇。當(dāng)你搜索CA的時候，你可能會遇到幾個不同等級的證書。最常見的就是Domain Validation(DV)，用于認(rèn)證一個域名的所有者。再往上就是所謂的Organization Validation(OV)與Extended Validation(EV)，包括了驗證這些證書的請求機構(gòu)的信息。雖然高級別的證書需要額外的消耗，不過還是很值得的。

當(dāng)你申請到了證書之后，你就可以開始配置你的服務(wù)器支持HTTPS了。雖然HTTPS啊，包括TLS/SSL的原理好像要個密碼學(xué)的PHD學(xué)位才能理解，但是要把他們配置著用起來還是很容易的呦。不同的加密算法與站點使用的協(xié)議的版本差異會大大影響到它能夠提供的通信的安全級別。所以咋才能一方面保證我們站點的安全性另一方面又保證那些使用老版本的瀏覽器的用戶也能正常使用網(wǎng)站服務(wù)呢？這里要推薦下Mozilla提供的Security/Server Side TLS工具，可以協(xié)助來自動創(chuàng)建適用的Web服務(wù)器的配置。

現(xiàn)在我們經(jīng)常碰到一些網(wǎng)站僅僅只用HTTPS來保護(hù)部分資源，有些情況下只會保護(hù)一些對于敏感資源的提交操作。另一些情況下，部分網(wǎng)站只會將HTTPS用于自認(rèn)為敏感的資源上，譬如一個用戶登錄之后才能見到的東西往往是HTTPS加密的。而現(xiàn)在的麻煩事還有很多站點并未使用HTTPS來保護(hù)自己，導(dǎo)致整個網(wǎng)站還處于被中間人攻擊的危險之下。筆者很是建議這類網(wǎng)站應(yīng)該直接關(guān)閉掉HTTP端口從而強制性讓用戶轉(zhuǎn)到HTTPS，雖然這并不是一個理想的解決方案，不過估計是最好的解決方法。

如果是在Web瀏覽器中呈現(xiàn)的資源，那可以添加一個HTTP請求轉(zhuǎn)發(fā)的配置，來將所有的HTTP請求轉(zhuǎn)發(fā)到HTTPS端口上，譬如：

# Redirect requests to /content to use HTTPS (mod_rewrite is required)
RewriteEngine On
RewriteCond %{HTTPS} != on [NC]
RewriteCond %{REQUEST_URI} ^/content(/.*)?
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

讓用戶從HTTP遷移到HTTPS可以來避免使用原始的HTTP請求帶來的風(fēng)險。為了幫助站點把用戶從HTTP遷移到HTTPS，現(xiàn)代的瀏覽器支持一個非常強力的安全特征叫做HSTS(HTTP Strict Transport Security)，來告訴瀏覽器我這個站點只會接收來自于HTTPS的請求。這個特性最早來自于2009年的Moxie Marlinspike"s提出的一個用于演示基于HTTP的潛在危險的SSL剝離攻擊?？梢杂萌缦碌脑O(shè)置來啟用這個特性:

Strict-Transport-Security: max-age=15768000

上述的設(shè)置會告訴瀏覽器只和使用HTTPS的站點進(jìn)行交互，HSTS是一個非常重要的強制使用HTTPS的特性。一旦開啟之后，瀏覽器會自動把不安全的HTTP請求切換到HTTPS，盡管用戶沒有顯式的輸入"https://"。而在瀏覽器端開啟HSTS特性只需要添加如下的一行代碼：

    ...

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=15768000"

不過現(xiàn)在并不是所有的瀏覽器都支持HSTS特性，你可以通過訪問 Can I use. 來看看你面向的用戶常用的瀏覽器能不能使用。

瀏覽器目前有內(nèi)建的安全機制來避免包含敏感信息的Cookie暴露出來。在Cookie中設(shè)置secure標(biāo)識位能夠強制讓瀏覽器只會用HTTPS來傳遞Cookie，如果你已經(jīng)使用了HSTS也要記得這樣設(shè)置來保護(hù)Cookie。

即使你全站都用了HTTPS，也還是有幾個地方可能導(dǎo)致敏感信息的泄露的。譬如如果你直接把敏感數(shù)據(jù)放在URL里面，然后這個敏感的URL又被緩存在了瀏覽器的歷史記錄里。除此之后，如果包含了敏感信息的站點被鏈接到了其他的網(wǎng)站中，那么在用戶點擊鏈接之后整個敏感數(shù)據(jù)就會被放在Referer Header中然后傳送過去，然后就呵呵了。另外，有時候因為大家都懂的原因我們會使用一些代理然后允許他們監(jiān)控HTTPS的流量，也是有危險地，這個時候就要在Header中來關(guān)閉緩存從而降低風(fēng)險。筆者建議你可以參考OWASP Transport Protection Layer Cheat Sheet 來收獲一些有用的建議。

最后一步，你要仔細(xì)驗證你的配置是否有效。有很多的在線工具可以幫你做這件事，譬如SSL Lab的SSL Server Test能夠幫你深度分析你的HTTPS的配置，再看看是不是有啥地方配錯了。這個工具會在發(fā)現(xiàn)了新的攻擊手段與協(xié)議更新之后實時更新，所以多用用它還是個很不錯的事情嗷。

啥地方都要用HTTPS

采用HSTS來強制使用HTTPS

別忘了從可信的證書機構(gòu)中請求可信證書

不要亂放你的私鑰

用合理的配置工具來生成可靠地HTTPS配置

在Cookie中設(shè)置"secure"標(biāo)識

不要把敏感的數(shù)據(jù)放在URL中

隔一段時間就要好好看看你的HTTPS的配置，表過時了