前言

最近有在看多方 webrtc 的解决方案: 多方 webrtc 的选择, 后面觉得 SFU 应该是不错的解决方案，而目前开源的 SFU 框架有好几个:

• Janus
• Jitsi
• Kurento
• mediasoup
• Medooze

后面打算一个一个用下，看看效果， 所以本次先用 Kurento 这个框架看看效果。

前言

我们通常用的 webrtc 技术其实是一对一的 call，也就是 peer to peer。

ClientA 和 ClientB 如果能够顺利建立 P2P 的连接，则可直接通过 P2P 互相交换数据。如果由于某些网络环境原因，无法成功打通 P2P 连接的话，则可以通过一台 TURN Server 来中转数据给对方。

但是有时候我们会有一对多的情况，比如视频直播之类的(视频直播还有另一种技术: 推流 rtmp - cdn)， 甚至是多对多的情况，比如多方会议。 这时候是没法满足的。所以我们需要对 webrtc 技术延伸出 一对多，甚至 多对多的 架构形式。结合网上的资料 (以下的资料和总结大量参考了文章底部列出的参考资料)。 要实现多方的 webrtc，有以下三种选择：

• Mesh
• MCU
• SFU

前言

有时候在使用 docker 容器的时候， 容器会默认没有安装 vim， 比如前段时间我在测试 kerento 的时候，要在容器中修改某一个配置文件，然后再重启，这时候在修改的时候，就会提示:

1
2

root@f596838cdaaf:/etc/kurento/modules/kurento# vim WebRtcEndpoint.conf.ini 
bash: vim: command not found

这时候就会提示 命令不存在。 这个是因为在创建 docker 镜像的时候，并没有把 vim 也放进去， 其实这个是非常常见，因为很多的 docker image 的创建都是基于那个最白版的 Ubuntu 系统，那个里面就没有 vim 命令，只有一些最基础的，比如 ls, cat 之类的，我们可以去 /bin/ 查看一下，当前所支持的 shell 指令:

前言

因为自己的团队会定期进行好文好站的分享，发现一些文章或者站点非常有意思，又能学习，又不会枯燥，所以就记下来备忘一下。后续要学习或者推荐的时候，可以直接从这里拿

教你设计模式的神奇站点

推荐理由: 学不会设计模式，是因为你还没用过这个神奇的网站。图文并茂的方式讲设计模式，个人觉得这种方式更加利于记忆，也更加有趣。网站有包括中文在内的五种语言翻译，以及八种编程语言的代码示例

玩游戏也能写 git

推荐理由: 如果你觉得学习 Git 很枯燥，那是因为你还没玩过这款游戏！什么？玩游戏也能学git？是的，亲测简单又有趣，学习效果还真好，十分炫酷。大家一起来通关吧。

为什么这么设计系列文章

推荐理由: 很多技术人员耳熟能详的基础知识，但是你有深究为啥要这么设计吗，比如为啥 js 中 0.1 + 0.2 不等于 0.3 吗? 为什么 Mac 地址不需要全球唯一 ? 为什么总是需要无意义的 ID ? 这些设计理念当初都是怎么来的 ? 这个是一个开始看就停不下来的站点

前言

作为一个站点，肯定少不了那些好心的 researcher 给你的站点或者服务提出各种各样的安全缺陷, 让你去修改，并且适当的给他们一点奖励。 所以如何评价安全漏洞的危害性就显得很重要, 毕竟你也不希望一个小安全问题就给一大笔现金奖励吧，钱多也不是这么花的。 而且除了对安全漏洞评分之外， 还需要根据不同的危害性给予不同的奖励。 比如我们就是以 CVSS 3.0 标准来对安全漏洞进行级别划分，并且根据以下级别进行奖励:

1. 无危害性 –> 0 –> 没有奖励
2. 低危害性 –> 0.1 - 3.9 –> 我们产品的一年 vip 使用权限
3. 中危害性 –> 4.0 - 6.9 –> $xxx 现金奖励
4. 高危害性 –> 7 - 10 –> $xxxx 现金奖励

接下来接下来讲一下 CVSS 3.0 是一个怎么样的标准:

前言

前段时间一位好心的白帽子发了一封邮件过来:

1
2
3
4
5
6

Hi team,
    I found another potential bug on your site.
    Description
    The application fails to prevent users from connecting to it over unencrypted connections. An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection. The sslstrip tool automates this process.
    
    To exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defences such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.

