提高安全性而在HTTP响应头中可以使用的各种响应头字段

本文介绍在Web服务器做出响应时,为了提高安全性而在HTTP响应头中可以使用的各种响应头字段。由于部分浏览器中有可能对某些字段或选项不提供支持,所以在使用这些字段时请先确认客户端环境。

X-Frame-Options

该响应头中用于控制是否在浏览器中显示frame或iframe中指定的页面,主要用来防止Clickjacking(点击劫持)攻击。

X-Frame-Options: SAMEORIGIN
  • DENY 禁止显示frame内的页面(即使是同一网站内的页面)
  • SAMEORIGIN 允许在frame内显示来自同一网站的页面,禁止显示来自其他网站的页面
  • ALLOW-FROM origin_uri允许在frame内显示来自指定uri的页面(当允许显示来自于指定网站的页面时使用)

X-Content-Type-Options

如果从script或stylesheet读入的文件的MIME类型与指定MIME类型不匹配,不允许读取该文件。用于防止XSS等跨站脚本攻击。

X-Frame-Options: nosniff

X-XSS-Protection

用于启用浏览器的XSS过滤功能,以防止XSS跨站脚本攻击。

X-XSS-Protection: 1; mode=block
  • 禁用XSS过滤功能
  • 启用XSS过滤功能

Content-Security-Policy

用于控制当外部资源不可信赖时不被读取。用于防止XSS跨站脚本攻击或数据注入攻击(但是,如果设定不当,则网站中的部分脚本代码有可能失效)。

之前的字段名为X-Content-Security-Policy

Content-Security-Policy: default-src ‘self‘
  • default-src ‘self‘ 允许读取来自于同源(域名+主机+端口号)的所有内容
  • default-src ‘self‘ *.example.com允许读取来自于指定域名及其所有子域名的所有内容

X-Permitted-Cross-Domain-Policies

用于指定当不能将“crossdomain.xml”文件(当需要从别的域名中的某个文件中读取Flash内容时用于进行必要设置的策略文件)放置在网站根目录等场合时采取的替代策略。

X-Permitted-Cross-Domain-Policies: master-only
  • master-only 只允许使用主策略文件(/crossdomain.xml)

Strict-Transport-Security

用于通知浏览器只能使用HTTPS协议访问网站。用于将HTTP网站重定向到HTTPS网站。

Strict-Transport-Security: max-age=31536000; includeSubDomains
  • max-age 用于修改STS的默认有效时间。
  • includeSubDomains 用于指定所有子域名同样使用该策略。

Access-Control-Allow-Origin等CORS相关字段

当使用XMLHttpRequest从其他域名中获取资源进行跨域通信时使用。

Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-TRICORDER
Access-Control-Max-Age: 1728000

上述代码用于设定与“http://www.example.com”进行跨域通信处理,允许使用POST, GET, OPTIONS方法,在发送的请求头中添加X-TRICORDER字段,通信超时时间为1,728,00秒。

X-Download-Options

用于放置直接打开用户下载文件。

X-Download-Options: noopen
  • noopen 用于指定IE 8以上版本的用户不打开文件而直接保存文件。在下载对话框中不显示“打开”选项。

Set-Cookie

用于设置Cookie。

Set-Cookie: name=value; secure; HttpOnly
  • secure 只在进行HTTP通信时发送Cookie。
  • HttpOnly 指定不能从JavaScript脚本代码访问Cookie值。
  • 虽然path属性用于指定Cooki发送路径,但是不能被作为一种安全手段。
  • domain属性具有后方一致特性,出于安全考虑最好不要使用该属性,除非明确指定向多个域发送Cookie。

Cache-Control

指定浏览器的缓存方式,通过逗号分隔。

Cache-Control: no-cache, no-store, must-revalidate
  • no-cache 指定服务器端不缓存数据。
  • no-store 指定不能在本地缓存中保存数据。
  • must-revalidate 指定服务器端可以缓存数据,但是必须对数据进行确认。

pragma

用于与HTTP/1.0进行向后兼容的响应头字段,原本只被使用在客户端请求头中。与“Cache-Control: no-cache”结合使用。

pragma: no-cache
  • no-cache 客户端要求所有中间服务器不能缓存数据。

expires

指定数据的有效时间。不希望缓存数据时可以将该字段值与Date字段值指定为相同值或者将该字段值指定为“-1”。

expires: -1

content-type

指定实体内对象的媒体类型(MediaType)。在charset关键字中指定文字编码格式。

content-type: text/html;charset=utf-8

HTTP响应头的设定方法

在Apache服务器中指定响应头时,需要在httpd.conf文件中将下述模块设定为有效状态。

  • LoadModule headers_module modules/mod_headers.so

然后使用下述方法设定HTTP响应头。

Header set HeaderFieldName "value"
//例如
Header set X-XSS-Protection "1; mode=block”
时间: 2024-08-04 13:49:44

提高安全性而在HTTP响应头中可以使用的各种响应头字段的相关文章

【协议分析】HTTP响应头中的2种编码方式介绍

