天蓝色在ps中的色值_天蓝色devsecops管道Web配置

天蓝色在ps中的色值

Content Security Policies & The Occasional Silent Failure

内容安全策略和偶发的静默故障

The Preface

前言

Forewarned, this one got away from me a little! It covers the usage of ‘Best Practice’ Web-Server Security Headers, specifically for Microsoft’s Azure Platform and AzureDevOps (Formerly Visual Studio Team Services). Over my Time at Head Full of Heart I’ve also come across a few little ‘gotchas’ that come along with these headers and some tools that make life easier.

事先警告，这个人离我有点远！ 它涵盖了“最佳实践” Web服务器安全标头的用法，专门用于Microsoft的Azure平台和AzureDevOps(以前称为Visual Studio Team Services)。 在我全力以赴的时间里，我还遇到了一些带有这些标题的小“陷阱”以及一些使生活更轻松的工具。

Web.Config最佳实践 (The Web.Config Best Practice)

The group at OWASP have a nice project called the “Secure Headers Project”. It lists and lays out all the headers you should probably be sending from your web-server of choice. In the case of Azure WebApps, it’s Microsoft IIS. The headers themselves applicable across all the major Web Servers (Nginx, Apache, IIS, Kestrel, etc…), with their applicable syntax applied.

OWASP的小组有一个很好的项目，称为“安全标头项目”。 它列出并列出了您可能应该从选择的Web服务器发送的所有标头。 对于Azure WebApp，它是Microsoft IIS。 标头本身适用于所有主要Web服务器(Nginx，Apache，IIS，Kestrel等)，并应用了适用的语法。

If that sounds good and you just want the code, there is an example of the “Bare Starting Minimum” here, and the “Gold Standard” here. There is also the jokingly titled “Draconian” here. Just keep in mind that your security needs will certainly be different, and these are just some starting points!

如果这听起来不错，只是想和你的代码中，有“裸启动最低”的一个例子在这里 ，和“黄金标准” 在这里 。 也有开玩笑的标题为“恶法” 在这里 。 请记住，您的安全需求肯定会有所不同，而这些只是一些起点！

