所谓 UA（User Agent / 用户代理），最初是指浏览器告知网站管理员，本浏览器支持的类型和框架，让网站管理员以支持的模式结构向浏览器发送页面，呈现给用户浏览。关于浏览器的 UA，还有一段很复杂的历史演变。演变到今天，网站管理员为了给用户带呈现最佳的页面效果，为了使不同浏览器展现同样的网站页面，通过浏览器获取用户的系统信息，包括硬件平台、系统软件、应用软件和用户个人偏好，然后通过服务器解析后以适合用户的页面类型发送到浏览器。 何星星通过分析监测到的以下 UA 信息供网站管理员参考使用，何星星自以为是已经最全的啦，如果有需要补充的请在文章尾部留言，何星星将补全。目前 UA 分析监测可补全的系统：Windows 7、Windows 10、Mac OS X Lion、Ubuntu 14.04；浏览器：所有品牌和系列。 // 分析平台：Windows 7 64 位；其中，Internet Explorer 10 浏览器和 Internet Explorer 11 浏览器以及微软 Edge 浏览器为 Windows 10 64 位。 Chrome｜谷歌浏览器 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.87 Safari/537.36 Firefox｜火狐浏览器 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 Opera｜欧朋浏览器 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.87 Safari/537.36 OPR/37.0.2178.32 Safari｜苹果浏览器 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 360极速浏览器 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 […]
View Details电脑操作系统是Win10中文版，新装的英文版SQL Server 2008，纯默认安装，没有做任何改动。 装完SQL Server 2008之后，发现只能用默认的机器名来登录： 如果用127.0.0.1登录就会报出如下的错误： 在网上查询一番之后，发现让开启SQL Server Configuration Manager中的Named Pipes就可以解决问题，然而试了并没有什么卵用。。。 于是开始自己动手尝试解决方案，经过一番尝试，功夫不负有心人啊！终于算是找到了，下面把步骤贴出来： 第一步，开启TCP/IP。因为装完SQL之后这项协议默认是不开通的： 第二步，设置TCP/IP中属性的"IP ALL"的端口为1433。众所周知，SQL Server的默认端口为1433，只是不知道为何，默认安装却没有这一项。 然后，重启SQL服务就可以用127.0.0.1登录上了： from:https://www.cnblogs.com/goldenbiu/p/4726463.html
View Details在阅读本文前，大家要有一个概念，在实现正常的TCP/IP 双方通信情况下，是无法伪造来源 IP 的，也就是说，在 TCP/IP 协议中，可以伪造数据包来源 IP ，但这会让发送出去的数据包有去无回，无法实现正常的通信。这就像我们给对方写信时，如果写出错误的发信人地址，而收信人按信封上的发信人地址回信时，原发信人是无法收到回信的。 一些DDoS 攻击，如 SYN flood, 就是利用了 TCP/ip 的此缺陷而实现攻击的。《计算机网络》教材一书上，对这种行为定义为“发射出去就不管”。 因此，本文标题中的伪造来源IP 是带引号的。并非是所有 HTTP 应用程序中存在此漏洞。 那么在HTTP 中， " 伪造来源 IP", 又是如何造成的？如何防御之？ 在理解这个原理之前，读者有必要对HTTP 协议有所了解。 HTTP 是一个应用层协议，基于请求 / 响应模型。客户端（往往是浏览器）请求与服务器端响应一一对应。 请求信息由请求头和请求正文构成（在GET 请求时，可视请求正文为空）。请求头类似我们写信时信封上的基本信息，对于描述本次请求的一些双方约定。而请求正文就类似于信件的正文。服务器的响应格式，也是类似的，由响应头信息和响应正文构成。 为了解这个原理，可使用Firefox Firebug, 或 IE 浏览器插件 HTTPwatch 来跟踪 HTTP 请求 / 响应数据。 本文中，以HTTPwatch 为例说明之。安装 httpwatch 并重启 IE 浏览器后， IE 的工具栏上出现其图标，点击并运行 Httpwatch, 就会在浏览器下方显示出 HTTPWatch 的主界面。 点击左下角红色的“Record ”按钮，并在地址栏输入 www.baidu.com, 等页面打开后，选中一个请求，并在下方的 tab 按钮中选择“ Stream ”，如图： 左边即是请求数据，右边即是服务器响应数据。左边的请求头均以回车换行结束，即“\r\n ” , 最后是一个空行（内容为 \r\n ） , 表示请求 header 结束。而请求 header 中除第一行外，其它行均由 header 名称， header 值组成，如 Accept-Encoding: gzip, deflate ， header 名称与值之间有冒号相隔，之间的空格是可有可无的。 那么，在HTTP 应用程序中，如何取得指定的请求 header 信息呢？这里使用 PHP 语言为例说明。对所有客户端请求 header, PHP 程序中取得其值的方式如下： $_SERVER['HTTP_ HEADER_NAME '] HEADER_NAME应该以换成对应的 header 名称，此项的规律是：全大写，连接线变成下划线。比如要取得客户端的User-Agent 请求头，则使用 $_SERVER['HTTP_USER_AGENT'], 掌握这个规律，即可达到举一反三的效果。如要取得 COOKIE 信息，则使用 $_SERVER['HTTP_COOKIE'] 即可。也就是说， $_SERVER 数组中，以 HTTP 开头的项均属于客户端发出的信息。 回归到HTTP 应用程序层，来源 IP 的重要性不言而语，例如表单提交限制，频率等等均需要客户端 IP 信息。使用流行的 Discuz X2.5 的文件 source/class/discuz/discuz_application.php 中的代码片断： private function _get_client_ip() { $ip = $_SERVER['REMOTE_ADDR']; if (isset($_SERVER['HTTP_CLIENT_IP']) && preg_match('/^([0-9]{1,3}\.){3}[0-9]{1,3}$/', $_SERVER['HTTP_CLIENT_IP'])) { $ip = $_SERVER['HTTP_CLIENT_IP']; 如以下的JSP代码片段： public String getIpAddr(HttpServletRequest request) { String ip = request.getHeader("x-forwarded-for"); if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) { ip = request.getHeader("Proxy-Client-IP"); } if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) { ip = request.getHeader("WL-Proxy-Client-IP"); } if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) { ip = request.getRemoteAddr(); } return ip; } 以上代码片段即是获取客户端IP ，这段程序会尝试检查 HTTP_CLIENT_IP, HTTP_X_FORWARDED_FOR, 根据之前的原理说明，以 HTTP_ 开头的 header, 均属于客户端发送的内容。那么，如果客户端伪造 Client-Ip, X-Forward-For ，不就可以欺骗此程序，达到“伪造 IP ”之目的？ 那么如何伪造这项值？如果你会写程序，并了解HTTP 协议，直接伪造请求 header 即可。或者使用 Firefox 的Moify Headers 插件即可。 按图示顺序号输入或点击相应按钮。Start 按钮这里变为红色 Stop ，说明设置成功。 这时，如果我们使用Firefox 访问其它网站，网站服务器就针接收到我们伪造的 X-Forward-For, 值为 1.1.1.1 。 严格意义上讲，这并不是程序中的漏洞。Discuz 为了保持较好的环境兼容性 ( 包含有反向代理的 web 服务器环境，如 nginx 作为 php fastcgi 的前端代理 ) ，如此处理是可以理解的。那么如何处理，才能杜绝这个问题呢？ 服务器重新配置X-Forward-For 为正确的值。 如对典型的nginx + php fastcgi 环境（ nginx 与 php fastcgi 是否位于同一机器，并不妨碍此问题的产生） , nginx和 php fastcig 进程直接通信： 切记，$_SERVER['REMOTE_ADDR'] 是由 nginx 传递给 php 的参数，就代表了与当前 nginx 直接通信的客户端的 IP （是不能伪造的）。 再比如，存在中间层代理服务器的环境： 这种情况下，后端的HTTP 文件服务器上获取取的 REMOTE_ADDR 永远是前端的 squid/varnish cache 服务器的通信 IP 。 服务器集群之间的通信，是可以信任的。我们要做的就是在离用户最近的前端代理上，强制设定X-Forward-For 的值，后端所有机器不作任何设置，直接信任并使用前端机器传递过来的 X-Forward-For 值即可。 即在最前端的Nginx 上设置： location ~ ^/static { proxy_pass ….; proxy_set_header X-Forward-For $remote_addr ; […]
View Details有人会说：IP验证是在TCP层完成的，不是HTTP层完成的，如果伪造IP的话可能连TCP的三次握手都完不成。我这里说的不是完全意义的伪造。如果你使用透明代理上网，那么在透明代理发送给服务器端的HTTP请求中会包含x-forward-for信息。例如：X-Forwarded-For: 162.150.10.16 那么我们只要在发给服务器端的http请求中加入X-Forwarded-For: 162.150.10.16信息即可。 例如下边一个请求: GET http://www.ahjinzhai.gov.cn/sdyxnx/vote.php?id=1 HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Referer: http://www.ahjinzhai.gov.cn/sdyxnx/ Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt; TencentTraveler ) Host: www.ahjinzhai.gov.cn Cookie: PHPSESSID=1847fc15020bc16b47ce250f457daab4 Cache-Control: no-cache X-Forwarded-For: 162.150.10.16 Pragma: no-cache from:https://www.cnblogs.com/sanler/p/7248952.html
View Details