幾個(gè)Web前端開(kāi)發(fā)框架的比較

原文在我的博客中，歡迎大家來(lái)訪交流

強(qiáng)調(diào)一下，這篇日志主要還是針對(duì)想學(xué)前端開(kāi)發(fā)的新朋友寫(xiě)的，不是說(shuō)我有什么獨(dú)特見(jiàn)解，而是比較客觀的狀態(tài)，就各種框架的異同和應(yīng)用場(chǎng)合，需要注意的地方做簡(jiǎn)單描述，不做具體深入分析，有的地方比較抽象，對(duì)于抽象之處大家可以到網(wǎng)上或各大高手博客中深入學(xué)習(xí)，當(dāng)然也可以與我繼續(xù)探討。

一直以來(lái)對(duì)Web前端開(kāi)發(fā)興趣頗深，用過(guò)一些框架產(chǎn)品。在JavaEye上看到一些剛接觸前端開(kāi)發(fā)朋友的疑問(wèn)，猶豫這些產(chǎn)品的前景利弊，不知從何入手。想把自己的一點(diǎn)經(jīng)驗(yàn)分享給大家，如有不到位之處請(qǐng)一起來(lái)糾正。

jQuery

1.絕對(duì)的萬(wàn)金油，核心js只有50K，占用帶寬小，門(mén)戶(hù)網(wǎng)站、管理系統(tǒng)，用在哪都可以。2.jQuery是對(duì)js底層dom操作封裝最薄的一個(gè)框架，沒(méi)有大量的專(zhuān)有對(duì)象，多為提供函數(shù)進(jìn)行dom操作。準(zhǔn)確的說(shuō)，它不是偏重于富客戶(hù)端的框架，而是側(cè)重于對(duì)jsdom編程。下面幾種才是完整的富客戶(hù)端的框架。

3.我認(rèn)為它最大的三個(gè)亮點(diǎn)，一是支持CSS3的大量選擇符，想定位或選擇一個(gè)html元素簡(jiǎn)直輕而易舉。二是靈活便捷的Ajax請(qǐng)求和回調(diào)操作。三是事件綁定功能，內(nèi)部封裝了很多事件，想統(tǒng)一為一個(gè)頁(yè)面上的一些元素添加事件很方便，這也提高了復(fù)用性和可維護(hù)性，避免了頁(yè)面中出現(xiàn)大量的html屬性。合理的編碼可以使html與js,css分離開(kāi)，便于維護(hù)。4.此外它也封裝了很多常用的操作，例如節(jié)點(diǎn)的添加刪除、常用的動(dòng)畫(huà)效果、邏輯判斷比較等等。避免了直接使用domapi進(jìn)行繁瑣的操作。

5.本身提供了可擴(kuò)展的函數(shù)，可以自己編寫(xiě)插件與核心jQuery對(duì)象進(jìn)行集成使用。這也是常用的手段，只要你理解js面向?qū)ο缶幊蹋�熟悉jQueryAPI，就能寫(xiě)出很多定制的插件，復(fù)用在各種地方。

6.至于jQueryUI，與其他框架不一樣的地方在于，它很少用js去生成html，而是把現(xiàn)有的html通過(guò)jQueryUI的API加工成想要的效果，關(guān)于這點(diǎn)是好是壞，我覺(jué)得就是見(jiàn)仁見(jiàn)智的問(wèn)題了，沒(méi)有必要爭(zhēng)論什么。7.新生的jQueryEasyUI不錯(cuò)。

8.如果今后的更新都保持現(xiàn)在這種模式，我認(rèn)為它的前景很樂(lè)觀，什么時(shí)候javascript完蛋了才輪到它玩完。

ExtJS

1.一整套帶有UI的js庫(kù)，封裝得很多，很厚，核心js就600多K，這么大的東西門(mén)戶(hù)網(wǎng)站當(dāng)然就別想了，里面的效果當(dāng)然也不會(huì)運(yùn)用到門(mén)戶(hù)網(wǎng)站，所以它是專(zhuān)門(mén)為管理系統(tǒng)而生的。因?yàn)榫钟蚓W(wǎng)不會(huì)有帶寬問(wèn)題。

