博客 (17)

原标题:关于 PHP 获取 IP 地址的几种方法


PHP 获取客户端的 IP 地址有 4 种方式:

  1. REMOTE_ADDR:浏览当前页面的用户计算机的 IP 地址

  2. HTTP_X_FORWARDED_FOR:记录代理信息,会把每一层代理都记录

  3. HTTP_CLIENT_IP:客户端的 IP

  4. X-Real-IP:没有标准,由上一跳决定


REMOTE_ADDR 一般是不能伪造的,因为是通过服务器与客户端握手协议来获取的。而 HTTP_X_FORWARDED_FOR 和 HTTP_CLIENT_IP 是在 header 信息里面,所以客户端是可以进行很轻松的伪造。下面是对这三种方式详解:

https://www.v2ex.com/t/230367

https://www.test404.com/post-1448.html

https://www.cnblogs.com/mypath/articles/5239687.html


一、关于 REMOTE_ADDR
这个变量获取到的是“直接来源”的 IP 地址,所谓“直接来源”指的是直接请求该地址的客户端 IP 。这个 IP 在单服务器的情况下,很准确的是客户端 IP ,无法伪造。当然并不是所有的程序都一定是单服务器,比如在采用负载均衡的情况(比如采用 haproxy 或者 nginx 进行负载均衡),这个 IP 就是转发机器的 IP ,因为过程是客户端 -> 负载均衡 -> 服务端。是由负载均衡直接访问的服务端而不是客户端。


二、关于 HTTP_X_FORWARDED_FOR 和 HTTP_CLIENT_IP
基于“一”,在负载均衡的情况下直接使用 REMOTE_ADDR 是无法获取客户端 IP 的,这就是一个问题,必须解决。于是就衍生出了负载均衡端将客户端 IP 加入到 HEAD 中发送给服务端,让服务端可以获取到客户端的真实 IP 。当然也就产生了各位所说的伪造,毕竟 HEAD 除了协议里固定的那几个数据,其他数据都是可自定义的。


三、为何网上找到获取客户端 IP 的代码都要依次获取 HTTP_CLIENT_IP 、 HTTP_X_FORWARDED_FOR 和 REMOTE_ADDR
基于“一”和“二”以及对程序通用性的考虑,所以才这样做。 假设你在程序里直接写死了 REMOTE_ADDR ,有一天你们的程序需要做负载均衡了,那么你有得改了。当然如果你想这么做也行,看个人爱好和应用场景。也可以封装一个只有 REMOTE_ADDR 的方法,等到需要的时候改这一个方法就行了。


X_FORWARDED_FOR 与 X-Real-IP 的区别:

X_FORWARDED_FOR:记录了所有链路里的代理 IP 值,比如下面所说的,经过了 3 次代理,分别是 1.1.1.1, 2.2.2.2, 3.3.3.3,其中 1.1.1.1 是客户端 IP,2.2.2.2 是代理服务器,接下来同理。

X-Real-IP:是只会记录前一次代理的 IP 地址。

一般来说,X-Forwarded-For是用于记录代理信息的,每经过一级代理(匿名代理除外),代理服务器都会把这次请求的来源IP追加在X-Forwarded-For

来自4.4.4.4的一个请求,header 包含这样一行

X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3

代表请求由1.1.1.1发出,经过三层代理,第一层是2.2.2.2,第二层是3.3.3.3,而本次请求的来源IP4.4.4.4是第三层代理

X-Real-IP,没有相关标准,上面的例子,如果配置了X-Read-IP,可能会有两种情况

// 最后一跳是正向代理,可能会保留真实客户端IP
X-Real-IP: 1.1.1.1
// 最后一跳是反向代理,比如Nginx,一般会是与之直接连接的客户端IP
X-Real-IP: 3.3.3.3

所以 ,如果只有一层代理,这两个头的值就是一样的。

那一般在后端取值(比如 node.js 通过 nginx 代理)是用哪个值呢?我看 sf 上看一般推荐是用 X-Forwarded-For,直接用 X-Real-IP 岂不是更方便点?

