ACM通信

实践

保护混乱的网络

由克里斯托弗Kern
ACM通信，2014年9月，第57卷第9期，第38-47页
10.1145 / 2643134
评论(1)

脚本注入漏洞是Web应用程序开发的祸根:原因和补救措施看似简单，但在大规模Web开发中却难以预防。

跨站点脚本(XSS)^2，7，8当Web应用程序内的数据验证、消毒或转义不足，允许攻击者在应用程序的上下文中导致浏览器端执行恶意JavaScript时，就会出现这种情况。然后，这种注入的代码可以使用受害者的特权，做攻击者想做的任何事情。利用XSS bug会导致受害者与脆弱应用程序的会话完全(尽管不一定是持久的)破坏。本文概述了XSS漏洞是如何产生的，以及为什么在真实的Web应用程序软件开发中很难避免它们。然后描述了在谷歌为解决该问题而开发的软件设计模式。

这些设计模式的一个关键目标是将潜在的XSS错误限制在应用程序代码库的一小部分内，从而显著提高了人们推断这类安全错误是否存在的能力。在谷歌内部的几个软件项目中，这种方法大大降低了XSS漏洞的发生率。

类派生的字符串没有得到充分的验证、消毒或转义，这是最常见的XSS漏洞不受信任的源然后传给了水槽这将以一种可能导致脚本执行的方式解释它们。

不可信数据的常见来源包括HTTP请求参数以及位于持久数据存储中的用户控制数据。字符串在赋值给接收器之前通常与更大的字符串连接或内插。最常遇到的与XSS漏洞相关的接收器是那些将分配的值解释为HTML标记的接收器，其中包括mime类型的服务器端HTTP响应text / html,Element.prototype.innerHTML文档对象模型(DOM)⁸属性在浏览器端JavaScript代码中。

图1一个显示来自一个假想的照片共享应用程序的脆弱代码片段。与许多现代Web应用程序一样，它的大部分用户界面逻辑都是在浏览器端JavaScript代码中实现的，但本文中的观察结果很容易转移到通过传统服务器端HTML呈现实现UI的应用程序上。

在图中的代码片段(1)中，当另一个用户邀请用户查看相册时，应用程序为通知生成HTML标记，以显示给用户。生成的标记被分配给innerHTMLDOM元素(浏览器窗口中UI元素的分层对象表示中的节点)的属性，导致它的计算和呈现。

该通知包含专辑的标题，由第二个用户。恶意用户可以创建一个名为:

由于没有应用转义或验证，因此攻击者选择的HTML被原样插入到代码段(1)中生成的标记中innerHTMLsink，因此在受害者会话的上下文中进行计算，执行攻击者选择的JavaScript代码。

要修复此错误，专辑的标题必须为已被html转义在标记中使用之前，确保它被解释为纯文本，而不是标记。HTML转义替换HTML元字符，例如<，>”,，＇，而且＆具有相应的字符实体引用或数字字符引用:<， >， "， ',,．然后，结果将被解析为文本节点或属性值中的子字符串，而不会引入元素或属性边界。

如前所述，大多数具有XSS潜力的数据流都进入将数据解释为HTML标记的接收器。但是其他类型的sink也会导致XSS bug:图1 b显示前面提到的照片共享应用程序的另一部分，负责在登录操作后导航用户界面。在一个新的登录后，应用程序导航到一个预先配置的URL为应用程序的主页。但是，如果登录是由于会话超时导致的，应用程序将导航回用户在超时前访问过的URL。使用Web应用程序中短期状态存储的一种常见技术，该URL被编码在当前URL的参数中。

对象的赋值实现页面导航window.location.hrefDOM属性，浏览器将其解释为将当前窗口导航到提供的URL的指令。不幸的是，在浏览器中导航到表单的URLjavascript: attackScript导致执行URL的主体作为Java脚本。类的参数提取目标URL当前的URL，它通常在攻击者的控制下(受害者访问的恶意页面可以指示浏览器导航到攻击者选择的URL)。

因此，此代码也容易受到XSS的攻击。要修复这个bug，有必要验证通过确保其方案是良性的，例如，https．

回到顶部

为什么XSS如此难以避免?

