JavaScript 常見(jiàn)安全漏洞和自動(dòng)化檢測(cè)技術(shù)
前言
隨著 Web2.0 的發(fā)展以及 Ajax 框架的普及，富客戶(hù)端 Web 應(yīng)用（Rich Internet Applications，RIA）日益增多，越來(lái)越多的邏輯已經(jīng)開(kāi)始從服務(wù)器端轉(zhuǎn)移至客戶(hù)端，這些邏輯通常都是使用 JavaScript 語(yǔ)言所編寫(xiě)。但遺憾的是，目前開(kāi)發(fā)人員普遍不太關(guān)注 JavaScript 代碼的安全性。據(jù) IBM X-Force 2011 年中期趨勢(shì)報(bào)告揭示，世界五百?gòu)?qiáng)的網(wǎng)站及常見(jiàn)知名網(wǎng)站中有 40% 存在 JavaScript 安全漏洞。本文將結(jié)合代碼向讀者展示常見(jiàn) JavaScript 安全漏洞，旨在幫助讀者能夠在日常編碼工作中規(guī)避這些安全漏洞。此外，客戶(hù)端 JavaScript 安全漏洞與服務(wù)器端安全漏洞原理略為不同，自動(dòng)化檢測(cè) JavsScript 安全漏洞目前存在較大的技術(shù)難題，本文將結(jié)合案例跟讀者分享如何利用 IBM Rational AppScan Standard Edition V8.0 新特性（JavaScript Security Analyzer，JSA）技術(shù)自動(dòng)化檢測(cè) JavaScript 安全漏洞。
JavaScript 常見(jiàn)安全漏洞
2010 年 12 月份，IBM 發(fā)布了關(guān)于 Web 應(yīng)用中客戶(hù)端 JavaScript 安全漏洞的白皮書(shū)，其中介紹了 IBM 安全研究機(jī)構(gòu)曾做過(guò)的 JavaScript 安全狀況調(diào)查。樣本數(shù)據(jù)包括了 675 家網(wǎng)站，其中有財(cái)富 500 強(qiáng)公司的網(wǎng)站和另外 175 家著名網(wǎng)站，包括 IT 公司、Web 應(yīng)用安全服務(wù)公司、社交網(wǎng)站等。為了不影響這些網(wǎng)站的正常運(yùn)行，研究人員使用了非侵入式爬蟲(chóng)，僅掃描了無(wú)需登錄即可訪問(wèn)的部分頁(yè)面，每個(gè)站點(diǎn)不超過(guò) 200 個(gè)頁(yè)面。這些頁(yè)面都被保存下來(lái)，研究人員采用 IBM 的 JavaScript 安全分析技術(shù)離線分析了這些頁(yè)面，集中分析了基于 DOM 的跨站點(diǎn)腳本編制及重定向兩種漏洞。
測(cè)試結(jié)果令人驚嘆，這些知名網(wǎng)站中有 14% 存在嚴(yán)峻的 JavaScript 安全問(wèn)題，黑客可以利用這些漏洞進(jìn)行植入流氓軟件，植入釣魚(yú)站點(diǎn)，以及劫持用戶(hù)會(huì)話等。更令人驚嘆不已的是，隨著 IBM 的 JavaScript 安全分析技術(shù)的成熟發(fā)展，2011 年中期 X-Force 報(bào)告顯示，IBM 重新測(cè)試了上述這些知名網(wǎng)站并發(fā)現(xiàn)了更多的安全漏洞，大約有 40% 的網(wǎng)站存在 JavaScript 安全漏洞。
java企業(yè)級(jí)通用權(quán)限安全框架源碼 SpringMVC mybatis or hibernate+ehcache shiro druid bootstrap HTML5
下文本文將結(jié)合代碼向讀者展示常見(jiàn)這些 JavaScript 安全漏洞，以便讀者在實(shí)際編碼過(guò)程中注意到這些安全問(wèn)題，及早規(guī)避這些風(fēng)險(xiǎn)。
基于 DOM 的跨站點(diǎn)腳本編制
我們都聽(tīng)說(shuō)過(guò) XSS（Cross Site Script，跨站點(diǎn)腳本編制，也稱(chēng)為跨站腳本攻擊），指的是攻擊者向合法的 Web 頁(yè)面中插入惡意腳本代碼（通常是 HTML 代碼和 JavaScript 代碼）然后提交請(qǐng)求給服務(wù)器，隨即服務(wù)器響應(yīng)頁(yè)面即被植入了攻擊者的惡意腳本代碼，攻擊者可以利用這些惡意腳本代碼進(jìn)行會(huì)話劫持等攻擊?？缯军c(diǎn)腳本編制通常分為反射型和持久型：當(dāng)請(qǐng)求數(shù)據(jù)在服務(wù)器響應(yīng)頁(yè)面中呈現(xiàn)為未編碼和未過(guò)濾時(shí)，即為反射型跨站點(diǎn)腳本編制；持久型指的是包含惡意代碼的請(qǐng)求數(shù)據(jù)被保存在 Web 應(yīng)用的服務(wù)器上，每次用戶(hù)訪問(wèn)某個(gè)頁(yè)面的時(shí)候，惡意代碼都會(huì)被自動(dòng)執(zhí)行，這種攻擊對(duì)于 Web2.0 類(lèi)型的社交網(wǎng)站來(lái)說(shuō)尤為常見(jiàn)，威脅也更大。應(yīng)對(duì)跨站點(diǎn)腳本編制的主要方法有兩點(diǎn)：一是不要信任用戶(hù)的任何輸入，盡量采用白名單技術(shù)來(lái)驗(yàn)證輸入?yún)?shù)；二是輸出的時(shí)候?qū)τ脩?hù)提供的內(nèi)容進(jìn)行轉(zhuǎn)義處理。
但鮮為人知的是還有第三種跨站點(diǎn)腳本編制漏洞。2005 年 Amit Klein 發(fā)表了白皮書(shū)《基于 DOM 的跨站點(diǎn)腳本編制—第三類(lèi)跨站點(diǎn)腳本編制形式》（"DOM Based Cross Site Scripting or XSS of the Third Kind"），它揭示了基于 DOM 的跨站點(diǎn)腳本編制不需要依賴(lài)于服務(wù)器端響應(yīng)的內(nèi)容，如果某些 HTML 頁(yè)面使用了 document.location、document.URL 或者 document.referer 等 DOM 元素的屬性，攻擊者可以利用這些屬性植入惡意腳本實(shí)施基于 DOM 的跨站點(diǎn)腳本編制攻擊。
下面我們將通過(guò)一個(gè)很簡(jiǎn)單的 HTML 頁(yè)面來(lái)演示基于 DOM 的跨站點(diǎn)腳本編制原理。假設(shè)有這么一個(gè)靜態(tài) HTML 頁(yè)面（如清單 1 所示），用來(lái)展示歡迎用戶(hù)成功登錄的信息。
清單 1. 存在 DOM based XSS 的 HTML 代碼
<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system
…
</HTML>
按照該頁(yè)面 JavaScript 代碼邏輯，它會(huì)接受 URL 中傳入的 name 參數(shù)并展示歡迎信息，如清單 2 所示：
清單 2. 正常情況下的訪問(wèn) URL
http://www.vulnerable.site/welcome.html?name=Jeremy
但如果惡意攻擊者輸入類(lèi)似如下的腳本，見(jiàn)清單 3，該頁(yè)面則會(huì)執(zhí)行被注入的 JavaScript 腳本。
清單 3. 訪問(wèn) URL 中注入腳本
http://www.vulnerable.site/welcome.html?name=<script>alert(document.cookie)</script>
很明顯，受害者的瀏覽器訪問(wèn)以上 URL 的時(shí)候，服務(wù)器端會(huì)跟正常情況下一樣返回清單 1 中所示 HTML 頁(yè)面，然后瀏覽器會(huì)繼續(xù)將這個(gè) HTML 解析成 DOM，DOM 中包含的 document 對(duì)象的 URL 屬性將包含清單 3 中注入的腳本內(nèi)容，當(dāng)瀏覽器解析到 JavaScript 的時(shí)候會(huì)執(zhí)行這段被注入的腳本，跨站點(diǎn)腳本編制攻擊即成功實(shí)現(xiàn)。
值得關(guān)注的是，通過(guò)以上示例可以看出，惡意代碼不需要嵌入服務(wù)器的響應(yīng)中，基于 DOM 的跨站點(diǎn)腳本編制攻擊也能成功?？赡苣承┳x者會(huì)認(rèn)為：目前主流瀏覽器會(huì)自動(dòng)轉(zhuǎn)義 URL 中的 '<' 和 '>' 符號(hào)，轉(zhuǎn)義后的注入腳本就不會(huì)被執(zhí)行了，基于 DOM 的跨站點(diǎn)腳本編制也就不再有什么威脅了。這句話前半段是對(duì)的，但后半段就不準(zhǔn)確了。我們要意識(shí)到攻擊者可以很輕松地繞過(guò)瀏覽器對(duì) URL 的轉(zhuǎn)義，譬如攻擊者可以利用錨點(diǎn) '#' 來(lái)欺騙瀏覽器，如清單 4 所示。瀏覽器會(huì)認(rèn)為 '#' 后面的都是片段信息，將不會(huì)做任何處理。
清單 4. 訪問(wèn) URL 中結(jié)合錨點(diǎn)注入腳本
http://www.vulnerable.site/welcome.html#?name=<script>alert(document.cookie)</script>
通過(guò) URL 重定向釣魚(yú)
網(wǎng)絡(luò)釣魚(yú)是一個(gè)通稱(chēng)，代表試圖欺騙用戶(hù)交出私人信息，以便電子欺騙身份。通過(guò) URL 重定向釣魚(yú)指的是 Web 頁(yè)面會(huì)采用 HTTP 參數(shù)來(lái)保存 URL 值，且 Web 頁(yè)面的腳本會(huì)將請(qǐng)求重定向到該保存的 URL 上，攻擊者可以將 HTTP 參數(shù)里的 URL 值改為指向惡意站點(diǎn)，從而順利啟用網(wǎng)絡(luò)釣魚(yú)欺騙當(dāng)前用戶(hù)并竊取用戶(hù)憑證。清單 5 給出了較為常見(jiàn)的含有通過(guò) URL 重定向釣魚(yú)漏洞的代碼片段。
清單 5. 執(zhí)行重定向的 JavaScript 代碼片段
<SCRIPT>
…
var sData = document.location.search.substring(1);
var sPos = sData.indexOf("url=") + 4;
var ePos = sData.indexOf("&", sPos);
var newURL;
if (ePos< 0) {
newURL = sData.substring(sPos);
} else {
newURL = sData.substring(sPos, ePos);
}
window.location.href = newURL;
…
</SCRIPT>
可以看出，這些 JavaScript 腳本負(fù)責(zé)執(zhí)行重定向，新地址是從 document.location、document.URL 或者 document.referer 等 DOM 元素的屬性值中截取出來(lái)的，譬如用戶(hù)輸入清單 6 所示。
清單 6. 執(zhí)行重定向的 URL
http://www.vulnerable.site/redirect.html?url=http://www.phishing.site
顯然用戶(hù)一旦執(zhí)行了清單 6 所示 URL，將被重定向到釣魚(yú)網(wǎng)站。這個(gè)漏洞的原理很簡(jiǎn)單，比服務(wù)器端的重定向漏洞更好理解。但通過(guò) URL 重定向釣魚(yú)的情況下，釣魚(yú)站點(diǎn)的網(wǎng)址并不會(huì)被服務(wù)端攔截和過(guò)濾，因此，這個(gè)漏洞往往比服務(wù)器端重定向漏洞更具有隱蔽性。
客戶(hù)端 JavaScript Cookie 引用
Cookie 通常由 Web 服務(wù)器創(chuàng)建并存儲(chǔ)在客戶(hù)端瀏覽器中，用來(lái)在客戶(hù)端保存用戶(hù)的身份標(biāo)識(shí)、Session 信息，甚至授權(quán)信息等?？蛻?hù)端 JavaScript 代碼可以操作 Cookie 數(shù)據(jù)。如果在客戶(hù)端使用 JavaScript 創(chuàng)建或修改站點(diǎn)的 cookie，那么攻擊者就可以查看到這些代碼，通過(guò)閱讀代碼了解其邏輯，甚至根據(jù)自己所了解的知識(shí)將其用來(lái)修改 cookie。一旦 cookie 包含了很重要的信息，譬如包含了權(quán)限信息等，攻擊者很容易利用這些漏洞進(jìn)行特權(quán)升級(jí)等攻擊。
JavaScript 劫持
許多 Web 應(yīng)用程序都利用 JSON 作為 Ajax 的數(shù)據(jù)傳輸機(jī)制，這通常都容易受到 JavaScript 劫持攻擊，傳統(tǒng)的 Web 應(yīng)用程序反而不易受攻擊。JSON 實(shí)際上就是一段 JavaScript，通常是數(shù)組格式。攻擊者在其惡意站點(diǎn)的頁(yè)面中通過(guò) <SCRIPT> 標(biāo)簽調(diào)用被攻擊站點(diǎn)的一個(gè) JSON 動(dòng)態(tài)數(shù)據(jù)接口，并通過(guò) JavaScript Function Hook 等技術(shù)取得這些 JSON 數(shù)據(jù)。如果用戶(hù)登錄被攻擊網(wǎng)站后（假定其身份認(rèn)證信息是基于 Session Cookie 來(lái)保存的），又被攻擊者誘引訪問(wèn)了惡意站點(diǎn)頁(yè)面，那么，由于 <SCRIPT src="> 這種標(biāo)簽的請(qǐng)求會(huì)帶上 Cookie 信息，惡意站點(diǎn)會(huì)發(fā)送 JSON 數(shù)據(jù)獲取請(qǐng)求至被攻擊站點(diǎn)，被攻擊站點(diǎn)服務(wù)器會(huì)認(rèn)為當(dāng)前請(qǐng)求是合法的，并返回給惡意站點(diǎn)當(dāng)前用戶(hù)的相關(guān) JSON 數(shù)據(jù)，從而導(dǎo)致用戶(hù)數(shù)據(jù)泄密。整個(gè)過(guò)程相當(dāng)于一個(gè)站外類(lèi)型的跨站點(diǎn)請(qǐng)求偽造 CSRF 攻擊。
隨著 Ajax 的進(jìn)一步推廣，以及 HTML5 的逐步應(yīng)用，還有更多的客戶(hù)端安全漏洞出現(xiàn)。目前對(duì)于 JavaScript 的安全研究尚不多，新推出的 HTML5 客戶(hù)端存儲(chǔ)、跨域通信等新特型也都跟安全緊密相關(guān)，有興趣的讀者可以作進(jìn)一步閱讀。鑒于筆者知識(shí)有限，JavaScript 相關(guān)安全漏洞暫且分享這么多，下面將談?wù)?JavaScript 安全漏洞的檢測(cè)技術(shù)。
自動(dòng)化檢測(cè) JavaScript 安全漏洞
正如我們所熟知，檢測(cè)代碼安全漏洞一般有白盒檢查和黑盒檢查。白盒檢查側(cè)重于對(duì)代碼的分析，可以通過(guò)手工代碼審查，或者自動(dòng)代碼分析工具。黑盒檢查主要是模擬黑客攻擊的方式進(jìn)行滲透測(cè)試。通常而言，黑盒檢查的準(zhǔn)確度高一些，但代碼覆蓋面比較小，而白盒檢查的代碼覆蓋率較高，但誤報(bào)率比較高。兩種方式相結(jié)合能夠互相彌補(bǔ)不足，混合檢查方式將會(huì)是未來(lái)的趨勢(shì)。
結(jié)合 JavaScript 代碼而言，出于跨瀏覽器兼容、更好的 Ajax 特性需求等原因，越來(lái)越多的 Web 應(yīng)用依賴(lài)于第三方的 JavaScript 代碼庫(kù)，譬如 Dojo、JQuery 等。這些代碼庫(kù)為了降低文件大小，往往都進(jìn)行了代碼壓縮，導(dǎo)致其可讀性極差，因此手工代碼審查幾乎不具備可行性。此外，頁(yè)面 JavaScript 調(diào)用入口很多，手工對(duì)其進(jìn)行滲透測(cè)試的工作量和難度都非常大。因此，我們需要推薦使用自動(dòng)化測(cè)試工具來(lái)檢測(cè) JavaScript 安全漏洞。
Rational AppScan JSA 原理簡(jiǎn)述
JSA 是 Rational AppScan Standard V8.0 新推出的一項(xiàng) AppScan 擴(kuò)展，用來(lái)進(jìn)行執(zhí)行靜態(tài) JavaScript 分析，以檢測(cè)常見(jiàn)客戶(hù)端安全漏洞。JSA 融合了 JavaScript 靜態(tài)污點(diǎn)分析技術(shù)和網(wǎng)站動(dòng)態(tài)爬蟲(chóng)技術(shù)。簡(jiǎn)而言之，AppScan 會(huì)保存爬蟲(chóng)所探索到的所有 URL 的完整的 HTTP 響應(yīng)，然后 JSA 對(duì)這些響應(yīng)頁(yè)面逐個(gè)進(jìn)行 JavaScript 代碼分析。JSA 在分析每個(gè)頁(yè)面時(shí)應(yīng)用兩個(gè)階段：數(shù)據(jù)流分析和字符串分析。首先，JSA 查找從源（Source）到接收器（Sink）中未經(jīng)過(guò)清除工具（Sanitizer）的軌跡。如果可找到此軌跡（Trace），那么 JSA 將在第二步中使用字符串分析的變體——字符串前綴分析（SPA)進(jìn)行驗(yàn)證。相比于單純的 JavaScript 代碼靜態(tài)分析技術(shù)而言，JSA 技術(shù)更為先進(jìn)和準(zhǔn)確，因?yàn)樗窃谕耆馕龊玫?HTML 頁(yè)面及 DOM 環(huán)境中進(jìn)行安全漏洞分析。
如今 Web2.0 網(wǎng)站及 Ajax 應(yīng)用中，HTML 頁(yè)面往往都需要瀏覽器基于服務(wù)器響應(yīng)里的 HTML 和 JavaScript 代碼進(jìn)行動(dòng)態(tài)解析后才形成完整的 HTML 和 DOM，單純基于服務(wù)器響應(yīng)中的 JavaScript 代碼進(jìn)行靜態(tài)污點(diǎn)分析存在一個(gè)明顯缺陷 -- 其所測(cè) JavaScript 代碼及執(zhí)行環(huán)境不一定完整，因此它無(wú)法保證測(cè)試的準(zhǔn)確度和全面性。JSA 正是克服了以上缺點(diǎn)，融合了白盒檢測(cè)和黑盒檢測(cè)兩種測(cè)試方法的優(yōu)點(diǎn)，并引入 IBM 的字符串分析技術(shù)，所以 JSA 有著更好的準(zhǔn)確性和全面性。
利用 AppScan 檢測(cè) JavaScript 安全漏洞
Altoro Mutual 是 IBM 所提供的 Web 安全漏洞演示網(wǎng)站，下文筆者將向讀者展示如何利用 AppScan JSA 來(lái)檢測(cè)該網(wǎng)站所存在的 JavaScript 安全漏洞。
啟動(dòng) AppScan，點(diǎn)擊菜單"掃描– 掃描配置"打開(kāi)掃描配置對(duì)話框，設(shè)置起始 URL 為"
圖 1. 設(shè)置起始 URL 在掃描配置對(duì)話框左側(cè)，點(diǎn)擊"登錄管理"，然后點(diǎn)擊右側(cè)的"記錄 ..."按鈕錄制登錄過(guò)程，確保會(huì)話中檢測(cè)處于活動(dòng)狀態(tài)。 圖 2. 設(shè)置登錄方法 在掃描配置對(duì)話框左側(cè)，點(diǎn)擊"測(cè)試策略"，檢查測(cè)試策略設(shè)置。默認(rèn)測(cè)試策略應(yīng)該是"缺省"，其已經(jīng)包含了常見(jiàn) JavaScript 測(cè)試，可以點(diǎn)擊"已啟用 / 已禁止"查看當(dāng)前默認(rèn)啟用的測(cè)試策略。 圖 3. 檢查測(cè)試策略 關(guān)閉掃描配置對(duì)話框，點(diǎn)擊菜單"掃描 -- 僅探索"或單擊快捷按鈕（如圖 4 所示）啟動(dòng)探索。本文僅示例如何檢測(cè) JavaScript 安全漏洞，所以選擇"僅探索"+ 客戶(hù)端 JavaScript 分析的測(cè)試方式。 圖 4. 啟動(dòng)探索 點(diǎn)擊菜單"工具– 擴(kuò)展名– JavaScript Security Analyzer"或者快捷按鈕（如圖 5 所示）打開(kāi)"分析 JavaScript"。在彈出的 JavaScript Security Analyzer 對(duì)話框中，單擊"立即分析"。 圖 5. 分析 JavaScript JavaScript Security Analyzer 掃描完成后，即在結(jié)果列表中列出所發(fā)現(xiàn)的客戶(hù)端 JavaScript 安全漏洞。如下圖所示，Altoro Mutual 站點(diǎn)存在"基于 DOM 的跨站點(diǎn)腳本編制"及"開(kāi)放式重定向"漏洞，下文將展示這些漏洞的詳細(xì)信息。 圖 6. 查看掃描結(jié)果 展開(kāi)結(jié)果列表中的"基于 DOM 的跨站點(diǎn)腳本編制"，單擊第一個(gè)"JavaScript"問(wèn)題，在下方的問(wèn)題信息中將會(huì)展示其詳細(xì)信息。我們可以看出，AppScan 保存了對(duì) JavaScript 問(wèn)題代碼的分析結(jié)果，并用黃色標(biāo)識(shí)定位了源（Source）和接收器（Sink），利于開(kāi)發(fā)人員快速修復(fù)該漏洞。 圖 7. 基于 DOM 的跨站點(diǎn)腳本編制問(wèn)題信息 同樣，展開(kāi)并查看"開(kāi)放式重定向"問(wèn)題，在問(wèn)題信息欄中展示了該漏洞的代碼分析結(jié)果。 圖 8. 開(kāi)放式重定向問(wèn)題信息 注意： 本文為了快速展示如何檢測(cè) JavaScript 安全漏洞，所以選擇"僅探索"+ 客戶(hù)端 JavaScript 分析的測(cè)試方式。實(shí)際工作中，建議您只需要跟通常一樣進(jìn)行掃描（即手工探索結(jié)合自動(dòng)探索站點(diǎn)，然后執(zhí)行測(cè)試），AppScan 默認(rèn)會(huì)在測(cè)試過(guò)程中自動(dòng)執(zhí)行 JavaScript Security Analyzer。 Rational AppScan Standard 能檢測(cè)已知常見(jiàn) JavaScript 安全漏洞，但 Altoro Mutual 僅展示了基于 DOM 的跨站腳本編制和重定向漏洞，故本案例的結(jié)果列表中僅包含上述兩項(xiàng)安全漏洞。 結(jié)論 java企業(yè)級(jí)通用權(quán)限安全框架源碼 SpringMVC mybatis or hibernate+ehcache shiro druid bootstrap HTML5 本文介紹了 JavaScript 常見(jiàn)安全漏洞，分析了手工檢測(cè) JavaScript 代碼存在較大的技術(shù)難度。IBM Rational AppScan V8.x 新推出了 JSA 擴(kuò)展組件，在業(yè)界率先提供了客戶(hù)端 JavaScript 安全檢測(cè)方案。本文跟讀者分享了 JSA 的基本原理和技術(shù)優(yōu)勢(shì)，并結(jié)合案例向讀者演示了如何使用 IBM Rational AppScan JSA 測(cè)試客戶(hù)端 JavaScript 安全。 本文寫(xiě)的存在問(wèn)題局限性，歡迎提出批評(píng)，共同學(xué)習(xí)進(jìn)步。
相關(guān)文章
這篇文章介紹了js全屏顯示顯示代碼的三種方法，有需要的朋友可以參考一下2013-11-11
微信小程序獲取用戶(hù)信息的兩種方法wx.getUserInfo與open-data實(shí)例分析
這篇文章主要介紹了微信小程序獲取用戶(hù)信息的兩種方法wx.getUserInfo與open-data,結(jié)合實(shí)例形式分析了wx.getUserInfo與open-data獲取用戶(hù)信息的相關(guān)操作技巧與使用注意事項(xiàng),需要的朋友可以參考下2019-05-05
手寫(xiě)Spirit防抖函數(shù)underscore和節(jié)流函數(shù)lodash
這篇文章主要介紹了手寫(xiě)Spirit防抖函數(shù)underscore和節(jié)流函數(shù)lodash，接下來(lái)將會(huì)帶你們了解下這兩者的區(qū)別,以及我們?cè)撊绾问謱?xiě)實(shí)現(xiàn)這兩個(gè)函數(shù)2022-03-03
回車(chē)換Tab 方便，實(shí)現(xiàn)tab功能，屏蔽回車(chē)提交2008-12-12
超級(jí)兔子讓浮動(dòng)層消失的前因后果...2007-03-03
微信小程序使用map組件實(shí)現(xiàn)解析經(jīng)緯度功能示例
這篇文章主要介紹了微信小程序使用map組件實(shí)現(xiàn)解析經(jīng)緯度功能,涉及微信小程序map組件結(jié)合高德地圖進(jìn)行經(jīng)緯度獲取相關(guān)操作技巧,需要的朋友可以參考下2019-01-01
javascript數(shù)組中的reduce方法和pop方法
這篇文章主要介紹了javascript數(shù)組中的reduce方法和pop方法，文章內(nèi)容介紹詳細(xì)，具有一定的參考價(jià)值需要的小伙伴可以參考一下，希望對(duì)你的學(xué)習(xí)有所幫助2022-03-03
BootStrapTable服務(wù)器分頁(yè)實(shí)例解析
項(xiàng)目中經(jīng)常會(huì)使用到表格，數(shù)據(jù)量大的時(shí)候還需要進(jìn)行分頁(yè)，項(xiàng)目設(shè)計(jì)階段，我選擇了bootstrapTable的js插件，個(gè)人覺(jué)得這個(gè)框架非常好用，支持服務(wù)器端分頁(yè)，此篇主要寫(xiě)的主要是關(guān)于服務(wù)器分頁(yè),需要的朋友可以參考下2016-12-12
小程序角標(biāo)的添加及綁定購(gòu)物車(chē)數(shù)量進(jìn)行實(shí)時(shí)更新的實(shí)現(xiàn)代碼
這篇文章主要介紹了小程序角標(biāo)的添加及綁定購(gòu)物車(chē)數(shù)量進(jìn)行實(shí)時(shí)更新的實(shí)現(xiàn)代碼,本文通過(guò)實(shí)例代碼給大家介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2020-12-12
EditPlus 正則表達(dá)式 實(shí)戰(zhàn)(3)
這篇文章主要介紹了EditPlus 正則表達(dá)式 實(shí)戰(zhàn)(3)的相關(guān)資料,非常不錯(cuò)，具有參考借鑒價(jià)值，需要的朋友可以參考下2016-12-12