前言

之前我们尝试使用 yakpro-po 和 Swoole Compiler 对我们的本地化部署的 PHP 项目进行混淆加密

• 使用 yakpro-po 对 PHP 项目进行混淆加密
• 使用 swoole compiler 对 PHP 项目进行加密

接下来我们继续试用另一个扩展加密的方案 - ionCube

ionCube

• PHP Encoder 12

我们用的是 PHP Encoder 12 这个版本 (他的低版本有被破解的风险，这个版本是扩展加密版本，目前外网没有被破解的相关资讯，安全性应该靠谱)

简单的来说 ionCube 编码器将源代码编译为字节码，可以根据需要对编译后的代码进行混淆和加密，并具有以各种方式保护解密密钥的功能。

此外，Pro 和 Cerberus 版本中内置的 PHP 许可功能允许对 PHP 脚本进行许可，限制 PHP 代码可以在哪里运行以及它是否有到期时间。

前言

随着对 SEO 的越来越重视， 我们也希望我们提供的站点在加载性能上也会越来越快，越来越好。

但是本质上页面的性能加载是否优越的界限其实是相对比较模糊的，尤其是有一些站点的页面其实服务的是全球的用户，而不同地方用户的不同的网络情况又会极大的影响站点的加载速度。

举个简单的例子，在网络通达的日本和韩国，哪怕你页面写的不怎么样，但是架不住人家网络快，冲浪浏览起来就是快。 然后在印度，非洲这种地方，网速本来就慢， 就算你页面优化的非常到位，有可能还是要 load 很久才会出来 (巧妇难为无米之炊)。

所以如果要跟进和标准量化页面的性能加载问题，那么就要有一套通用的检测和分析的标准。这个标准就会涉及到几个方面:

1. 检测页面性能的工具
2. 优化页面性能的固定检测指标

前言

之前试了一下 yakpro-po 混淆加密的测试: 使用 yakpro-po 对 PHP 项目进行混淆加密

接下来我们试一下扩展加密 Swoole Compiler 的效果

Swoole Compiler

Swoole Compiler 是swoole官方推出的PHP代码加密和客户端授权解决方案， 通过业内先进的代码加密技术（流程混淆，花指令，变量混淆，函数名混淆，虚拟机保护技术，扁平化代码，sccp优化等）将PHP程序源代码编译为二进制指令，来保护您的源代码，加密技术更先进、更安全。

与 Zend Guard 等传统的PHP加密器不同，Swoole Compiler 没有软件界面，它提供了API，可将 Swoole Compiler 集成到您的打包发布平台中，完全是可编程的。Swoole Compiler 相比其他传统的PHP加密器，安全强度更高。

Swoole Compiler 使用了特殊定制的ZendVM，与普通的PHP程序运行模式有较大差异。并具有如下特性：

1. 保护程序源码：避免 PHP 源代码泄漏，避免被编辑
2. 提升性能：使用Swoole Compiler底层内置了多个编译优化器，可优化 opcode，性能比源码执行有较大提高
3. 授权管理：内置了授权管理功能，可限制PHP程序运行的机器硬件和网络环境

还有一点，就是国人开发，响应时间快

前言

之前有讨论 浅谈之 - PHP 项目代码加密方案, 所以本次我们尝试使用 yakpro-po 对我们的 PHP 项目进行混淆加密

• YAK Pro - Php Obfuscator
• PHP Parser

环境需求

因为 yakpro-po 是基于 PHP Parser 4.x 的语法解析器做的。 而 PHP Parser 4.x 库的运行环境要求是要在 PHP 7.0 以上环境才能运行， 不过混淆后的代码可以在 PHP 5.2 到 7.3 之间都可以工作。

而我们的 PHP 程序是跑在 PHP 5.6 上面的。 所以可以满足混淆之后运行代码的环境。 而且为了更直观的表现出混淆加密和针对加密文件的运行可以在不同的服务器和 PHP 环境上，本次的测试用两台测试机器来测试，这样子会显得更直观

