Privoxy过滤X-Frame-Options以及hide referer

shixudong@163.com

疫情期间，因工作原因，在树莓派上加装了privoxy，用作http代理，满足了实际需要。几日后，碰到了一个奇怪现象，原先不使用http代理能正常访问的一个网站，使用privoxy代理后反而不能正常访问，现把问题解决过程分享如下。

一、不正常现象

设置Win10的代理指向privoxy，通过chrome浏览器访问http://www.example.com，页面框架能正常显示，页面中间部分提示“www.example.com拒绝了我们的连接请求”，临时关闭代理，整个网页显示恢复正常，显然与privoxy的代理行为有关。当时稍稍百度了一下privoxy相关资料，没有认真查找privoxy端的解决方案，又不想在win10代理设置里添加例外，给chrome装了个switchyomega，草草解决了事。

第二天，ipad通过privoxy代理访问同一网站，出现同样现象，此时，既不方便添加例外，也不能安装switchyomega，又不想安装另外的app（注：本人是通过ipad无线局域网配置http代理实现ipad代理上网的，没有借助专门的app）。

二、分析与解决

鉴于ipad调试不便，于是又回到win10前，继续收集更多线索，首先换用火狐浏览器（通过privoxy代理）打开同一网站，同样不正常，火狐给出提示“Firefox 无法打开此页面”、“为了保护您的安全，www.example.com将不允许Firefox显示嵌入了其他网站的页面。要查看此页面，请在新窗口中打开。详细了解...”。在新窗口确实能打开不正常显示的部分，根据火狐提供的建议,是网站启用了防止“点击劫持”的安全技术，与被访问网站的x-frame选项（X-Frame-Options）或内容安全政策（Content-Security-Policy）有关。Chrome的调试console也给出了类似错误提示“Refused to display 'http://www.example.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'”。据此，基本可以推断，网页显示不正常是因为被访问网站的X-Frame-Options设置导致网页部分内容被浏览器拦截。基于实际情况（多终端多浏览器），还是回到privoxy端一劳永逸解决此问题为妥。

有了针对性，百度搜索效率更高了，根据搜索建议，修改user.action 配置文件，拦截服务端禁止在iframe中加载的响应头，在user.action 末尾添加两行：

{ +crunch-server-header{X-Frame-Options} }

/   或   .example.com

然后重启privoxy，但还是和以前一样不正常。奇怪了，联想到先前火狐给出的提示，难道被访问网站采用了Content-Security-Policy而非X-Frame-Options，于是将user.action配置中的X-Frame-Options替换为Content-Security-Policy，还是无效。一时陷入困顿之中，想着能否在privoxy配置中设置代理例外，仔细研究了一下privoxy的配置文件（config）,发现无解（注：树莓派通过特殊机制连接互联网，privoxy代理用于给其他终端提供这种特殊机制，所以privoxy代理全是直接本地转发，不需要转发上级代理）。短暂思考后，开启privoxy的debug功能（debug=8 # show header parsing），在logfile中赫然发现Header:scan:X-FRAME-OPTIONS:SAMEORIGIN，居然是大写惹的祸，于是用X-FRAME-OPTIONS替换user.action配置中的X-Frame-Options，终于搞定，一切终端OK。

三、现象再分析

问题得到解决后，对上述步骤进行了回顾，发现浏览器地址栏为：http://i.mooc.example.com/，而被拦截的部分按照火狐和chrome的提示，全是针对http://www.example.com/，两者域名不一致，显然不符合服务端X-Frame-Options关于SAMEORIGIN的要求，网页被拦截是浏览器的正常行为。然而让人奇怪的是，如不通过privoxy直接访问时，按理两者域名仍然不一致，为何www.example.com又不被浏览器拦截，能正常显示整个网页呢？提高解决问题能力的诀窍就是“宜将剩勇追穷寇”，乘着刚解决完问题的兴奋，又开始了进一步分析，因为涉及直接访问，故需要wireshark登上舞台。好久不用wireshark，百度了一下wireshark查找字节流中字符串的方法（编辑-查找分组，选择分组字节流和字符串），发现还有忽略字符串大小写的功能（注：先前要是早用上这个功能的话，也不用折腾那么久了）。通过本机抓包对比，证实通过privoxy访问时服务端有X-Frame-Options要求，直接访问时则无此要求。继续通过本机抓包与privoxy所在树莓派抓包进行对比，发现针对服务端有X-Frame-Options要求的本机请求包，http头有referer字段，取值为“i.mooc.example.com”，而树莓派上privoxy发出的同一个请求包，则压根没有referer字段。按照网上资料，如网站采用了动态X-Frame-Options技术，在需要启用X-Frame-Options功能时，仅对没有referer字段的http请求启用，结合抓包对比情况和先辈经验，完美解释了上述奇怪现象。

四、问题再解决

既然查到了问题背后的深层次原因，根源就是privoxy“贪污”了http请求包的referer字段，这就为解决问题提供了新的思路，于是点根烟再次百度，发现可在user.action配置中启用{-hide-referer}选项，便删除{+crunch-server-header{X-Frame-Options}}选项，重启privoxy后果然也能搞定。顺便研究了一下user.action全文，发现fragile选项包含了-hide-referer功能，根据user.action自带注释，在使用privoxy访问网站出现不正常现象时，如懒得查找原因或懒得找privoxy反馈问题时，简单的启用fragile功能即可。于是再删除{-hide-referer}选项，直接使用fragile，一样OK。

# Now you noticed that the default configuration breaks Forbes Magazine, but you were too lazy to find out which action is the culprit, and you were again too lazy to give feedback, so you just used the fragile alias on the site, and -- whoa! -- it worked. The 'fragile' aliases disables those actions that are most likely to break a site. Also, good for testing purposes to see if it is Privoxy that is causing the problem or not.