為了便于分析這個(gè)漫畫所要表達(dá)的含義，我們假設(shè)這個(gè)成績(jī)追蹤系統(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語(yǔ)句為：

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

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

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

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

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

DROP TABLE Students

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

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

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();
 }

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

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

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

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

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

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

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

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

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

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

我們并不能替用戶選擇所使用的網(wǎng)絡(luò)，他們很有可能使用一個(gè)開放的，任何人都可以竊聽的網(wǎng)絡(luò)，譬如一個(gè)咖啡館或者機(jī)場(chǎng)里面的開放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來(lái)保證傳輸?shù)陌踩浴?/p> HTTPS and Transport Layer Security

HTTPS最早主要用于類似于經(jīng)融這樣的安全要求較高的敏感網(wǎng)絡(luò)，不過(guò)現(xiàn)在日漸被各種各樣的網(wǎng)站鎖使用，譬如我們常用的社交網(wǎng)絡(luò)或者搜索引擎。HTTPS協(xié)議使用的是TLS協(xié)議，一個(gè)優(yōu)于SSL協(xié)議的標(biāo)準(zhǔn)來(lái)保障通信安全。只要配置與使用得當(dāng)，就能有效抵御竊聽與篡改，從而有效保護(hù)我們將要去訪問(wèn)的網(wǎng)站。用更加技術(shù)化的方式說(shuō)，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的請(qǐng)求，乃至于當(dāng)用戶訪問(wèn)非HTTPS的網(wǎng)站的時(shí)候給出明確的提示。很多基于HTTP/2的實(shí)現(xiàn)都只支持基于TLS的通信，所以我們現(xiàn)在更應(yīng)當(dāng)在全部地方使用HTTPS。

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

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

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

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

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

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

如果是在Web瀏覽器中呈現(xiàn)的資源，那可以添加一個(gè)HTTP請(qǐng)求轉(zhuǎn)發(fā)的配置，來(lái)將所有的HTTP請(qǐng)求轉(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可以來(lái)避免使用原始的HTTP請(qǐng)求帶來(lái)的風(fēng)險(xiǎn)。為了幫助站點(diǎn)把用戶從HTTP遷移到HTTPS，現(xiàn)代的瀏覽器支持一個(gè)非常強(qiáng)力的安全特征叫做HSTS(HTTP Strict Transport Security)，來(lái)告訴瀏覽器我這個(gè)站點(diǎn)只會(huì)接收來(lái)自于HTTPS的請(qǐng)求。這個(gè)特性最早來(lái)自于2009年的Moxie Marlinspike"s提出的一個(gè)用于演示基于HTTP的潛在危險(xiǎn)的SSL剝離攻擊。可以用如下的設(shè)置來(lái)啟用這個(gè)特性:

Strict-Transport-Security: max-age=15768000

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

    ...

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

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

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

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

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

啥地方都要用HTTPS

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

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

不要亂放你的私鑰

用合理的配置工具來(lái)生成可靠地HTTPS配置

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

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

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