HTTP 1.1中有两个实体头(Entity-Header)直接与编码相关,分别为Content-Encoding和Transfer-Encoding.    先说Content-Encoding, 该头表示实体已经采用了的编码方式.Content-Encoding是请求URL对应实体(Entity)本身的一部分.比如请求URL为 http://host/image.png.gz时,可能会得到的Content-Encoding为gzip.Content-Encoding的值是不区分大小写的,目前

Java中生成符合http响应头中的Date格式的字符串

在http header中,Date头域表示消息发送的时间,时间的描述格式由rfc822(电子邮件的标准格式)定义.例如,Date: Sat, 05 Jul 2014 12:53:36 GMT.具体格式说明如下: 标准格式:DAY, DD MMM YYYY HH:MM:SS GMT,其中 DAY: 由三个英文字母指代的星期(Sun, Mon, Tue, Wed, Thu, Fri, Sat). DD: 日(such as 01 for the first day of the month). M

Http消息头中常用的请求头和响应头

作为Web开发对常用http的请求头和响应头熟悉了解一下还是很有必要的.比如请求头中Content-type指定了请求的内容,若类型是application/x-www-form-urlencoded,就可以调用reqeust的获取参数方法取到内容,若是其它都需要调用获取流的方法获取.又比如响应头X-Frame-Options 的设置直接决定了你的页面是否能被其它非同源的ifream嵌入,而这个设置可以是在html页面中,也可以是框架或代码的响应头设置中,也可以是在http服务器(nginx或t

你知道 http 响应头中的 ETag 是如何生成的吗

关于 etag 的生成需要满足几个条件 当文件不会更改时,etag 值保持不变.所以不能单纯使用 inode 便于计算,不会特别耗 CPU.这样子 hash 不是特别合适 便于横向扩展,多个 node 上生成的 etag 值一致.这样子 inode 就排除了 关于服务器中 etag 如何生成可以参考 HTTP: Generating ETag Header 那么在 nginx 中的 etag 是如何生成的? nginx 中 ETag 的生成 我在网上找到一些资料与源代码了解到了 etag 的计算

HTTP 请求头中的 X-Forwarded-For

我一直认为,对于从事 Web 前端开发的同学来说,HTTP 协议以及其他常见的网络知识属于必备项.一方面,前端很多工作如 Web 性能优化,大部分规则都跟 HTTP.HTTPS.SPDY 和 TCP 等协议的特点直接对应,如果不从协议本身出发而是一味地照办教条,很可能适得其反.另一方面,随着 Node 的发展壮大,越来越多的前端同学开始写服务端程序,甚至是框架( ThinkJS 就是这样由前端工程师开发,并有着众多前端工程师用户的 Node 框架),掌握必要的网络知识,对于服务端程序安全.部署.

修改WordPress后台登录地址,提高安全性

使用 Stealth Login Page 插件 该插件设置非常简单,设置一个非法访问后台地址 /wp-admin 或 /wp-login.php 时,重定向到指定网址:然后设置自定义登录地址的链接参数,具体见下图: 保存设置后,只能通过那个自定义登录地址才能访问到登录表单,其他后台地址一律重定向到所设置的重定向地址.该插件一个比较大的特色就是支持 多站点网络,具体设置可以查看插件文档(插件自带一个文档页面) 在后台插件安装界面搜索 Stealth Login Page 即可在线安装,或者下载

ajax 访问--提高安全性

首先受到struts token的启发,产生了客户端发起的ajax请求进行验证的想法,大致思路是客户端每次请求产生一个key ,然后服务端接收到key,然后解析,判断是否为合法key, 对于不带key 或者验证失败的直接拦截下来,从而减轻服务器的压力,好了废话不多说,上代码 首先我使用的是struts2的拦截器,(ps:不知道的度娘告诉你) 继承 AbstractInterceptor 实现init()和 intercept() ,从字面意思上去理解这两个方法 初始化 和拦截 第一个方法 就是从

如何在HTTP头中隐藏PHP版本号

PHP 配置默认允许服务器在 HTTP 响应头 X-Powered-By 中显示安装在服务器上的 PHP 版本.出于服务器安全原因(虽然不是主要的要担心的威胁),建议你禁用或隐藏此信息,避免那些针对你的服务器的攻击者知道你是否运行了 PHP.在本文中,我们将解释如何隐藏或关闭服务器 HTTP 响应头中的 PHP 版本号. PHP 配置默认允许服务器在 HTTP 响应头 X-Powered-By 中显示安装在服务器上的 PHP 版本. 出于服务器安全原因(虽然不是主要的要担心的威胁),建议你禁用或

防御CSRF的方法有哪些(一) HTTP 头中自定义属性并验证 CSRF跨站域请求伪造攻击

CSRF (Cross Site Request Forgery, 跨站域请求伪造)是一种网络的攻击方式,该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点,从而在并未授权的情况下执行在权限保护之下的操作,有很大的危害性. CSRF 攻击实例 CSRF 攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点,从而在并未授权的情况下执行在权限保护之下的操作. 比如说,受害者 Bob 在银行有一笔存款,通过对银行的网站发送请求 http://bank.example