You will generally be in good shape using IIS 10 to securely host websites, but there are some changes you must make to pass a security audit.

使用IIS 10安全地托管网站通常会保持良好状态，但是必须进行一些更改才能通过安全审核。

Although many potential security flaws may lurk in the applications you host (and you’ll need to attend to those for sure), the more predictable ones can be dealt with at the server level. You’ll want to be certain your web sites can survive a security audit before your client asks for one, so here are the typical extra configurations you’ll need to add so it passes with flying colors.

尽管您托管的应用程序中可能隐藏了许多潜在的安全漏洞(并且您肯定需要关注它们)，但是可以在服务器级别处理更可预测的漏洞。 您将要确定您的网站在客户要求进行安全审核之前可以通过一次安全审核，因此，这里是您需要添加的典型附加配置，以便其以鲜艳的色彩通过。

This isn’t an exhaustive list, but includes the main issues I have repeatedly encountered over the last several years in my work maintaining professional web sites for top-tier corporations.

这不是一个详尽的清单，但包括我在过去几年中为顶级公司维护专业网站的过程中反复遇到的主要问题。

保持饼干安全 (Keep your cookies safe)

A lot of sites use cookies, especially for authentication. In many cases, the application running on the site doesn’t need to access these cookies with client-side JavaScript. In this situation, you should always secure your cookies by setting them to be httpOnly.

许多站点都使用cookie，尤其是用于身份验证。 在许多情况下，站点上运行的应用程序不需要使用客户端JavaScript访问这些cookie。 在这种情况下，应始终通过将cookie设置为httpOnly来保护它们的安全。

Even if your application does access cookies through client-side JavaScript, you should set the secure flag. This ensures that the cookies can only be accessed using SSL, adding another layer of security to your cookie use. You can do this very simply by editing the web.config file for your site or application.

即使您的应用程序确实通过客户端JavaScript访问cookie，也应设置安全标志。 这样可以确保只能使用SSL访问cookie，从而为cookie使用增加了另一层安全性。 您可以通过编辑站点或应用程序的web.config文件非常简单地完成此操作。

Just add the following to the system.web element of each site’s web.config file:

只需将以下内容添加到每个站点的web.config文件的system.web元素中：

<httpCookies domain="String"        httpOnlyCookies="true"            requireSSL="true" />

The requireSSL value sets the secure flag, and the httpOnlyCookies value does just what you would expect. If you really can’t have httpOnly cookies, just set that value to “false” instead.

requireSSL值设置了安全标志，而httpOnlyCookies值正是您所期望的。 如果您真的不能拥有httpOnly cookie，只需将该值设置为“ false”即可。

不允许非HTTPS连接 (Don’t allow non-HTTPS connections)

These days every site should be using SSL, of course. But you probably also have your websites mapped to port 80, just in case people type in the URL without using https. You need to redirect those users to the SSL version and you need to make sure they can’t access any non-SSL resources on the website. You can handle all this easily at the website level using IIS’s URL Rewrite module.

这些天，当然，每个站点都应该使用SSL。 但是，也可能将您的网站映射到端口80，以防人们在不使用https的情况下键入URL。 您需要将这些用户重定向到SSL版本， 并且需要确保他们无法访问网站上的任何非SSL资源。 您可以使用IIS的URL重写模块在网站级别轻松处理所有这些问题。

If you don’t see it in IIS manager, you may need to install this indispensable module. That’s easily done by following the instructions here. Once that’s done, open URL Rewrite at the level of each website you want to protect, add a new blank rule and enter the settings shown below:

如果您在IIS管理器中看不到它，则可能需要安装此必不可少的模块。 遵循此处的说明即可轻松完成。 完成后，在要保护的每个网站级别打开URL Rewrite，添加新的空白规则，然后输入以下所示的设置：

In the rewrite section of your web.config file, the rule will look like this:

在web.config文件的rewrite部分中，规则如下所示：

