5、Django+Uwsgi+Nginx的生产环境部署---为nginx的访问加上对应的http响应头

本文大部分出自： https://www.imydl.tech/lnmp/263.html

为何要加入响应头

原因很简单：提高安全系数

常见的响应头

X-Frame-Options 响应头

X-Frame-Options HTTP 响应头是微软提出来的一个HTTP响应头，主要用来给浏览器指示允许一个页面可否在 , 或者 中展现的标记。网站可以使用此功能，来确保自己网站的内容没有被嵌到别人的网站中去，也从而避免了点击劫持 (ClickJacking{注1}) 的攻击。

使用 X-Frame-Options 有三个值:

DENY
表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。

SAMEORIGIN
表示该页面可以在相同域名页面的 frame 中展示。

ALLOW-FROM uri
表示该页面可以在指定来源的 frame 中展示。

如果设置为 DENY，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载。另一方面，如果设置为SAMEORIGIN，那么页面就可以在同域名页面的 frame 中嵌套

X-Content-Type-Options响应头

互联网上的资源有各种类型，通常浏览器会根据响应头的Content-Type字段来分辨它们的类型。例如：text/html代表html文档，image/png是PNG图片，text/css是CSS样式文档。然而，有些资源的Content-Type是错的或者未定义。这时，某些浏览器会启用MIME-sniffing来猜测该资源的类型，解析内容并执行。

例如，我们即使给一个html文档指定Content-Type为text/plain，在IE8-中这个文档依然会被当做html来解析。利用浏览器的这个特性，攻击者甚至可以让原本应该解析为图片的请求被解析为JavaScript

X-Content-Security-Policy响应头

W3C 的 Content Security Policy，简称 CSP。顾名思义，这个规范与内容安全有关，主要是用来定义页面可以加载哪些资源，减少 XSS 的发生。

Chrome 扩展已经引入了 CSP，通过 manifest.json 中的 content_security_policy 字段来定义。一些现代浏览器也支持通过响应头来定义 CSP。下面我们主要介绍如何通过响应头来使用 CSP，Chrome 扩展中 CSP 的使用可以参考 Chrome 官方文档。

浏览器兼容性
早期的 Chrome 是通过 X-WebKit-CSP 响应头来支持 CSP 的，而 firefox 和 IE 则支持 X-Content-Security-Policy，Chrome25 和 Firefox23 开始支持标准的 Content-Security-Policy

如何使用
要使用 CSP，只需要服务端输出类似这样的响应头就行了：

Content-Security-Policy: default-src 'self'

default-src 是 CSP 指令，多个指令之间用英文分号分割；‘self’ 是指令值，多个指令值用英文空格分割。目前，有这些 CSP 指令：

指令	指令值示例	说明
default-src	‘self’ cnd.a.com	定义针对所有类型（js、image、css、web font，ajax 请求，iframe，多媒体等）资源的默认加载策略，某类型资源如果没有单独定义策略，就使用默认的。
script-src	‘self’ js.a.com	定义针对 JavaScript 的加载策略。
style-src	‘self’ css.a.com	定义针对样式的加载策略。
img-src	‘self’ img.a.com	定义针对图片的加载策略。
connect-src	‘self’	针对 Ajax、WebSocket 等请求的加载策略。不允许的情况下，浏览器会模拟一个状态为 400 的响。
font-src	font.a.com	针对 WebFont 的加载策略。
object-src	‘self’	针对 、 或 等标签引入的 flash 等插件的加载策略。
media-src	media.a.com	针对 或 等标签引入的 HTML 多媒体的加载策略。
frame-src	‘self’	针对 frame 的加载策略。
sandbox	allow-forms	对请求的资源启用 sandbox（类似于 iframe 的 sandbox 属性）。
report-uri	/report-uri	告诉浏览器如果请求的资源不被策略允许时，往哪个地址提交日志信息。 特别的：如果想让浏览器只汇报日志，不阻止任何内容，可以改用 Content-Security-Policy-Report-Only 头。

PS:完整的浏览器 CSP 支持情况请移步 CanIUse 。

指令	指令值示例	说明
img-src	允许任何内容。
‘none’	img-src ‘none’	不允许任何内容。
‘self’	img-src ‘self’	允许来自相同来源的内容（相同的协议、域名和端口）。
data:	img-src data:	允许 data: 协议（如 base64 编码的图片）。
www.a.com	img-src img.a.com	允许加载指定域名的资源。
.a.com	img-src .a.com	允许加载 a.com 任何子域的资源。
https://img.com img-src	https://img.com	允许加载 img.com 的 https 资源（协议需匹配）。
https: img-src	https:	允许加载 https 资源。
‘unsafe-inline’	script-src ‘unsafe-inline’	允许加载 inline 资源（例如常见的 style 属性，onclick，inline js 和 inline css 等等）。
‘unsafe-eval’	script-src ‘unsafe-eval’	允许加载动态 js 代码，例如 eval()。

从上面的介绍可以看到，CSP 协议可以控制的内容非常多。而且如果不特别指定 ‘unsafe-inline’ 时，页面上所有 inline 样式和脚本都不会执行；不特别指定 ‘unsafe-eval’，页面上不允许使用 new Function，setTimeout，eval 等方式执行动态代码。在限制了页面资源来源之后，被 XSS 的风险确实小不少

当然，仅仅依靠 CSP 来防范 XSS 是远远不够的，不支持全部浏览器是它的硬伤。不过，鉴于低廉的开发成本，加上也没什么坏处

实际案例

Google+，使用了这几个本文提到的响应头

x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

Twitter使用了这些

strict-transport-security: max-age=631138519
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

PayPal的

X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=14400

Facebook则使用了这些（配置了详细的CSP，关闭了XSS保护）

strict-transport-security: max-age=60
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
content-security-policy: default-src *;script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net;style-src * 'unsafe-inline';connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:*;

PS：Facebook的CSP配置很有参考意义，大家可以根据自己网站的具体情况来整理出适合自己站点的CSP了。

X-XSS-Protection响应头

顾名思义，这个响应头是用来防范XSS的。最早我是在介绍IE8的文章里看到这个，现在主流浏览器都支持，并且默认都开启了XSS保护，用这个header可以关闭它。它有几种配置：

• 0：禁用XSS保护；
• 1：启用XSS保护；
• 1; mode=block：启用XSS保护，并在检查到XSS攻击时，停止渲染页面（例如IE8中，检查到攻击时，整个页面会被一个#替换）；
  浏览器提供的XSS保护机制并不完美，但是开启后仍然可以提升攻击难度，总之没有特别的理由，不要关闭它。

在nginx中的配置

打开conf下的nginx.conf，在server中加入以下需要配置的http响应头

X-Frame-Options 响应头

add_header X-Frame-Options:ALLOW-FROM https://tongji.baidu.com;
add_header X-Frame-Options:SAMEORIGIN;

X-Content-Type-Options响应头

add_header X-Content-Type-Options: nosniff

X-Content-Security-Policy响应头

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://ssl.google-analytics.com https://assets.zendesk.com https://connect.facebook.net; img-src 'self' https://ssl.google-analytics.com https://s-static.ak.facebook.com https://assets.zendesk.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://assets.zendesk.com; font-src 'self' https://themes.googleusercontent.com; frame-src https://assets.zendesk.com https://www.facebook.com https://s-static.ak.facebook.com https://tautt.zendesk.com; object-src 'none'";

X-XSS-Protection响应头

add_header X-Xss-Protection "1; mode=block";