2.它與jQuery不同，基本上是純用js來(lái)生成html的，頁(yè)面里只需引入各個(gè)ExtJS庫(kù)和你自己寫(xiě)的js，不會(huì)出現(xiàn)很多html內(nèi)容，body里基本沒(méi)什么。所以?xún)?yōu)化就顯得重要了，不然會(huì)嚴(yán)重浪費(fèi)資源。

3.UI就不說(shuō)了，大家都認(rèn)可，本來(lái)就是為UI而生，它可以做出來(lái)桌面級(jí)程序的效果。一般來(lái)說(shuō)，一個(gè)管理系統(tǒng)的項(xiàng)目如果用Ext，基本就從始至終都是Ext做了，不會(huì)像jQuery那樣，哪想要了就加在哪，很隨意。Ext更像一個(gè)整體(雖然它也可以拆開(kāi)用，不過(guò)麻煩，不建議)。4.提供了對(duì)其他js框架的適配，像對(duì)jQuery,prototype等。沒(méi)實(shí)際應(yīng)用過(guò)，就不說(shuō)了。5.理解js面向?qū)ο缶幊淘趀xt中很重要，如果你覺(jué)得用jQuery時(shí)了解簡(jiǎn)單的dom和css即可，那你在這就吃大虧了，Ext處處離不開(kāi)對(duì)象的概念。

6.Ext的UI開(kāi)發(fā)類(lèi)似C#，有很多控件。不同的是，你要全部自己手寫(xiě)，所以開(kāi)發(fā)量較大�，F(xiàn)在雖然有ExtDesigner可視化工具，但其效果并不很好，生成的代碼有的往往不是想要的，不易維護(hù)，真做起來(lái)還是自己寫(xiě)更方便。

7.團(tuán)隊(duì)開(kāi)發(fā)時(shí)，必須保證做UI的人每人都會(huì)Ext，而且深入應(yīng)用過(guò)，因?yàn)镋xt項(xiàng)目是整體，不適于參雜html替代。

8.Ext項(xiàng)目在IE系列瀏覽器上不可用，相當(dāng)卡，我想這不是Ext本身的問(wèn)題，所謂內(nèi)存泄露等問(wèn)題現(xiàn)在早已解決了，而且不是關(guān)鍵所在。我開(kāi)很多網(wǎng)頁(yè)同時(shí)用IE8看jQuery.net官網(wǎng)時(shí)有時(shí)也會(huì)卡，試想他們官網(wǎng)肯定做到很好的優(yōu)化了吧，jQuery既是如此，何況Ext。反觀其他瀏覽器，F(xiàn)ireFox,Chrome等瀏覽Ext項(xiàng)目都很流暢，所以應(yīng)該是瀏覽器對(duì)js解析不同造成的。

9.版權(quán)問(wèn)題，Ext運(yùn)用在商業(yè)項(xiàng)目中是收費(fèi)的。

Flex[自己也是在學(xué)習(xí)中，不敢妄言，以后深入應(yīng)用后再做補(bǔ)充]

1.Adobe平臺(tái)的，基于ActionScript實(shí)現(xiàn)，用在哪都行，但偏重于內(nèi)網(wǎng)管理系統(tǒng)，用在門(mén)戶(hù)網(wǎng)站就相當(dāng)于在線(xiàn)玩Flash游戲，loading...

2.與Ext不同，它有健壯的可視化開(kāi)發(fā)工具FlashBuilder，可以同C#一樣進(jìn)行拖拽布局，生成一種xml，也便于維護(hù)。

3.編譯后生成swf文件直接嵌入html即可，提高安全性，瀏覽時(shí)同flash，需要flashplayer。4.與Ext相同，也是屬于一個(gè)整體，有豐富的控件庫(kù)。

