為了便于分析這個(gè)漫畫所要表達(dá)的含義，我們假設(shè)這個(gè)成績追蹤系統(tǒng)有一個(gè)用于增加新的學(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")

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

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

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

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

DROP TABLE Students

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

對于上文描述的這種場景，如果只是依賴于簡單的清洗過濾，肯定無法應(yīng)付所有的攻擊載荷，這也不是一個(gè)正道。基本上能夠采取的方法就是所謂的參數(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();
 }

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

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

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

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

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

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

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

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

NoSQL 也存在著注入的危險(xiǎn)

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

我們并不能替用戶選擇所使用的網(wǎng)絡(luò)，他們很有可能使用一個(gè)開放的，任何人都可以竊聽的網(wǎng)絡(luò)，譬如一個(gè)咖啡館或者機(jī)場里面的開放WiFi網(wǎng)絡(luò)。普通的用戶很有可能被欺騙地隨便連上一個(gè)叫免費(fèi)熱點(diǎn)的網(wǎng)絡(luò)，或者使用一個(gè)可以隨便被插入廣告的網(wǎng)路當(dāng)中。如果攻擊者會(huì)竊聽或者篡改網(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é)議，一個(gè)優(yōu)于SSL協(xié)議的標(biāo)準(zhǔn)來保障通信安全。只要配置與使用得當(dāng)，就能有效抵御竊聽與篡改，從而有效保護(hù)我們將要去訪問的網(wǎng)站。用更加技術(shù)化的方式說，HTTPS能夠有效保障數(shù)據(jù)機(jī)密性與完整性，并且能夠完成用戶端與客戶端的雙重驗(yàn)證。

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

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

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

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

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

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

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

如果是在Web瀏覽器中呈現(xiàn)的資源，那可以添加一個(gè)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)險(xiǎn)。為了幫助站點(diǎn)把用戶從HTTP遷移到HTTPS，現(xiàn)代的瀏覽器支持一個(gè)非常強(qiáng)力的安全特征叫做HSTS(HTTP Strict Transport Security)，來告訴瀏覽器我這個(gè)站點(diǎn)只會(huì)接收來自于HTTPS的請求。這個(gè)特性最早來自于2009年的Moxie Marlinspike"s提出的一個(gè)用于演示基于HTTP的潛在危險(xiǎn)的SSL剝離攻擊?？梢杂萌缦碌脑O(shè)置來啟用這個(gè)特性:

Strict-Transport-Security: max-age=15768000

上述的設(shè)置會(huì)告訴瀏覽器只和使用HTTPS的站點(diǎn)進(jìn)行交互，HSTS是一個(gè)非常重要的強(qiáng)制使用HTTPS的特性。一旦開啟之后，瀏覽器會(huì)自動(dòng)把不安全的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)建的安全機(jī)制來避免包含敏感信息的Cookie暴露出來。在Cookie中設(shè)置secure標(biāo)識(shí)位能夠強(qiáng)制讓瀏覽器只會(huì)用HTTPS來傳遞Cookie，如果你已經(jīng)使用了HSTS也要記得這樣設(shè)置來保護(hù)Cookie。

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

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

啥地方都要用HTTPS

采用HSTS來強(qiáng)制使用HTTPS

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

不要亂放你的私鑰

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

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

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

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