1. 一台服务器 -> 混淆加密服务器，上面安装了 7.4 的 PHP 版本， 采用 docker-compose 安装的，参照: LNMP一键安装程序， 这一台用来混淆加密 PHP 代码。
2. 一台服务器 -> 加密文件运行服务器, 用来运行混淆过的 PHP 程序的代码，PHP 5.6 的环境， 看是否可以成功运行。

嫌麻烦的可以直接用一台，然后在各自的 docker 里面跑

前因

未来有个项目需要对客户进行远程部署交付，意味着我们的服务会部署在用户自己的服务器上，考虑到商业代码的安全性，有一些服务是用 PHP 开发的项目，PHP 这种解释性语言，其实是直接源文件显示的， 这样子其实就相当于把我们的源代码暴露出来。 这样子肯定是不行的。

所以我们要对 PHP 的代码进行加密，所以结合网上针对 PHP 加密的一些文章， 我这边再次加工自己总结了一份。

PHP 的几种加密方式

按照加密的方式来看， PHP 可以包含以下几种方式:

1. 壳”加密”

这一类“加密”包括：

• 无扩展加密：phpjiami、zhaoyuanma 的免费版本等
• 有扩展的加密：php-beast、php_screw、screw_plus、ZoeeyGuard、tonyenc 等市面上几乎所有的开源PHP加密扩展。

前言

前段时间有用 vue3 + vue-router 做了一个前端的单页面应用程序， 那时候为了让路由看起来更美观一点，使用了 vue-router 的 history 模式 (还有一种就是 hash 模式)。

1
2
3
4

const router = createRouter({
  history: createWebHistory(),
  routes
})

虽然 history和 hash 都是利用浏览器的两种特性实现前端路由，history 是利用浏览历史记录栈的API实现，hash 是监听 location 对象 hash 值变化事件来实现。

但是 history 模式因为是直接走 url 的 pathname 中，所以首次访问或者刷新的时候，都会请求到后端的服务器的。 所以后端的服务器是要适配路由的。

这时候因为是单页面应用程序，所以适配路由其实是全部回到首页，简单的来说，就是在请求路由 404 的情况下， 请求首页 index.html 就行了。

前言

前段时间在对某一个长连接的 wss 服务进行端口优化的时候， 因为原先的端口是一个不常用端口，想改成一个常用的端口，比如 tls 的 443 端口， 又因为这一台服务器已经有安装 nginx，并启用了 443 端口。

所以就采用了 nginx 转发 ws 端口， 然后变成 wss 的 443 端口。 具体可以看: nginx 转发代理 wss 和 https (目标程序是 ws 和 http)

因为 nginx 的端口转发会需要映射到服务器的可用端口，所以就将服务器的可用端口调成一个比较大的值:

1
2

[kbz@VM-16-9-centos ~]$ cat /proc/sys/net/ipv4/ip_local_port_range
1024    65000

但是只顾了这个要扩大端口号，而忘了也要调整 nginx 的最大可连接数。 导致上线之后没有多久就出现长连接连不上的情况，查看了一下 nginx 的 error log，发现:

1

[alert] 23725#0: *1972528 8000 worker_connections are not enough while connecting to upstream, client: 109.xxx.xxx.92,

解决

查了一下，确实是 nginx 的配置文件中，配置的单核最大可连接数只有 8000:

1
2
3

events {
  worker_connections 8000;
}

然后 worker_processes 是 2 核 (几个 CPU 一般就可以调用几个)， 所以 nginx 的最大可连接数就是 2 * 8000 = 16000 个， 所以一旦长连接超过了这个数量，就会报上述的错误。

所以解决的方式也很简单，后面将其改成了 50000， 配合我们的 2 核(2 个 cpu)， 最大可支持 10w 的最大可连接数 (不可能到 7w， 因为服务器本身的可转发端口就满了)

前言

前段时间我们官网要做一个活动页面， 但是活动页面是用另一个活动页域名， activity.example.com, 但是运营人员需要对外展示的落地页是以官网 www 的域名来处理，所以这时候就会需要在官网的 nginx 指向那边进行页面的代理转发:

1
2
3
4

location  /promo/student-discount {
    resolver 8.8.8.8;
    proxy_pass https://activity.example.com/promo/student-discount;
}

但是实测的过程中， 却发现代理转发的时候，报了一个 502 的错误