5.這條純屬個(gè)人觀點(diǎn)，HTML5不支持插入對(duì)象，也就意味著不能插入swf文件，難道Flex就完蛋了？雖然HTML5不支持Flash是客觀事實(shí)，但HTML5的統(tǒng)一為時(shí)尚遠(yuǎn)，各大瀏覽器對(duì)HTML5的支持，Adobe是否會(huì)有對(duì)策，這些會(huì)怎么樣現(xiàn)在都不好說(shuō)，HTML5與HTML4并行應(yīng)該會(huì)有很長(zhǎng)一段時(shí)間，至少Flex在現(xiàn)在是一個(gè)名列前茅的好產(chǎn)品，所以我選擇了它。

SilverLight

微軟平臺(tái)的，主要是應(yīng)用在微軟系列的語(yǔ)言中，包括CS與BS架構(gòu)。同樣，除了jQuery，Asp.net也不適合與以上等框架集成，因?yàn)锳sp.net是事件驅(qū)動(dòng)，這些框架都是為消息驅(qū)動(dòng)而生的，勉強(qiáng)應(yīng)用只會(huì)事倍功半，喪失.net本身的優(yōu)勢(shì)。

js面向?qū)ο缶幊涛乙恢痹谔�，其�?shí)并不難理解，關(guān)于這點(diǎn)應(yīng)該學(xué)習(xí)下，很有必要。它涉及到代碼復(fù)用、功能擴(kuò)展、對(duì)象繼承、閉包、優(yōu)化等很多問(wèn)題，能省去不少編碼，便于維護(hù)，還能不改變框架源代碼而實(shí)現(xiàn)不同的功能。

閑話(huà)不多說(shuō)了，希望能給剛走進(jìn)前端開(kāi)發(fā)的朋友一點(diǎn)幫助。以后可能還會(huì)就js面向?qū)ο缶幊淘賹?xiě)一篇日志，有興趣可以來(lái)看看。我的QQ是421557193，有興趣可以與我交流，請(qǐng)注明是IT同行。

擴(kuò)展閱讀：Web開(kāi)發(fā)框架安全雜談

Web開(kāi)發(fā)框架安全雜談

Writebyadminin未分類(lèi)at201*-03-1522:21:03Web開(kāi)發(fā)框架安全雜談EMail:wofeiwo#80sec.comSite:Date:201*-03-14

From:[目錄](méi)0×00起0×01承0×02轉(zhuǎn)0×03合0×00起

最近框架漏洞頻發(fā)，struts任意代碼執(zhí)行、Djangocsrftoken防御繞過(guò)、Cakephp代碼執(zhí)行等等各大語(yǔ)言編程框架都相繼暴出高危漏洞，這說(shuō)明對(duì)于編程框架的安全問(wèn)題已經(jīng)逐漸走入安全工作者的視線(xiàn)。Web開(kāi)發(fā)框架就相當(dāng)于web應(yīng)用程序的操作系統(tǒng)，他決定了一個(gè)應(yīng)用程序的模型結(jié)構(gòu)和編程風(fēng)格�？蚣苌铣隽寺┒�，就如同當(dāng)年一個(gè)rpc遠(yuǎn)程EXP就走遍全世界windows的時(shí)代。

然而挖掘深層原因，從應(yīng)用的模型和架構(gòu)上考慮問(wèn)題，其實(shí)這些框架漏洞都不只是一種偶然，而是一種必然。正是因?yàn)榭蚣艿哪Ｐ徒Y(jié)構(gòu)，正因?yàn)樗麄兊倪@種編程風(fēng)格，才極大的增加了漏洞產(chǎn)生的可能性。0×01承

現(xiàn)代編程框架的幾個(gè)大特點(diǎn)：

1、將程序代碼分為不同層次，業(yè)務(wù)開(kāi)發(fā)、前端開(kāi)發(fā)、數(shù)據(jù)庫(kù)開(kāi)發(fā)人員各司其職，框架根據(jù)需要組裝代碼、調(diào)度執(zhí)行

