作者：[美] 约翰·保罗·米勒（John Paul Mueller）
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Web安全开发指南试读：
前言
勒索软件、病毒、分布式拒绝服务（distributed denial-of-service，DDoS）攻击、中间人攻击、安全漏洞，这些词都会勾起参与应用程序管理的人噩梦般的回忆。现在已经到了这样的地步：在处理关乎应用程序或其相关数据安全的问题时，任何人都会变得风声鹤唳、极其保守。你肯定不希望承担应用程序安全相关的责任，但这是在所难免的。
任何一种安全失误所造成的灾难性后果都会困扰你的余生，让你承受极大的压力。与大多数错误不同的是，你不能将这种错误隐藏起来，因为它会出现在所有人都能看到的行业媒体上。虽然你的名字不会成为安全事故的代名词，但安全问题仍会给你带来很多麻烦，比如官司缠身、失业等。那么应该如何处理这个问题呢？
逃避并不能解决问题，至少不是长期的解决方案。本书并不打算介绍我们可能会遇到的每一种安全威胁或解决它们的方法，而是提供独立解决任何一种安全问题所需要的指导原则和工具，让你看到成功的希望。本书的真正目的是教你如何将事情做对，从而可以安心地睡个好觉。本书预览
本书会提供处理应用程序安全问题所需的资源。是的，你还会在书中看到一些关于平台的信息，因为浏览器是在特定的平台上运行的。此外，你可能会看到使用桌面端应用程序时出现的一些安全问题，因为这些问题在这两种应用领域中都存在。但是，不论这些应用程序在什么地方运行，本书会聚焦于 Web 应用程序的安全性。你在本书中读到的内容不仅会涉及最新的智能手机，而且会涉及老旧的台式计算机等各种设备。本书会将内容分解为以下几个部分，每个部分都会协助你在安全性建设的道路上走好相应的一步。第一部分● 无计划不成事。但在计算机行业中，一些最严重灾难的发生恰恰是由于糟糕的计划，而不是没有计划。这一部分会帮助你为公司创建良好的安全计划，即一个考虑到所有最新的用户设备和用户需求的计划。此外还将讨论第三方支持的必要性，因为我们不得不面对这样的事实：在复杂的环境下确实很难独自创建出安全的应用环境。这些内容有助于定位正确的第三方支持，并确保你能收获自己想要的价值。第二部分● 如今的应用程序开发都会依赖第三方代码库、API 和微服务。这一部分将有助于你思考编码问题。你不会读到太多涉及位或字节层面的内容，但会找到将这些元素成功集成到应用程序中的一些技巧。这一部分会帮助你驾驭应用程序，而不是被它们所驾驭。第三部分● 测试应用程序安全性的方法有很多种。比如，你可以创建自己的测试套件或者使用其他人创建的套件。第三方程序也能为你做测试。也许你想要知道怎样才能最好地整合不同的测试策略，以确保整个应用程序被完整覆盖。这一部分可以回答你所有关于现代化测试策略的问题，并介绍如何让工作更有效率。第四部分● 应用程序在某个时间点被发布到生产环境中，并且运行良好。一些应用程序会以这样的方式持续运行多年而不需要适当的维护。不幸的是，现代的应用程序开发需要不断更新，因为黑客在不停地想出新的策略来入侵系统。而你所使用的所有第三方库、API 和微服务的更新则让情况变得更加混乱。这一部分将为你提供一张走出“更新迷宫”的地图，以便应用程序的各部分能够按照你最初的设想保持正常运行。第五部分● 安全威胁在持续地演变，这意味着你需要一些方法来持续跟进。第一种方法是跟踪这些安全威胁。当然，如果你跟踪每一种威胁，那将一事无成。这一部分描述了你能用来避免信息泛滥的一些技巧。第二种方法是接受额外的培训。事实上，整个公司都需要一些培训来了解最新的安全问题和处理它们的技术。这一部分还以一种所有公司都能采用的方式探讨了安全培训的要求，即使是只有一个人的公司或者创业公司也同样适用。阅读须知
本书的读者可以是拥有任何头衔的人，比如网页设计师、前端开发人员、UI 设计师、用户体验设计师、交互设计师、美术总监、内容策略师、开发运营人员、产品经理、搜索引擎优化专家、数据科学家、软件工程师或者计算机科学家。大家都有一个共同的需求，即创建安全的 Web 应用程序，让用户能以有意义的方式与之交互。这些人员都是之前开发过 Web 应用程序的专业人士，可能真正需要的是重新了解新形势下的安全技能。这种新形势指的是大部分应用程序是被非传统的方式攻破的，比如通过污染第三方的 API 和库。
本书会给出系统性的安全方案，但不会过多地进行手把手的指导。本书假设你想要了解最新的关于如何在不同级别阻止安全威胁的信息，其中包括对这些威胁的精确解读，以及黑客如何使用它们破坏你的安全措施。
本书包含一些安全编程的示例。要想使用这些例子，你需要具备良好的 CSS3、HTML5 和 JavaScript 编程技术方面的基础。但如果你不具备相关的技能，则可以跳过编程示例，但仍然能够从本书中获得大量有用的信息。编程示例提供只有程序员才会关注的细节。
除了编程技巧，更重要的是你接受过一定程度的安全培训。举个例子，如果你根本不知道什么是中间人攻击，那么确实需要先阅读较为基础的图书。本书当然不会假设你是了解中间人攻击各种细节的专家，但确实会认为你之前接触过它。开发环境
运行本书中的编程示例，只需要文本编辑器和浏览器。文本编辑器必须输出纯文本，不要有任何形式的格式化。它还要能够用正确的文件扩展名（.html、.css 和 .js）来保存这些示例文件。我和多位图书编辑、试读者使用 Linux、Mac 和 Windows 平台上最流行的浏览器测试过书中的例子。事实上，我们甚至在 Windows 10 系统的 Edge 浏览器上测试过这些例子。本书使用的图标
不同的图标用于传达不同种类的重点信息。本书使用的图标很少，但你需要知道其中每一个图标的含义。 此图标强调一些重要内容，这些内容略微偏离主题或者可能会破坏文字的连贯性。你需要阅读这些说明，因为它们通常会提供有助于你更好执行安全任务的信息。它们还会方便你找到所记得的重要内容，否则你可能很难找到。 此图标表示你必须知道的信息；如果不知道这些信息，你可能会遭受可怕的后果。与说明图标一样，这个图标强调了特殊的内容，这些内容会告诉你可能导致更严重问题的潜在问题。如果你读过某章后没有任何收获，那么一定要将这些警告内容学好并记牢，这能让你在今后避免代价高昂的错误。补充信息这一部分包含一些有用的信息，但你在开发 Web 应用程序时不一定需要了解它们。你应该找个时间将这些内容都看一遍，因为它们非常有趣，但没必要立即阅读。这部分内容是对当前话题的补充，不一定是关于该话题的内容。排版约定
本书使用了下列排版约定。楷体● 表示新术语或重点强调的内容。constant width● 等宽字体（）表示程序片段，以及正文中出现的变量、函数名、数据库、数据类型、环境变量、语句和关键字等。constant width bold● 加粗等宽字体（）表示应该由用户输入的命令或其他文本。Constant width italic● 等宽斜体（）表示应该由用户输入的值或根据上下文确定的值替换的文本。获取更多信息
我想要尽量确保你能够获得最好的阅读体验。如果有任何关于本书的问题，请一定发邮件到 John@JohnMuellerBooks.com。你也可以关注本书的博客 http://blog.johnmuellerbooks.com/category/technical/security-for-web-developers/。这个博客会提供更多的内容，并回答读者常问的问题。如果本书有勘误之处，你也能在博客上找到相关的修正。使用代码示例
补充材料（代码示例、练习等）可以从 https://github.com/oreillymedia/Security_for_Web_Developers 下载。
本书是要帮你完成工作的。一般来说，如果本书提供了示例代码，你可以把它用在你的程序或文档中。除非你使用了很大一部分代码，否则无需联系我们获得许可。比如，用本书的几个代码片段写一个程序就无需获得许可，销售或分发 O'Reilly 图书的示例光盘则需要获得许可；引用本书中的示例代码回答问题无需获得许可，将书中大量的代码放到你的产品文档中则需要获得许可。
我们很希望但并不强制要求你在引用本书内容时加上引用说明。引用说明一般包括书名、作者、出版社和 ISBN。比如：“Security for Web Developers by John Paul Mueller (O'Reilly). Copyright 2016 John Paul Mueller, 978-1-49192-864-6.”
如果你觉得自己对示例代码的用法超出了上述许可的范围，欢迎你通过 permissions@oreilly.com 与我们联系。®Safari Books Online
Safari Books Online（http://www.safaribooksonline.com）是应运而生的数字图书馆。它同时以图书和视频的形式出版世界顶级技术和商务作家的专业作品。技术专家、软件开发人员、Web 设计师、商务人士和创意专家等，在开展调研、解决问题、学习和认证培训时，都将 Safari Books Online 视作获取资料的首选渠道。
对于组织团体、政府机构和个人，Safari Books Online 提供各种产品组合和灵活的定价策略。用户可通过一个功能完备的数据库检索系统访问 O'Reilly Media、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、 Course Technology 以及其他几十家出版社的上千种图书、培训视频和正式出版之前的书稿。要了解 Safari Books Online 的更多信息，我们网上见。联系我们
请把对本书的评价和问题发给出版社。
美国：
O'Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
北京市西城区西直门南大街 2 号成铭大厦 C 座 807 室（100035）
奥莱利技术咨询（北京）有限公司
O'Reilly 的每一本书都有专属网页，你可以在那儿找到本书的相关信息，包括勘误表、示例代码以及其他信息。本书的网站地址是：
http://shop.oreilly.com/product/0636920041429.do
对于本书的评论和技术性问题，请发送电子邮件到：
bookquestions@oreilly.com
要了解更多 O'Reilly 图书、培训课程、会议和新闻的信息，请访问以下网站：
http://www.oreilly.com
我们在 Facebook 的地址如下：
http://facebook.com/oreilly
请关注我们的 Twitter 动态：
http://twitter.com/oreillymedia
我们的 YouTube 视频地址如下：
http://www.youtube.com/oreillymedia致谢
感谢我的妻子 Rebecca。虽然她已离世，但她的精神存在于我写的每一本书以及每一个词里。当没有人相信我的时候，她一直相信我。
感谢 Russ Mullen、Billy Rios 和 Wade Woolwine 对本书进行的技术编辑。这三位技术编辑极大地提升了书中内容的准确性和深度。很多时候，我都能与他们就书中核心话题的研究进行交流，并寻求他们的帮助。
感谢我的经纪人 Matt Wagner 帮我取得了这份合同，并帮忙打理大多数作者都不会关注的各种细枝末节。我一直感激他的帮助。知道有人愿意帮忙真的是一件非常棒的事情。
许多人阅读了全书或者部分内容，帮助我改进了方法，测试脚本，并提供了所有读者都希望包含的大量输入数据。这些不收酬劳的志愿者以各种各样的方式提供帮助，这里就不一一罗列了。我特别感谢 Eva Beattie、Glenn A. Russell 和 Luca Massaron 的帮助，他们提供了大量输入数据并读完整本书，忘我地参与到这个项目中来。
最后，我要感谢 Meg Foley、Nicole Shelby、Jasmine Kwityn 以及参与编辑和印制工作的所有其他人员。第一部分制订安全计划
在这一部分中，你将了解如何制订用于应用程序开发的安全计划。拥有一份好的安全计划能确保应用达到特定的目标，并且有助于与开发团队商讨如何实现安全性。缺乏良好的安全计划，黑客通常就能轻易地侵入应用程序并给公司制造各种问题。第 1 章将通过让你了解安全计划的组成部分来开启你的安全之旅。
很重要的一点是，你要认识到安全计划的制订不仅应考虑应用程序本身，而且要考虑用户如何使用应用。正如第 2 章中所说的，每一个成功的应用程序都将用户牢记在心头。
此外，你需要明白，现在的应用程序不再处于真空状态，它们会与在线数据源进行交互并依赖第三方代码。明白了这一点后，你还必须思考第三方解决方案会如何影响你的应用，积极影响和消极影响都应考虑在内。使用第三方解决方案能极大地减少你的编码时间。第 3 章会帮你达成这个目标。第1章定义应用环境
对于任何公司来说，数据都是最重要的资源。可以说，除了数据，公司的任何部分都可以被取代。当数据被篡改、破坏、窃取或删除时，公司会遭受严重的损失。事实上，如果某公司的数据发生了足够多的错误，那么该公司很可能会因此而不复存在。所以，谈到安全的时候，焦点不在于黑客、应用程序、网络或其他任何别人可能告诉过你的东西，而在于数据。因此，这本书是关于数据安全的，其中包括了许多其他话题，但当阅读这些话题时，你需要明白你真正要保护的是什么。
不幸的是，数据孤独地呆在黑暗中时并没有多少用处。无论你的服务器有多高档，或者你的数据库有多强大的存储能力，直到你利用数据时，数据才会有价值。我们需要使用应用程序来管理数据，这就是本章要讨论应用环境的原因。
然而，在进一步阅读之前，很重要的一件事是，要先明确应用和数据是如何交互的，因为如果对此没有了解，那本章余下的内容对你不会有太大用处。一个应用程序无论多么复杂，它只会对数据进行四种操作。你可以用 CRUD 这个缩写来指代这四种操作。● 创建（Create）● 读取（Read）● 更新（Update）● 删除（Delete）
接下来会讨论与 Web 环境有关的数据、应用程序和 CRUD。你会发现数据安全是如何影响 Web 开发中这三个方面的。记住，虽然数据是重点，但所需的 CRUD 任务是由应用程序来执行的。保证数据安全意味着要理解应用程序的运行环境，进而理解应用程序管理的数据所面临的威胁。1.1 明确Web应用威胁
你可以在互联网上找到 Web 应用威胁的清单。其中有一些是全面而不带偏见的，有一些论述了作者认为的最重要的威胁，还有一些会告诉你哪些是最常见的威胁，此外你还可以找到各种各样的其他清单。所有这些清单的问题在于，它们的作者并不了解你的应用程序。比如，SQL 注入攻击只在应用程序以某种方式使用 SQL 时才会成功，但你的应用程序可能并未采用这种方式。
很明显，你需要知道在哪些场景下应该检查什么，而这些清单确实是个好的起点。然而，你需要根据自己的应用程序来考虑这些清单的内容。此外，不要只依赖一份清单，尽量参考多份，这样你能对可能的威胁有更好的认识。带着这样的需求，下面列出了现在最常见的一些 Web 应用威胁。缓冲区溢出● 攻击者试图将足够多的数据发送到输入缓冲区中，以便让应用程序或输出缓冲区溢出，从而导致在缓冲区外的内存数据被损坏。某些形式的缓冲区溢出能使攻击者执行看起来不可能完成的任务，因为受影响的内存中保存着可执行的代码。解决这种问题最好的办法是，对应用程序处理的所有数据都执行边界和大小检查，无论是输入还是输出。你可以在网页 http://www.upenn.edu/computing/security/swat/SWAT_Top_Ten_A5.php 和 https://www.owasp.org/index.php/Buffer_Overflows 上看到更多关于 Web 应用程序缓冲区溢出的内容。代码注入● 一个实体以中间人攻击（man-in-the-middle-attack）的形式将代码添加到服务器和客户端（如浏览器）之间的数据流中。被攻击方经常会将这种注入代码视为原始页面的一部分，但它可能包含任何东西。当然，被攻击方甚至看不到这些注入的代码。它可能潜伏在后台，随时准备给应用程序制造各种各样的问题。解决该攻击的一种好方法是确保使用了加密的数据流、HTTPS 协议和代码验证（如果可能）。提供客户端反馈机制也是一个好主意。 代码注入往往发生得比你想象的频繁。在某些情况下，代码注入甚至不算攻击的一部分，虽然也可能是。最近有一篇文章（http://www.infoworld.com/article/2925839/net-neutrality/code-injection-new-low-isps.html）讨论了互联网服务提供商（Internet service provider，ISP）如何将 JavaScript 代码注入到数据流中以便在页面上放置悬浮广告。而为了确定要投放哪一类广告，ISP 还会监听数据传输。跨站脚本● （cross-site scripting，XSS）攻击者将 JavaScript 脚本或其他可执行代码注入到应用程序的输出流中。接收者会将你的应用程序看作感染源，但其实它并不是。大多数时候，不应该在没有严格验证的情况下允许用户通过你的应用程序直接将数据发送给其他用户。对于像博客这样的应用程序来说，采取审核机制是很有必要的，以此确保你的应用程序最终不会沦为病毒的宿主，或者出现更糟糕的情况：被掺入看似无害的数据。 很少有专家会提醒你检查输出数据。但是，你并不能准确地知道自己的应用程序是否值得信赖。黑客有可能破解应用程序并污染输出数据。验证核查应涵盖输入数据和输出数据。文件上传● 即使看上去是无害的，但每一次的文件上传也应该被认为是可疑的。黑客有时候会利用服务器的文件上传功能来上传后门程序，这些文件会包含一些很危险的东西。如果可能，应禁止服务器的文件上传。当然，我们通常无法提供这种级别的安全性，所以你需要限制允许上传的文件类型，然后扫描这些文件，检查它们是否有问题。尽可能验证文件始终是一个好主意。例如，一些文件会在头部包含一段签名信息，你可以用它来判断这个文件的合法性。不要单纯依赖文件扩展名进行排除，黑客经常会将一个文件伪装成另一种类型来绕过服务器的安全验证。硬编码的认证● 出于测试目的，开发人员经常将认证信息放在应用程序的初始化文件中。我们需要去掉这些硬编码的认证信息，以集中式存储的安全信息替代。将数据存储在安全的位置而不是 Web 应用服务器上是很重要的，这样黑客就不能轻易地查看到可用于访问应用程序的凭据。如果你的应用程序确实需要一些初始化文件，那么要确保这些文件放在 Web 根目录以外的地方，以防止黑客偶然发现它们。发现隐藏或受限制的文件 / 目录● 当应用程序允许输入一些特殊字符（比如斜杠或反斜杠）时，黑客就有可能发现隐藏或受限制的文件和目录。这些地方可能包含各种有助于黑客攻击你的系统的信息。尽可能禁止使用特殊字符是一个很好的主意。除此之外，请把重要的文件放在 Web 根目录之外且操作系统能直接控制的地方。缺少认证或者认证不正确● 知道谁正在使用应用程序是很重要的，特别是在你处理敏感数据的时候。许多 Web 应用程序依赖公共账户来执行某些任务，这意味着不可能知道是谁访问了这个账户。应该避免因为任何原因而使用访客账户，并为每一个用户分配独立的账户。缺少授权或者授权不正确● 即使知道了谁正在使用你的应用，还有一件重要的事：只为用户提供执行特定任务时所需要的权限。此外，授权应该反映用户的访问方式，比如一个桌面系统通过本地网络访问应用程序可能比一部智能手机在当地咖啡店里访问应用程序更安全。依靠安全提升来协助处理敏感任务，能够让你在处理任务之外的时间里维持最低的授权。任何降低用户权限的行为都有助于维持一个安全的环境。缺少加密或者加密不正确● 使用加密技术在两个终端之间传输数据可以防止黑客监听通信。重点是要跟进最新的加密技术，并且依靠用户环境所能支持的最好加密算法。例如，三重加密算法（Triple Data Encryption，3DES）已经不再安全了，但一些组织仍在使用它。高级加密标准（Advanced Encryption Standard，AES）目前仍然是安全的，但你要尽可能用最长的密钥来加大破解难度。操作系统命令注入● 攻击者会修改应用程序使用的操作系统命令来执行特定的任务。你的 Web 应用程序一开始可能就不应该使用系统调用。但是，如果必须使用，请确保你的应用程序在一个沙盒环境中运行。 有些专家会强调在某些使用场景中需要校验输入数据，但对其他的使用场景不作此要求。请始终对从任意数据源接收到的任何数据进行校验。你无法知道黑客会用什么工具来侵入系统或以怎样的方式来制造损害。输入数据总是可疑的，即使该数据来自你自己的服务器。当你处理安全相关的任务时，变得多疑是件好事。参数篡改● 黑客会对作为请求头或 URL 一部分的参数进行尝试。例如，使用 Google 搜索时，你可以通过改变 URL 来改变搜索结果。请确保加密你在浏览器和服务器之间传递的任何参数。此外，在传递参数时，使用安全的网络传输协议，比如 HTTPS。 如果有足够的时间和精力，黑客仍然能操纵参数。仔细定义好参数的取值范围和数据类型也很重要，这能减少此种攻击带来的潜在问题。远程代码包含● 如今的很多 Web 应用程序依赖包含外部库、框架和 API。大多数情况下，包含语句会含有一个相对路径或者使用一个记录着硬编码路径的变量，这样做是为了方便以后更换远程代码的位置。当黑客能够获取到这些路径信息并更改它们的时候，远程代码包含就可能被指向黑客想要包含的任何代码，从而使得黑客可以完全掌控你的系统。避免这种问题的最佳方法就是尽量使用硬编码的完整路径，尽管这会使代码维护变得困难。 许多专家会建议你使用经过审核的库和框架来执行有风险的任务。但是，这些添加的插件不过是更多的代码而已。黑客总能发现破坏和规避这些库以及框架的方法。你仍然需要确保应用程序和所有它依赖的代码能够安全地与外界交互，这意味着需要有额外的测试。使用外部库和框架确实能降低维护成本并且能提供及时的 bug 修复，但是 bug 仍旧会存在并且你仍需要保持警惕。保证数据安全没有万全之策。第 6 章包含了更多关于使用外部库和框架的内容。会话劫持● 每次用户登录到你的 Web 服务器，服务器就会为其创建一个唯一的会话。会话劫持者会侵入到会话中并拦截用户与服务器之间传输的数据。含有劫持会话所需信息的三个最常见的地方是：cookie、URL 重写和隐藏域。黑客会在这些地方查找会话信息。只要保持会话信息是加密的，你就能降低会话被劫持的风险。例如，确保使用 HTTPS 协议来登录。你也应该避免使用可被预测的会话 ID。SQL 注入● 攻击者会修改由应用程序创建的查询，而这个查询是由用户或其他输入引起的。大部分 SQL 注入的情况是，应用程序需要的是用于查询的数据，但它实际接收到的却是一些 SQL 片段。其他形式的 SQL 注入攻击与使用了转义字符或其他意想不到的字符或字符串有关。一个避免 SQL 注入攻击的好办法是避免动态查询。
看起来我们周围存在着许多不同的网络威胁，但如果在网上搜索的时间足够长，你会轻易地将这份清单的长度变成现在的 3 倍，然而这些也只是众多黑客攻击手段中的一小部分。当继续读这本书时，你会碰到更多种类的网络威胁并开始了解解决它们的方法。不用担心，大部分情况的解决方案都是一些常识，并且一个方案能解决不止一个问题。例如，再看看上面的清单，你会发现仅仅使用 HTTPS 就可以解决其中的多个问题。考虑隐私安全问题当一家公司涉足安全时，它往往会首先关注自己的数据安全，毕竟，如果公司的数据丢失、被损坏、被修改或以别的方式变得不可用，那它可能会面临破产。公司下一个级别的安全考虑通常涉及第三方，比如合作伙伴。用户数据的安全性通常是最后才考虑的，并且，很多公司根本不考虑客户数据的安全。问题是，许多用户和客户把他们的数据安全看得非常重要。所有的隐私问题都归结于用户数据的保护，在没有经过用户同意或用户不知情的情况下，不能滥用或暴露用户信息。总之，在构建应用程序时，必须把用户数据的隐私作为一个重要的安全问题纳入考虑范围。最近的一篇文章（http://www.infoworld.com/article/2925292/internet-privacy/feds-vs-silicon-valley-who-do-you-trust-less.html）指出，用户和客户把科技行业视为糟糕的数据受托方。事实上，科技行业确实在这方面已落后于政府，人们相信政府会更好地保护他们的信息。许多科技公司公开支持其他实体（比如政府）提出的增强安全性的策略，但私底下却用各种方式侵犯用户和客户的隐私。这种两面派的做法比起科技行业公开承认侵犯用户和客户的数据更糟糕。要创建一个真正安全的应用程序，必须涵盖安全的每一个方面，包括用户和客户的数据。这要求应用程序只获取和管理其执行相关任务所需的数据，而不去涉及那些不再需要的数据。只有对操作的所有数据都遵循相同的原则，不管它们从何而来，应用程序才会收获信任。1.2 理解软件安全保障
软件的目的是与数据进行交互。但是，软件本身也是一种数据。事实上，数据有很多你可能从未考虑过的形式，并且其影响比你想象的要广泛得多。随着物联网（Internet of Things，IoT）时代的到来，如今的数据可能具有抽象和物理双重影响力，这在几年前甚至无法想象。成功入侵应用程序之后，黑客可以做破坏电网和向自来水系统投毒这样的事情。从个人层面来说，黑客同样可以悄悄地把你家的温度调高到可怕的程度，关掉你家所有的灯，或者通过你的网络摄像头监视你，这只是一些例子。软件安全保障（Software Security Assurance，SSA）的观点是，软件需要某种监管来确保它不会导致其使用、控制和保护的数据及资源发生丢失、误差、篡改、不可用或误用。这一要求是 SSA 的一部分。接下来会更详细地讨论 SSA。 SSA 目前并不是一个实际的标准。它是许多公司基于自身需求进行量化并写入文档的一个概念。在这许多的文档中出现了一些相同的基本模式，进而 SSA 这一术语用以指代这些确保软件安全的做法。通过查阅各大公司的在线 SSA 文档，你会发现 SSA 是如何影响这些公司的，比如 Oracle（https://www.oracle.com/support/assurance/index.html）和 Microsoft（https://msdn.microsoft.com/library/windows/desktop/84aed186-1d75-4366-8e61-8d258746bopq.aspx）。事实上，目前许多大公司都在适当的地方有某些形式的 SSA。1.2.1 考虑OSSAP
为了使 SSA 在 Web 应用程序中成为现实，有一个重要的网站需要关注，那就是开放 Web 应用安全项目（Open Web Application Security Project，OWASP，https://www.owasp.org/index.php/OWASP_Software_Security_Assurance_Process），如图 1-1 所示。这个网站对如何使 OWASP 的安全软件保障流程（OWASP Security Software Assurance Process，OSSAP）成为软件开发生命周期（Software Development Lifecycle，SDLC）的一部分进行了流程分解。是的，这里有一大堆首字母缩写，不过你需要了解这个组织，这会帮你为自己的应用程序创建一套流程来与其他公司所做的工作相匹配。此外，这个网站上的信息能帮助你为应用程序开发一套真正能用的安全流程，使其成为开发流程中的一部分，而这并不会花费太多的时间。图 1-1：OWASP 网站会告诉你关于 Web 应用的 SSA 虽然 OSSAP 提供了一个很棒的框架来确保应用满足 SSA 的要求，但你并不需要与该组织有任何的互动。这个组织已经将它的方法授权给 SSA。不过，这个组织现在还在发展中，你可以在网站上发现很多待定的事项，这些都会在后面的时间里补充上。当然，你需要一个当前能用的计划，所以 OWASP 和它的 OSSAP 为你提供了研究当前解决方案的平台，并且在今后也能获得更多的帮助。
在应用程序中将 SSA 作为软件开发生命周期一部分的根本原因，是想尽可能确保软件是可靠和无差错的。在与某些人的交谈中，会发现他们认为 SSA 会解决你可能遇到的所有潜在安全问题，可实际上并非如此。SSA 会提升软件质量，但没有一款软件是没有差错的。假如你确实开发了一款没有错误的软件，仍然需要考虑用户、环境、网络和所有其他的软件安全问题。因此，SSA 只是安全版图中的一小块，而实现 SSA 也只能解决许多而不是全部的安全问题。最佳的做法就是将安全建设视为一个持续的过程。1.2.2 定义SSA的要求
要将实现 SSA 作为应用程序的一部分，第一步需要先定义 SSA 的要求。这些要求会帮你确定软件的当前状态、需要解决的问题，以及这些问题的严重程度。在定义问题之后，你能够明确修复进程以及任何其他要求，以确保软件安全。实际上，你可以将 SSA 分解为以下 8 个步骤。
(1) 评估软件和制订修复计划。
(2) 定义数据的各种安全风险并进行分类，优先修复最严重的风险。
(3) 执行全面的代码检查。
(4) 进行必要的更改。
(5) 测试修复并在生产环境中验证它们确实是有效的。
(6) 制定防御机制来保护应用程序的访问及其管理的数据。
(7) 衡量你所做的这些更改的有效性。
(8) 以适当的方式培训管理者、用户和开发人员，以确保良好的应用安全性。另一种 SSA 策略当涉及安全问题的时候，你会发现针对一个问题有许多解决方法。根据公司的文化和工作方式，你也许会发现有另一种技巧可以确保 SSA 工作得更好。一些安全专家会建议以下这些步骤。(1) 把安全性要求置于产品需求之上（这一条只需要在启动新软件开发时执行）。(2) 定义并与开发人员沟通写代码时必须遵守的安全编码规范。(3) 开发人员在写新代码时要启用自动代码检查。(4) 完成应用开发之后要执行全面的代码检查。(5) 对整个应用程序进行渗透测试和脆弱性评估。(6) 评估测试结果以找到安全和业务之间的平衡点。制订计划，修复已确定的、对业务有很大危害的漏洞。(7) 执行所有需要进行的安全性修复。(8) 重复步骤 (5)。1.2.3 对数据和资源分类
这一过程包括识别应用程序涉及的各种数据，包括它自身的代码和配置信息。一旦识别了所有数据，你就要对其进行分类来确定所需的安全级别，从而保护这些数据。数据有很多分类方式，而用什么方式则取决于公司的需要和对数据的定位。例如，有些数据可能只会给公司带来麻烦，而有些数据则可能对人造成伤害。定义数据安全漏洞会如何影响整个安全环境，是至关重要的。
完成数据分类之后，就可以开始用这些分类信息来执行各种任务。例如，你可以考虑通过以下方式减少漏洞：● 制定编码规范● 执行强制的开发人员培训● 在开发团队中聘请安全主管● 使用专门定位安全问题的自动化测试程序
所有这些方法都指向公司使用和依赖的资源，以确保应用程序正确地管理数据。资源分类意味着确定对特定资源的重视程度。例如，拒绝培训开发人员会比拒绝培训用户产生更大的影响，因为开发人员与应用程序是一体的。当然，培训对所有人都很重要。既然这样，将资源分类会让你明确在何地如何花钱才能获得最佳的投资回报，同时仍然能满足应用的安全性目标。1.2.4 进行必要的分析
作为 SSA 的一部分，你需要对应用程序进行分析（包括威胁建模、用户界面漏洞和数据展示漏洞）。准确地知道代码可能包含怎样的缺陷是很重要的。这里的关键词是可能。在进行深入分析之前，你无法知道代码中实际的安全问题。Web 应用程序特别容易有潜藏的问题，因为与桌面端应用程序不同，其代码会出现在许多地方，并且脚本语言易于隐藏问题，而经过编译的应用程序则没有这种情况，因为脚本语言是在运行时而不是编译时进行解析的。重要的一点是，要理解数据安全不仅与代码有关，还涉及创建代码所需的工具和使用这些工具的开发人员的技能。当一家公司选择错误的工具来完成这个工作时，出现安全漏洞的风险会大大提高，因为这些工具可能无法创建出严格符合预期的代码。同样，当使用工具的开发人员不具备必需的技能时，软件出现安全漏洞就毫不奇怪了，但更熟练的开发人员能避免这些漏洞。某些专家宣称，有些公司实际上容忍不合格的工作。在大多数情况下，给这种行为找的借口是开发进度落后于预期或缺少必需的工具或专业技能。公司有可能会专门设计用来解决安全问题的软件（比如防火墙），这并不能减轻开发人员开发安全代码的重任。公司需要坚持编码标准来确保取得良好的结果。1. 逻辑
与应用程序及其管理的数据进行交互是一系列过程。虽然用户可
能会以看起来随机的方式执行任务，但具体的任务总会遵循一定
的模式，因为用户必须遵循一定的过程逻辑来获得良好的结果。
通过记录及理解这些过程，你能够从实际的角度分析应用程序的
逻辑。用户依赖于由开发人员设计应用程序的方式决定的特定过
程。改变这个设计势必会引起过程的改变。
分析的目的是要找出过程逻辑中的安全漏洞。例如，应用程序可
能会允许用户保持其登录状态，却没有对过期后的登录状态有效
性进行检测。这里的问题是，在线用户可能根本就不在线，而是
其他人利用了他的凭据登录了系统，并且没人知道这件事，因为
所有人都觉得这个用户是像平时一样正常登录该系统。
但是，对数据漏洞的分析可采用其他的方式。例如，一个序列号
可能由几个可量化的元素构成。为了得到好的序列号，应用程序
可获取这些元素并根据这些元素来构建序列号，而不是把序列号
当作一个整体。这样做是为了让过程逻辑更简洁、清晰和更不易
出错，从而使数据库不会存储大量不良信息。2. 数据
也许看起来不可能从安全性的角度对数据进行太多的分析，但确
实有很多问题需要予以考虑。事实上，很多公司的数据分析都做
得不够好，因为他们把重点放在了如何管理和使用数据上，而忽
略了如何确保数据的安全（有理由相信你需要解决这三个问
题）。当分析数据时，你必须考虑以下这些问题：谁能访问数据● ● 数据以什么格式存储数据何时可被访问● ● 数据存储在什么地方为什么每个数据项都能作为应用程序的一部分被使用● ● 数据如何分解成各个部分，以及组合数据供应用程序使用的后果
比如，一些应用程序没有执行数据隐藏，但其实数据隐藏应该是
任何好的应用程序应该有的重要特征。它是指只为用户提供其执
行给定任务时确实需要的信息。
一些应用程序对数据格式的处理也不正确。比如，存储明文密码，
只要有人攻破了系统，几乎可以肯定会出问题。更好的做法是存
储经过安全加密算法（还没有被破解的算法）处理的密码散列
值。散列值对于攻破系统的人来说毫无用处，因为应用程序需要
的是用来生成散列值的原密码。
让所有数据一直可访问也不是好的做法。对于敏感数据来说，应
当只在有人监管其使用并能对用户的异常行为作出及时反应的前
提下，才将其显示出来。
把敏感数据存储在云端是相当糟糕的做法。是的，采用云存储能
更方便和快捷地访问数据，但也会使数据更容易遭受攻击。当你
能直接使用保证数据安全的所有安全特性时，请将敏感数据保存
在本地服务器上。
应用开发人员喜欢提供过多的信息。你应该采用数据隐藏将面向
管理员的数据与其他人员隔绝。然而，有些数据在应用程序中根
本没有被任何一处地方使用。如果在处理一个任务时确实不需要
用到某些数据，那就不要将这些数据添加到应用中。
如今的许多数据项是其他数据元素的聚合。通过探测数据聚合方
式分解数据项来发现数据的各个组成部分，黑客有可能窃取到关
于公司的大量信息。关键是要考虑如何将数据合并，并添加安全
防护措施，从而让数据源更难被发现。3. 界面
现今软件的一大问题是包含了不必要的功能。一个应用程序应该
满足一组特定的目标，或者执行一组特定的任务。总有些人在想，
如果软件能有一些额外的特性，可能会更好，虽然这些特性与其这个词由来已久，你经常
要达成的核心目标完全无关。功能膨胀
在涉及金钱消耗的场景中发现它，比如应用程序性能问题的根
源、用户培训费用的提升，以及开发进度的延迟等。但是，受功
能膨胀的影响，应用程序界面的问题会因攻击面（attack
surface）的增加而对安全性产生重大影响。攻击面的每一次增
加都会为黑客提供更多入侵公司系统的机会。将不必要的功能移
除或将它们移到另一个不同的应用中，可以减少应用的攻击面，
从而让应用程序更安全。当然，你也会省下不少钱。
另一个潜在的威胁是提示界面，它提供给潜在的黑客太多信息或
功能，从而丢失了应用程序的安全性。虽然提供一种途径让用户
找回密码是有必要的，但有些实现方式确实有可能让黑客得到用
户的密码从而伪装成该用户。黑客甚至可能会修改用户的密码，
使得真正的用户无法登录（但是这一举动会适得其反，因为管理
员能轻松恢复用户的访问权限）。一个更好的系统要确保用户在
干任何其他事情之前先发送认证请求，并确保管理员能以安全的
方式发送登录信息。4. 约束
约束就是一种方法，在允许执行某一行为之前，用来确保其满足
特定的标准。例如，除非用户拥有相关权限，否则禁止其访问数
据元素就是一种约束。但是，约束有其他更重要的形式。最重要
的约束是确定用户如何管理数据。大部分用户只需要读取数据，
但应用程序通常提供了读 / 写访问，从而打开了一个巨大的安全
缺口。
对于数据也需要考虑约束。当处理数据时，你必须精确定义用什
么来保证数据的唯一性，并确保应用程序不会破坏任何与唯一性
有关的规则。有了这个想法，你一般需要考虑下面几种约束：● 确保数据有正确的类型定义数据能接受的值的范围● 明确数据长度的最大值和最小值● ● 列出所有不能接受的数据值1.3 探究与语言相关的问题
应用环境是由所采用的开发语言定义的。正如每一种语言都有善于处理某些任务的功能，每一种语言也都有造成安全风险的潜在问题。即使是低级语言，尽管具有灵活性，也有因复杂性引起的问题。当然，基于 Web 的前端应用程序通常依赖三种特定的语言：HTML、 CSS 和 JavaScript。接下来将描述与这三种语言相关的问题。1.3.1 定义HTML的关键问题
HTML5 因支持极为广泛的平台而变得相当热门。不需要开发人员编写特殊的代码，同一个应用程序就能很好地在用户的桌面电脑、平板设备和智能手机上运行。通常，库、API 和微服务不需要开发人员的介入就能提供自动适配宿主系统的内容。但是，HTML5 提供的这种灵活性也存在问题。以下清单列出了你在使用 HTML5 时会遇到的一些关键的安全性问题。代码注入● HTML5 里有大量黑客可用来注入恶意代码的方法，包括你通常不认为可疑的数据源，比如一段 YouTube 视频或是流式音乐。用户跟踪● 因为大多数情况下应用程序使用了不同来源的代码，所以你可能会发现库、API 或微服务实际上执行了一些类型的用户跟踪，而黑客能利用其来获取公司信息。你给黑客的每一份信息都会让攻克系统安全变得更容易。污染输入● 除非你提供自己的输入项检查，否则 HTML5 会放行所有用户想要提供的输入。你可能只需要一个数字型的值，但用户可能输入一段脚本代码。尝试对输入进行彻底检测以确保真正得到你要求的输入数据，这在客户端近乎是不可能的，所以你还需要确保有强大的服务器端检查机制。HTML5 的攻击面HTML5 增加了许多有趣的、黑客非常喜欢的特性，因为这些特性提供了更多的攻击面。例如，在你发现恶意软件能轻易利用 LocalStorage 入侵系统的本地存储之前，LocalStorage 看起来是个很好的东西。你能在网页 http://www.slideshare.net/shreeraj/html5-localstorageattack-vectors 和 https://blog.whitehatsec.com/web-storage-security/ 上读到这种攻击的相关细节（包括一些攻击案例）。另一个有问题的特性是WebSocket。这一特性允许客户端与服务器端的双向通信。唯一的问题是，客户端可能在运行不可靠的代码。你能在网页 http://www.slideshare.net/SergeyShekyan/bay-threat-2012-websockets 和 http://blog.kotowicz.net/2011/03/html5-websockets-security-new-tool-for.html 上看到更多关于这一问题的资料，其中有些例子会告诉你如何使用 WebSocket 来克服安全保护的问题以及潜在的解决方案。1.3.2 定义CSS的关键问题
Web 应用程序非常依赖 CSS3 来创建美观的界面，而不需要为每个设备硬编码相关信息。已有的 CSS3 代码库使得创建专业美观的应用变得简单，并且用户能更换它们来满足不同的需求。例如，用户可能需要在某一设备上有一个不同的界面，或者需要一种特殊格式的展现来满足一个特定的需求。以下列举了一些在使用 CSS3 时会遇到的关键安全性问题。设计主导● CSS3 代码导致安全问题的一个主要原因是由设计来主导一切。标准委员会最初设计 CSS 是用来控制 HTML 元素的展现的，而不是影响整个 Web 页面的展现。因此，设计师从来不会考虑相关的安全问题，因为 CSS 就不是用在这一领域的语言。问题在于 CSS 的样式级联部分不允许 CSS3 知道除了其父节点之外的任何信息。因此，黑客能创建出一种声称要做某件事的界面，实际上却做着另外的事情。一些库（如 jQuery）确实能帮你解决这一问题。上传的 CSS● 在某些情况下，应用程序的设计者会允许用户上传一份 CSS 文件来获得某一特定的应用外观或让其在一个特定的平台上运行得更加良好。但是，上传的 CSS 也可能包含一些代码，使得黑客更容易破坏设在各个地方的安全措施，或者在可见范围内隐藏脏东西。例如，黑客会在 CSS 里隐藏 URL，从而将应用重定向到不安全的服务器上。CSS 着色器● 一种特殊的 CSS 用法，它允许访问浏览器数据和跨域数据，从而会产生一些极端的问题。本书后面的章节会详细讨论相关的细节，但你能在网页 http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security 上快速浏览这一话题。重要的是要明白，有时候在屏幕上展现数据的行为会导致你最初未考虑到的潜在安全漏洞。1.3.3 定义JavaScript的关键问题
JavaScript 和 HTML5 的结合已经创造了整个 Web 应用的奇迹。没有这两种语言的结合，就不可能创造出在所有设备上都运行良好的各种应用程序。用户甚至不再想用原来的那种应用程序，因为其不能提供这种能力。现在，用户能在任何地方用适合该位置的设备完成工作。但是，JavaScript 是一门有着严重安全缺陷的脚本语言。下面列出了你在使用 JavaScript 时会遇到的一些关键的安全性问题。跨站脚本（XSS）● 这一问题在本章前面出现过，因为它是一个非常严重的问题。只要你在沙盒环境之外运行 JavaScript，黑客就有可能对你的应用程序做一些讨厌的动作。跨站请求伪造（CSRF）● 一段脚本能够利用保存在 cookie 里的用户凭据来访问其他站点。在这些网站上，黑客能执行应用程序设计目的之外的各种任务。例如，黑客能以用户的名义，进行账户篡改、窃取数据、欺诈以及许多其他的违法活动。浏览器及其插件的漏洞● 很多黑客会利用已知的浏览器及浏览器插件的漏洞来强迫应用程序执行其不应执行的任务。例如，用户的系统可能突然变成了向其他系统传送病毒代码的傀儡。黑客能够破坏的程度受限于相关的漏洞。一般来说，你要确保自己安装所有的更新，并要了解这些安全漏洞会如何影响应用程序的作业。1.4 考虑端点的防御要素
端点是指网络传输的目的地，比如一个服务或一个浏览器。当数据包到达端点时，其包含的数据会被解包出来并提供给应用程序做进一步的处理。端点安全是至关重要的，因为端点是网络的一个主要入口点。除非端点是安全的，否则网络会接收到恶意的数据。此外，糟糕的端点安全性会对网络里的其他节点造成损害。接下来会讨论端点安全的三个阶段：预防、检测和修复。 重要的是不要低估端点安全性对应用和网络基础设施的影响。一些端点的情况非常复杂，以至于其后果难以被检测甚至理解。最近的一篇文章（http://www.infoworld.com/article/2926221/security/large-scale-attack-hijacks-routers-through-users-browsers.html）讨论了一种路由器攻击，攻击者将毫无防范的用户定向到一个特定的网站。此类攻击针对的是用户发起域名系统（DNS）请求时依赖的路由器。通过完全控制这种路由器，攻击者能将用户重定向到他控制的站点。1.4.1 预防安全漏洞
避免安全陷阱的第一步是一开始就承认陷阱是存在的。问题是，如今大多数公司并不认为自己会遭遇数据安全陷阱，认为这总是发生在其他安全性不高的公司。然而，根据 Ponemon 研究所关于 2014 年全球网络犯罪造成损失的统计报告（http://info.hpenterprisesecurity.com/LP_CP_424710_Ponemon_ALL），2014 年网络犯罪导致的损失金额高达 1270 万美元，而 2010 年该值是 650 万美元。显然，所有这些入侵行为不会只发生在别人的公司，它们也很容易发生在你的公司，所以，最好假设某个地方的某个黑客已盯上了你的公司。事实上，如果一开始就意识到黑客不仅会入侵公司系统，还会偷走你的财物，你就会真正为现实生活中的场景做好准备。你构建的所有应用程序必须足够可靠以实现以下功能：● 对抗普通的攻击● 在安全措施失效时发出警报● 避免对可能会发生漏洞的地方做出假设● 要假设即使是受过训练的用户也会犯导致安全事故的错误
试读结束[说明：试读内容隐藏了图片]