While I won’t list every header you can send (the full list can be found at https://www.owasp.org/index.php/OWASP_Secure_Headers_Project) The absolute bare minimum is used at Head Full of Heart are the following:

虽然我不会列出您可以发送的每个标头(完整列表可以在https://www.owasp.org/index.php/OWASP_Secure_Headers_Projec t上使用)，但在“满头的心”中使用了绝对的最低要求，如下所示：

• HSTS
  HSTS
• X-Frame-Options
  X框架选项
• X-XSS-Protection
  X-XSS保护
• Content Security Policy (CSP)
  内容安全政策(CSP)
• X-Content-Type
  X内容类型

As these are very much settings-per-web-server and settings-per-web-application, there is absolutely nothing stopping you having boilerplate, secure-by-default configurations that need only a little tweaking (usually, it’s all in the CSP Header). For me, it starts out looking something like this:

由于这些都是每个Web服务器的设置和每个Web应用程序的设置，因此绝对没有阻止您进行样板操作的默认安全配置，只需进行一些调整即可(通常，所有这些都在CSP中)标头)。 对我来说，开始看起来像这样：

<httpProtocol>
  <customHeaders>
    <remove name=”X-Powered-By” /> 
    <add name=”Strict-Transport-Security” value=”max-age=86400"/> 
    <add name=”X-Frame-Options” value=”SAMEORIGIN” />
    <add name=”X-XSS-Protection” value=”1; mode=block” />
    <add name=”X-Content-Type-Options” value=”nosniff” />
    <add name=”Content-Security-Policy” value=”default-src ‘self’/>     
  </customHeaders>
</httpProtocol>

CSP标头和有趣的失败 (CSP Headers and Interesting Failures)

The CSP is funny thing, and can cause all sorts of interesting failures, and the best way to fix it is to break things. It can also break dependencies in a silent manner.

CSP是一件很有趣的事情，并且可能导致各种有趣的故障，而解决它的最佳方法就是破坏它。 它还可以以静默方式破坏依赖关系。

We had an interesting one where a form service was getting blocked, ninja-style. None of the usual console errors, non on-screen errors, no breakpoints showing issues, there was (more than) a little bit of tail chasing. Application Insights caught the error for us: CSP was blocking a NodeJS module that utilized an inline-eval that was a part of our form service.

我们有一个有趣的场景，其中忍者风格的表单服务被阻止。 没有常见的控制台错误，非屏幕错误，没有显示问题的断点，也没有(多于)一点点的追尾。 Application Insights为我们发现了错误：CSP阻止了NodeJS模块，该模块利用了内联评估作为表单服务的一部分。

Cue much relief, and a quick patch later the forms worked again — with equal parts ‘That’s good, the CSP works as it should’ and ‘How do we deal with this potential issue’. Enough of our collective misery — back to fun stuff!

尽力而为，然后快速修补，表格又重新起作用了-相等的部分“很好，CSP可以正常工作”和“我们如何处理这个潜在问题”。 我们的集体苦难已足够-回到有趣的东西！

For Azure, the best way to test a CSP is via the ‘App Service Editor’, where you can make like changes to the web.config file (actually, any file on the service) and test your CSP live before committing it to your source control, all in a VS-Code-esq editor in browser.

对于Azure，测试CSP的最佳方法是通过“应用程序服务编辑器”，您可以在其中对web.config文件(实际上是该服务上的任何文件)进行类似的更改，并在将CSP提交到您的计算机之前对其进行实时测试。源代码控制，全部在浏览器中的VS-Code-esq编辑器中进行。

My advice would do not be tempted to write the CSP, commit to source, deploy via pipeline and then load up your app; you will be left looking at your broken app, wondering why your fonts are gone, images wont load or third-party-integrations are down.

我的建议不会试图编写CSP，提交源代码，通过管道部署然后加载您的应用程序。 您将只能看着坏了的应用程序，想知道为什么字体消失了，图像无法加载或第三方集成失败了。

This is rather expensive in terms of time spent tracking down all the required URLs to add to your CSP. Pick the way that takes you least amount of time!

就花时间追踪所有添加到您的CSP所需的URL而言，这是相当昂贵的。 选择花费您最少时间的方式！

A Reminder: web.config files are volatile! A badly formatted command, unclosed xml tag or any other syntax-based errors will, on Azure, throw your app into complete shutdown, with a 500 Internal Server Error. Until you fix the error, and then it will be back online within seconds.

温馨提示：web.config文件易变！ 在Azure上，格式错误的命令，未关闭的xml标记或任何其他基于语法的错误将使您的应用程序完全关闭，并出现500 Internal Server Error。 除非您纠正错误，然后它会在几秒钟内恢复在线。

“黄金标准” (The ‘Gold Standard’)

I briefly mentioned the Feature Policy, but we also have a few other possible headers that can tighten the screws a little bit more and keep to that ‘Gold Standard’ of doing all the security things right.

我简短地提到了功能策略，但是我们还有其他一些可能的接头，可以进一步拧紧螺钉，并保持正确执行所有安全性工作的“黄金标准”。

The last two are the ‘Feature-Policy’ and ‘Referrer Policy’ headers.

最后两个是“功能策略”和“推荐人策略”标头。

The Feature Policy is fairly new (by header standards), it only came in the latter half of 2018 and is more focused on keeping mobile device features away from malicious attackers. It doesn’t have full support everywhere (yet), but all the major browser has it implemented to varying degrees.

功能政策是相当新的(按标头标准)，仅在2018年下半年才出台，其重点是使移动设备功能远离恶意攻击者。 它并没有在所有地方都提供全面支持，但是所有主流浏览器都在不同程度上实现了它。

It functions in a very similar way to the Content Security Policy Headers. It has restrictions on things like vibration, notifications and microphone, just to name a few. The spec is over here, and you can see it in both the ‘Gold Standard’ and ‘Draconian’ examples.

它的功能与内容安全策略标头非常相似。 它对振动，通知和麦克风等有限制，仅举几例。 规格已在此处，您可以在“黄金标准”和“德拉科尼亚”示例中看到它。

Referrer Policy is older, circa 2017, and is specifically for controlling when and how the Referrer header is sent in requests. Sometimes, you might want to prevent specific routes or other from HTTPS to HTTP that can leak via the Referrer Header.

Referrer Policy较旧，大约在2017年，专门用于控制何时以及如何在请求中发送Referrer标头。 有时，您可能想阻止从HTTPS到HTTP的特定路由或其他路由，这些路由可能通过Referrer Header泄漏。

Pulling all of these things together creates a web.config file that can be called a ‘Gold Standard Starting Point’ and is what Head Full of Heart and Taptu prefer to start with, then lock down further as we need.

将所有这些东西放在一起会创建一个web.config文件，该文件可以称为“黄金标准起点”，这是“全力以赴”和Taptu所喜欢的，然后根据需要进一步锁定。

那只小额外的龙 (That Little Extra Dragon)

Draconian, get it? Anyways, you can restrict nearly everything with your web.config, and some of it can rightfully be classed as security theater, the dog-and-pony-show of security. When we get down to restricting individual HTTP Verbs from interacting with our WebApp then we should have a very good reason. For this case, its due to the compiled Angular app not needing to receive anything but GET. And with a few lines, that is all it can do.

Draconian，懂吗？ 无论如何，您都可以使用web.config限制几乎所有内容，并且可以将其中的某些内容正确地归类为安全性剧院，即安全性的“门狗戏”。 当我们开始限制单个HTTP动词与WebApp交互时，我们应该有一个很好的理由。 对于这种情况，这是由于编译后的Angular应用程序不需要接收任何东西，而只能接收GET。 只需几行，便可以完成所有操作。

It should be clear, but this only affects incoming traffic. The app itself can still POST/PATCH/PUT/Etc. to API end-points to its hearts content.

应该清楚，但这只会影响传入的流量。 该应用程序本身仍可以POST / PATCH / PUT / Etc。 API端点指向其心脏内容。

<security>
  <requestFiltering removeServerHeader=”true”>
    <verbs>
      <add verb=”PUT” allowed=”false” />
      <add verb=”HEAD” allowed=”false” />
      <add verb=”POST” allowed=”false” />
      <add verb=”DELETE” allowed=”false” />
      <add verb=”CONNECT” allowed=”false” />
      <add verb=”TRACE” allowed=”false” />
      <add verb=”PATCH” allowed=”false” />
    </verbs>
  </requestFiltering>
</security>

You can go even further, and start looking at the other headers and options for re-write rules and blocks, but there is a very good test to apply before you go too far: Ask yourself — “Do I need that?”.

您甚至可以走得更远，开始寻找其他标题和选项来重写规则和块，但是在走得太远之前，有一个很好的测试可以应用：问问自己-“我需要吗？”。

A good test we use here at Head Full of Heart is the Security Headers Tester site. It’s an excellent grading tool and helps stop the silly errors that get people in trouble. While not the absolute be-all-end-all, its over at https://securityheaders.com.

我们在“满脑子”这里使用的一个很好的测试是Security Headers Tester网站。 这是一个出色的评分工具，有助于阻止那些使人陷入困境的愚蠢错误。 虽然不是绝对的万事通，但请访问https://securityheaders.com 。

停止小花絮 (Stopping the Little Tidbits)

As a security person, I very much enjoy talkative services, of any type. It makes figuring out plans of attack much easier when it coughs up name, version and framework without me having to lift a finger beyond ‘F12’. Preventing these little hints at every opportunity make it just that little bit harder for nefarious actors to gather intelligence, adding to the defense-in-depth.

作为安全人员，我非常喜欢各种类型的健谈服务。 当它确定名称，版本和框架时，无需我伸出手指来使它更加容易确定攻击计划。 在每一个机会中避免使用这些小提示，使邪恶的参与者更难收集情报，从而增加了深度防御的能力。

The snippets beforehand actually had two such restrictions. As with all things, they are scattered around the configuration, never in the one place.

预先的代码片段实际上有两个这样的限制。 与所有事物一样，它们分散在整个配置中，而不是一处。

<requestFiltering removeServerHeader=”true”>
<remove name=”X-Powered-By” />

So, what does that do? Well, it does what it says on the tin!

那么，那是做什么的呢？ 好吧，它按锡上所说的做！

One removes the X-Powered-By Header, where you usually get a nice marker saying ASP.NET or perhaps Servlet/3.0 or other information of what is running behind-the-scenes.

可以删除X-Powered-By标头，在该标头上通常可以看到一个漂亮的标记，上面写着ASP.NET或Servlet / 3.0或幕后运行的其他信息。

Another Note: Removing the X-Powered-By header only works if it is the web-server injecting that Header. If you have (as an example) a .NET Core API that’s running in a Web App, then that line will do nothing. Any type of middleware will also tamper with this.

另一个注意事项：仅当X-Powered-By标头是Web服务器注入该标头时，才起作用。 如果您有(例如)在Web App中运行的.NET Core API，则该行将不起作用。 任何类型的中间件都将对此进行篡改。

The other removes the Server Header, which is IIS, Kestrel, Apache, Nginx or whatever your web-server is, and sometimes, depending on the config, you also get the version number in the server header.

另一个删除服务器标头，即IIS，Kestrel，Apache，Nginx或任何Web服务器，有时，根据配置，您还会在服务器标头中获得版本号。

何必呢？ (Why bother?)

Every little bit of information helps when gathering information. If I can tell that the webpage was served from an embedded HTTP server, I can take a good guess as to its limitations.

收集信息时，每一点信息都会有所帮助。 如果可以确定该网页是从嵌入式HTTP服务器提供的，则可以对其局限性做出很好的猜测。

From there, if I have the back-end technology I can narrow my guesses even further. Keeping the bad guys guessing means it takes them longer and they are (hopefully) more likely to give up.

从那里，如果我拥有后端技术，我可以进一步缩小猜测范围。 让坏人继续猜测意味着他们需要更长的时间，并且(希望)他们更有可能放弃。

但是管道在哪里？ (But where is the Pipeline?)

There’s been much waffle of web.config and assorted security measures and headers and standards and all the fluff around it, but how to get this into a CI/CD Pipeline?

大量的web.config以及各种安全措施，标头和标准以及周围的所有毛病都一团糟，但是如何将其纳入CI / CD管道？

For Azure DevOps Pipelines this can take many approaches; variable substitutions/xml transformations, deployment tasks, build tasks… there are so many ways to get that important config file up and through the pipeline.

对于Azure DevOps管道，这可以采用许多方法。 变量替换/ xml转换，部署任务，构建任务……有很多方法可以使重要的配置文件通过管道。

Personally, I like to apply Occam’s Razor, that the simplest also tends to be the best.

就我个人而言，我喜欢使用Occam的Razor，最简单的也往往是最好的。

No matter the approach, you will need some sort of “web.config” file in your source control, and as there isn’t anything sensitive in the file (for security headers), and there isn’t any need to run it though say, Azure Key Vault.

不管采用哪种方法，您都将在源代码管理中需要某种“ web.config”文件，并且由于该文件中没有任何敏感内容(对于安全标头)，因此也无需运行它例如，Azure Key Vault。

For Angular CLI Projects, this can be done with no changes to an existing pipeline and all. It’s a single line in your angular.json file. By adding a reference to your web.config (where ever it may be in your repository) to “assets” under the “build” the Angular Compiler will grab it and include it into build.

对于Angular CLI项目，可以在不更改现有管道及全部的情况下完成此操作。 它是angular.json文件中的一行。 通过将对web.config的引用(无论它在存储库中的任何位置)添加到“构建”下的“资产”，Angular编译器将获取该引用并将其包含到构建中。

It’s that simple, that is, if a single web-config suits your deployment. Chances are, this just isn’t going to cut it, and for Head Full of Heart, it certainly doesn’t — deploying the same web.config and headers to Development, Quality Assurance, User Acceptance Testing and Production is just asking for trouble, and broken environments all day long. No thank you!

就这么简单，也就是说，如果单个Web配置适合您的部署。 很有可能，这不会削减它，对于“全心全意”的人来说，肯定不会—为开发，质量保证，用户验收测试和生产部署相同的web.config和标头只是在自找麻烦以及整天破坏的环境。 不，谢谢！

A

一个

输入配置转换 (Enter Config Transforms)

Configuration transforms are all sort of awesome, and they neatly solve the problem of having to commit a full web.config to your repo; for AzureDevOps Pipelines, they come in two flavors — XML and JSON.

配置转换真是太棒了，它们巧妙地解决了必须将完整的web.config提交给您的仓库的问题。 对于AzureDevOps管道，它们有两种样式-XML和JSON。

I’ll be focusing on the XML variant for this one, but the JSON transforms follow the same base principles. I won’t go over all of the possible options, as XML transforms have been around for quite some time.

我将重点介绍这一方面的XML变体，但是JSON转换遵循相同的基本原理。 我不会讨论所有可能的选项，因为XML转换已经存在了一段时间。

For Azure, where I spend most of my time, this can be done by crafting the web.config a little differently and the introduction of a new files per environment — web.debug.config. This file tells the xml transform how to override/update/transform/remove the xml in the web.config file, allowing us to specify variables needed.

对于Azure，我将大部分时间都花在了上面，这可以通过以下方式完成：对web.config的制作略有不同，并针对每个环境引入新文件-web.debug.config。 该文件告诉xml转换如何覆盖/更新/转换/删除web.config文件中的xml，从而允许我们指定所需的变量。

In short, your ‘web.config’ file becomes a template of what you want filled. The transformations for an environment reside in a new file ‘web.debug.config’. Simply make sure your WebApp Deploy Task has the XML Transformation box ticked, and ‘Copy if Newer’ is specified for the config file (or it might not overwrite the file if you update the transformations). It can get a little complicated, but the base of it is pretty easy.

简而言之，您的“ web.config”文件将成为您要填充的文件的模板。 环境的转换位于新文件“ web.debug.config”中。 只需确保您的WebApp部署任务的“ XML转换”框被打勾，并且为配置文件指定了“如果更新则复制”(否则，如果您更新转换，它可能不会覆盖该文件)。 它可能会有些复杂，但是它的基础非常简单。

There is also a pretty handy tool to play around with how it all works here. The Microsoft page for file and variable substitutions is well done and is sitting here.

还有一个非常方便的工具可以解决这里的一切。 用于文件和变量替换的Microsoft页面做得很好，位于此处 。

而已！ (That’s It!)

Thanks for sticking with such a long article, and hopefully it was a little helpful! Want to know more? Throw a question at me on Twitter at @TeamHFoH, @TaptuIT or @TheStudyScott.

感谢您坚持这么长的文章，希望对您有所帮助！ 想知道更多？ 在Twitter上通过@ TeamHFoH，@ TaptuIT或@TheStudyScott向我提问。

翻译自: https://medium.com/@scott.anderson_95492/azure-devsecops-pipelines-web-config-ccdf113f6978

天蓝色在ps中的色值