1
2

2022/08/16 11:58:22 [error] 2293#0: *213338285 SSL_do_handshake() failed (SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL handshaking to upstream, client: 14.xxx.1.86, server: www.example.com, request: "HEAD /promo/student-discount HTTP/1.1", upstream: "https://13.xxx.xxx.101:443/promo/student-discount", host: "www.example.com"
2022/08/16 11:58:22 [warn] 2293#0: *213338285 upstream server temporarily disabled while SSL handshaking to upstream, client: 14.xxx.1.86, server: www.example.com, request: "HEAD /promo/student-discount HTTP/1.1", upstream: "https://13.xxx.125.101:443/promo/student-discount", host: "www.example.com"

看了一下，应该是 nginx 在进行代理请求的时候，就报错了， 应该是 ssl 的握手的错误 SSL_do_handshake()

前言

之前在实作 webrtc 浏览器对浏览器的远程投屏的时候， 有发现了一种情况，就是在 IOS 下， 远程传输过来的视频流 (mediaStream), 不管是在 chrome 还是 safari 下都没有办法播放, 不同版本的 IOS 表现还不一样:

1. IOS 14 及以下，会出现只播放第一帧， 就卡住
2. IOS 14 以上， 整个视频流直接黑屏

因为是自动播放，之前的代码是这样子的:

1
2
3
4
5

video.play()?.catch(e => {
  // 刚开始初始化的时候，要禁音，不然 chrome 会报这个错误 Uncaught (in promise) DOMException: play() failed because the user didn't interact with the document first.
  video.muted = true
  video.play()
})

因为相当于也是自动播放， 在 PC 和 android 浏览器都正常，就是 IOS 浏览器不正常。

后面查了一下，发现还真是要加一个 IOS 系统特有的属性:webrtc with firebase :how to fix black screen on ios/safari

在调用 video.play() 之前，要加上这个设置项:

1

video.playsInline = true

就可以正常播放了

后面查了一下，原来在 IOS 系统上，如果要实现自动播放， 直接在标签上添加 autoplay, 或者 js 直接调用 video.play(), 是不行的。

还要加上 playsInline 属性才行， 其实就是允许视频内屏播放(没有这个属性也不一定是默认全屏播放，不过对于 IOS 来说，没有这个属性， 自动播放都不行)。

前言

前段时间，运营人员有反馈在钉钉邮箱收到我们服务的邮件的时候， 有显示一个代发 字样, 在问能不能去掉， 而且不仅仅是钉钉邮箱， 国内的 qq 邮箱， 163 邮箱，都会有这个 代发 提醒，类似于

看样子是显示 010001819d4f0433-21f905e9-ad1a-48a0-8177-9966cbc581a0-000000@amazonses.com 这个代发，跟我们实际的发送邮件的 发件人邮箱 no-reply@example.com 不是同一个域。

所以刚开始怀疑是因为这两个域不一样导致的

SES 自定义 mail from 域

可以在 SES 后台自定义这个发件人邮箱的 mail from 域，配置也很简单，这样子就配置好了

前言

这段时间一直在处理浏览器 webrtc 投屏的事情，不管是其他端(android, ios, win, mac) 投给浏览器， 还是浏览器自己投给浏览器, 都会涉及到双向语音。

在这期间有踩了一些坑， 干脆就记录一下。

webrtc 浏览器要发送语音，那就是要启用麦克风来收集音频，然后传给对方。 因为浏览器可以作为投屏的投屏端(source)，以及接受投屏的客户端(node), 这两种情况下的处理方式是不一样的，所以就分开讲。

浏览器作为客户端(node)启用麦克风将语音传给对方的几种方式

本文不是科普文，所以对于 webrtc 的一些技术，不在这边进行基础讲解

浏览器作为客户端(node)启用麦克风将语音传给对方，在我的实作中， 其实有 3 种:

前言

前段时间测试人员在测试一个新的站点的时候， 有发现在旧的 ios 上，会出现页面加载失败的情况， 会报 ssl 错误:

1

The certificate for this server is invalid.

但是在其他的比较新的 ios 或者 android 上， https 的页面又显示正常。 而且证书看起来也没有过期。