X-Forwarded-For 确实是一般的做法

  1. 他在正向(如 squid)反向(如 nginx)代理中都是标准用法,而正向代理中是没有 x-real-ip 相关的标准的,也就是说,如果用户访问你的 nginx 反向代理之前,还经过了一层正向代理,你即使在 nginx 中配置了 x-real-ip,取到的也只是正向代理的 IP 而不是客户端真实 IP

  2. 大部分 nginx 反向代理配置文章中都没有推荐加上 x-real-ip ,而只有 x-forwarded-for,因此更通用的做法自然是取 x-forwarded-for

  3. 多级代理很少见,只有一级代理的情况下二者是等效的

  4. 如果有多级代理,x-forwarded-for 效果是大于 x-real-ip 的,可以记录完整的代理链路


1、将以下代码保存为 Client.php

// php 脚本开始
$ch = curl_init();
$url = "http://localhost/ser.php";
$header = array('CLIENT-IP:208.165.188.175', 'X-FORWARDED-FOR:208.165.188.175');
// 声明伪造 head 请求头
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);
$page_content = curl_exec($ch); curl_close($ch);
echo $page_content;


2、将以下代码保存为 ser.php

// php 脚本开始
echo getenv('HTTP_CLIENT_IP');
echo getenv('HTTP_X_FORWARDED_FOR');
echo getenv('REMOTE_ADDR');


测试结果为

208.165.188.175
208.165.188.175
127.0.0.1


上面结果可看出,http_client_ip、http_x_forwarded_for 都被伪造了,而 remote_addr 还是127.0.0.1 就是客户端 IP

总结:

如果我们没用到负载均衡(CDN)的话直接用 REMOTE_ADDR 获取 IP。

如果使用了一级 CDN 的话,CDN 会把 REMOTE_ADDR 转发成 X-Real-IP,我们服务器可以获取 X-Real-IP 来获取 IP 值。如果是多级 CDN 的话需要我们来做 nginx 代理,详细:https://www.cnblogs.com/princessd8251/articles/6268943.html

就是第一台负载服务器获取 REMOTE_ADDR 转发成 X-Real-IP,之后的去继承前一台的 X-Real-IP 就可以了,这里记住必须是去继承,不然第二台会把第一台的 REMOTE_ADDR 转发成 X-Real-IP 导致错误。

在 discuz! 中的获取 IP 的方法:

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'];
    } elseif(isset($_SERVER['HTTP_X_FORWARDED_FOR']) AND preg_match_all('#\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}#s', $_SERVER['HTTP_X_FORWARDED_FOR'], $matches)) {
        foreach ($matches[0] AS $xip) {
            if (!preg_match('#^(10|172\.16|192\.168)\.#', $xip)) {
                $ip = $xip;
                break;
            }
        }
    }
    return $ip;
}

这里 DZ 为了符合有些用户会用代理,所以才首先使用了两个容易伪造的方法,如果有需要可以自行修改。

h
转自 hykeda 7 年前
11,528

今天发现,阿里云 CDN 的 Refer 防盗链并没有真正防止白名单外的域名调用 OSS 的图片。经过一番研究发现,这跟 https 有关。

我在阿里云开通了 OSS 来存在图片,并使用 CDN 访问,在 CDN 中开启了 https,但并不强制。并且使用“白名单”的方式来设置 Refer 防盗链。关键是开启了“允许空 Referer”。

image.png 

我在 http://b.com/ 上测试调用 httphttps 的图片都是打不开的(防盗链有效),但是在 https://b.com/ 上却能显示 http 的图片(防盗链失效):

image.png

究其原因,是 https 页面在调用 http 图片时请求头不包含 Referer 字段,导致 CDN 判断 Referer 为空,这时候如果开启了为空也允许访问的话,就会出现防盗链失效的情况了。

image.png

image.png

总结:如果 CDN 开启了 https 访问,那么不要允许空 Referer。这里白名单内的网站必须使用与 CDN 一致的 protocol(http 或 https)。建议的写法是:

<img src="//cdn.xxx.com/abc.jpg" />


xoyozo 7 年前
9,728
提供商IPv4IPv6备注
下一代互联网国家工程中心

240c::6666

240c::6644

http://www.chinaipv6.com.cn/

