OWASP中与Angular开发人员相关的威胁

许多前端开发人员可能将安全性视为非功能性问题，由安全部门处理，而他们应该只专注于功能开发。现实情况是，对安全性的了解实际上迫使您获得有关浏览器工作方式的知识，从而总体上可以使您成为更好的Angular开发人员。

在当今时代，高绩效团队通常是自主的DevOps团队，并使用连续交付以更快地交付功能。只有当我们前端开发人员在构建功能部件时也对安全性负责时，这种工作方式才有可能。

这篇文章旨在通过加深对与Angular开发人员相关的浏览器和安全概念的了解，为您提供在功能开发中构建安全性并成为更好的开发人员的专业知识。

我将介绍与Angular开发相关的OWASP十大安全威胁，并在这篇文章中解释如何缓解每种威胁。

OWASP的前十名是来自“开放式Web应用程序安全性项目”基金会的十大Web安全性风险列表。它由一组安全专家组成，每3-4年发布一次相关安全风险的前10名列表，许多公司都将其用于集中精力进行安全工作。

OWASP十强已经发展了许多年，并且摆脱了一些安全风险，这些风险已不再足以使其成为2017年版的十强。

其他威胁主要在后端处理，因此不在本文中讨论。

让我们看一些基本的安全概念，以增进我们对浏览器工作方式的理解。

同源策略（SOP）是一种安全概念，它限制了一个起源与其他起源的交互方式。来源包括协议，域和端口：

在同源策略中，通常禁止跨源进行读取，而通常允许跨源进行写入。

对于写入，允许链接，重定向和表单提交。使用SOP和跨域写入的一般经验法则是：允许您使用HTML表单执行的所有操作

使用SOP和跨域写入的一般经验法则是：允许您使用HTML表单执行的所有操作。

默认情况下，不允许从其他来源读取（稍后会在CORS标头中提供更多信息）。这样做将导致此错误（您尝试从另一个来源获取）：

当嵌入脚本，CSS和图像时，通常也允许嵌入，因此通常也是常见的攻击面（我们将在后面介绍）。

隐式身份验证意味着身份验证是基于浏览器在每个请求上自动（隐式）发送的内容。这可能是cookie，HTTP基本身份验证和TLS客户端证书。

这种身份验证的问题是，如果服务器没有明确地防止这种情况的发生（例如，跨站点请求伪造攻击，攻击者就有可能代表用户执行经过身份验证的写操作），我们将很快看到更多信息。关于）。

显式身份验证是指开发人员手动（显式）发送身份验证令牌，例如通过HTTP标头。最常见的方法是在标头中使用OAuth承载令牌。

跨域资源共享是一种由服务器上的HTTP响应标头控制的机制，用于允许源对服务器执行“非HTML格式兼容”请求。根据此类请求，浏览器将首先发出预检请求，以加载CORS标头，然后执行实际请求。

如果这是跨域的非格式请求，浏览器会自动发送预检（OPTIONS），以读取Access-Control-Allow-Origin标头。如果标题存在且有效（需要包含客户的来历或*），则客户将继续实际的请求。

“不符合HTML表单格式”请求是一种包含自定义标头和标准HTML表单内容类型以外的内容类型的请求：

跨域资源处理的最佳实践是将起源白名单，允许调用服务器而不是使用通配符*的起源。

CSRF攻击涉及攻击者利用隐式身份验证（例如会话cookie）来使您向站点发出经过身份验证的请求。 CSRF攻击是由许多框架和机制（例如CMS和OAuth2）自动处理的，因此不再足以使其成为2017年OWASP十大威胁，但仍然值得了解如何在Angular应用程序中进行缓解。

典型的CSRF攻击涉及到攻击者托管一个站点，一旦我们的用户访问了该站点，该站点就会向目标网站发出请求。如果目标站点使用隐式身份验证并且用户已经在目标站点上进行了身份验证（并且没有CSRF保护），则此方法将起作用。

如果服务器包含Access-Control-Allow-Origin：*我们只需要隐式身份验证就可以将CSRF攻击（是否告诉您不要在CORS中使用通配符？）作为非标准标头和非格式内容类型是导致CORS起飞前必要的原因。

用户访问攻击者站点，该站点向bank.com执行表单请求，其中使用会话cookie对用户进行身份验证。该站点现在可以触发例如。代表用户帐户的付款。

在大多数情况下，CSRF不再是安全威胁，因为大多数Angular应用程序都使用诸如OAuth2之类的显式身份验证。

如果您的应用程序使用隐式身份验证，例如使用Cookie，那么保护自己免受CSRF攻击的最简单方法是：

由于自定义标头无法在没有CORS进行预检的情况下跨域发送，因此，如果您不使用Access-Control-Allow-Origin：*，这将使您免受CSRF的攻击。

Angular的HttpClient在执行更改请求（例如POST）时，会在每个请求上自动发送X-XSRF-TOKEN标头。

对于Node Express服务器，中间件csurf可以轻松处理此问题，它将检查每个请求中是否存在CSRF标头。