<rule name="ssl-redir" stopProcessing="true">  <match url="(.*)" />    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">      <add input="{HTTPS}" pattern="off" />    </conditions>    <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"       redirectType="Permanent" /></rule>

You can see in the Match URL section we are just matching all patterns. In the Conditions section, we look for HTTPS being “off”. Then in the Action section, the redirect is set to the same website but using the https protocol. This guarantees that visitors can only access all resources via SSL, whether it’s web pages, images, scripts, json, PDFs or any other kind of content. Simple.

您可以在“匹配网址”部分看到我们正在匹配所有模式。 在“条件”部分，我们查找HTTPS为“关闭”。 然后在“操作”部分中，将重定向设置为同一网站，但使用https协议。 这保证了访问者只能通过SSL访问所有资源，无论是网页，图像，脚本，json，PDF还是任何其他类型的内容。 简单。

删除所有IIS品牌响应标题 (Remove all of IIS’s branded response headers)

This next one is more complex and involves several different configurations. If you open the web page of one of your sites in Firefox or Google, and use the developer tools to look at the response headers for a web page, you will be likely to see something like this:

下一个更复杂，涉及几种不同的配置。 如果您在Firefox或Google中打开您网站之一的网页，并使用开发者工具查看网页的响应标题，则可能会看到以下内容：

I’ve highlighted the two problem headers: server and x-powered-by. They tell hackers which software and version you are using, to make it super-easy for them to attack your site. So they have to go. To get rid of the X-powered-by header, add the highlighted lines in each web site’s web.config file.

我突出了两个问题头：服务器和x-powered-by。 他们告诉黑客您正在使用哪种软件和版本，以使他们轻松轻松地攻击您的网站。 所以他们必须走。 要摆脱X-by-by标头，请在每个网站的web.config文件中添加突出显示的行。

In order to remove the server response header, you will need to crack open Powershell. Find it by typing Powershell in the search bar, and then type the following (just one line):

为了删除服务器响应标头，您将需要打开Powershell。 通过在搜索栏中键入Powershell来找到它，然后键入以下内容(仅一行)：

Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST'  -filter "system.webServer/security/requestFiltering" -name "removeServerHeader" -value "True"

No need to reboot after that one.

之后无需重启。

你必须有一个政策 (You gotta have a policy)

In order to stop those crafty potential intruders from finding ways to hijack your site, it’s a good idea to set up a referrer policy. Depending on how your applications work, it’s sometimes possible to leak information to external websites because when a web browser follows a link from one site to another, it sends a “referer” (yes, that misspelling is correct) header, which the next website can read. If the URL of one of your pages contains sensitive information (perhaps a user logs in and the URL path includes their name or ID number), we don’t want to send it in the request to an external site. And you can use a referrer policy header to prevent it.

为了阻止那些狡猾的潜在入侵者找到劫持您网站的方法，建议您建立推荐人政策。 根据您的应用程序的工作方式，有时可能会将信息泄漏到外部网站，因为当网络浏览器跟踪从一个网站到另一个网站的链接时，它将发送“引荐来源”(是的，拼写错误是正确的)标头，该标头是下一个网站可以阅读。 如果您其中一个页面的URL包含敏感信息(例如，用户登录且URL路径包含其名称或ID号)，则我们不希望在请求中将其发送到外部站点。 并且您可以使用引荐来源网址策略标头来阻止它。

I suggest using the confusingly named origin-when-cross-origin value, because that ensures that whenever referrer information is sent outside the bounds of your site, it only contains the domain name and not the specific page URL in the referer header. In the same place that you removed the X-Powered-By header above (the system.webServer section of web.config), you can use the custom headers settings to add a Referrer-Policy header as follows:

我建议使用名称混乱的origin-when-cross-origin值，因为这样可以确保每当将引荐来源信息发送到您的网站范围之外时，它仅包含域名，而不包含引荐标头中的特定页面URL。 在删除上方X-Powered-By标头的同一位置(web.config的system.webServer部分)，可以使用自定义标头设置来添加Referrer-Policy标头，如下所示：