后面查了一下，因为这个站点，我们那时候用的是 Let’s Encrypt 签发的免费证书， 而这个证书在一些比较旧的系统上，比如 iOS < 10 , macOS < 10.12.1 会有证书的不信任问题。

接下来我们简单的盘一下为啥会这样子

HTTPS 和 CA 机构 (证书颁发机构)

在说到 Let’s Encrypt 这个 CA 机构之前，我们得先了解一下什么是 CA 机构。 而在讲 CA 之前，要先了解一下 HTTPS 的加密方式， 这一部分资料网上很多， 我这边长话短说

HTTPS 加密方式

前言

前段时间，有运营的同学反馈有一个不应该被 google 搜索收录的站点，被收录了， 并且在 google 搜索结果中，可以看到搜索结果。

检查 robots.txt

正常情况下，我们如果站点不想被 搜索引擎 爬虫进行收录的话， 是会在根目录下的 robots.txt 设置 disallow。

所以我检查了这个站点的 robots.txt 文件，看是否有配置这个文件，或者这个路由(有些是没有实体 txt 文件的，而是在 nginx 那边根据 robots.txt 路径来进行返回)

1
2
3

[kbz@centos156 ~]$ curl https://example.com/robots.txt
User-agent:*
Disallow: /

检查了一下，确实有配置所有的爬虫都是 disallow。 那么为啥还会被收录呢， 会不会是 robots.txt 的语法有问题?

为了检查 robots.txt 的语法是否有问题，我就采用了一些第三方工具来进行验证

1. 使用百度的 robots 工具进行验证

刚开始用 百度的 robots 工具 来检查 robots 文件是否存在以及合法性

前言

前段时间有个需求， 就是我们有做一个 web 的投屏端， 可以将另一个客户端(比如 android，ios，win，mac) 投屏到 web 站点来。 但是期间因为涉及到引流， 所以针对投屏的客户端是否在同一个局域网下要做不同的判断，如果在同一个局域网下，那么就可以免费使用，如果不是的话，就会有其他的引导。

所以我们得到客户端的 ip 地址之后，需要判断当前浏览器是否跟这一台客户端在同一个局域网下。 有几种判断方式

以下的测试数据，都是基于 chrome 98 的浏览器， 早期的浏览器可能会有不同的表现

1. 让客户端开启一个本地端口，然后浏览器去请求这个端口

最简单的方式就是让这个客户端开启一个本地端口，就是类似于 ip+port 的方式，可以是 http ，也可以是 websocket 的方式。 然后让浏览器去请求这个端口。

如果可以请求成功，那么就说明是在同一个局域网。 不过这边有几个问题:

前言

前段时间运营需要对投递发送的邮件进行更详细的追踪用户行为分析，包括邮件发送的成功率，是否有被退回，反弹，是否有被打开，以及打开之后，是否有点击邮件里面的链接，点击的是哪个链接。

其实关于在邮件里面进行用户行为分析的话，早期的话，有用 ga 的方式试过:

• 在邮件模板里面增加ga统计来统计邮件的打开率

这个的好处就是适合各种的邮件发送服务厂商， 坏处就是只能统计邮件打开率， 其他的比如退回，拒绝，反弹都不行。

不过我们用的邮件发送服务是 AWS 的 SES 服务，他其实是有匹配的邮件监控事件机制的。 甚至我们之前还结合另一个通知服务 SNS 来统计邮件的反弹率:

• AWS 的邮件发送服务 SES 订阅 SNS 来处理硬反弹邮件

本身邮件的反弹率就是邮件监控事件的一部分了，所以那时候就有 touch 到这个点了。

前言

关于 nginx 设置 CORS 跨域的事情，其实在我之前的一些文章都或多或少都有提到，比如:

• 页面跳转，浏览器地址栏地址保持不变的几种方式
• 关于 XMLHttpRequest 对象需要注意的地方

但是都没有比较详细的代码，导致我有时候要写的时候，都要自己查自己写的文章，所以就自己写一个比较通用的范例， 后面用的时候，直接抄就行了。

至于 CORS 原理就不再多说了，网上到处都是。 这边给出的通用范例要符合以下标准

