这段时间一直研究怎么才能在  webbrowser中设置referer来路来伪造来路进行刷流量，可是最后研究了半个月最终以失败告终，因为现在的统计代码，比较实际的就是cnzz.com和google adsense自带的统计，他们的统计都是通过js文件进行统计的，这样就形成了伪造来路的不成功，具体为什么不成功就让下面的一篇文章说明吧！
众所周知，服务器端的referer来路是可以伪造的，无论是ASP、PHP还是其他脚本都是可以伪造referer的，一些下载软件更是把referer伪造的惟妙惟肖，利用webbrowser控件可以方便的伪造来路。那么，作为保护网站的守门人，它如何防止这些伪造的referer呢？
这里，利用的是 Javascript 这一利器。
上面提到的伪造referer的方法都是通过服务器端的脚本来实现的，但它们并不能欺骗客户端。而JS是在客户端执行的，它并不会理会服务器端的headers信息，所以，利用js的 document.referer 方法可以准确地判断网页的真实来路。
几乎所有的第三方统计不约而同地采用了 document.referer 来判断来路，为什么？正是基于 js 下的 referer来路 是不可伪造的。即使在服务器端成功地伪造了referer的网页脚本，在第三方统计里也是无法被统计到的，原因正是由于这些三方统计采用了 document.referer 来判别真实的来路。
所以，为了对抗虚假的 referer 伪造信息，统计代码需要利用 js 的 document.referer 来判别，就可以将伪造的信息拒之门外
据目前所知，到目前为止，js下是无法伪造 referer 的。
那么有人问了，如果客户端把JAVASCRIPT脚步甚至cookies关闭了，你还怎么判断这个referer？其实答案也很简单，就是 js 和 asp/php 脚本之间通过 操作cookies 这个中间桥梁来实现，js里把这个referer写入cookies，asp/php读取这个cookies，如果读取不到这个cookies，则判断非本站来路。

			

HTTP_REFERER有效和无效的情况





页面跳转服务器获取http头时，有时有 HTTP_REFERER，而有时又没有，下面整理了一些 http_referer
的使用注意情况：

【准备】

http://www.libaqiang.com下test.php文件

echo $_SERVER['HTTP_REFERER'];

【有效的情况】

1、以iframe 形式调用地址

2、以window.open调用，打开新页面

window.open(url);

3、使用window.location.replace在Firefox 和Chrome下可以获取HTTP_REFERER

window.location.replace(url);

4、使用window.location.href在Firefox 和Chrome下可以获取HTTP_REFERER

window.location.href = url;

5、使用A标签跳转可以获取HTTP_REFERER

你可以用js来创建a连接后激活点击事件。

【无效的情况】

1、使用函数
file_get_contents或file等函数调用URL地址，这个地址所在的文件无法获取HTTP_REFERER

2、使用window.location.replace在IE6、IE7、IE8下无法获取HTTP_REFERER

window.location.replace(url);

3、使用window.location.href在IE6、IE7、IE8下无法获取HTTP_REFERER

window.location.href = url

IE是个大悲剧。
							
		

这段时间一直研究怎么才能在  webbrowser中设置referer来路来伪造来路进行刷流量，可是最后研究了半个月最终以失败告终，因为现在的统计代码，比较实际的就是cnzz.com和google adsense自带的统计，他们的统计都是通过js文件进行统计的，这样就形成了伪造来路的不成功，具体为什么不成功就让下面的一篇文章说明吧！
众所周知，服务器端的referer来路是可以伪造的，无论是ASP、PHP还是其他脚本都是可以伪造referer的，一些下载软件更是把referer伪造的惟妙惟肖，利用webbrowser控件可以方便的伪造来路。那么，作为保护网站的守门人，它如何防止这些伪造的referer呢？
这里，利用的是 Javascript 这一利器。
上面提到的伪造referer的方法都是通过服务器端的脚本来实现的，但它们并不能欺骗客户端。而JS是在客户端执行的，它并不会理会服务器端的headers信息，所以，利用js的 document.referer 方法可以准确地判断网页的真实来路。
几乎所有的第三方统计不约而同地采用了 document.referer 来判断来路，为什么？正是基于 js 下的 referer来路 是不可伪造的。即使在服务器端成功地伪造了referer的网页脚本，在第三方统计里也是无法被统计到的，原因正是由于这些三方统计采用了 document.referer 来判别真实的来路。
所以，为了对抗虚假的 referer 伪造信息，统计代码需要利用 js 的 document.referer 来判别，就可以将伪造的信息拒之门外
据目前所知，到目前为止，js下是无法伪造 referer 的。
那么有人问了，如果客户端把JAVASCRIPT脚步甚至cookies关闭了，你还怎么判断这个referer？其实答案也很简单，就是 js 和 asp/php 脚本之间通过 操作cookies 这个中间桥梁来实现，js里把这个referer写入cookies，asp/php读取这个cookies，如果读取不到这个cookies，则判断非本站来路。

最近在接入H5微信支付时遇到了一个比较坑的问题，所以写篇总结



问题描述

在接入H5微信支付时，如果是APP里调起H5支付，需要在webview中手动设置referer，如下



Map extraHeaders = new HashMap();
extraHeaders.put("Referer", "商户申请H5时提交的授权域名");//例如 http://www.baidu.com 
webView.loadUrl(targetUrl, extraHeaders);//targetUrl为微信下单地址

因为微信要验证请求来源，所以如果这个地方没有去设置的话，会跳转如下页面中 


但是测试过程中发现一个兼容性问题：在4.4.4、4.4.3的设备上，下单时一直会跳转到上面的页面中。后来通过抓包发现设置的Referer没有生效。。。



解决方案

google了一大圈最终发现了一个靠谱的解决方案，就是利用loadDataWithBaseURL方法代替loadUrl方法，通过js去请求微信下单Url，loadDataWithBaseURL方法的具体描述如下



public void loadDataWithBaseURL(String baseUrl, String data, String mimeType, String encoding, String historyUrl)

data可以是Html代码片。baseUr为页面的基础Url，用来组织html中的相对路径。我们data这个参数中传入js代码片去请求微信下单Url，而baseUr设置为授权域名，这样请求微信下单Url时，referer自动会被设置为baseUrl（正常请求的referer默认就是请求的来源地址）

最终的代码如下



if (("4.4.3".equals(android.os.Build.VERSION.RELEASE))
                || ("4.4.4".equals(android.os.Build.VERSION.RELEASE))) {
     //兼容这两个版本设置referer无效的问题
     view.loadDataWithBaseURL("商户申请H5时提交的授权域名",
                    "<script>window.location.href=\"" + targetUrl + "\";</script>",
                    "text/html", "utf-8", null);
 } else {
      Map<String, String> extraHeaders = new HashMap<>();
      extraHeaders.put("Referer", "商户申请H5时提交的授权域名");
      view.loadUrl(targetUrl, extraHeaders);
 }

希望本文能帮助到遇到相同问题的程序员们

微信H5支付常见问题汇总 
https://pay.weixin.qq.com/wiki/doc/api/H5.php?chapter=15_4 

最后感谢提供本方案的大佬，他写的文章地址如下 
https://www.jianshu.com/p/8e138577ec8e