敏感数据泄露是指攻击者在传输过程中（例如在中间人攻击中）或通过篡改请求的页面来使敏感数据被读取。如果DNS被黑。

中间人攻击涉及一个中介网络设备，该设备能够读取未加密的数据并在请求站点时篡改返回的有效负载。

我们将看到，即使使用HTTPS，中间人也可能发生攻击：

客户端将来的请求现在是中间人可以嗅探和篡改的HTTP

这里的基本问题是，第一个请求未加密，因此中间的人可能会对其进行篡改。有两种解决方案； VPN和HSTS标头。

VPN不是您可以在自己的站点上设置的安全机制，因此让我们关注HSTS标头。

解决方案是通过使用HTTP严格传输安全标头来确保第一个请求是HTTPS。

通过将过期时间设置为一年以上，并设置includeSubDomains和preload，该站点将成为浏览器预加载列表的一部分，该列表是浏览器中的硬编码列表，从而确保仅通过HTTPS请求该站点。您可以在此处检查您的域是否在预加载列表中。否则，每次HSTS标头到期时，客户端都会执行HTTP请求。

遭到入侵的DNS涉及攻击者获得对DNS服务器的控制权，并能够将域指向其他服务器，例如。自己的恶意网站。

在UI方面，此恶意网站可能是原始网站的克隆，但包含例如的逻辑。嗅探登录名和信用卡。

保护用户免受DNS侵害的解决方案是使用脚本标记中的完整性属性，加载DNS资源，这是一种校验和机制，可确保DNS服务的完整性：

现在，如果CDN中的完整性受到损害，您将得到一个错误。许多DNS提供商都支持此功能。

跨站点脚本是最危险的威胁之一，因为它涉及攻击者通过从应用程序的输入源（例如数据存储和URL）执行javascript来控制应用程序的javascript。

MySpace的Samy蠕虫是最著名的XSS攻击之一。一位19岁的男子Samy发现，您可以将HTML（包括脚本标签）注入您的个人资料页面，以控制访问您个人资料页面的用户的javascript。

他用它为访客注入蠕虫，蠕虫写道：“……而所有萨米人都是我的英雄”，并把萨米添加为他们的朋友。为了使它成倍地传播，他还确保访客的访客也将感染相同的蠕虫。

他最终收到了超过一百万个朋友的请求，而MySpace必须关闭他们的网站几个小时才能了解发生了什么。 Samy最终获得了3年的“无互联网”缓刑。

该蠕虫是Web安全的转折点，因为它更加关注跨站点脚本威胁，而这些威胁似乎在许多其他站点上都存在。

源是用户输入，当未验证和/或清除XSS漏洞时，它们可以处理XSS漏洞。源应经过验证，水槽应经过消毒以保持安全。

XSS攻击涉及某种用户输入（源），它由代码中的接收器执行。接收器可以在其中执行用户输入，从而导致XSS波动。

或任何可以更新Dom的默认Javascript方法，例如。注入脚本标签：

因此，建议避免在Angular应用程序中使用任何这些接收器，而应遵循“ Angular方式”，并让Angular负责DOM操作，并避免将字符串传递给任何接收器（例如setTimeout）。另外，在XSS攻击的情况下，我们想限制破坏，例如。通过确保无法从Javascript中读取敏感数据。

内容安全策略或CSP是主机服务器上的HTTP响应标头，用于防止跨站点脚本攻击。此标头有一些用于将资源来源列入白名单的指令。确定允许从哪个域加载脚本和iframe源。

例如。用于仅允许从当前来源和https://example.com加载脚本，以及仅允许iFrames加载表单原始网站和https：// youtube的CSP，CSP为：

在为Angular应用提供服务时，应从托管服务器返回此标头。

点击劫持攻击是将您的网站隐式地嵌入到攻击者的网站上的位置，因此，例如当您点击时。在尝试点击攻击者网站上的按钮时，实际上是在您自己的网站上单击“付款”，您可能会在该网站上被授权执行此操作。

CSP标头还可以通过限制网站的嵌入位置来防止点击劫持攻击：

当涉及到XSS安全性时，Angular会承担繁重的工作（这就是为什么您不应该手动更改DOM的原因，例如使用DOM API或jQuery）。 插值将删除代码中的所有“危险标签”，这意味着任何可以接管网站控制权的标签。 内部HTML将允许呈现一些“安全”标签，而不安全标签将被写出。 插值不会对标签做任何事情，并且字符串将在写入时显示出来。 摆脱XSS攻击的最好方法是仅通过Angular的插值更新DOM（我是否提到过？）。 Angular的内置保护功能还将禁止执行其他操作，这些操作可能会导致XXS漏洞，例如将动态URL传递给例如。 iframe，图片或脚本代码。 在一种情况下，我们需要绕过Angular的安全性，那就是我们想将动态URL传递给iFrame。

在这种情况下，iFrame的URL将需要绕过Angular的安全性，因此它受到Angular的信任，或者我们得到：