2、統(tǒng)一化自動(dòng)化邏輯處理

3、常見(jiàn)功能的代碼庫(kù)封裝并高度重用

4、腳手架功能，常見(jiàn)代碼組件自動(dòng)組裝生成。如默認(rèn)用戶(hù)系統(tǒng)、默認(rèn)后臺(tái)。然而就是以上幾點(diǎn)廣受好評(píng)的功能導(dǎo)致了安全薄弱點(diǎn)的產(chǎn)生。1、代碼調(diào)度

讓我們來(lái)先回顧一下WEB應(yīng)用框架所最常見(jiàn)的MVC模型。

用戶(hù)發(fā)送一個(gè)HTTP請(qǐng)求過(guò)來(lái)，框架的入口點(diǎn)（一般是route，路由）分析用戶(hù)請(qǐng)求的url。然后依照url中蘊(yùn)含的信息分析出用戶(hù)所要訪問(wèn)的controller、action，從而分發(fā)給相應(yīng)的controller文件中的action函數(shù)，執(zhí)行之；隨后controller再將model中的數(shù)據(jù)結(jié)合用戶(hù)輸入數(shù)據(jù)依照view層中的代碼邏輯填充模板，最后view、controller執(zhí)行完畢，返回用戶(hù)最后的HTML。整個(gè)生命周期是這樣的：

用戶(hù)請(qǐng)求url->route分發(fā)->controller接管處理用戶(hù)輸入及業(yè)務(wù)邏輯->view層代碼執(zhí)行->controller返回展現(xiàn)結(jié)果

從上面的流程發(fā)現(xiàn)了什么？

MVC模型就是一個(gè)將程序員分散在M、C、V中的代碼尋找并整合在一起執(zhí)行的過(guò)程。那這必然就要牽涉到一個(gè)代碼調(diào)度執(zhí)行的問(wèn)題。這里route就是一個(gè)非常明顯的例子。一個(gè)框架這么多代碼文件，route每一次調(diào)用controller，都需要根據(jù)用戶(hù)輸入的url進(jìn)行匹配并執(zhí)行用戶(hù)指定的函數(shù)。這里就是一個(gè)薄弱點(diǎn)，一個(gè)必然繞不過(guò)去的問(wèn)題。

對(duì)應(yīng)到現(xiàn)實(shí)的例子，一個(gè)非常明顯的例子就是：struts2框架的動(dòng)態(tài)方法調(diào)用（DMI）

當(dāng)你訪問(wèn)!test.action時(shí)，struts會(huì)根據(jù)你的url幫你映射到名為a的controller中名為test的Action方法。而通過(guò)修改test的值，我們可以訪問(wèn)a這個(gè)類(lèi)中的所有方法。如果恰好這個(gè)方法中含有敏感的信息，攻擊者就獲得了一切。結(jié)合其他技巧，攻擊者能夠做到的更多。但這就是框架的功能，框架總是要依靠URL中的內(nèi)容去匹配執(zhí)行程序代碼。

那么對(duì)于PHP的框架呢？仔細(xì)想一下，如果PHP需要做分散在不同文件中的代碼調(diào)度執(zhí)行，唯一能夠?qū)崿F(xiàn)的方式就是使用require/include函數(shù)包含文件。文件名來(lái)源于哪里？來(lái)源于用戶(hù)輸入的URL。實(shí)際上目前市面上的大部分PHP框架也都是這么實(shí)現(xiàn)的，Yii，F(xiàn)leaPHP等等。如果對(duì)用戶(hù)的輸入沒(méi)有做好驗(yàn)證，就很容易導(dǎo)致一個(gè)本地文件包含漏洞。筆者曾經(jīng)就在某不知名框架中發(fā)現(xiàn)過(guò)這樣的漏洞，在不涉及應(yīng)用程序邏輯的情況下，直接獲取了系統(tǒng)權(quán)限。2、統(tǒng)一化邏輯處理