我国首个 IPv6 公共 DNS

114DNS

114.114.114.114

114.114.115.115


http://www.114dns.com/

虽然称为 114DNS,但并非电信专用,联通、移动全国通用。

阿里

223.5.5.5

223.6.6.6

2400:3200::1

2400:3200:baba::1

http://www.alidns.com/

腾讯(DNSPod)
119.29.29.29

https://www.dnspod.cn/Products/Public.DNS

百度180.76.76.762400:da00::6666

http://dudns.baidu.com/intro/publicdns/

谷歌

8.8.8.8

8.8.4.4


更国际化
IBM
9.9.9.9

Cloudflare

1.1.1.1

1.0.0.1

2001:2001::

2001:2001:2001::

全球最快


xoyozo 8 年前
5,496

知其然,才能使其安——王震

 

常见的攻击手法

SQL 注入

文件上传

弱口令

Nday 攻击

XSS

社会工程学

等等……

 

被黑原因总结

不知道 不及时 不在意
不知道自用系统安全动态 不及时更新系统安全补丁 不在意个人信息安全
不知道常见黑客攻击手段 不及时修复漏洞 不在意用户数据安全
不知道该如何修复 不及时排查被黑系统 不在意各种安全软件提示、提醒
不知道今后该如何防御   不在意细节

 

那些年,醉人的“三字经”

网站渗透娱乐版 针对企业的实战版

进谷歌 找注入

没注入 就旁注

没旁注 用0day

没0day 猜目录

没目录 就嗅探

爆账户 找后台

传小马 放大马

拿权限 挂页面

放暗链 清数据

搞企业 先扫描

默认密 都知道

社工库 找一找

邮箱号 先列好

九头蛇 跑一跑

搞不定 放大招

发邮件 凭伪造

没邮箱 搞网站

二级域 皆可爆

老漏洞 没修好

新漏洞 刷一票

干研发 Git 找

原代码 全都要

CDN 可以跳

防火墙 可以撬

堡垒机 可以绕

云防护 可以秒

是企业 没有哪家搞不了

 

攻击手法统计

Nday攻击:45%

漏洞攻击:35%

其他攻击:15%

0day攻击:5%

 

一些箴言

80%的安全问题都是已知的安全问题,但是能抵御已知安全问题的网站只有20%

弱口令虽然看起来很弱,但是忽视弱口令只会让你的网站变得更弱

没有百分之百的安全,你所做的一切不是为了让自己无坚不摧,只是让自己不再弱不禁风

80%的系统安全问题都是可以通过升级补丁来解决,但是能做到这点的人只有20%

SQL注入存在十几年了,依然是主流攻击手段,可见安全比的不是谁更先进,而是谁更细心

不要得罪你的开发人员,这就跟你吃饭不要得罪服务员一样,你不知道他下一秒会不会在你的菜里吐口水

 

还有一句

永远不要觉得你安装的安全防护软件真的可以保护你的安全

 

服务器安全注意事项

不安装不必要的软件

排查所有系统弱口令

关闭不常用的端口

控制目录权限

不在服务器上下载、打开非官方提供软件

不在服务器上打开他人发来的网页链接

 

如何排查暗链?

利用查看网站的源代码来检查黑链

使用站长工具“网站死链检测”功能来检查黑链

用 FTP 查看网站文件的修改时间来检查黑链

接入 webscan.360.cn 检测

 

后门排查

Windows 下,D 盾、安全狗、主机卫士

Linux 下,Seay 一句话扫描脚本、主机卫士 Linux 版

用 FTP 查看网站文件的修改时间来排查恶意后门

接入 webscan.360.cn 等在线检测

 

安全类书籍推荐

《Web 安全深度剖析》——张炳帅 著

《白帽子讲 Web 安全》——吴瀚清 著

《Web 前端黑客技术揭秘》——钟晨呜(余弦)著

《黑客攻防技术宝典 Web 实战篇》——国外某黑客 著

 

联系方式

官网:www.flsec.com

xoyozo 10 年前
5,186

一、在 OSS 中新建一个 Bucket,获得一个 OSS 域名(外网域名例:bucketname.oss-cn-hangzhou.aliyuncs.com)