另外，当我们绕过Angular的安全性时，我们需要确保自己清除输入内容，并将可能通过CSP frame-src注入的URL列入白名单。

可信类型是一种CSP指令，用于通过指定允许传递到接收器的可信类型来防止XXS（因为将输入传递到接收器是XXS攻击的根源）。

可信类型是通常经过某种形式的清理的值，并被浏览器标记为可以安全地用于接收器中。

注意：如果您使用延迟加载，则当前Angular应用程序与Trusted Types不兼容，因为Webpack试图将Sink（src）设置为不受信任的类型，您将收到此错误：

这意味着在大多数情况下，您还不能在Angular应用中使用Trusted Types。解决了webpack / Angular问题后，就可以在本节中使用该理论了。

要从更务实的角度了解受信任的类型，让我们看看如何在您的应用中使用受信任的类型。

如果您将任何不受信任的值传递给接收器并将其报告给报告URI，则将导致安全错误。

我们还可以指定策略白名单以允许创建“受信任的类型”：

这表示;需要DOM XXS注入接收器功能的受信任类型，并且这些受信任类型需要使用策略customtype1或customtype2创建。

如果在标头中未指定任何受信任的类型策略，则可以使用DOMPurify库清理并返回受信任的类型：

否则，如果您不想/不能依赖第三方库，则可以创建一个自定义策略来处理清理并返回Trusted Type：

if（window.trustedTypes＆amp;＆amp; amp; amp; amp; amp; amp; amp; amp; amp; amp; amp ;; TrustedTypes.createPolicy）{//功能测试const escapeHTMLPolicy = trustTypes.createPolicy（＆＃39; custompolicy1＆＃39 ;, {createHTML：string =＆gt; string.replace（/ \＆amp; lt // g，＆＃39;＆amp; lt;＆＃39;）}）;}

const转义= custompolicy1.createHTML（＆amp; lt; img src = x onerror = alert（1）＆gt;＆＃39;）; console.log（TrustedHTML的转义实例）; // trueel.innerHTML =转义； //＆amp; lt; img src = x onerror = alert（1）＆gt;＆＃39;

您可以使用默认策略自动清除传递到接收器的字符串，这对于避免来自第三方库的Trusted Type违规有时是必要的（因为您无法在其中使用自定义策略）：

if（window.trustedTypes＆amp; amp; ampedTypes.createPolicy）{//功能测试trustTypes.createPolicy（＆＃39; default＆＃39 ;, {createHTML：（string，sink）=＆gt; DOMPurify.sanitize（字符串，{RETURN_TRUSTED_TYPE：true}）}）;}

但是请注意，不建议使用这样的全局代码，因为它会破坏封装。相反，最佳实践是首先尝试使用DOMPurify（没有指定的受信任的类型策略）或自定义策略（在标头中指定受信任的类型策略）。

这些可以用来对您的应用进行安全审查，并使其明确，例如。如果要允许不安全的旁路并使用jit编译器。

为了指定在应用程序中既不允许不安全旁路也不允许jit编译器，可以设置以下CSP标头：

如果发生XSS攻击，我们希望减轻损害，因此我们例如。不要让攻击者收集登录信息和信用卡。

我们这样做是通过将敏感数据（例如登录名和信用卡表单）与网站分开来实现的，方法是将其显示在另一个来源托管的iFrame中，因为Javascript无法跨来源读取iFrame的DOM（只能通过某些方法（例如自定义进行通信）事件）。

这种方法很常见，但如果您遇到这种情况，仍然容易受到XXS攻击。在iFrame上放置一个嗅探器，以收集用户输入。

更好，更安全的方法是将登录站点或付款站点完全重定向到另一站点（位于另一个来源），因为这将使XXS攻击无法访问这些单独的站点。

这涉及使用第三方库，这些库要么存在安全漏洞，要么有意试图对我们做有害的事情（例如，收集敏感数据，挖掘密码或监视用户）。在当今时代，我们的应用程序主要由第三方代码组成，这也使这成为最危险的威胁之一。

使用npm审核扫描npm软件包。这可以让您知道您的软件包是否包含已知漏洞。

第三方库要格外小心，这些库没有受信任的组织支持+未被广泛采用。

如上一节所述，在发生破坏的情况下缓解XSS攻击（保护敏感数据，使用受信任的类型和CSP）。

在本文中，我们研究了OWASP排名前10位与Angular开发人员相关的威胁。

我们介绍了SOP和CORS等安全概念。 我们还研究了CSRF，敏感数据泄露，XXS和具有已知漏洞的组件等威胁。 学习这些内容将帮助您开发更安全的Angular应用程序，并避免出现漏洞，从而为您的公司节省数百万美元。 在Angular Architect Accelerator中，我将通过逐步的代码演示来介绍这些安全性概念以及更多内容，因此您确切地知道如何遵循Angular应用程序的安全性最佳实践。 您现在可以注册免费的热身研讨会。 我是Christian，是一位自由软件开发人员，致力于帮助Angular开发人员。 如果您喜欢我的帖子，请确保在Twitter上关注我。