<httpProtocol>  <customHeaders>     <remove name="X-Powered-By" />     <add name="Referrer-Policy" value="origin-when-cross-origin" />  </customHeaders></httpProtocol>

And yes, in this case referrer needs to be spelled correctly.

是的，在这种情况下，引荐来源网址需要正确拼写。

什么是HSTS？ (What the HSTS?)

HSTS stands for Http Strict Transport Security. At the server end, it is nothing more than a header that your web server can set to insist that web browsers connect via SSL. Why do you need to do this when you have just enforced SSL using the rewrite rules above? Well, hackers can use packet sniffers to redirect traffic that relies on 301 redirects alone to enforce SSL. Because your users’ web browsers will insist on using SSL to connect to your site, it means attempts to intercept traffic between users and your site should fail.

HSTS代表Http Strict Transport Security。 在服务器端，Web服务器可以设置标题以坚持要求Web浏览器通过SSL连接。 使用上述重写规则强制实施SSL后，为什么需要这样做？ 好的，黑客可以使用数据包嗅探器来重定向仅依靠301重定向来实施SSL的流量。 由于用户的Web浏览器将坚持使用SSL连接到您的站点，因此这意味着尝试拦截用户与站点之间的通信将失败。

So we just need to add another header as we did with the referrer policy above, so that section in web.config under system.webServer will now look like this:

因此，我们只需要添加另一个标头即可，就像我们对上述引荐来源网址策略所做的那样，因此，system.webServer下web.config中的该部分现在应如下所示：

<httpProtocol> <customHeaders>   <remove name="X-Powered-By" />   <add name="Referrer-Policy" value="origin-when-cross-origin" />   <add name="Strict-Transport-Security" value="max-age=31536000" />    </customHeaders></httpProtocol>

Now, when you load a page in your browser and inspect the headers, you should see the new header:

现在，当您在浏览器中加载页面并检查标题时，应该会看到新的标题：

更改密码设置 (Changing the Cryptography Settings)

Fixing IIS cryptography settings would be the hardest of all, if it weren’t for a very useful and free piece of software called IISCrypto. Get the latest version and install that, it works on all versions of Windows Server from 2008 onwards. When you run it, you’ll see its Best Practices button in the bottom right hand corner, so just click that, and once you click Apply, it’s all done except for the reboot. However, some clients will have stricter requirements for which protocols to support, so you may have some additional items to disable. I have found myself needing to disable all versions of TLS below 1.2 (although be aware this will prevent a few older browsers from accessing the site).

如果不是要使用一个非常有用且免费的软件IISCrypto ，修复IIS密码设置将是最困难的。 获取并安装最新版本，该版本可在2008年以后的所有Windows Server版本上运行。 运行它时，您将在右下角看到其“最佳实践”按钮，因此只需单击该按钮，然后单击“应用”即可，除了重新启动以外，其他所有操作都已完成。 但是，某些客户端对支持哪些协议会有更严格的要求，因此您可能需要禁用其他一些项目。 我发现自己需要禁用所有低于1.2的TLS版本(尽管请注意，这将阻止一些较旧的浏览器访问该网站)。

You may also need to disable some cipher suites, so if you need to, click on that button in the left navigation:

您可能还需要禁用某些密码套件，因此，如果需要，请单击左侧导航栏中的该按钮：

At this time, these are the only cipher suites that are recommended, but of course that will change over time.

目前，这些是推荐的唯一密码套件，但是随着时间的推移当然会改变。

Now reboot your server. Check your website’s SSL setup by visiting SSLLabs’ SSL Server Test page, and entering your domain name. They will give you a security rating based on the changes you’ve made. If you’ve done everything above, you should be looking at an A+ rating.

现在重新启动服务器。 通过访问SSLLabs的SSL服务器测试页面并输入域名来检查网站的SSL设置。 他们会根据您所做的更改为您提供安全等级。 如果您已完成上述所有操作，则应查看A +等级。