此时不需要绑定自己的域名,如果我们的域名绑在 OSS 上,产生的费用会比绑在 CDN 上高许多。

二、在 CDN 中添加新域名,加速域名就是自己的域名(如:cdn.xoyozo.net),业务类型是“图片小文件”,源站类型是“OSS 域名”,把刚才的 OSS 域名复制到此处。

三、此时管理这个 CDN 域名可以看到域名信息中的“源站设置”,类似:bucketname.oss-cn-hangzhou.aliyuncs.com,这样只实现了 CDN 的效果,我们把它修改为 bucketname.img-cn-hangzhou.aliyuncs.com,这样我们就可以在使用图片时通过添加 @ 符号的方式任意获取缩略图了。

四、同样能在这个页面看到 CNAME 有一个类似 cdn.xoyozo.net.w.kunlun*.com 的域名,将我们的 cdn.xoyozo.net 作 CNAME 解析到这个域名上即可。

这样,在 OSS 上的一张图片,如:http://bucketname.oss-cn-hangzhou.aliyuncs.com/abc/123.jpg 就可以通过 http://cdn.xoyozo.net/abc/123.jpg@100w_100h_90Q.jpg 的方式来获取指定缩略图了。

查看如何通过地址栏带参对图片进行裁剪

xoyozo 10 年前
7,927

在 ASP.NET Core 或 ASP.NET 5 中部署百度编辑器请跳转此文


本文记录百度编辑器 ASP.NET 版的部署过程,对其它语言版本也有一定的参考价值。

【2020.02.21 重新整理】


下载

从 GitHub 下载最新发布版本:https://github.com/fex-team/ueditor/releases

按编码分有 gbk 和 utf8 两种版本,按服务端编程语言分有 asp、jsp、net、php 四种版本,按需下载。


目录介绍

以 v1.4.3.3 utf8-net 为例,

ueditor 目录结构.png


客户端部署

本例将上述所有目录和文件拷贝到网站目录 /libs/ueditor/ 下。

当然也可以引用 CDN 静态资源,但会遇到诸多跨域问题,不建议。

在内容编辑页面引入:

<script src="/libs/ueditor/ueditor.config.js"></script>
<script src="/libs/ueditor/ueditor.all.min.js"></script>

在内容显示页面引入:

<script src="/libs/ueditor/ueditor.parse.min.js"></script>

如需修改编辑器资源文件根路径,参 ueditor.config.js 文件内顶部文件。(一般不需要单独设置)

如果使用 CDN,那么在初始化 UE 实例的时候应配置 serverUrl 值(即 controller.ashx 所在路径)。


客户端配置

初始化 UE 实例:

var ue = UE.getEditor('tb_content', {
    // serverUrl: '/libs/ueditor/net/controller.ashx', // 指定服务端接收文件路径
    initialFrameWidth: '100%'
});

其它参数见官方文档,或 ueditor.config.js 文件。


服务端部署

net 目录是 ASP.NET 版的服务端程序,用来实现接收上传的文件等功能。

本例中在网站中的位置是 /libs/ueditor/net/。如果改动了位置,那么在初始化 UE 的时候也应该配置 serverUrl 值。

这是一个完整的 VS 项目,可以单独部署为一个网站。其中:

net/config.json  服务端配置文件
net/controller.ashx  文件上传入口
net/App_Code/CrawlerHandler.cs  远程抓图动作
net/App_Code/ListFileManager.cs  文件管理动作
net/App_Code/UploadHandler.cs  上传动作

该目录不需要转换为应用程序。


服务端配置

根据 config.json 中 *PathFormat 的默认配置,一般地,上传的图片会保存在 controller.ashx 文件所在目录(即本例中的 /libs/ueditor/)的 upload 目录中:
/libs/ueditor/upload/image/
原因是 UploadHandler.cs 中 Server.MapPath 的参数是由 *PathFormat 决定的。

修改 config.json 中的 imagePathFormat 为例:

原值:"imagePathFormat": "upload/image/{yyyy}{mm}{dd}/{time}{rand:6}"

