第 1 章 定义应用环境

第 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.phphttps://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-vectorshttps://blog.whitehatsec.com/web-storage-security/ 上读到这种攻击的相关细节(包括一些攻击案例)。

另一个有问题的特性是WebSocket。这一特性允许客户端与服务器端的双向通信。唯一的问题是,客户端可能在运行不可靠的代码。你能在网页 http://www.slideshare.net/SergeyShekyan/bay-threat-2012-websocketshttp://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 万美元。显然,所有这些入侵行为不会只发生在别人的公司,它们也很容易发生在你的公司,所以,最好假设某个地方的某个黑客已盯上了你的公司。事实上,如果一开始就意识到黑客不仅会入侵公司系统,还会偷走你的财物,你就会真正为现实生活中的场景做好准备。你构建的所有应用程序必须足够可靠以实现以下功能:

  • 对抗普通的攻击

  • 在安全措施失效时发出警报

  • 避免对可能会发生漏洞的地方做出假设

  • 要假设即使是受过训练的用户也会犯导致安全事故的错误

 不要假设安全漏洞只存在于某些平台。安全漏洞会出现在任何运行非定制软件的平台上。开发人员为某一平台做的准备越少,漏洞就会变得越严重。例如,许多人觉得销售点(point-of-sale,POS)终端机是安全的,但是黑客目前正在大力攻击此类设备(http://www.computerworld.com/article/2925583/security/attackers-use-email-spam-to-infect-pos-terminals.html)以获取信用卡信息。但有趣的是,如果店员正确使用 POS 终端机,那此类攻击就无法奏效。这个例子表明培训和强有力的策略有助于维持系统安全。当然,应用程序本身还是应该足够可靠,以对抗这些攻击。

继续阅读本书,你会发现一些可减少安全漏洞的有用技巧。一旦你承认漏洞会(并且很可能)发生,预防安全漏洞的关键就在于以下几点。

  • 创建用户理解并喜欢使用的应用(见第 2 章)

  • 谨慎选择外部数据(详见 1.6.4 节)

  • 构建具有天然入侵屏障的应用(见第 4 章)

  • 测试所写代码的可靠性,并详细记录故障及其原因(见第 5 章)

  • 谨慎选择外部库、API 和微服务(详见 1.6 节)

  • 对所有的应用元素(甚至是并非你自己所有的元素)执行全面的测试策略(详见第三部分)

  • 管理应用程序的各个部分,以确保安全防护措施不会在应用上线后失效(详见第四部分)

  • 持续跟进最新的安全威胁与解决策略(见第 16 章)

  • 培训开发人员,让他们在每个项目里都自始至终考虑安全问题(见第 17 章)

1.4.2 检测安全漏洞

所有公司最不希望发生的事是,听到别人的安全事故。在行业媒体上读到自己公司无力保护用户数据的报道是开始新一天的最糟糕方式,但这却是许多公司学习安全漏洞的方式。如果一家公司假设已经发生了数据泄露,那它最不可能遭受数据泄露导致的永久性损失,因而最有可能节省成本。公司要能检测数据泄露的出现并防止它变成一个事故,而不应该在它发生之后才耗费时间与资源去修复。检测意味着要提供必需的代码以作为应用程序的一部分,并确保这些检测方法是设计用来处理目前的安全威胁的。

作为一个整体,公司需要一个响应安全漏洞的团队。但是开发团队也需要在适当的地方独立地对安全漏洞进行检测。就目前而言,大部分的开发团队需要以下这些领域的专家:

  • 网络

  • 数据库管理

  • 应用设计与开发

  • 移动技术

  • 网络取证

  • 法规遵从

每个应用程序都需要一个团队,这个团队能够定期讨论与应用程序相关的安全需求和安全威胁。除此之外,审查各种威胁的情况并确定其发生时应该采取的对应措施也很重要。准备好这些之后,你更有可能较早地检测到安全漏洞,即在管理层急匆匆闯进你的办公室要求你给个解释之前。

1.4.3 修复受损的软件

当安全事故确实发生了,公司与之相关的任何团队都必须准备承担责任并采取修复措施。公司层面需要明白,如果不能尽快修复安全漏洞并将系统恢复至事故发生前的状态,那么公司可能面临破产。换言之,即使是公司的高层,你也可能要找一份新的工作了。

安全负责人可能让开发团队帮忙定位攻击者。安全信息与事件管理(security information and event management,SIEM)软件能帮忙查阅指向问题根源的日志。当然,这里假设你的应用程序确实记录了相关的日志。修复过程的一部分是,一开始就要对应用程序构建日志记录与跟踪功能。没有这些信息,要想找到罪魁祸首并阻止其攻击通常注定会失败。

修复过程应该包含对应用程序各部件的更新和补丁进行检查的策略。为了达成这一目标,必须维护良好的应用文档。当安全问题出现时才创建外部资源清单就太迟了,你必须在安全问题发生之前就将外部资源清单掌握在手中。当然,为了确保安全问题不再发生,开发团队需要对所有应用程序需要的更新进行测试。最后,你需要确保数据在整个过程中始终保持安全,并执行应用程序所需的所有数据恢复。

1.5 处理云存储

在一个员工要求随时随地能用身边的任何一种设备访问数据的世界里,云存储是一个必然的灾难。用户有各种各样的云存储解决方案可以选择,但现在最热门的是 Dropbox(https://www.dropbox.com/),到 2014 年年底它已拥有 3 亿多用户。Dropbox(以及很多其他的云存储提供商)有着盛衰无常的安全历史。例如,2011 年,Dropbox 出现了一个 bug,任何人都能用任何密码访问任何账户,这一事故持续了 4 个小时 [ 参见 InformationWeek 的文章(http://www.darkreading.com/vulnerabilities-and-threats/dropbox-files-left-unprotected-open-to-all/d/d-id/1098442)]。当然,所有供应商都会告诉你你的应用数据现在是安全的,他们已经提高了安全性。如果你认为这没什么关系,那么黑客还将会在云存储服务里找到漏洞,或者服务本身会再次出错。

大部分云存储的主要问题在于其天生是公开的。例如,商业版的 Dropbox 听起来非常好,并且确实提供了更多的安全特性,但该服务仍然是公开的。公司不能在自己的私有云上使用该服务。

此外,大多数云服务宣称它们会在自己的服务里加密数据,这似乎是真的。但是,这些服务提供商通常以必须用相关的凭据进行验证后才能访问你的数据为借口,持有着加密密钥。因为你不拥有自己的加密数据的密钥,所以就不能控制对数据的访问,并且加密的作用也会比你想象的小得多。

Web 应用程序的安全是一件大事,因为大部分应用(即使不是全部)始终要有 Web 应用程序的基础。用户想要他们的应用程序无处不在,而浏览器几乎是唯一能以高效的方式在众多平台上提供这种功能的方式。简言之,你必须从一开始就考虑云存储的问题。对于如何将云存储作为 Web 应用程序策略的一部分,有下面几个方案可供选择。

  • 阻止访问

    通过使用防火墙,指定策略或应用程序的特性,确实可能阻止所有对云存储的访问。但是,想要阻止无处不在的想要访问云存储的用户去访问是很难的,并且,用户访问的意愿是相当坚决的。此外,阻止访问会对业务需求产生负面作用。例如,合作伙伴可能会选择云存储来作为交换大文件的方法。阻止策略还会招致用户的愤怒,进而使他们不再使用你的应用程序,或者想办法规避你提供的这个特性。当你的公司必须管理大量敏感数据,有保护数据的法律要求,或者根本不需要用到云存储的灵活性时,阻止访问是最好的选择。

  • 允许不受控的访问

    你可以选择无视云存储使用过程中涉及的相关问题。但是,这样的策略会让公司面临数据丢失、数据泄露以及各种各样的其他问题。不幸的是,许多公司目前正是使用这样的方法,因为控制用户的访问已经变得非常困难,且这些公司缺乏采用其他方法的手段。

  • 依赖公司授权的安全场景

    如果要求用户用公司账户访问云存储,你至少能监控文件的使用并能在职员离职时恢复数据。但是,云存储的基本问题仍然存在。有相关知识的黑客仍然能侵入账户并窃走数据,或者只是以其他方式来窥探你。在你的公司不需要管理法律要求保护的数据,而你也愿意用一些安全性换取方便的时候,这一方案是可行的。

  • 控制应用程序的访问

    许多云服务支持以特别的方式与服务进行交互的 API。虽然这一方法非常耗时,但它确实能让你控制将用户敏感数据保存在哪里,同时用户仍然能够灵活地使用云存储处理不敏感的数据。在公司需要与大量合作伙伴进行交互,还需要管理大量敏感和核心数据时,你应该考虑这一方案。

  • 依赖第三方的解决方案

    你能找到一些第三方解决方案,比如 Accellion(http://www.accellion.com/),它提供了云存储的连接器。这种供应商提供的服务可以作为应用程序与在线数据存储之间的中介。用户可以无缝地与数据进行交互,但连接服务会根据你设置的策略来控制访问。这种方法的问题在于,在开发应用程序时你有额外的一层需要考虑。此外,你必须信任提供连接服务的第三方。在需要拥有灵活性而又不消耗一般的开发成本,并且不想创建依赖于 API 访问的解决方案时,你可以使用这种解决方案。

1.6 使用外部代码和资源

当今的大多数公司都不具有完全从头开始搭建一个应用程序所需的时间与资源。此外,维护这样一个应用程序的成本会很高。为了让成本处于可控范围,公司通常依赖各种形式的第三方代码。这些代码会执行基础任务,而开发人员会像玩乐高玩具一样使用它们组成自己的应用程序。但是第三方代码并不会消除安全方面的挑战。事实上,你正在依赖别人为你的应用程序写出不仅运行良好、能执行所需的所有任务,而且还很安全的代码。接下来会探讨在使用外部代码及资源时会遇到的一些问题。

1.6.1 定义库的使用

库是任何你添加进自己的应用程序的代码。许多人将库定义得更加广泛一些,但对本书而言,其要点是,库包含着代码,并且在应用投入使用时其已成为应用程序的一部分。一个常用的库是 jQuery(https://jquery.com/)。它为应用程序提供了丰富的基础功能。有趣的一点是,在 jQuery 里术语和 API 是可互换使用的,如图 1-2 所示。

{%}

图 1-2:很多网站把库和 API 互换使用

jQuery 的网站还会告诉你关于这个代码库的最佳配置。事实上,jQuery 展示其本身的方式为你想使用的任何库做了个很好的榜样。它有全面的文档,并且你能找到每个调用的多个例子(以确保你至少能找到接近于你想使用的场景的例子)。更重要的是,这些例子是实时在线的,所以你能真实地看到这些代码在与应用程序计划采用的同一款浏览器上的效果。

 像任何其他软件一样,jQuery 也有自己的缺陷。随着进一步阅读本书,你会了解其他的库以及关于它们的更多细节,从而开始发现功能与安全是如何一起运作的。因为 jQuery 是一个如此大而复杂的库,所以它提供了很多功能,但也提供了更多黑客可以利用的攻击面。

当使用库时,安全工作的重点是你的应用程序,因为你从主机服务器上下载用于应用程序的代码。库的代码是在进程内执行的,所以你需要明确获取库代码的源头是可信任的。第 6 章探讨了使用外部库作为应用程序开发策略一部分的复杂性。

1.6.2 定义API的使用

API 是任何可以像进程外服务一样调用的代码。如果你发送一个请求给 API,那 API 就会响应你所请求的资源。资源通常是某种类型的数据,但 API 也执行其他类型的任务。其特点是,代码驻留在其他系统里而不会成为应用程序的一部分。因为 API 是以请求 / 响应方式工作的,所以它们能提供比库更广泛的平台支持,但其运行速度会比库慢,因为其代码与使用它的系统并不在一个地方。

API 的一个优秀例子是 Amazon 提供给不同开发人员的服务(https://developer.amazon.com/)。图 1-3 展示了其中的少量服务。你必须为你想用的每个 API 进行注册,且大多数情况下 Amazon 会给你一个特殊的密钥。因为你正与 Amazon 的服务器进行交互,而不是简单地把代码下载到自己的系统中,所以使用 API 时应遵从的安全规则是不一样的。

{%}

图 1-3:Amazon API 是一个代码在外部主机服务器上执行的例子

每个 API 都有自己的生命周期且依靠不同的方法去处理管理数据等问题。因此,当比较两个 API 时,即使它们都来自同一家机构,你也不能对其中一个作出任何安全性方面的假设。

API 还依赖信息交换。任何信息交换都要求有额外的安全保障,因为你的部分数据始终会落在自己的主机系统上。你需要明白主机应提供适当的安全措施来保护请求中传递的数据。第 7 章探讨了如何安全地将 API 作为应用程序开发策略的一部分。

1.6.3 定义微服务的使用

与 API 类似,微服务也是在主机系统上运行。你发出请求,微服务则响应某种类型的资源(通常是数据)。但是,微服务与 API 差异巨大。微服务的重点放在小型任务上,一个典型的微服务专注于把单一任务执行好。此外,微服务往往很关注平台的独立性,其特点是,提供的服务要能与任何规模、具有任何能力的任何平台进行交互。API 与微服务关注点的不同会极大地影响安全形势。例如,API 往往更具安全意识,因为其所在主机能对发起请求的平台作出更多假设,并且一旦出问题,损失也会更大。

目前的微服务也往往是自产自销的,因为这一技术还比较新。看看现在提供 API 的网站,一旦该技术发展起来,它们也会开始提供微服务。与此同时,看看诸如微服务架构(http://microservices.io/)这样的网站,仔细审查微服务有何不同之处是值得的。这个网站提供了示例应用以及关于当前在线代码不同使用模式的讨论,如图 1-4 所示。

{%}

图 1-4:微服务是一门新技术,而该网站会通过不同的使用模式来帮你认识它们

当使用微服务时,你需要确保其所在的主机是可信赖的,且微服务执行的单个任务是明确定义的。还有一点很重要,要考虑微服务如何与你提供的任何数据进行交互,且不要假设每一个微服务都以相同的方式与数据进行交互(就算这些微服务存在于同一台计算机上)。微服务的使用意味着效率以及在更广泛平台上工作的能力,但你还需要意识到额外的安全检查的要求。第 8 章探讨了如何安全地将微服务作为应用程序开发策略的一部分。

1.6.4 访问外部数据

外部数据有各种各样的形式。任何形式的外部数据都是可疑的,因为有人会在单纯的数据访问行为中对数据进行篡改。但是,对数据按其可见级别进行分类,对我们考虑安全要求的相关事宜是有帮助的。

你通常可以认为私有数据源是相对安全的,不过你仍然需要检查数据是否存在潜在的有害元素(比如数据库字段中的加密脚本)。但是大部分情况下,数据源本身并不会刻意尝试引起问题。下面是最常见的作为外部私有数据源的信息存储来源:

  • 存储在你自己公司主机上的数据

  • 存储在合作伙伴计算机上的数据

  • 由在服务器上运行的应用程序计算出的数据

  • 从传感器或公司提供的其他数据源引入的数据

付费的数据来源也是相对安全的。任何提供付费数据访问服务的人都希望维持与你的关系,并且声誉在这一领域是最重要的。就本地和私有数据而言,你需要验证数据不会损坏或存在潜在威胁,比如一些脚本。但是,因为数据还需要在公共网络上传输,所以你需要检查是否存在由诸如中间人攻击这样的原因而引起的数据伪造和其他潜在问题。

 你可以找到很多有趣的在线数据仓库,当你开发应用时,它们很有用。不用自己创建数据或依靠付费渠道,你通常可以找到一份免费的数据源。Registry of Research Data Repositories 这样的网站现在就提供 API,让你能更准确地搜索到适合的数据仓库。在此情况下,你能在网页 http://service.re3data.org/api/doc 上找到相关的 API 文档。

数据仓库可能会存在问题,并且仓库越公开,就越会产生问题。数据仓库的使用方式确实有所区别,但确保你得到的是真正的而不是伪造的数据,这是最重要的。大多数情况下,你能在使用数据之前将其下载下来并进行扫描。比如,图 1-5 所示的世界卫生组织网站就提供了筛选数据仓库的方法,让你能够准确地找到所需的数据,然后你可以仅下载那部分数据集,从而降低得到不想要的数据的风险。

{%}

图 1-5:有些数据仓库(比如世界卫生组织的数据库)是可下载的

很多数据仓库和方法可以访问它们所存储的数据。你所使用的技术依赖数据仓库的接口以及应用程序的需求。请务必阅读第 3 章中与数据仓库有关的内容。第 6 章、第 7 章和第 8 章讨论了如何在库、API 和微服务中使用外部数据。每一个环境都有不同的要求,所以准确地理解代码会如何影响访问数据的方法,进而需要什么样的安全措施来保障无害地使用数据,这是很重要的。

1.7 允许他人访问

本章绝大部分内容讨论了对资源的保护,或者对由他人提供的数据和资源的使用。企业不是存在于真空中。当你创建了一份数据源、库、API、微服务或别人能用的其他资源时,第三方通常就会请求访问它们。只要允许第三方访问这些资源,你就将自己的网络暴露给了你可能永远无法想象的潜在安全威胁。商业伙伴也许是其他实体,它们似乎相当可靠且不会带来问题。但是,它们的病毒会变成你的病毒。它们面临的任何安全威胁都会变成你要面临的安全威胁。如果有很多第三方在使用你的资源,那么很可能至少有一个存在安全问题并且会导致你也出问题。

当然,在做任何事之前,你需要确保提供给外部的东西与你想象的一样好。确保提供的应用程序的安全性是很重要的。作为资源的提供者,你突然成为多个外部实体的单一故障点。维持环境安全意味着要完成以下事项:

  • 定期检查所有资源以确保它们是可用的

  • 提供有用的资源文档

  • 确保第三方开发者遵守规则(通过在采购语言里加入安全性要求等)

  • 执行必要的安全测试

  • 持续跟进资源存在的潜在威胁

  • 更新主机资源以避免已知的漏洞

将资源提供给外部访问的开发者还需要考虑其他的问题,但这些问题对于任何外部访问的场景来说都是很普遍的。此外,你必须期望第三方去测试资源以确保他们是按所给建议操作的。例如,当提供库、API 或微服务时,你必须期望第三方会执行输入和输出测试,而不是简单地相信你所说的,资源会按预期运行。

一旦通过了将资源提供给第三方使用的初始阶段,你还必须维护这些资源,以便应用程序能继续依靠其运行。此外,想象你在提供资源时面临着某些威胁是很重要的。下面是一些你必须考虑的事项:

  • 黑客会尝试利用你的资源来入侵你的网站

  • 开发人员会滥用资源,并尝试用它执行其设计目的以外的任务

  • 资源会以某种方式受损

目录

  • 版权声明
  • O'Reilly Media, Inc. 介绍
  • 献辞
  • 前言
  • 第一部分 制订安全计划
  • 第 1 章 定义应用环境
  • 第 2 章 迎合用户需求与期望
  • 第 3 章 获取第三方帮助
  • 第二部分 运用成功的编码实践
  • 第 4 章 开发成功的界面
  • 第 5 章 构建可靠的代码
  • 第 6 章 包含库
  • 第 7 章 慎用 API
  • 第 8 章 考虑使用微服务
  • 第三部分 创建有用及高效的测试策略
  • 第 9 章 像黑客一样思考
  • 第 10 章 创建 API 安全区域
  • 第 11 章 检查库和 API 的漏洞
  • 第 12 章 使用第三方测试
  • 第四部分 实现维护周期
  • 第 13 章 明确定义升级周期
  • 第 14 章 考虑更新选项
  • 第 15 章 考虑报告的需要
  • 第五部分 查找安全资源
  • 第 16 章 跟踪当前的安全威胁
  • 第 17 章 获取必需的培训
  • 关于作者
  • 关于封面