在实践中，避免将跨站引入重要的应用程序是一个困难的问题:根据开放Web应用程序安全项目(OWASP)，跨站仍然是Web应用程序中最主要的漏洞之一;⁴在谷歌中，它是谷歌漏洞奖励计划(https://goo.gl/82zcPK）.

传统上，关于如何预防跨站综合症的建议(包括我自己的)主要集中在:

• 培训开发人员如何处理(通过消毒、验证和/或转义)插入到HTML标记中的不可信值。^2，5
• 安全审查和/或测试代码，以遵守此类指导。

根据我们在谷歌的经验，这种方法肯定有助于减少XSS的发生率，但即使对于中等复杂的Web应用程序，它也不会阻止XSS的引入，使其具有相当高的置信度。我们看到了导致这种情况的一系列因素。

微妙的安全注意事项．正如所见，安全处理不可信值的需求取决于使用该值的上下文。最常遇到的上下文是HTML标记元素内容中的字符串插值;在这里，简单的html转义就足以防止XSS错误。但是，一些特殊的上下文应用于各种DOM元素和某些类型的标记中，其中嵌入的字符串被解释为url、级联样式表(CSS)表达式或JavaScript代码。为了避免XSS错误，每一个上下文都需要特定的验证或转义，或者两者的结合。^2，5附带的侧边栏，”一个微妙的XSS Bug，这表明要做到这一点是相当棘手的。

复杂的、难以推理的数据流．回想一下，XSS产生于不可信的、未经验证/转义的数据流，这些数据流入容易注入的接收器。要断言应用程序中没有XSS错误，安全审查人员必须首先找到所有这样的数据接收器，然后检查周围的代码，以便进行与上下文相适应的验证和转义传输到接收器的数据。当遇到缺少验证和转义的赋值时，审阅者必须反向跟踪该数据流，直到确定以下情况之一:

• 该值完全受应用程序控制，因此不会导致攻击者控制的注入。
• 该值经过验证、转义或以其他方式安全地构造。
• 该值实际上没有正确验证和转义，很可能存在XSS漏洞。

让我们检查数据流进入innerHTML嵌入代码片段(1)图1一个．为了便于说明，需要研究的代码片段和数据流显示为红色。因为没有转义应用于sharedAlbum.title，我们可以追溯到它的起源专辑实体(4)通过Web前端代码(2)在持久存储中。然而，这不是数据的最终来源——专辑名称之前是由不同的用户输入的(也就是说，起源于不同的时间上下文)。由于没有从最终不受信任的源对该值在其流的任何地方应用转义，因此出现了XSS漏洞。

---

这种方法的主要目标是将可能导致XSS漏洞的代码限制在应用程序代码库的很小一部分。

---

类似的考虑也适用于输入的数据流图1 b:在分配到之前没有立即进行验证window.location.href在(5)中，所以回溯是必要的。在代码片段(6)中，代码探索分支:在真正的分支中，值通过Web前端(8)起源于数据存储(3)中的配置实体;这个值可以被认为是应用程序控制的、值得信任的，不需要进一步验证就可以安全地使用。值得注意的是，持久存储在同一模式的不同实体中同时包含可信和不可信的数据，因此可以对所存储数据的来源进行全面假设。

在else-分支中，URL源自于的参数当前的URL,获得window.location.href，这是一个由攻击者控制的源代码(7)。由于没有验证，此代码路径会导致XSS漏洞。

犯错误的机会很多．图1一个而且1 b只显示一个假设的Web应用程序的两个小片段。实际上，一个大型的、重要的Web应用程序将有数百个(如果不是数千个的话)分支并将数据流合并到容易注入的接收器中。如果开发人员犯了与验证或转义相关的错误，每个这样的流都可能导致XSS错误。

对安全审查人员来说，探索所有这些数据流并断言不存在XSS是一项艰巨的任务，特别是考虑到正在积极开发的项目的代码库不断变化。使用启发式方法静态分析代码库中的数据流的自动化工具可以提供帮助。然而，根据我们谷歌的经验，它们并不能大大增加基于审查的评估的信心，因为它们的推理必然是不完整的，而且容易出现假阳性和假阴性。此外，他们在推理跨多个系统组件的整个系统数据流、使用各种编程语言、RPC(远程过程调用)机制等等以及涉及跨数据存储的多个时间上下文的流方面与人工审查员有类似的困难。

类似的限制适用于动态测试方法:很难确定测试套件是否为整个系统数据流提供了足够的覆盖。

模板来拯救我们?在实践中，HTML标记和其中的插补点通常使用HTML模板．模板系统公开用于呈现HTML标记的领域特定语言。HTML标记模板将一个函数从模板变量导入到HTML标记字符串中。

图1 c演示了HTML标记模板的使用(9):这个示例在照片共享应用程序中呈现了一个用户配置文件，包括用户的姓名、一个到个人博客站点的超链接以及允许用户表达任何特殊兴趣的自由格式文本。

有些模板引擎支持自动转义，其中转义操作会自动插入到模板的每个插补点周围。大多数模板引擎的自动转义功能是非上下文的，并且不加区分地应用HTML转义操作，但是不考虑特殊的HTML上下文，如url、CSS和JavaScript。

上下文auto-escaping模板引擎⁶推断每个模板替换的上下文所需的必要验证和转义操作，从而解释这些特殊的上下文。

使用上下文自动转义的模板系统极大地减少了潜在的跨站漏洞:在(9)中，替换不可信的值profile.name而且profile.blogUrl模板系统会自动推断所需的html转义和url验证。

然而，在不使用模板的代码中，XSS bug仍然可能出现，例如图1一个(1)，或者涉及非html接收器，如图1 b(5)。

此外，开发人员偶尔需要避免某些替换自动转义:in图1 c(9),逃离的profile.aboutHtml被显式地抑制，因为该字段被假定包含用户提供的带有简单、安全的HTML标记的消息(以支持在“about myself”用户概要字段中使用字体、颜色和超链接)。

不幸的是，有一个XSS错误:标记profile.aboutHtml它最终起源于在浏览器端代码中实现的富文本编辑器，但没有服务器端强制措施来防止攻击者使用篡改过的客户端注入恶意标记。在实践中，这个错误可能是由于前端和后端开发人员对数据验证和消毒责任的误解而产生的。

回到顶部

可靠地防止XSS bug的引入

根据我们在谷歌安全团队中的经验，代码检查和测试在相当高的可信度上并不能确保大型Web应用程序中没有XSS错误。当然，检查和测试都提供了巨大的价值，通常会发现一些应用程序中的bug(甚至可能是大多数)，但很难确定他们是否发现了所有bug(甚至。几乎所有的其中)。

这种方法的主要目标是将可能导致XSS漏洞的代码限制在应用程序代码库的很小一部分。

这种方法的一个关键目标是大幅减少可能导致XSS错误的代码。特别是，使用这种方法，应用程序的结构使其大部分代码不能负责XSS错误。因此，潜在的漏洞局限于基础架构代码，例如Web应用程序框架和HTML模板引擎，以及小型的、自包含的特定于应用程序的实用程序模块。

第二个同样重要的目标是提供与现有开发人员工作流相比不会增加不可接受的摩擦程度的开发人员体验。

这种方法的主要组成部分是:

• 固有的安全api．易于注入的web平台和html呈现api被封装在包装器api中，其设计初衷是对XSS具有内在的安全性，即使用此类api不会导致XSS漏洞。
• 安全类型的合同．特殊类型是通过契约来定义的，契约规定它们的值在特定的上下文中是安全的，无需进一步转义和验证。
• 编码指南．编码准则限制直接使用易于注入的api，并确保对某些安全敏感的api进行安全审查。可以通过简单的静态检查来加强对这些指导方针的遵守。

固有的安全api．我们的目标是为易于注入的浏览器端Web平台API接收器以及服务器端和客户端HTML标记呈现提供固有安全的包装器API。

对于某些api来说，这很简单。例如，脆弱的赋值图1 b(5)可以被替换为使用固有安全的包装器API，由JavaScript闭包库提供，如图2 b(5 ')。包装器API在运行时验证所提供的URL是无方案的URL还是具有已知的良性方案的URL。

使用安全包装器API可确保此代码不会导致XSS漏洞，而不管所分配URL的来源如何。关键的是，(5’)中的代码及其(6-8)中的扇入都不需要检查XSS错误。当(且仅当)第一个分支被取走，从配置存储中获得的URL被验证，即使它实际上是一个值得信任的值，这在技术上是不必要的运行时验证的成本非常小。

在某些特殊场景中，由固有安全API强加的运行时验证可能过于严格。这种情况可以通过固有安全api的变体来实现，这些api接受具有适合所需使用上下文的安全契约的类型。根据它们的契约，这些值无需进行运行时验证。下一节将更详细地讨论这种方法。

严格地上下文自动转义模板引擎．为HTML呈现设计一个固有安全的API更具挑战性。我们的目标是设计这样的api，确保在数据替换到可信HTML标记中的特定上下文中时，数据得到适当的验证、消毒和/或转义，除非可以根据其来源或先前的验证、消毒或转义证明特定数据项在该上下文中使用是安全的。

这些天生安全的api是通过加强上下文自动转义模板引擎的概念来创建的⁶成SCAETEs (严格上下文自动转义模板引擎)。实际上，SCAETE在模板代码上附加了两个约束:

• 不允许禁用或修改自动推断上下文转义和验证的指令。
• 模板只能使用递归坚持相同约束的子模板。

安全类型的合同．在刚才描述的形式中，sceas不考虑模板参数打算在不进行验证或转义的情况下使用的场景，例如aboutHtml在图1 cSCAETE无条件地验证和转义所有模板参数，并禁止禁止自动转义机制的指令。

这样的用例是通过契约规定其值可以在相应的HTML上下文中安全使用的类型来实现的，例如“内部HTML”、超链接url、可执行资源url等等。类型契约是非正式的:一个值满足给定的类型契约，前提是它已经被验证、净化、转义或构造，确保在类型的目标上下文中使用它不会导致攻击者控制的脚本执行。这是否真的是事实，取决于基于Web平台相关行为的专家知识，对创建此类值的代码进行专家推理。⁸正如将看到的，这种安全敏感的代码封装在少量专用库中;应用程序代码使用这些库，但它本身不依赖于正确创建此类类型的实例，因此不需要进行安全性审查。

下面是正在使用的类型和类型契约的示例:

• SafeHtml．类型的值SafeHtml，转换为字符串，当作为HTML标记使用时，不会导致攻击者控制的脚本执行。
• SafeUrl．当将此类型的值解引用为超链接url时，将不会导致攻击者控制的脚本执行。
• TrustedResourceUrl．此类型的值可以安全地用作可执行文件或“控件”资源的URL，例如src属性的<脚本>元素，或者CSS样式表的源。本质上，这种类型承诺其值是资源的URL，该资源本身是值得信任的。

这些类型被实现为包含底层字符串值的简单包装器对象。类型成员关系通常不能通过运行时谓词建立，类型的经过安全审查的工厂方法和构建器负责保证它们产生的任何实例的类型契约。类型成员关系可以基于处理(例如，验证或消毒)、构造和来源，或者它们的组合。

scaut使用安全契约来指定自动转义的豁免:如果替换值的类型的契约支持它在替换的HTML上下文中的安全使用，则替换值不受运行时转义的约束。

由SCAETE处理的模板产生保证发出不会导致XSS的HTML标记的函数，假设模板参数遵守它们的安全契约(如果适用的话)。实际上，应用scaete诱导的模板函数本身的结果满足SafeHtml合同类型。

图2 c展示了SCAETE和安全类型契约在的代码片上的应用图1 c．(9)中模板的严格上下文转义不允许使用noAutoescape指令。但是，只要删除它，就可以自动转义该值，这在本例中是不需要的。相反，我们改变aboutHtml要拥有的概要文件对象的字段SafeHtml类型，该类型不会自动转义。这种类型的使用贯穿整个系统(用绿色表示)，穿过rpc一直到后端代码中值的原点(12')。

不转换．当然，最终我们需要创建所需的类型值SafeHtml．在本例中，持久存储中的相应字段包含可能由攻击者恶意提供的HTML标记。将这个不受信任的标记通过HTML杀毒器传递，以删除可能导致脚本执行的任何标记，使其在HTML上下文中可以安全地使用，从而生成满足SafeHtml合同类型。

要真正创建这些类型的值，不转换提供的工厂方法使用任意字符串并返回给定包装器类型的实例(例如，SafeHtml或SafeUrl)而不应用任何运行时消毒或转义。

对这种未检查转换的每次使用都必须进行仔细的安全性审查，以确保在所有可能的程序状态下，传递给转换的字符串都满足基于上下文特定的处理或构造的结果类型的契约。因此，应该尽可能少地使用未经检查的转换，并且只在出于安全审查目的可以很容易地对其使用进行推理的场景中使用。

例如,在图2 c在美国，未检查转换与HTML杀毒器实现一起封装在一个库(12")中，杀毒器的使用依赖于其正确性，允许隔离地进行安全检查和测试。

编码指南．要使这种方法有效，必须确保开发人员编写的应用程序代码不会直接调用潜在的容易注入的接收器，而是使用相应的安全包装器API。此外，它必须确保未检查转换的使用在设计时考虑到了可审查性，并且实际上经过了安全性审查。这两个约束都代表了所有应用程序代码库必须遵守的编码准则。

根据我们的经验，即使在中等规模的项目中，编码指导方针的自动执行也是必要的，否则，随着时间的推移，违反一定会悄悄发生。

在谷歌上，我们使用开源的容易出错的静态检查器¹（https://goo.gl/SQXCvw)，它被集成到谷歌的Java工具链中，以及谷歌的开源闭包编译器(https://goo.gl/UyMVzp)将JavaScript中特定方法和属性的使用列入白名单。使用“被禁止的”API产生的错误包括参考相应安全API的文档，建议开发人员如何解决错误。通过谷歌的分布式构建系统提供的包可见性机制，对使用未检查转换的审查要求得到强制执行。^3.

如果工具链集成的检查不可用，那么可以通过更简单的类似lint的工具来执行编码指南。

在照片共享的例子中，这样的检查将引发分配给的错误innerHTML而且location.href在图1一个1 c并建议开发者使用相应的固有安全API。对作业innerHTML，这通常意味着用一个严格的模板替换HTML标记的临时连接，由模板系统的运行时直接呈现到DOM元素中，如图2一个．

回到顶部

把它们放在一起

在示例应用程序的代码片段符合编码指南之后，重新查看它们可以看到(图2一个2摄氏度)中容易注入的数据接收器的使用已被(1’)、(5’)、(9’)和(10’)中相应的固有安全api所取代。现在，这些代码片段都不会导致XSS错误，而且在安全审查期间也不需要检查它们及其风扇入。

需要检查安全代码的惟一代码段(除了SCAETE的实现、它的运行时和API包装器库等基础结构代码之外)是HtmlSanitizer包(12")，特别是将包本地扇入转换为未检查的转换SafeHtml．这种转换的正确性完全依赖于HTML杀毒器的正确性，并且可以独立地检查和测试这个包的安全性。如果一个库在多个应用程序之间共享，那么它的审查成本将在用户之间摊销。

当然，这种方法所能提供的保证是有局限性的:首先，安全审查人员可能会错过代码中与安全相关的部分(模板系统、标记杀毒器等等)中的bug;其次，应用程序代码可能使用反射等结构，而这些结构违反了我们所依赖的类型的封装;最后，一些类的XSS错误(实际上相对较少)不能通过我们的设计模式所确保的一般应用上下文数据验证和转验来解决，这些问题需要在Web应用程序框架的其他层或在单个Web应用程序的设计中解决。⁷

---

使用这样的api可以防止XSS错误，并在很大程度上使开发人员不必考虑和显式地指定转义和数据验证。

---

开发人员的影响．中脆弱代码片的比较图1一个1 c和他们安全的同伴在一起图2一个2摄氏度显示我们的方法不会对开发人员工作流进行重大更改，也不会对代码进行重大更改。例如,在图2 b(5’)，我们简单地使用一个安全的包装而不是“原始的”web平台API;否则，此代码及其扇入保持不变。

编码准则确实要求开发人员使用安全的api来生成HTML标记，例如图2一个(1)。然而，作为回报，使用这样的api可以防止XSS错误，并在很大程度上使开发人员不必考虑和显式地指定转义和数据验证。

只有在图2 c是否需要对应用程序进行更重要的更改:aboutHtml场变化字符串来SafeHtml，并且这种类型的使用是从后端到前端贯穿rpc。即使在这里，所需的更改也相对有限:更改字段的类型和添加对HtmlSanitizer库的后端代码(12')。

这样的场景在典型的Web应用程序中很少见;在绝大多数使用中，自动运行时验证和转义在功能上是正确的:大多数数据流到用户界面标记中，包括应用程序控制的和用户输入派生的，都倾向于表示纯文本、规则文本http / httpsurl和其他验证和/或转义干净的值。

回到顶部

实际应用

此设计模式已应用于谷歌上使用的几个开放源码和专有Web应用程序框架和模板引擎:闭包模板已添加了对严格上下文自动转义的支持(https://goo/gl/Y4G9LK), AngularJS (https://goo.gl/RvQvXb)，以及谷歌专有的模板系统。谷歌的安全工程师和基础设施开发人员还实现了诸如SafeHtml而且SafeUrl，并向谷歌Web Toolkit (https://goo.gl/dGk5G8)、JavaScript闭包库(https://goo.gl/7nbXCg)，以及各种google专有的库和框架。

降低XSS bug的发生率。要获得关于任何特定方法对错误预防的影响的精确统计数据是很有挑战性的:我们的设计模式首先防止引入XSS错误，但是我们不知道如果不使用它们会引入多少错误。

但是，我们可以根据采用我们方法的现有大型项目中的bug计数进行观察。这样的观察结果可能只是传闻，因为bug计数可能受到许多变量的影响，如代码大小、复杂性和与安全相关的开发人员教育程度。尽管如此，观察结果表明，我们的方法显著降低了XSS漏洞。

旗舰谷歌应用程序的几个开发团队已经采用了这些设计模式和编码指南。他们建立了静态强制，即所有HTML标记都是由严格上下文自动转义的模板生成的，并且禁止直接使用某些易于注入的web平台api，例如innerHTML．

其中最大也是最复杂的一个应用程序，使用了超过1000个闭包模板语言的HTML模板，在2013年初迁移到严格的自动转义。整个2012年(在迁移之前)，谷歌的bug跟踪器中针对该应用程序提交了31个XSS bug。迁移后，到2014年年中，只有4个XSS bug被提交，2014年上半年一个也没有。对于另一个大型应用程序(也使用1,000多个模板)，其迁移仍在进行中，在同一时期内XSS bug从21个减少到9个。

即使没有完全遵从编码指导方针，也可以实现一些好处:随着遵从代码的比例增加，可能导致漏洞的代码比例减少，对没有bug的信心增加。虽然没有理由不完全按照指导方针编写新代码，但是如果重构的成本超过了收益，并且我们已经通过其他方法(例如，密集的检查和测试)对代码的安全性有信心，那么我们可以选择不重构某些现有代码。

回到顶部

结论

软件设计可以用来将潜在的跨站漏洞隔离到应用程序代码库的很小一部分中。这使得只对代码的那些部分进行密集的安全检查和测试变得切实可行，从而使Web应用程序作为一个整体不容易受到XSS错误的影响。我们的方法实际上适用于大型的、复杂的、真实的Web应用程序，它已经在几个开发项目中显著减少了XSS错误。

这种解决涉及整个系统数据流的难题的方法包含两个关键原则:

• 根据观察，在典型的Web应用程序中，保守地运行时转义和验证流入易于注入的接收器的绝大多数数据在功能上是正确的，我们选择将所有字符串类型的值视为潜在的不可信的，并服从于运行时验证和转义，而不管它们的来源如何。这种设计选择完全避免了对典型Web应用程序中的绝大多数整个系统数据流进行整个程序推理的需要。
• 只有在默认值、运行时验证和转义在功能上不正确的情况下，我们才使用类型契约来传达在给定上下文中使用某些值已经是安全的。类型的这种使用允许对整个系统数据流进行组合推理，并允许安全专家基于包局部推理孤立地审查安全关键型代码。

我们的编码准则对应用程序代码施加了一定的约束(尽管它们通常只要求对现有代码进行有限的更改)。相比之下，许多现有的预防和检测XSS的方法旨在适用于现有的、未修改的代码。这个需求使问题变得更加困难，并且通常需要使用复杂的整个程序静态和/或动态数据流分析技术。有关该领域现有工作的概述，请参见Mike Samuel等人。⁶放松这一需求否定了对特殊用途的工具和技术的需求(例如运行时污点跟踪或整个程序静态分析)，允许我们仅仅依赖于软件设计、由非常简单的静态检查执行的编码指南、现有的语言原生类型系统，以及对现有上下文自动转义模板系统的一个小增强的组合。因此，我们的方法可以用于用各种编程语言编写的应用程序中，而不需要对工具链、构建系统或运行时环境提出特殊要求。

相关文章
在queue.acm.org

生产故障注入
约翰Allspaw
http://queue.acm.org/detail.cfm?id=2353017

高性能网站
Steve Souders
http://queue.acm.org/detail.cfm?id=1466450

恶性XSS
乔治Neville-Neil
http://queue.acm.org/detail.cfm?id=1113330

回到顶部

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2014 ACM, Inc.

---

评论

---

显示1评论