ZDNet的一份報(bào)告概述了成千上萬個(gè)CMS插件和PHP庫是如何使用戶處于危險(xiǎn)之中的。

上周，ZDNet的Catalin Cimpanu報(bào)告了一個(gè)首先由Paragon Initiative Enterprise的Scott Arciszewski提出來的問題：一批數(shù)量驚人的CMS插件和PHP庫正在禁用SSL/TLS證書驗(yàn)證。

“更糟糕的是，許多這些插件和庫都被用來建立了與付款服務(wù)器的連接，通過這些服務(wù)器，他們之后就可以傳輸敏感的用戶數(shù)據(jù)或處理金融交易?！?/p>

其結(jié)果是，由于大量插件的作者不正確的配置，那些與建立在內(nèi)容管理系統(tǒng)（如WordPress）上的熱門網(wǎng)站進(jìn)行交互的、數(shù)以百萬計(jì)的互聯(lián)網(wǎng)用戶可能就會(huì)受到攻擊。

因此，這是什么意思呢？為什么會(huì)有這樣的麻煩？你能做些什么來確保你不會(huì)在不經(jīng)意間危害你的客戶？

讓我們來討論一下。

內(nèi)容管理系統(tǒng)及其插件和庫的簡(jiǎn)要介紹

讓我們從頭開始。不同于建立他們自己的解決方案，許多網(wǎng)站都會(huì)依賴一個(gè)可以根據(jù)其需要進(jìn)行配置的、現(xiàn)成的CMS（如WordPress、Drupal等）。我們?yōu)镠ashed Out也采用了一個(gè)CMS。SSL Store在自己搭建的、由我們的開發(fā)團(tuán)隊(duì)進(jìn)行管理的CMS上運(yùn)行，但是考慮到Hashed Out每天都需要發(fā)布文章，我們使用的是WordPress。

許多這些CMS平臺(tái)最吸引人的特性之一是，它們所使用的插件和庫能夠幫助你避免構(gòu)建自己的web應(yīng)用程序和進(jìn)行大量額外的開發(fā)工作。這些插件的優(yōu)點(diǎn)是，當(dāng)它們正常工作時(shí)（大多數(shù)都是這樣），它們能夠幫助你節(jié)省大量的時(shí)間和精力。缺點(diǎn)是由于你對(duì)第三方過于信任，以至于當(dāng)?shù)谌椒噶隋e(cuò)誤時(shí)，會(huì)傷害到你的網(wǎng)站和用戶。

既然我們已經(jīng)討論到了這一點(diǎn)，讓我們來討論一下這些插件和PHP庫的問題。

錯(cuò)誤配置的代碼和cURL選項(xiàng)

cURL是一個(gè)庫和命令行工具，廣泛存在于現(xiàn)代服務(wù)器上。它主要是用于在遠(yuǎn)程服務(wù)器之間來回傳輸數(shù)據(jù)，并被打包成許多CMS插件和PHP庫。很多時(shí)候，系統(tǒng)都更傾向于使用cURL，而不是打開一個(gè)實(shí)際的瀏覽器會(huì)話來進(jìn)行連接。

cURL支持許多協(xié)議，但與本文最密切相關(guān)的兩個(gè)協(xié)議是HTTPS和SSL/TLS。

讓我們來看一個(gè)實(shí)際的例子。假設(shè)你正在運(yùn)行一個(gè)WordPress網(wǎng)站，而該網(wǎng)站會(huì)使用一個(gè)插件來將支付卡信息傳輸?shù)礁犊钐峁┥痰姆?wù)器上。典型的做法是通過為HTTPS配置的cURL——cURL還能處理連接的SSL/TLS身份驗(yàn)證問題。

“但是Arciszewski最近發(fā)現(xiàn)，當(dāng)cURL用來通過HTTPS連接下載或發(fā)送數(shù)據(jù)時(shí)，許多CMS插件和PHP庫的開發(fā)人員都會(huì)禁用cURL安全特性?！?/p>

