转载http://www.ibm.com/developerworks/cn/web/wa-vulnerabilities/index.html
简介
常用缩略词
- Ajax：异步 JavaScript + XML
- CSS：层叠样式表
- DOM：文档对象模型
- HTML：超文本标记语言
- JSON：JavaScript 对象表示法
- SQL：结构化查询语言
- UI：用户界面
- XML：可扩展标记语言
- XSS：跨站点脚本
Ajax 在 Web 开发领域日益兴盛，受众多开发人员热捧，这是因为它：
- 能够创建数据驱动网站所依赖的健壮 Web 应用程序
- 意味着提高网站速度和可用性
然而，这项被许多 Web 开发人员用来基于 Web 的应用程序模仿传统桌面应用程序的技术并不是一项正真的技术。Ajax 是一个技术集合，最终产品中的每个技术都发挥着重要作用。表 1 显示了 Ajax 中包含的技术。
表 1. Ajax 中使用的技术
| 技术 | 使用 |
|---|---|
| JavaScript | 脚本语言，支持所有技术共同工作。 |
| XML | 标记语言，支持数据在服务器和客户端传输、操作和交换。 |
| HTML 和 CSS | 支持 UI 设计和应用程序的描述的技术。 |
| DOM | 驱动内容动态显示和数据交互的技术。 |
Ajax 吸引 Web 开发人员的地方也是对其安全性最易受威胁的地方。众多安全专家一致认为 Web 应用程序是网络犯罪的一大目标，但是 Web 安全通常只是企业安全预算的一小部分。由于 Ajax 被用于开发很多可在 Web 上看到的应用程序，因此它的流行使其成为攻击者在 JavaScript 代码中寻找漏洞的目标。
Ajax 存在的核心是可以用它来创建数据驱动网站。真正吸引攻击者的不是可以将 Ajax 用作 Web 应用程序开发工具，而是数据，不管是金融数据、个人数据还是机密数据，都是珍贵的在线商品，Ajax 再次发现自己成为了网络犯罪的焦点。
在本文中，我们将研究一些常见的 Ajax 漏洞和易受到的威胁，包括基于浏览器的攻击、SQL 注入、XSS 和 Ajax 桥接，并了解一些可以防御攻击的措施。
了解攻击类型
Ajax 安全性：数字背后的故事
确定利用 Ajax 创建 Web 应用程序的数量是很难的。因为 Ajax 是 Web 开发人员中最收欢迎的，然而，我们假设在过去的 24 个月中，有 73% 的 Web 应用程序已经不可否认地受到了损害：
- 2,155 个是已知的 Web 应用程序漏洞
- 83% 的应用程序至少存在一个严重的漏洞
Ajax 很大程度上充当着方程式的作用。
JavaScript 中的漏洞为很多公司带来了不必要的压力。通过攻击跨站点脚本 (cross-site scripting, XSS) 漏洞，恶意黑客故意混淆 JavaScript 代码，以便窃取访客到站点的会话 cookie 。这些 cookie 可能包含登录信息，使得攻击者可获取绑定到受害者各个帐户的服务。
著名的 Samy 蠕虫实际上就是一个玩笑，蠕虫的创建者想要在社交网站获得更多朋友，他通过其个人资料来上传恶意代码：
- 将访问其个人资料的人添加到好友列表
- 在受害人个人资料的底部写上 “Samy 是我的英雄” 字样
- 将恶意代码复制给受害人朋友列表上的所有人
不到 24 小时，发布蠕虫的 Samy 就成了受害者，有了 1,000,000 个朋友，并且网站崩溃了。
使用 Ajax 并不会比使用其他 Web 技术带来的风险大，特别在您知道威胁是什么的时候。本文其余部分将概述一些在开发过程中可以预料并进行规划的安全漏洞。
基于浏览器的攻击
JavaScript 是 Ajax 的基础，恶意代码经常使用它。要让一个基于浏览器的攻击生效，恶意代码必须能够利用 Web 技术（在此是 JavaScript），使浏览器自己运行攻击者希望运行的代码。
举一个简单的例子，在发生一个基于浏览器的攻击时，受害者会发现其主页被篡改，或者当受害者在其浏览器地址栏中输入一个 URL 时，会被重定向到另一个网站。尽管这令人讨厌且很麻烦，但这些都不是最坏的情形。
许多基于浏览器的攻击被设计用来阻止受感染电脑发送通知或减少其他攻击。通常，对受害者浏览器进行的攻击会阻止他们访问恶意软件清除程序或使用 Web 订阅文件更新。其他威胁还包括浏览器代理和击键记录。
预防措施
保护自己不受基于浏览器的攻击比较容易，只需禁用 Java™ 技术、JavaScript 和 Microsoft® ActiveX® 控件即可。不过，这样做通常会阻止运行许多 Web 应用程序。相反，您应该确保 操作系统、浏览器软件和防病毒软件的及时更新。另外，还可以使用一个信誉良好的防火墙程序，并在下载文件和访问网站时小心谨慎。
SQL 注入
SQL 注入如何成为了 Ajax 安全的一个威胁？毕竟 Ajax 中没有 “S”。很简单，SQL 注入之所以构成威胁是因为 Ajax 在客户端运行。Web 应用程序服务器端仍然需要 SQL 数据库。
当攻击者在网站开发不完善的区域（比如一个表单）输入恶意代码时，就会发生 SQL 注入。如果受攻击网站比较脆弱，那么该数据库的所有内容都可能会曝光。密码数据库曝光或者从在线支付系统盗取信用卡数据使用的就是这种攻击方法。最近，入侵者利用这种方法从明星网站窃取粉丝邮箱地址。尽管没有盗窃财物，但是垃圾邮件发送者利用了这些邮箱地址，借用明星产品为幌子来传播恶意软件。
与其他 Web 技术一样,应减轻使用 Ajax 开发的应用程序中的 SQL 注入。不过，仅使用基于 JavaScript 的 sanitation 技术尚不足以防止这类利用。JavaScript 是在客户端运行而不是在服务器端运行，这才是发生 SQL 注入的主要原因。
预防措施
在使用 Ajax 时，要保护您的数据库，则必须验证用户输入，而且该验证是在服务器 端进行的。参数化语句或者预处理语句，这些都是为了阻止 SQL 注入，因为不能将值直接输入数据库或者 SQL 语句中。相反，在使用占位符（也称为绑定变量）时，占位符的值是通过一个单独的 API 调用提供的。
跨站点脚本
XSS 是注入攻击的另一个示例，恶意代码被注入到应用程序。易受 XSS 攻击的 Web 应用程序包括基于浏览器的脚本，就像那些常见的 Ajax 攻击一样。通常，攻击者利用这类弱点将恶意脚本传递给对该网站毫无戒心的访问者。这些脚本负责盗用身份，窃取 Cookie，暗中监视访客的 Web 使用，访问机密信息，甚至阻止服务攻击。
2010 年成为新闻焦点的著名的 XSS 攻击涉及到社会信息网络。这次攻击是从一个名为 @Matsta 的用户开始的，造成当浏览者鼠标滑过恶意消息时，出现 JavaScript 弹出窗口。其他 XSS 对该网站的攻击导致用户被重定向到一个调查网站或者内容不健康的网站。
预防措施
在使用 Ajax 进行开发时，可以采用以下步骤防止出现 XSS 漏洞
- 确保 JavaScript 变量被引用。
- 使用 JavaScript 十六进制编码。
- 使用 JavaScript Unicode 编码。
- 避免反斜杠编码（
\"、\‘或\\）。 - 使用 JSON.parse 或 json2.js 库来分析 JSON。
- 避免使用
eval()方法分析 JSON，它执行任何包含 JSON 的脚本。
Ajax 桥接
Ajax 应用程序被构建用来连接托管它们的网站。作为一项安全措施，来自站点 A 的应用程序不能连接到站点 B。然而，许多站点依靠第三方网站和数据源来创建混搭网站。人们创建了 Ajax 桥接服务，通过一个主机提供 Web 服务，该服务将充当代理，用来在该浏览器上运行的 JavaScript 和第三方站点之间转发数据。使用 Ajax 桥接，现在站点 A 可以向来自站点 B 的访客提供数据或内容。
正如 Ajax 不是一项特定技术而是一个技术集合，桥接也不是一个特定漏洞。Ajax 桥接为恶意黑客提供了额外攻击途径，增加了威胁。诸如 XSS 和 SQL 注入等攻击可以通过 Ajax 桥接服务传递。尽管站点 B 可能用尽一切办法保护其 Web 应用程序免受访客带来的相应威胁，但是站点 A 可以使用 Ajax 桥接攻击站点 B，这常常被忽视。
预防措施
要避免桥接漏洞，则需要在使用桥接来访问时与第三方的站点之间建立信任。您也应该审核第三方站点以何种方式访问您的站点，并扫描可能被桥接利用的任何漏洞。
结束语
Ajax 本身并不存在任何新的或独特的安全漏洞，也不应该认为它比开发 Web 应用程序的其他方法更不安全。在本文中，您可了解一些 Ajax 安全漏洞和易受到的威胁，还可了解如何在您的开发活动中采取相应的预防措施。
当最初规划您的应用程序时，预防漏洞应该在开发早期阶段就予以优先考虑。频繁的测试和扫描应该是任何组织的 Web 安全策略的一部分。