改为:"imagePathFormat": "/upload/ueditor/{yyyy}{mm}{dd}/{time}{rand:6}"

以“/”开始的路径在 Server.MapPath 时会定位到网站根目录。

此处不能以“~/”开始,因为最终在客户端显示的图片路径是 imageUrlPrefiximagePathFormat,若其中包含符号“~”就无法正确显示。

在该配置文件中查找所有 PathFormat,按相同的规则修改。


说到客户端的图片路径,我们只要将

原值:"imageUrlPrefix": "/ueditor/net/"

改为:"imageUrlPrefix": ""

即可返回客户端正确的 URL。

当然也要同步修改 scrawlUrlPrefix、snapscreenUrlPrefix、catcherUrlPrefix、videoUrlPrefix、fileUrlPrefix。


特殊情况,在复制包含图片的网页内容的操作中,若图片地址带“?”等符号,会出现无法保存到磁盘的情况,需要修改以下代码:

打开  CrawlerHandler.cs 文件,找到

ServerUrl = PathFormatter.Format(Path.GetFileName(this.SourceUrl), Config.GetString("catcherPathFormat"));

替换成:

ServerUrl = PathFormatter.Format(Path.GetFileName(SourceUrl.Contains("?") ? SourceUrl.Substring(0, SourceUrl.IndexOf("?")) : SourceUrl), Config.GetString("catcherPathFormat"));


如果你将图片保存到第三方图库,那么 imageUrlPrefix 值设为相应的域名即可,如:

改为:"imageUrlPrefix": "//cdn.***.com"

然后在 UploadHandler.cs 文件(用于文件上传)中找到

File.WriteAllBytes(localPath, uploadFileBytes);

在其下方插入上传到第三方图库的代码,以阿里云 OSS 为例:

// 上传到 OSS
client.PutObject(bucketName, savePath.Substring(1), localPath);

在 CrawlerHandler.cs 文件(无程抓图上传)中找到

File.WriteAllBytes(savePath, bytes);

在其下方插入上传到第三方图库的代码,以阿里云 OSS 为例:

// 上传到 OSS
client.PutObject(bucketName, ServerUrl.Substring(1), savePath);


最后有还有两个以 UrlPrefix 结尾的参数名 imageManagerUrlPrefix 和 fileManagerUrlPrefix 分别是用来列出上传目录中的图片和文件的,

对应的操作是在编辑器上的“多图上传”功能的“在线管理”,和“附件”功能的“在线附件”。

最终列出的图片路径是由 imageManagerUrlPrefiximageManagerListPath + 图片 URL 组成的,那么:

"imageManagerListPath": "/upload/ueditor/image",

"imageManagerUrlPrefix": "",

以及:

"fileManagerListPath": "/upload/ueditor/file",

"fileManagerUrlPrefix": "",

即可。

如果是上传到第三方图库的,且图库上的文件与本地副本是一致的,那么将 imageManagerUrlPrefix 和 fileManagerUrlPrefix 设置为图库域名,

服务端仍然以 imageManagerListPath 指定的路径来查找本地文件(非图库),但客户端显示图库的文件 URL。

因此,如果文件仅存放在图库上,本地没有副本的情况就无法使用该功能了。

综上,所有的 *UrlPrefix 应该设为一致。


另外记得配置不希望被远程抓图的域名,参数 catcherLocalDomain


服务端授权

现在来判断一下只有登录用户才允许上传。

首先打开服务端的统一入口文件 controller.ashx

继承类“IHttpHandler”改为“IHttpHandler, System.Web.SessionState.IRequiresSessionState”,即同时继承两个类,以便可使用 Session,
找到“switch”,其上插入:

if (用户未登录) { throw new System.Exception("请登录后再试"); }

即用户已登录或 action 为获取 config 才进入 switch。然后,

else
{
    action = new NotAllowedHandler(context);
}

这里的 NotAllowedHandler 是参照 NotSupportedHandler 创建的,提示语 state 可以是“登录后才能进行此操作。


上传目录权限设置

上传目录(即本例中的 /upload/ueditor/ 目录)应设置允许写入和禁止执行。


基本用法

设置内容:

ue.setContent("Hello world.");

获取内容:

var a = ue.getContent();

更多用法见官方文档:http://fex.baidu.com/ueditor/#api-common


其它事宜

配置上传附件的文件格式

找到文件:config.json,更改“上传文件配置”的 fileAllowFiles 项,

同时在 Web 服务器上允许这些格式的文件可访问权限。以 IIS 为例,在“MIME 类型”模块中添加扩展名。


遇到从客户端(......)中检测到有潜在危险的 Request.Form 值。参考此文


另外,对于不支持上传 .webp 类型的图片的问题,可以作以下修改:
config.json 中搜索“".bmp"”,替换为“".bmp", ".webp"
IIS 中选中对应网站或直接选中服务器名,打开“MIME 类型”,添加,文件扩展名为“.webp”,MIME 类型为“image/webp


最后,为了在内容展示页面看到跟编辑器中相同的效果,请参照官方文档引用 uParse

若有插入代码,再引用:
<link href="/lib/ueditor/utf8-net/third-party/SyntaxHighlighter/shCoreDefault.css" rel="stylesheet" />
<script src="/lib/ueditor/utf8-net/third-party/SyntaxHighlighter/shCore.js"></script>

其它插件雷同。


若对编辑器的尺寸有要求,在初始化时设置即可:

var ue = UE.getEditor('tb_content', {

  initialFrameWidth: '100%',
  initialFrameHeight: 320
});


图片等附件上传到阿里云 OSS 参考此文

xoyozo 10 年前
8,187

今天终于把大量占用论坛服务器带宽的元凶找到了!

我们的论坛使用阿里云的 ECS+RDS+OSS+CDN 架构,最近发现 ECS 的带宽怎么都不够用了,也没有什么突发事件呀,再说附件都在 OSS 上。观察了云监控控制台,发现半夜里的流量也不减呀,白天更是触顶下不来,坛友们真是不辞辛劳为 PV 作贡献啊。

我对 CentOS 还是不够熟悉的,查阅了一些资料后,终于找到方向入手了。

重点肯定是日志文件了,但是面对每天几个 G 的大块头,还真是无法下手,一条一条看估计胡子都白花花了。

那么,首先安装 GoAccess 这个好东西(yum install goaccess

然后进入网站日志目录,用 GoAccess 来分析一下(goaccess -f xxxxxx.log -a),具体用法参官网

选择日志格式,nginx 默认为 NCSA Combined Log Format,空格选中,回车确认

稍等片刻就可以看到主界面了,统计信息丰富多彩,统计结果一目了然,看截图,如果你分析的日志文件是当前正在使用中的,它还会每秒刷新主界面,让你看到实时统计

大致分为几块内容:

按 1 定位到“按天访问量”

按 2 定位到“最多次被请求的 URL”

按 3 定位到“最多次被请求的静态文件”

按 4 定位到“最多次被请求的 404”

按 5 定位到“最多次请求的用户 IP”

按 6 定位到“用户的操作系统”

按 7 定位到“用户的浏览器”

按 8 定位到“按小时的统计”

按以上数字键后,再按回车可以查看具体或更多的信息,按 s 可以更换排序,按 q 返回或退出

那么我先找 5 最多次请求的用户 IP,排前面的全部是从 60.191.127.4 到 60.191.127.26 的 IP,每个 IP 都是几 G 级的带宽占用。

负责任的,你必须保证这些 IP 不是政府或大企业的对公 IP,而且得拿这些 IP 直接去日志文件里搜到底请求了哪些 URL。经查证,它们只请求版块的帖子列表页,没有请求任何图片、脚本、样式等,还有,UserAgent 中没有带 Spider 之类的关键字,证明不是搜索引擎的蜘蛛,那么就可以果断认为它“不是人”

啥都不说了,找到 nginx 的 conf 配置文件,在 server 中添加 deny 60.191.127.0/24;

检查配置:nginx -t

使配置生效:nginx -s reload

呵呵,马上就能在阿里云监控里看到过山车式的折线了。 

另外,备注下查看各IP的连接数的命令:

netstat -an|grep :80| awk '{print $5}'| cut -d':' -f1| sort |uniq -c

xoyozo 10 年前
5,375