框架的一大功能就是，通過(guò)統(tǒng)一的入口點(diǎn)，可以做一些統(tǒng)一的安全防護(hù)、邏輯控制。在軟件工程學(xué)里的說(shuō)法，這個(gè)叫“面向切面編程”（AOP）。

然而我們并不是說(shuō)這樣的統(tǒng)一控制模式不好，但對(duì)于這樣的統(tǒng)一控制，如果框架設(shè)計(jì)或?qū)崿F(xiàn)的不好，就能直接淪陷所有跑在之上的應(yīng)用。

這里有一個(gè)典型的統(tǒng)一處理導(dǎo)致安全問(wèn)題的極端的例子：struts2任意代碼執(zhí)行漏洞。

漏洞起因是struts2希望能讓用戶(hù)提交的值能夠直接注入到程序中的數(shù)據(jù)對(duì)象，而無(wú)需手動(dòng)類(lèi)型轉(zhuǎn)換并給內(nèi)部變量賦值等操作。為此struts2專(zhuān)門(mén)設(shè)計(jì)了一個(gè)叫做ognl的表達(dá)式。通過(guò)它，用戶(hù)提交的參數(shù)就能被自動(dòng)解析為程序上下文中所存在的變量。

想想為什么能夠自動(dòng)解析？原因是用戶(hù)提交的參數(shù)被當(dāng)作自定義語(yǔ)言的代碼被解析執(zhí)行了！只是你并沒(méi)有意識(shí)到這一點(diǎn)而已。于是有心人研究了一下，發(fā)現(xiàn)ognl表達(dá)式除了參數(shù)值注入，還能通過(guò)它直接調(diào)用Java自身的API。于是，一個(gè)巨大的通殺0day就這么誕生了。

回想一下，如果struts2沒(méi)有這么“智能”的自動(dòng)化、統(tǒng)一化用戶(hù)輸入處理機(jī)制，也就不會(huì)出現(xiàn)上述的大漏洞了。

前段時(shí)間爆出的Django的csrftoken繞過(guò)漏洞也是在統(tǒng)一安全處理的設(shè)計(jì)上出的問(wèn)題。深究一下，為什么會(huì)出現(xiàn)這樣的繞過(guò)問(wèn)題？原因就是，框架必須要對(duì)所有用戶(hù)的提交在真正的應(yīng)用執(zhí)行前做統(tǒng)一的csrf防范，于是django框架產(chǎn)生的token是保存在cookie中的（老版本和sessionid有關(guān)，這個(gè)也是保存在cookie中）。對(duì)于用戶(hù)提交的POST請(qǐng)求，表單中增加一項(xiàng)token，框架在獲得token值后，與cookie中的正確token值比對(duì)，如果相等就通過(guò)。然而對(duì)于ajax的請(qǐng)求，框架設(shè)計(jì)者卻想當(dāng)然的認(rèn)為只要判斷X-Requested-With這個(gè)Ajax特有的HTTP頭即可，根本無(wú)需運(yùn)算比對(duì)token。所以，框架對(duì)于http頭中包含有X-Requested-With域的請(qǐng)求放行。通常情況下，只有ajax的請(qǐng)求瀏覽器才會(huì)帶上此自定義域，且瀏覽器一般無(wú)法自定義此字段。

結(jié)果被人發(fā)現(xiàn)可以利用flash+307跳轉(zhuǎn)可以偽造自定義http頭，結(jié)果就繞過(guò)了此防范，導(dǎo)致統(tǒng)一的csrf防護(hù)毫無(wú)作用。如果應(yīng)用程序完全依靠框架的統(tǒng)一安全實(shí)現(xiàn)，就會(huì)受到安全漏洞的威脅。

其實(shí)Django也很無(wú)奈，在它的架構(gòu)設(shè)計(jì)中，它通過(guò)這個(gè)自定義頭判斷ajax思路上也沒(méi)有什么問(wèn)題。可惜在目前連黃瓜都不可靠的年代，就沒(méi)什么是可靠的了。3、常見(jiàn)代碼高度封裝