大意就是说我们的站点虽然有强制 https 请求，但是并没有添加 Strict-Transport-Security，所以有可能会遭受 SSL 剥离攻击。 建议我们赶紧加上。

最后 POC 附上 hstspreload 检测截图

前言

前段时间，有位好心的白帽子给我们发了一封邮件，讲了一个关于 A 标签target=”_blank”的安全问题:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Hi team,

I am security researcher and i found this vulnerability in your website  
https://www.example.com/en/

Vulnerability report:  Tab nabbing
`
Issue lies Here :

< a class="item-social-icon item-social-icon-twitter" href= "http://twitter.com/#!/Team" target="_blank" data-type="footerNav-goTwitter" >

Here i can see you are using target=_blank and no more rel tag.
Here , target=_blank means it will open in another new tab but due to tab nabbing it can change parent tab as well .

FIX & MITIGATION :
To mitigate this issue we need to use rel="nofollow noopener noreferrer" as follows:

吓的我赶紧检查了一下，这个问题确实存在，我发现官网的部分外链的 A 标签是通过 target="_blank" 来跳转的，所以就会存在这个安全问题。 万幸的是， 我们官网的外链大部分都是我们自己的内部网站。只有少部分是真正的外链, 比如 facebook，Twitter， YouTube 我们的主页，不过这些大的站点一般也不会太大的危害，但是当务之急还是将这些外链的这个安全问题修复一下。

前言

之前有个好心的白帽子有发了一个邮件过来:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

i am a security researcher and i founded this vulnerability in your website.

I have found that you are leaking via the referrer the reset password link. I am attaching the photo as proof of concept that the site is indeed leaking the reset password link via the referrer.

Proof of concept:       
图片1
图片2
图片3
    Thats when someone loads the reset password link and decided to click on external links.

Impact

Password Reset Token will be leaked by the Server to that third party site and that token can be used by third parties to reset the password and take over the account.

Thanks

他说我们的忘记密码功能的重置密码链接，会加载第三方统计，这时候带过去的 referer 头部就会将这个页面的 url 带过去，从而暴露了重置密码的 token。

分析

我分析了一下，发现重置密码这个页面，确实在加载第三方统计的时候，referer 头部会将整个 url 当做值带过去, 也就是这些第三方程序是可以在用户进入这个重置密码页面的时候，通过 referer 头部来得到这个重置密码的链接，比如下图：

前言

最近一直有在处理一些安全问题，其中有几个是跟重置密码链接相关的安全问题， 所以就想谈一谈关于重置密码链接的几个安全问题，包括以下几个情况:

1. 刷忘记密码接口使其一直发送邮件
2. 第三方站点的 referer 头部泄露重置密码链接
3. 发送新的重置密码链接的时候, 并没有将旧的重置密码链接设置为无效
4. 重置密码链接用过之后并没有马上设置为无效
5. 登录密码长度没有限制
6. 重置密码成功，其他端的 session 就要全部设置为过期。 客户端要重新进行登录
7. 修改邮箱的时候，要将未失效的重置密码邮件都设置为无效
8. 重置密码的校验接口，要做速率限制

因此我们在设计这个功能的时候，一定要严防以上情况。

前言

前段时间一个好心的白帽子，发了一封邮件告知我们的某一个站点可以被其他第三方站点内嵌，会有点击劫持(Clickjacking)的风险, 事实上关于 Clickjacking 这个安全问题，之前我就在 web 页面防iframe嵌入（防止点击劫持Clickjacking） 写过怎么处理了， 无非就是加上 x-frame-options 这个头部， 不过那时候出问题的那个站点是部署在我们的服务器的，是用 nginx 的，所以在 nginx 的配置上加上:

1

add_header X-Frame-Options "SAMEORIGIN";

就可以了。 但是这次的站点比较特殊，所以他是有 CDN 加速的，而且是如果是在国内访问的话，用的 CDN 加速是网宿的， 国外访问的话， 用的 CDN 加速是 AWS 的 cloudfront。 当然无论是国内还是国外，获取的源都在 aws 的 S3 上。 所以如果要添加 x-frame-options 这个头部，那么无论是 网宿 还是 cloudfront 都要加。

前言

前段时间运营那边有个需求给开发， 之前运营那边有做了一个购买 2-3 年订单的优惠活动， 导致很多用户都买了这个活动。 但是后面发现这些用户中，有很多用户本来就是我们产品的 vip 用户，而且本身就有循环订购我们的产品。 也就是说，虽然我们在后台给他们加了 2-3 的 vip 的时限，但是因为这些用户本身就有循环订阅，导致 vip 还没有用完的时候， 下一个循环周期就扣费了。 这样子就会对用户的权益造成影响。 所以运营那边希望开发将这些用户找出来，并且将这些循环订单进行延迟结算，一直到用户本身的 vip 快到期的时候，才重新激活循环订阅，使其重新扣费。

我们现在的循环订阅的支付方式有 3 种， PayPal, Stripe, google iap。所以要针对这三种方式的循环支付进行额外的处理。

前言

前段时间有一个很神奇的需求，因为 cacti 的业务预警需求，我要在一个表内， 找到 5 分钟之内， 得到连接失败的去重复的设备数的数量和所有连接的去重复的设备数的数量， 然后得到 5 分钟内，按照唯一设备的失败率是多少，用一个 sql 表示。

处理

前言

前段时间有位好心的白客有发了一封邮件过来，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

Hi team, 
    
    this time i founded this vulnerability in your website.
    
    Vulnerability 9 : No csrf on login 
    
    Level : critical
    
    Login form is not protected against Cross Site Request Forgery.
    An attacker can craft html page containing POST information to have victim sign into an attacker's account, where the victim can add information assuming he/she is logged into the correct account, where in reality, the victim is signed into the attacker's account where the changes are visible to the attacker.
    
    The real issue here, is that when the victim runs the html Proof of Concept, the account is logged in to attacker's without any visible warnings, thus the victim is capable of theft of data and potentially vulnerable to account takeover.
    ...

简单的来说，就是虽然我们其他的业务接口都有 csrf token 的令牌校验，但是那是建立在用户登录后的情况下才下发的。 而恰恰登录接口是没有 csrf 校验，所以具备 CSRF 安全攻击的隐患，让我们赶紧修复。

修复问题

之前我们就非常重视 CSRF 的危害性 (具体看 web安全系列(1) - web 安全攻击和防护)，所以在用户登录的业务接口中，都会校验下发的 csrf token 令牌。如果校验不对，就认为非法请求。 但是恰恰登录接口是用来下发令牌的，所以这个接口就没有 csrf 令牌校验了。

前言

前段时间有位好心的白客有发了一封邮件过来，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Hi Team,
    
    This time I found this vulnerability in https://www.example.com/
    
    Vulnerability Type: Missing Certificate Authority Authorization Rule
    
    Description:
    
    Certificate Authority Authorization (supported by LetsEncrypt and other CAs) allows a domain owner to specify which Certificate Authorities should be allowed to issue certificates for the domain. All CAA-compliant certificate authorities should refuse to issue a certificate unless they are the CA of record for the target site. This helps reduce the threat of a bad guy tricking a Certificate Authority into issuing a phony certificate for your site.
    
    The CAA rule is stored as a DNS resource record of type 257. You can view a domain's CAA rule using a DNS lookup service:
    
    
    https://dns.google.com/query?name=example.com&type=A&dnssec=true    
     
     
    Vulnerable Location: https://caatest.co.uk/example.com
     
    ...

简单的来说，就是我们的站点并没有添加 DNS CAA 保护。 具有被中间人劫持的风险。 不过确实是这样子，那时候确实并没有为我们的站点添加 CAA 的 DNS 记录，这个是他的站点检测截图：

前言

前段时间有让 DBA 归档了一些数据库表，有包含统计表，也有包含一些业务表。 当然对于统计表来说，是会有定时归档的计划任务的。 不过这些事情一般都是由 DBA 来做，在请教了一下 DBA 之后，我也整理了一下 mysql 的数据库表的一些归档策略。

通用的归档逻辑

一般是以下面的图为例:

假设归档大表 A, 操作的过程大体分为 3 部分：

1. 生成只有原表 A 的表结构的空表 A_temp (ps, 这里有一个 id 自增长的 AUTO_INCREMENT的值的问题, 下文会分类说明), 这时服务端还是访问表 A
2. 对原表 A 和 A_temp 进行 rename 操作: A -> A_timeA, A_temp -> A, rename 操作会对相关的表加表级别的锁, 这个操作的时间很快(而且因为会锁表，所以也不用担心在这个过程 A 表会有入数据或者更新数据), 这时服务端访问的是新的表 A (也就是原来的空表 A_temp)

3. 因为归档时间范围问题, 一般我们需要将一些数据补偿回到新的 A 表中, 补偿的方式为分批执行:

   1	insert into A ... select ... from A_timeA WHERE ...

4. 归档 A_timeA 表，并且删除掉一些中间表(回补的时候，会涉及到将一些数据先存放到中间表)

前言

早在之前，有收到一个白客的邮件，说我们发送电子邮件的域名缺少安全检查，让我们最好补上对应的安全检查：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

I'm an independent cyber security researcher i have found multiple issues in your website.

Vulnerability : Missing SPF 


I am just looking at your SPF records then found following. SPF Records missing safe check which can allow me to send mail and phish easily any victim.

PoC:

<?php

$to = "VICTIM@example.com";

$subject = "Password Change";

$txt = "Change your password by visiting here - [VIRUS LINK HERE]l";

$headers = "From: https://karve.io";

mail($to,$subject,$txt,$headers);

?>
SPF record lookup and validation for: xxx.com

后面检查了一下，发现确实是这样子，我们的电子邮件没有加上对应的安全检查，很容易被别人冒发，从而有可能对我们的用户造成严重的电子邮件欺诈。

发送欺诈电子邮件的危害

举个例子，黑客可以通过这个站点 emkei.cz 来冒充我们的官方 support 邮箱来发送一些钓鱼邮件给用户。如果用户信以为真，那么就会对用户的利益造成损失，这就是电子邮件欺诈

前言

虽然在之前的文章有写过，怎么在 windows 7 上通过 docker 来实现多个 golang 环境, 并使用了 Go Module:

• windows7 通过 docker 来实现多个 golang 版本并存
• 初试 Go Module

但是事实上在本机进行开发的时候，还是本地环境装的 golang 环境开发起来更方便 (macOS 还好，差别不大，但是 windows 7 的 docker 实在不怎么友好)， 所以就打算将本机环境的 golang 版本升级到 1.13 版本。

升级 golang 版本

查看了一下，发现本机环境装的 golang 还是 1.7.6 这个版本，太老了

1
2

F:\airdroid_code\go\src\resque-worker-server>go version
go version go1.7.4 windows/amd64

前言

前段时间在小组轻分享中，有成员分享了 <项目百态> 这本书的其中一章 <巨神阿特拉斯>, 由于找不到电子版，所以就手动扫描了 这一章 的 pdf 版本, 这章后面提出来一个问题，有一位万能的，包打天下的领导，对团队来说，是福是祸 ？ 肯定是福，但要防止变成祸。本节描述了这样一个场景，并表明福变为祸的原因。不过，本节并没有提出明确的建议，让读者自己去思考。

思考

本来有这种领导对于下属来说是一件非常幸福的事情，但是一定要警惕，千万不能有 “溺爱” 现象，否则就会出现 “巨婴”。正是因为他太万能了，反而影响下属们的自然成长规律，尤其是下属的领导力和管理经验。总的来说，就是不懂得放权，或者是说是不舍得放权。而这就是祸。

对于这一点，我倒是挺有感触的，我接触技术管理也有 3-5 年了。对于放权更有感触，总结这几年的管理上的成长，我最感谢我领导的地方就是他懂得对我放权，允许我通过犯错误来得到成长。当然有一个很重要的前提就是，不要犯愚蠢的错误或者重复犯错。可以犯经验错误，但是有且仅有一次。

前言

之前有时候要紧急调试线上服务器的代码，一般都是用 Xshell 4 等工具，远程登录到服务器，然后直接用 vim 编辑代码。但是对 vim 语法不够熟练，而且有些代码比较长，显示也不太方便。 如果可以像本地 IDE 那样子显示服务器上的代码，并且直接编辑，实时保存就好了。后面找了一下，发现 vscode 配合他的一个插件 remote ssh， 就可以实现这个功能。

安装

做开发的应该没有人不知道 vscode 的吧，号称前端开发神器。 配合各种各样的插件简直无往不利。 首先去 这边 下载一个，因为我是 windows 7 的。所以就下载 windows 的版本了。

前言

通过 初试 Go Module 我们已经能够使用 Go Module 来安装项目的依赖包。 接下来我们试一下我们正式线上的项目，会有没有问题。

映射 ssh 文件夹

我们将一个叫做 resque-worker-server 的项目，放到容器中的共享目录 /go/src/ 中，并初始化 mod:

1

go mod init gitlab.airdroid.com/airdroid_background/resque-worker-server

然后接下来就直接构建 go build, 但是发现报错了: