摘要：因?yàn)榈栏窭沟拇蠖鄶?shù)作品并沒(méi)有注明日期，所以，我不確定他是否是在年創(chuàng)造了這個(gè)術(shù)語(yǔ)。但這并不能說(shuō)明是魔鬼，這只是開(kāi)發(fā)工作流程中的一點(diǎn)問(wèn)題。中間人攻擊被認(rèn)為是的永遠(yuǎn)存在的危險(xiǎn)，會(huì)受到蠕蟲(chóng)的的攻擊。

原文來(lái)自：https://www.nczonline.net/blog/2013/06/25/eval-isnt-evil-just-misunderstood/ 作者：Nicholas C.Zakas

在JavaScript中，我不確定是否有比eval()受到更多誹謗的。它就是個(gè)簡(jiǎn)單的函數(shù)被設(shè)計(jì)用來(lái)將字符串轉(zhuǎn)換為可被執(zhí)行的JavaScript代碼。在我的早期的職業(yè)生涯里，它比任何其他的東西更受關(guān)注和誤解。

大多數(shù)人認(rèn)為‘eval()是魔鬼’這句話是Douglas Crockford說(shuō)的。他說(shuō)：“eval函數(shù)（及其親屬，F(xiàn)unction，setTimeout，和setInterval）提供對(duì)JavaScript編譯器的訪問(wèn)。這有時(shí)是必要的，但大多數(shù)情況，它證明這個(gè)存在是極其糟糕的代碼。因?yàn)閑val()這個(gè)特性常常被誤用”。

因?yàn)榈栏窭沟拇蠖鄶?shù)作品并沒(méi)有注明日期，所以，我不確定他是否是在2002年創(chuàng)造了這個(gè)術(shù)語(yǔ)。不管怎么說(shuō)吧，不管是否真正理解了eval()的使用，他都成為了一個(gè)熱門(mén)的短語(yǔ)。

盡管這種理論流行開(kāi)來(lái)了（道格拉斯的堅(jiān)持），但這并不意味著eval()的存在就有問(wèn)題。使用eval()不會(huì)自動(dòng)觸發(fā)XSS攻擊，或者你沒(méi)有意識(shí)到的但存在的安全漏洞。就像工具一樣，你要知道如何使用它，但即使你使用不正確，但潛在風(fēng)險(xiǎn)依然很低，并且是可容忍的。

eval()之所以成為了魔鬼，是因?yàn)槟切?duì)JavaScript語(yǔ)言理解不夠深的人誤用的原因。你可能會(huì)奇怪，誤用跟安全和性能好型沒(méi)有關(guān)系吧。誤用是不理解如何在JavaScript中構(gòu)造和使用引用。假設(shè)你有幾個(gè)表單input的名字包含數(shù)字，如：option1，option2，常見(jiàn)的代碼實(shí)現(xiàn)如下：

function isChecked(optionNumber) {
    return eval("forms[0].option" + optionNumber + ".checked");
}

var result = isChecked(1);

在這種情況下，開(kāi)發(fā)人員在盡力嘗試寫(xiě)forms[0].option1.checked，而沒(méi)有想我不用eval()該如何做。這樣的情況出現(xiàn)在很多10年左右工作經(jīng)驗(yàn)的開(kāi)發(fā)者，它們不明白如何更好地使用。這里也不是說(shuō)eval()在這里不合適，而是因?yàn)闆](méi)有必要，你完全可以更簡(jiǎn)單的實(shí)現(xiàn)，用如下的代碼：

function isChecked(optionNumber) {
    return forms[0]["option" + optionNumber].checked;
}

var result = isChecked(1);

在很多情況下，你可以使用[]表示法來(lái)替換eval()的使用去構(gòu)造屬性名，這也是 [] 存在的一個(gè)原因。包括道格拉斯在內(nèi)的早期博主們都是在討論這個(gè)問(wèn)題。

不使用eval()的一個(gè)重要理由是為了達(dá)到調(diào)試的目的。以前，如果出現(xiàn)問(wèn)題，不可能進(jìn)入eval()代碼。這就意味著你的代碼運(yùn)行在一個(gè)黑盒中，然后從中取出?，F(xiàn)在Chrome開(kāi)發(fā)工具可以調(diào)試eval()內(nèi)的代碼，但是有一個(gè)問(wèn)題是，你必須等代碼執(zhí)行一次后才出現(xiàn)在源面板中。

不使用eval()可以令我們的代碼調(diào)試起來(lái)更容易，跟方便的查看源代碼。但這并不能說(shuō)明eval()是魔鬼，這只是開(kāi)發(fā)工作流程中的一點(diǎn)問(wèn)題。

對(duì)eval()的另一個(gè)重要影響是它的性能。在舊的瀏覽器中，你遇到了雙重解釋?xiě)土P，也就是說(shuō)，你的代碼被解釋，而eval()中的代碼被解釋。在沒(méi)有編譯JavaScript引擎的瀏覽器中，結(jié)果可能會(huì)慢十倍(甚至更糟)。

在現(xiàn)代編譯JavaScript的引擎中，eval()仍然是一個(gè)問(wèn)題。大多數(shù)引擎可以用兩種方式運(yùn)行代碼:快速路徑或慢路徑。快速路徑代碼是一種穩(wěn)定且可預(yù)測(cè)的代碼，因此可以為更快的執(zhí)行而編譯。緩慢的路徑代碼是不可預(yù)測(cè)的，這使得編譯很難，并且可能仍然使用一個(gè)解釋程序運(yùn)行。在你的代碼中僅僅存在eval()意味著它是不可預(yù)測(cè)的，因此將在解釋器中運(yùn)行它以“舊瀏覽器”的速度運(yùn)行，而不是“新瀏覽器”的速度(10倍的差異)。

同樣的，eval()使YUI壓縮器不可能在調(diào)用eval()的范圍內(nèi)munge變量名。由于eval()可以直接訪問(wèn)任何這些變量，重命名它們會(huì)引入錯(cuò)誤(其他工具如閉包編譯器和UglifyJS可能仍然會(huì)蒙混這些變量——最終導(dǎo)致錯(cuò)誤)。

因此，在使用eval()時(shí)，性能仍然是一個(gè)大問(wèn)題。但這很難讓它成為邪惡，但這是一個(gè)需要注意的警告。

在說(shuō)到eval()的安全時(shí)，這是大部分人認(rèn)為eval是魔鬼的有力佐證。大多數(shù)情況下，就是說(shuō)XSS攻擊，以及eval()如何向它們打開(kāi)代碼。在表面上，這種混淆是可以理解的，因?yàn)閑val()在頁(yè)面上下文中可執(zhí)行任意代碼。如果你接受用戶輸入并通過(guò)eval()運(yùn)行它，這將是危險(xiǎn)的。但是，如果你的輸入不是來(lái)自用戶，是否存在真正的危險(xiǎn)?

我收到了不止一個(gè)的抱怨，在我的CSS解析器中使用eval()的一段代碼中使用的代碼使用eval()將字符串標(biāo)記從CSS轉(zhuǎn)換為JavaScript字符串值。除了創(chuàng)建自己的字符串解析器外，這是獲得token的正確字符串值的最簡(jiǎn)單方法。到目前為止，還沒(méi)有人能夠或愿意提出一種攻擊方案，在這種情況下，這段代碼會(huì)引起麻煩，因?yàn)?

eval()的值來(lái)自于tokenizer

tokenizer已經(jīng)驗(yàn)證了它是一個(gè)有效的字符串

代碼最常在命令行上運(yùn)行。

即使在瀏覽器中運(yùn)行，該代碼也被封閉在閉包中，不能直接調(diào)用。

當(dāng)然，由于這段代碼的主要目標(biāo)是命令行，所以這個(gè)故事有點(diǎn)不同。

設(shè)計(jì)用于瀏覽器的代碼面臨不同的問(wèn)題，但是eval()的安全性通常不是其中之一。同樣，如果你以某種方式接收用戶輸入并將其傳遞給eval()，那么你就是在自找麻煩，不要這樣做。但是，如果你使用eval()的輸入，只有你控制并且不能被用戶修改，那么就沒(méi)有安全風(fēng)險(xiǎn)。

最常見(jiàn)的攻擊是來(lái)自服務(wù)器的eval()代碼。這一模式以引入JSON而著名，它之所以流行，是因?yàn)樗梢酝ㄟ^(guò)eval()快速轉(zhuǎn)換成JavaScript。實(shí)際上，Douglas Crockford自己在他的原始JSON實(shí)用程序中使用eval()，因?yàn)樗梢赞D(zhuǎn)換速度。他確實(shí)添加了檢查以確保沒(méi)有真正的可執(zhí)行代碼，但是實(shí)現(xiàn)從根本上是eval()。

現(xiàn)在，大多數(shù)人都使用瀏覽器內(nèi)置的JSON解析功能來(lái)實(shí)現(xiàn)這一目的，盡管有些人仍然通過(guò)eval()來(lái)獲取任意的JavaScript，作為延遲加載策略的一部分。一些人認(rèn)為，這才是真正的安全漏洞。如果正在進(jìn)行中間人攻擊，那么你將在頁(yè)面上執(zhí)行任意攻擊代碼。

中間人攻擊被認(rèn)為是eval()的永遠(yuǎn)存在的危險(xiǎn)，會(huì)受到蠕蟲(chóng)的的攻擊。但是，這是一個(gè)與我無(wú)關(guān)的場(chǎng)景，因?yàn)槿魏螘r(shí)候你不能相信你正在聯(lián)系的服務(wù)器，就意味著有可能出現(xiàn)很多不好的事情。中間人攻擊可以通過(guò)多種方式向頁(yè)面注入代碼:

返回通過(guò) 加載的JavaScript代碼。

通過(guò)返回攻擊者控制的JSON-P請(qǐng)求代碼。

通過(guò)從一個(gè)Ajax請(qǐng)求返回attacker控制的代碼，然后eval()。

此外，這樣的攻擊可以很容易地竊取cookie和用戶數(shù)據(jù)，而不會(huì)改變?nèi)魏螙|西，更不用說(shuō)通過(guò)返回攻擊者控制的HTML和CSS來(lái)進(jìn)行網(wǎng)絡(luò)釣魚(yú)的可能性了。

簡(jiǎn)單地說(shuō)，eval()不會(huì)像加載外部JavaScript那樣打開(kāi)中間人攻擊。如果你不能信任服務(wù)器上的代碼，那么你將遇到比eval()調(diào)用更大的問(wèn)題。

我不是說(shuō)你應(yīng)該跑出去，開(kāi)始使用eval()。實(shí)際上，很少有好的用例來(lái)運(yùn)行eval()。對(duì)于代碼清晰性、調(diào)試性，以及不應(yīng)該忽略的性能，確實(shí)存在一些問(wèn)題。但是在eval()有意義的情況下，你不應(yīng)該害怕使用它。不要第一次使用它，但是不要讓任何人嚇到你，認(rèn)為你的代碼在使用eval()時(shí)更加脆弱或不安全。

文章稍后可能還會(huì)繼續(xù)修改，也歡迎各位批評(píng)指正。有問(wèn)題或者有其他想法的可以在我的GitHub上pr。