代碼的高度封裝，對(duì)外只暴露幾個(gè)接口，一行說(shuō)明書(shū)。這必然造成一種現(xiàn)象：普通程序員就像是在搭建一個(gè)模型，只要按照說(shuō)明書(shū)組建積木就可以了，不需要知曉其原理，不需要知道為什么要這樣做。于是這時(shí)候就安全問(wèn)題就產(chǎn)生了。

舉一個(gè)同樣在用戶(hù)輸入?yún)��?shù)自動(dòng)化處理方面的例子：在PHP的ZendFramework中，獲取用戶(hù)輸入是調(diào)用getParam方法，而不是常見(jiàn)PHP程序中分開(kāi)來(lái)的$_GET、$_POST等變量。那么，如果同時(shí)在GET、POST、COOKIE、HEADER中提交相同名字的參數(shù)，getParam到底獲取的是哪一個(gè)的值？先后順序是什么？如果前后可以覆蓋，會(huì)不會(huì)影響到我們自定義的一些統(tǒng)一安全措施？這是一個(gè)值得檢查的安全薄弱點(diǎn)。

再舉一個(gè)struts2的例子：對(duì)于常見(jiàn)的文件上傳場(chǎng)景，struts提供了一個(gè)FileUploadInterceptor攔截器，直接可以在應(yīng)用邏輯運(yùn)行前對(duì)用戶(hù)上傳文件進(jìn)行檢查。然而在筆者的代碼審計(jì)經(jīng)驗(yàn)中，常常發(fā)現(xiàn)程序員只對(duì)maximumSize（文件大小）和allowedTypes（文件mime-type）進(jìn)行限制，卻放過(guò)了最關(guān)鍵的allowedExtensions（擴(kuò)展名）限制。為什么？筆者檢查了一下官方文檔，發(fā)現(xiàn)在struts2.2之前的文檔，都沒(méi)有給出allowExtensions的說(shuō)明�；蛟Sstruts開(kāi)發(fā)者想當(dāng)然的認(rèn)為allowedTypes就可以限制上傳文件的類(lèi)型，殊不知只要偽造HTTP包中的mime-type字段，就可以直接上傳任意文件。于是開(kāi)發(fā)者也就依照官方的例子，只限制了allowdTypes，從而導(dǎo)致安全問(wèn)題的產(chǎn)生。

高度代碼封裝的確解決了“重復(fù)造輪子”的問(wèn)題，但是它解決不了程序員的安全意識(shí)和懶惰的習(xí)慣。或許它設(shè)計(jì)的很好，或許它實(shí)現(xiàn)的也很好，但是只要它組裝的不好，就有可能造成問(wèn)題。4、腳手架功能

Django的腳手架功能是非常好用的。它默認(rèn)自帶了一些app，只要通過(guò)幾個(gè)簡(jiǎn)單的命令或配置，就可以在不敲一句代碼的情況下搭起一個(gè)普通網(wǎng)站的腳手架，自帶了用戶(hù)注冊(cè)、登陸等系統(tǒng)，甚至還有一個(gè)默認(rèn)的管理員后臺(tái)。

然而正如上文所說(shuō)，普通程序員并不了解框架真正做了些什么。他很有可能通過(guò)腳手架生成網(wǎng)站后，卻直接忘卻了程序自帶的內(nèi)容沒(méi)有去除。當(dāng)這樣的網(wǎng)站上線(xiàn)后。我們發(fā)現(xiàn)他是Django所寫(xiě)，那我們就可以直接嘗試在url后加入/admin/路徑訪問(wèn)，直接猜解后臺(tái)管理員密碼。此外如果框架自帶的默認(rèn)后臺(tái)出現(xiàn)安全漏洞，甚至可能直接繞過(guò)進(jìn)入后臺(tái)。

一旦使用框架默認(rèn)的組件，就得考慮到框架所帶來(lái)的默認(rèn)功能的安全問(wèn)題。其實(shí)這問(wèn)題可以擴(kuò)大，tomcat自帶的后臺(tái)、fck編輯器自帶的上傳組件，都可以說(shuō)屬于此類(lèi)問(wèn)題。0×02轉(zhuǎn)