這顯然是有問題的，因?yàn)榻靡韵氯魏我环N設(shè)置都可能導(dǎo)致無數(shù)問題。

第一個(gè)設(shè)置是“CURLOPT_SSL_VERIFYPEER”，它應(yīng)該設(shè)置為真（或者值為1）。不幸的是，許多插件都將其設(shè)置為了假（0），這意味著它遭到了禁用，cURL將不再驗(yàn)證它所連接的網(wǎng)站的URL。我真的覺得所有人都不需要很多額外的上下文，就能理解為什么這句話是非常危險(xiǎn)的。

當(dāng)“CURLOPT_SSL_VERIFYPEER”被設(shè)置為假時(shí)，cURL與網(wǎng)站進(jìn)行連接所需的唯一東西就是一個(gè)有效的SSL/TLS證書。無論誰發(fā)行了它，無論它是否是來自可以任意進(jìn)行簽發(fā)的免費(fèi)CA的免費(fèi)DV證書，只要它是有效的，cURL就會(huì)連接。

另一個(gè)被錯(cuò)誤配置的cURL設(shè)置是“CURLOPT_SSL_VERIFYHOST”。這也依賴于一個(gè)值。它應(yīng)該設(shè)置為2，因?yàn)橄到y(tǒng)需要對(duì)服務(wù)器的SSL/TLS證書進(jìn)行更嚴(yán)格的驗(yàn)證。許多插件都將其設(shè)置為了0，這意味著cURL甚至將可以接受自簽名證書。同樣，不需要太多的上下文我們就可以理解為什么這是十分危險(xiǎn)的——尤其是當(dāng)我們討論付款插件時(shí)。

為什么會(huì)這樣，我能做什么？

讓我們從原因開始。對(duì)于這些插件和庫的創(chuàng)建者來說，這與其說是一種惡意行為，不如說是一種逃避行為。當(dāng)這些插件和庫配置了更多的安全優(yōu)先的關(guān)注時(shí)，它們往往會(huì)產(chǎn)生一些錯(cuò)誤，而這些錯(cuò)誤會(huì)對(duì)用戶提出警告。這是很糟糕的，尤其是當(dāng)轉(zhuǎn)化率處于平衡狀態(tài)時(shí)。

因此，為了避免錯(cuò)誤消息和警告所帶來的負(fù)面影響，這些創(chuàng)建者便將賭注下在了無知是福上，并且禁用了這些特性以避免引起公眾注意。

“正如Arciszewski所闡釋的那樣，這些錯(cuò)誤的原因是，cURL需要根據(jù)已知的和有效的SSL/TLS證書列表來驗(yàn)證遠(yuǎn)程HTTPS服務(wù)器的證書。在許多地方都可以下載到真實(shí)證書頒發(fā)機(jī)構(gòu)（一些允許頒發(fā)SSL/TLS證書的組織）列表。不幸的是，部分web托管服務(wù)根本不會(huì)存儲(chǔ)這個(gè)列表，同時(shí)許多服務(wù)器會(huì)將其存儲(chǔ)在不同的服務(wù)器位置上，這就使得為能夠在所有服務(wù)器上無縫工作的CMS插件和PHP庫配置cURL設(shè)置變得不可能了?！?/p>

為了解決這個(gè)問題，Arciszewski創(chuàng)建了一個(gè)名為Certainty的自定義PHP庫，該P(yáng)HP庫可以從cURL主頁定期下載一個(gè)名為CACERT.pem的文件，并將它托管在本地，以便所有網(wǎng)站都能夠擁有最新的CA列表。

對(duì)于我來說，一個(gè)起源于一些簡(jiǎn)單的事情（如服務(wù)器沒有一個(gè)有效的CA列表），但卻可能帶來真正災(zāi)難性后果的問題總是很好笑的。

但是，如果你在CMS上運(yùn)行你的網(wǎng)站，并且你擔(dān)心你的某個(gè)插件可能出現(xiàn)問題，請(qǐng)嘗試Scott的解決方案。你是絕對(duì)承受不起SSL/TLS加密遭到破壞的嚴(yán)重后果的。