1. Access-Control-Allow-Origin 我不会设置为 *, 因为除了不安全之外，还会与设置携带 cookie 的这个 Access-Control-Allow-Credentials 有冲突
2. Access-Control-Allow-Origin 会有一个默认值，但是为了对开发环境更友好，也会有一个白名单的二级域名，只要在这个二级域名下的子域名，也都是可以符合

所以具体配置如下:

前言

之前在对项目进行安全渗透测试的时候，有发现我们有一个图片上传接口，有暴露出一个 任意文件上传 的安全缺陷问题。 这个是一个高危的漏洞。

后面查了一下代码，发现原来只在前端有对上传的图片进行 图片的后缀名校验， 服务端是没有校验文件类型的。 所以如果是在 postman 中进行上传操作的话(有拿到合法的 session 的情况下)， 是可以绕过前端验证，直接上传任意文件的，包括 .php 文件。

任意文件上传漏洞描述

一般情况下文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。

文件上传本身是web中最为常见的一种功能需求，关键是文件上传之后服务器端的处理、解释文件的过程是否安全。

前言

前段时间公司有请了安全服务公司来给公司的项目做 安全渗透， 尤其是 web 应用的安全渗透。 其中可测试点非常多。

其实关于 web 安全方面， 我之前也写了一些文章: 分类 - web 安全, 但是更多的是各种的安全的案例以及对应的解决方案。好像还没有从大的方向上来总结和归纳。

所以本次我也想总结一下 web 安全渗透到底是什么，为什么要做， 以及怎么做?

什么是渗透测试

渗透测试（Penetration Test）是指安全工程师尽可能完整地摸拟黑客使用的漏洞发现技术和攻击手段，对 目标网络/系统/主机/应用 的安全性做深入的探测，发现系统最脆弱的环节的过程，渗透测试能够直观的让管理人员知道自己网络面临的问题。

前言

前段之前产品有个需求， 想要对一个申请页面的修改进行 A/B 测试, 从而判断出是哪个页面的转化率会比较高。 所以需要前端人员针对原先的 申请页面 进行 A/B 测试。

简单的来说就是:

1
2
3
4
5
6
7

用户访问的还是同一个入口: mobile-device-management-free-trial/index.html
然后 A 用户 得到的是旧页面: mobile-device-management-free-trial-old/index.html (这边为了区分，将旧页面的路由改成 old)
然后 B 用户 得到的是新页面: mobile-device-management-free-trial-new/index.html

而且还会有多语言，比如: zh-cn/mobile-device-management-free-trial/index.html
然后 A 用户 得到的是旧页面: zh-cn/mobile-device-management-free-trial-old/index.html
然后 B 用户 得到的是新页面: zh-cn/mobile-device-management-free-trial-new/index.html

然后新旧页面的各自流量是一半。

nginx ngx_http_split_clients_module

nginx 的 ngx_http_split_clients_module 可以满足这种需求，可以用来实现流量的分流 (当然也可以实现负载均衡)。 而且该模块是默认就载入的，不需要额外再载入。

前言

之前官网重构的时候，为了保证原页面的 seo 权重，就有针对一些旧页面路由进行 301 重定向到新路由。 具体看 nginx 通过 301 跳转将旧页面的 seo 权重转移到新页面上， 但是后面又提了一个新需求， 就是针对一些路由进行目录结构上的调整。

比如原先是 a.html 后面会移动到 product/a.html， 而且 html 的名称还不能变。 所以这时候从用户访问来看就是:

1
2
3

访问 www.foo.com/a.html --> 301 重定向 --> www.foo.com/product/a.html
考虑到大部分是有小语种路径的，比如 zh-cn，那么就是
访问 www.foo.com/zh-cn/a.html --> 301 重定向 --> www.foo.com/zh-cn/product/a.html

原先的方法不适用

如果是原先这种方式的话:

1
2
3

if ($request_uri ~* "a.html") {
    rewrite ^/(.*)a.html$ /$1product/a.html permanent;
}

就会发现其实重定向后的 url 也是符合这个规则的，就会导致 nginx 无限重定向。 所以这样子是不行的