重定向相关的安全隐患

隐患来源：

Web应用中有时会重定向至外界指定的URL。典型的案例为，在登录页面的参数中指定URL，登录成功后再重定向至该URL。

比如：使用以下URL登录Googe后，就会重定向到continue=指定的URL（此处为Gmail）。

https://www.goole.com/accounts/ServiceLogin?continue=https://mail.goole.com/mail/

重定向处理时产生的安全隐患有如下几种，而且他们都会招致被动攻击。

自由重定向漏洞
HTTP消息头注入漏洞

自由重定向安全隐患

自由重定向漏洞概要：

有些Web应用中提供了能够重定向到参数指定的URL的功能，该重定向功能就被称为重定向器（Redieector）。

其中，能够重定向至任意域名的重定向叫做自由重定向（Open Redirect）。自由重定向可能会导致用户在不知情的情况下被带到其他域名的网站，从而遭受到钓鱼式攻击（Phishing）。

为了防范自由重定向漏洞，应该重新评估“外界能够指定重定向目标URL”的功能是否真的不可或缺，并尽可能将重定向的目标固定。如果实在不能固定重定向的目标，就需要将重定向的目标限制在允许的域名范围内。

自动重定向漏洞总览：

产生地点：

能够重定向至外界指定的URL的地方。

影响范围：

影响范围并非仅限于Web应用中的某个页面，通过钓鱼式攻击被窃取重要信息后，Web应用的用户就会遭受损失。

影响类型：

将用户诱导至钓鱼网站，使其输入重要信息。
冒充设备驱动程序或更新补丁来散布病毒。

影响程度：

中~大

用户参与程度：

很大，点击链接并且输入信息。

对策概要：

固定重定向目标
采用白名单机制，将重定向目标限定在允许的域名范围内。

安全隐患的产生原因：

自由重定向漏洞产生的原因有以下两点。

重定向的目标URL能够由外界指定。
没有对重定向的目标域名进行校验。

以上两点是AND条件，也就是说只有同时满足这两点时才会形成自由重定向漏洞，因此，只要使其中一项无法满足，也就消除了安全隐患。

解决对策：

自动重定向漏洞的根本性防范策略有以下三项，实施时任选其一即可。

固定重定向的目标URL
使用编号指定重定向的目标URL
校验重定向的目标域名。

HTTP消息头注入

HTTP消息头注入概要：

HTTP消息头注入漏洞是指在重定向或生成Cookie等基于外部传入的参数输出HTTP响应头时所产生的安全隐患。输出响应消息头时，攻击者通过在参数中插入换行符，就可以在受害人的浏览器上实现如下操作：

任意添加下响应消息头
伪造响应消息体。

HTTP请求报文格式：

POST /form/entry  HTTP/1.1 
Connection: Keep-alive
Content-Type: application/X-www-form-urlencoded
Content-Length: 16
空行
name=make&age=18

在HTTP请求头部中，每行用换行来隔开，一个空行后表示后面为正文内容。

针对HTTP消息头注入漏洞实施的攻击就叫做HTTP消息头注入攻击。

响应头中的换行符有特殊意义。 如果在输出过程中南没有对外界指定的换行符进行处理，就会导致HTTP消息头注入漏洞的产生。

Web应用中若存在HTTP消息头注入漏洞，就会造成如下影响。

生成任意Cookie
重定向至任意URL（重定向至外部网站）
更改页面显示内容（显示伪造页面）
执行任意JavaScript而造成与XSS同样的损害。

换行符（%0D%0A）。

Apache从CGI脚本中南接收的消息头中如何有多个Location消息头，Apache就会只将最后一的Location消息头作为响应返回，因此，原来的超重定向目标就会作废，而被换行符后面指定的URL取而代之。

HTTP消息头注入也会将其称为CRRF注入或者HTTP响应截断攻击。

HTTP注入安全隐患的产生原因：

HTTP响应头信息能够以文本格式逐行定义消息都，也就是说消息头之间互相以缓和符相隔。而如果攻击者恶意利用该特性，在指定重定向目标URL或者Cookie值的参数中插入换行符，且该换行符又被直接作为响应输入的话，就会产生HTTP消息头注入漏洞。

解决对策：

对策1：不将外界参数作为HTTP响应消息头输出：

绝大多数情况下，经过重新进行设计评估后，都能够做到不将外界参数作为HTTP响应消息头输出。Web应用中会用到输出HTTP响应消息头的典型功能为重定向和生成Cookie，而只要遵循以下方针，就能大幅度减少直接将外界参数作为消息头输出的机会。

不直接使用URL指定重定向目标，而是将其固定或者通过编号等方式来指定。
使用Web应用开发工具提供的会话变量来移交URL

因此，在设计阶段就应该尽量不把外界参数作为HTTP响应消息头输出。而如果无论如何都必须将外界参数输出到HTTP响应消息头中的话，可以通过如下方式来处理。

由专门的API来进行重定向或生成Cookie的处理：

CGI脚本中能够使用print等语句直接记述HTTP响应头，但是使用这种方法需要严格遵守HTTP和Cookie等标准规格，否则就可能会导致安全隐患等Bug产生。

所以可以使用各种编程语言提供的API来处理。

语言	生成Cookie	重定向	输出响应消息头
PHP	setcookie/setrowcookie	无（利用header）	header
Perl+CGI.pm	CGI::Cookie	redirect	header
Java Servlet	HttpServletResponse#addCookie	HttpServletResponse#sendRedirect	HttpServetResponse#setHeader
ASP.NET	Respone.Cookie.Add	Respone.Redirect	Response.AppendHeader

对策2：检验生成消息头的参数中的换行符：

针对换行符的处理方法右如下两种。

URL中含有换行符就报错
将Cookie中的换行符进行百分号编码

学习过程中笔记的记录与资料整理。