框架的應(yīng)用是軟件開(kāi)發(fā)的必然趨勢(shì)，本文的目的也不在于抵制框架的使用。但對(duì)于框架應(yīng)用后所帶來(lái)的新安全問(wèn)題，安全從業(yè)人員需要提高重視，緊跟技術(shù)發(fā)展，更新知識(shí)。對(duì)于此，我們能夠做點(diǎn)什么？1、對(duì)于常見(jiàn)的應(yīng)用場(chǎng)景，如文件操作、命令行操作、數(shù)據(jù)庫(kù)操作、用戶(hù)權(quán)限及認(rèn)證等，我們需要了解框架的實(shí)現(xiàn)，給出相應(yīng)的安全編碼范例。

框架文檔中給出的例子并不一定就是最好的。安全工作者必須對(duì)程序員進(jìn)行安全意識(shí)的培訓(xùn)，讓他知道如何利用框架的API去安全的組合出常用功能。2、對(duì)于應(yīng)用漏洞挖掘，我們需要擴(kuò)充字典。

框架的封裝，可能引入更多的危險(xiǎn)API或危險(xiǎn)特性。在代碼審計(jì)的過(guò)程中，需要將這些內(nèi)容加入到危險(xiǎn)詞字典中。

3、對(duì)于應(yīng)用漏洞挖掘，由于框架結(jié)構(gòu)所帶入的新的安全薄弱點(diǎn)，需要專(zhuān)門(mén)對(duì)框架的設(shè)計(jì)及實(shí)現(xiàn)做檢查，是否存在問(wèn)題。

例如PHP框架中代碼調(diào)度執(zhí)行的實(shí)現(xiàn)、文件上傳統(tǒng)一檢查的實(shí)現(xiàn)、封裝的變量獲取形式是否可靠等。本文中提到的安全薄弱點(diǎn)只是一個(gè)例子，更多的還需要大家的共同挖掘。0×03合

實(shí)際上對(duì)于一個(gè)應(yīng)用的安全審計(jì)歸根到底就是個(gè)思路問(wèn)題。筆者一直認(rèn)為，了解程序員的思路，了解框架的思路，了解應(yīng)用的思路，這些才是安全審計(jì)中最花時(shí)間的。而實(shí)際上真槍實(shí)彈看代碼的漏洞挖掘卻只占用很小的一部分時(shí)間。

只有將這些思路融會(huì)貫通，在腦中將審計(jì)對(duì)象進(jìn)行抽象建模，了解應(yīng)用需要保護(hù)什么，弱點(diǎn)在哪里，才能更為有效和有針對(duì)性的進(jìn)行代碼審計(jì)、安全防護(hù)。

最后，非常感謝劍心及空虛浪子心之前的研究成果和意見(jiàn)，對(duì)本文的幫助極大

友情提示：本文中關(guān)于《幾個(gè)Web前端開(kāi)發(fā)框架的比較》給出的范例僅供您參考拓展思維使用，幾個(gè)Web前端開(kāi)發(fā)框架的比較：該篇文章建議您自主創(chuàng)作。

來(lái)源：網(wǎng)絡(luò)整理 免責(zé)聲明：本文僅限學(xué)習(xí)分享，如產(chǎn)生版權(quán)問(wèn)題，請(qǐng)聯(lián)系我們及時(shí)刪除。

《幾個(gè)Web前端開(kāi)發(fā)框架的比較》由互聯(lián)網(wǎng)用戶(hù)整理提供,轉(zhuǎn)載分享請(qǐng)保留原作者信息,謝謝!
鏈接地址：http://m.weilaioem.com/gongwen/585518.html

• 上一篇：網(wǎng)頁(yè)設(shè)計(jì)項(xiàng)目實(shí)訓(xùn)指導(dǎo)書(shū)
• 下一篇：web前端性能