灰产-如何破解请求验签（下）

写在前面

再来个前情提要：灰产-如何破解请求验签（上）

以下都是情节模拟，并非具体情况，请细加甄别

阿哈！Showmak……啊不，是新的 Sign 替换后不久就，两周左右就又被破解了呢——

“我们新的加签，可是从多个随机数池取值生成的 sign1，然后把sign1和多个参数混合在一起按时间戳不同取模排列生成的sign2，怎么可能……”

啊，虽然很想吐槽这反派一般被反击了感叹自己部署被打乱了的感觉，但是来不及为已经逝去的 sign2 感到悲伤了，接下来赶到战场的是……

是我这个苦力！

我打灰产？真的假的？要上吗？

总而言之

总而言之，在解释了旧 Sign 是怎么泄露的后，调查新 Sign 是怎么泄露的这个任务又又又落到我这里了= =，已经不想吐槽了

实现漏洞

“怎么实现的……额，实际上我们等于是接了一个生成库，你可以理解为类似SDK，里面有各种 Sign1 和 Sign2 的实现方式，什么移位啊取模啊都多久前的了，我都快忘了，你想看的话文档给你你可以看一下”

“有没有可能是这个实现的模块泄露了或者可以被调用啥的？”

“我觉得没有吧，感觉也有可能是 Hook 了，但就不知道是怎么弄的”

然后直到最后我除了在研发显示屏上看到了一眼实现文档，我再也没看到那实现方式一眼了

摸索开始了——

首先通过请求日志我发现，灰产用到的 sign1 有一批量重复的（说好的随机池随机取呢），但是生成的 sign2 是不重复的（sign1 只作为一个参数参与生成 sign2 的计算），我们并没有对 sign1 进行校验，所以导致这个 sign1 可以在请求中被替换，重复利用。

顺带一提的是，在其他应用里很早就出现这个情况了，不是我的话都还没发现……

定向Hook

sign1 的问题因为没有校验可以重复利用解决了，那 sign2 呢？

前端没有找到泄露 sign2 计算点，因为前端都可能没用新的 Sign；

应用端源码没看到 sign2 的计算方式，因为做了较好的混淆；

……

那选择就只有一个了！（折断拐杖）

对它使用 Hook 吧！

早在 MobSF移动安全测试框架|自动化静动态app分析框架 的使用中，我就接触了 Frida，why？因为一开始装不上，并且因为种种原因（MobSF 自带证书冲突等）执行动态分析的效果很差，虽然后来还是能试出来。

扯远了，回到现在，利用 Frida 对应用进行 Hook，我是在 Genymotion 上做的，当然，由于应用配置的关系，你可能需要先：

• 进行 ARM - X86 的转换才能跑起来应用，低版本 Android 不可运行要换成高版本转译：Genymotion_A11_libhoudini
• 高版本 Android 可以开启 SSL pinning 等，需要 Magisk + TrustMeAlready ：How to install Xposed/EdXposed/LSPosed + Magisk with Genymotion Desktop?
• 安装 Frida：brida从0配置

这里就要说了，为什么涉及到 Brida？

因为一开始是想用 Brida 直接 Hook 调用函数，传到 BurpSuite 直接修改请求，但是后来发现你根本不知道是哪个函数计算 sign2 ，别说改了，Hook 都不知道 Hook 谁，怎么办？

java.security.MessageDigest

还记得旧 Sign 最后的加密算法吗？SHA1-Hash

再看看新 Sign，尤其是 sign2 的样式，分明也是 SHA1！

嘛，灵光一现：不如利用 js 跟踪“java.security.MessageDigest”的调用，并输出加密入参与之后的值，js 参考：

• 安卓逆向 - Frida Hook（抓包实践）
• Frida java层自吐加密算法

入参值反解出来是一堆字节码，需要用 java 重新转一下回去：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

public class exchange {
   public static void main(String[] args) {
       byte[] b = { 108, ……, 102,
               105, ……, 105,
               111, ……, 107,
               45, ……, 61,
               50, ……, 52,
               32, ……, 117,
               115, ……, 118,
               105, ……, 110,
               118, ……, 73,
               70, ……, 78,
               74, ……, 85,
               85, ……, 108,
               107, ……, 107,
               45, ……, 110,
               61, ……, 48,
               67, ……, 45,
               116, ……, 112,
               61, ……, 104,
               73, ……, 57 };
       String s = new String(b);
       System.out.println(s);
   }
}



Output:
……data={"userId":"……"}……sign1=GORNJPBOGXJXZQRRKYKYZNGZXZSYOUUSCMCM……timestamp=1714030269543……

sign1&timestamp

ok，入参也出来了，现在只剩一个问题：sign1 在入参中的位置。

其实到这里直接去遍历都可以，但是我还是采集了几份 sign1 在 sign2 生成位置与 timestamp 的关系进行比对，然后发现比对了个寂寞——差一位数的时间戳里 sign1 的插入位置可以相同的 = =：

所以不整了，收工！

写在后面

下篇也写完了，感觉好像也就这样，后续把加固啥的弄上议程吧，不然好像还有些硬编码问题也是头疼，但还要验证一下效果。

沉默，然后……事已至此，先吃（pao）饭（lu）吧

参考引用

灰产-如何破解请求验签（上）

MobSF移动安全测试框架|自动化静动态app分析框架

Genymotion_A11_libhoudini

How to install Xposed/EdXposed/LSPosed + Magisk with Genymotion Desktop?

brida从0配置

安卓逆向 - Frida Hook（抓包实践）

Frida java层自吐加密算法

灰产-如何破解请求验签（上）

前情提要

先来个前情提要：灰产-如何对APK修改后重签

在写那篇文章的我，是否会想到我竟然还有有关“灰产”的下文来写？而且就标题来说，还有分上下两篇！所以这4个月不到的时间我又经历了什么呢？

写在前面

以下都是情节模拟，并非具体情况，请细加甄别

让我们把时间拨回到年后。

年后回来一阵子，接到业务风控同学的反馈，我们有用户发现自己的账户被盗了，自己购买了不是自己的商品（不产生金额）并对这个商品统一匿名评价……

我第一反应卧槽哥们我们应用不是做了端校验，不同设备必须验证码登录，怎么连手机一起丢了才有后面能说漏洞导致账密泄漏的事？

后面通过网关日志、应用日志、接口日志等排查，发现这个用户的登录凭证（token）有从境外服务器请求服务的情况，可以基本确认是 token 的泄漏；

再和用户沟通以及进一步的深入排查，我们发现 token 的泄漏源于用户被钓鱼，这里细节不表；被社工得到的 token 会先从 ip 1 被收集并转发给 ip 2 进行购买请求与评论……

这里涉及到一个问题，我们的请求在各端做了验签，Sign 参数会根据不同端走不同的计算方式，想要更改 token 并发起购买请求，不重新计算 Sign是不可能通过校验的，只有两种可能：

• 我们的 Sign 计算方式被破解
• 我们的 Sign 计算方式可被任意调用

总而言之

总而言之，这个任务又落到我这里了= =

会议讨论对齐的时候，研发一致认为是在 H5 端的 Sign 计算方式太简单了，如何计算已经被破解，应该换上现在端上更安全的 Sign 计算就可以了！

直接破解一个计算方法理论上是不太容易的，我更在意的是是否是哪个地方泄漏了 Sign 的计算方法，或者在什么地方的计算代码可以被调用，直接入参入值然后得到结果。

但这里就要提到另一个事情了，研发不告诉你！

他们只表述这个好像比较简单就能破，但问他们怎么破的，不知道；问他们在哪里可能泄漏了，不知道：

“大概是从前端 JS 泄漏的？你看我们这里都做了混淆了，你看是不是就是这个位置，sign 关键词都命中了……”“可是为啥我调试/下断点没反应啊？”

后来嘛，在把钓鱼的口子堵了一下后，换上“更安全”的 Sign 计算方式后，喜闻乐见的钓鱼的口子也被绕过了，“更安全”的 Sign 计算也被破解了……

然后呢？

遭殃的还是我好吧，本来他们都认为可行的解决办法没用的时候，我就不得不花时间和精力来看看不在我 OKR 上的问题了

泄漏发现

算研发很配合安全工作，虽然告诉了我一个错误的泄漏位置，但起码提醒了我可能是 JS 就已经泄露了，没必要一来就去逆向找源码。

开始的思路还是去利用前端给到的 JS 复用：Burp Suite作为代理，复用目标站点的js代码处理指定的内容

后来发现 JSFlash 必须要能够指定调用代码函数才行，前端 JS 混淆了，指向不出来，直接分析不了

然后我就在前端登录页 Source - js 找到了 Sign 计算点，并且下断点步进调试看到了所有 Sign 的计算入参：

它端验证

在前端 JS 调试的过程中能看到有一个 secret 参数是不会暴露在 request 里的，其他端的如何获得？

Jadx 逆向反编译一下应用端，以 SIGN 为关键词，在源代码中发现了硬编码在其他端使用的 secret，以及使用的 Sign 最后加签算法：

写在后面

上篇就到这里，写的好像很简单，解过程也没遇到什么麻烦，但是还得说和大伙配合的还是不好，我还是认为不管是锻炼或者检验个人能力也好，工作任务忙不想接手深入这个事情也好，如果是以把事情完成的结论来说，相互配合是很重要的。

以旧 Sign 为例，大家说的好像每个人都知道这个是怎么生成的，但就是没人和你说，告诉的还是错误的位置，即使真的可能知道是怎么生成的不知道是在哪里泄露的，那信息汇通还是更重要的。研发完全可以告诉你“我猜是在前端 JS 泄漏的，位置是在这里，他的调用是这样的……”给你演示出来，如果真的在前端直接 Debug 下断点走一遍，就会知道一开始的位置告诉错了，并且一下就把泄漏点找出来了。

不会浪费双方的时间的。

参考引用

灰产-如何对APK修改后重签

Burp Suite作为代理，复用目标站点的js代码处理指定的内容

灰产-如何对APK修改后重签

写在前面

前段时间没有事做的时候，组织上仿佛看穿了我很咸，突然让我去研究下灰产包，让我分析用了什么技术&做出了什么改动。

总而言之

虽然入职就听说了公司应用之前有被灰产“薅羊毛”的问题，但真让我弄我也没专门弄过啊，而且这部分之前是交给风控组去做的，这么久了整不来靠我嘛？而且我也想吐槽这灰产包你们又是怎么弄来的，还有两份不同技术实现的……

签名篡改

如果想对apk内部内容进行修改，从而达到实现某些功能或规避某些审查的目的，就一定要对签名进行重签，这一点上只需要和正版签名比对一下便能发现。如何检测使用了这些篡改应用的用户等不在这次的任务范围内，篡改功能点内容也不展开讨论，此处仅讨论绕过审查重签的技术。

MT APP签名检查及绕过

对灰产包简单的逆向后，我在第一个包很快地就发现了一个KillApplication.java：

很显然，做篡改的兄弟还不够细，或者根本没懂相应的原理性知识，留下了如此明显的痕迹，并且在URL参数直接暴露了篡改方式：

ApkSignatureKillerEx

算是让我直接回忆起之前用过的MT管理器，好像酷安就能下到，不过我已经很久没用过了，不知道MT现在是自带这种签名方式还是作为外部插件使用的。

而MT APP签名检查及绕过在Android逆向-获取APP签名 一文中有详细表述，在此不做赘述（懒）

NP APP签名检查及绕过

那我们再来看下一个，啊，还不用我找，MobSF都给我翻出来了：

你是？

顺着FuckSign.java 和 2863678687@qq.com 这两个信息（痕迹也是太明显了），我找到了另一种篡改方式：

NP-Manager

直接获取下来也很容易就复现了篡改与绕过：

写在后面

首先啊，风控安全真是和什么都斗争不断，除开apk包篡改，也还有模拟GPS定位、虚拟用户接码手机号等等，还好不是我直接负责：

然后，之前文章提到过外网可能是MobSF官方开的一个在线检测的平台，直接暴露了非常多的检测应用报告，无独有偶，我在做这次灰产分析的时候，在搜索引擎寻找FuckSign.java，发现了国内一个仿MobSF的在线检测平台，从搜索引擎记录来看，市场上很多其他应用也不堪灰产侵扰：

我在发现这个检测平台的时候，它给检测项部分“需要开通VIP”解锁，该说是刻意而为导致规避了部分问题还是啥呢……总之，我在几周后重新访问的时候，他已经是崩溃状态，嘛，不好评价：

最后，要做灰产黑产，就要从原理性把痕迹去除或转化，不能留太明显的技术痕迹，虽然可以说这些最后找到的都是开源项目，是卖刀者不是作恶人，但淹死的多是会水的，这里分享一篇文章：灰产，赚点快钱？。

参考引用

ApkSignatureKillerEx

Android逆向-获取APP签名

NP-Manager

Firebase Installations API 密钥硬编码

灰产，赚点快钱？

Firebase Installations API 密钥硬编码

起因

新公司让我对应用移动端产品也渗透一下，自然地想到移动端APK相关的自动化检测工具，于是Docker起了一个MobSF跑了下检测，算是做个铺垫。

当然还不如自己手动测来的漏洞直接，自动化扫描得出的结果不一定都具有直接性和威胁性，但MobSF还支持动态检测，实测下来确实能自动化访问activity事件，但每次调用Frida去执行注入测试的时候就会出大大小小的问题：

1. 目前Mac M1/M2芯片由于ARM架构的问题，还无法完全解决Genymotion跑不了ARM包的问题（Genymotion给的MAC客户端实现用的是X86架构，完全不是官方说的因为是ARM芯片就可以直接支持ARM包了，实践出真知），M1/M2可使用的系统目前只有Android11，无法打translation包
2. 很多移动应用做了SSL-Pinning等方式防抓包，需要用各种Posed去解，这些操作可能会与MobSF动态检测的模块冲突与覆盖（如MobSF动态检测会自动植入证书）

虽然对个人的工作不会带来太大的影响（又不是没有扫描器就不会渗透了），但我还是想流畅地使用一回动态检测啊，看看能达到什么层度，有这个执念在，我萌生了一个想法：

互联网上有没有别人搭建好的完整检测平台呢？

资产发现

还真被我找到一个，而且像是官方搭建的站点，此处相关域名隐去，不予展开。

作为一个安全人员，自然会考虑提交检测的包会上传存储在哪及检测内容是否会暴露的问题，于是我先下意识地访问了recent scans：

这是啥？！为什么我能看到今天所有提交检测的应用，并且可以看到完整的检测报告？！而且更哈人的是，举例应用竟然是未对外发布的内部研发版本（官网版本2.0.011 < 研发版本2.0.015），且没有做加固之类的！

这不禁让我想到了两个问题：

1. MobSF这个线上检测平台肯定是没做好权限划分的，或者从设计来说MobSF可能就没实现这点，因为一般都是在本地部署的检测平台；纵使在后台做了定期清理数据的策略，在短期内这些检测内容还是会留存下来
2. 所有被检测的应用可以被任意的人员查看，如果有安全问题很有可能线上版本也存在类似问题，而且数据泄漏就是泄漏了，在一段时间内一个访问凭证都将是有效的，即使你知道它已经泄露，会因为你不知道多少功能调用用到了这个凭证而不敢直接替换

那么这个应用里有什么呢？

API Key泄露

直接上图，这些码应该够了吧：

除了显而易见的google_maps_key 外，apk内还硬编码了firebase_database_url、google_api_key、google_app_id、google_storage_bucket 等敏感参数（有些是我直接获取源包找的），firebase_database_url 直接访问果然无权限，但是剩下的几个参数是怎么调用的？能获得什么信息呢？

首先猜测和存储空间有关，但不对，Google Cloud并不是用这样的参数类型请求访问的；那既然存在firebase_database_url，会不会和Firebase有关？一番文档翻找下，我大致了解了Firebase是啥，还有一部分的API调用，并知道了相关的API Key是在什么位置被生成又用于何处的：

之后要做的事情就简单了，构造一个请求，就可以获取到与Firebase服务器交互许可的凭证了：

之后的操作就不做了，扩大影响面应该很容易，所以为什么要演奏春日……啊不对，为什么要把应用程序的报告暴露在公开检测平台！

参考引用

Deploy an application - Desktop User Guide

How to install Xposed/EdXposed/LSPosed + Magisk with Genymotion Desktop?

管理 Firebase 安装

排查初始化选项问题

QQ群名称改动的一些小问题

写在前面

别问我为啥最近更博客更这么勤，首先我得承认，确实新公司在我试用期的时候没有安排很多复杂的活给我干，虽然这样，但也不代表我每天能产出或者转载这么多文章，毕竟都是技术文章，都要自己看过理解再push上来的，每天有这么多时间吗？

前段时间没有，这段时间有了= =

因为临近年关，加上推进DLP和其他安全服务都阻塞在了钱上，导致最近我甚至能在Copy之于，写几篇这样的原创文章，分享下杂七杂八的技术来了。

但说实话，不论是转载来的文章还是自己原创的文章，都是比较久前接触到的知识了，也就是即使我是现在写出来的，接触我所描述的技术也是在大半年前甚至一年多前了（比如下文），每次写博客就是这样把旧东西重新捡拾的过程，有点像中学时期的错题本，常看常新，再看再新……

所以这不算是在工位上摸鱼哦，是增长技术积累，嗯，一定是这样。

问题二则

其一：讨论组的实现与群聊不同

读者要说了：你这是废话

之前在QQ创建讨论组和创建群的方式就不一样，实现上不一致是很自然的事情，但是在作者写这篇文章的时候，QQ已经把“创建讨论组”这一功能下线了，所有的讨论组理论上也都自动转群了。

那么这个时候，讨论组转成的群和直接创建的群有什么差异吗？毕竟现在看起来一摸一样，转换后的群是重构了实现还是直接被套了个群外壳？

任意群成员可修改群名

在讨论组内，大家的权限划分是较为统一的，或者可以理解为没有做好权限划分，在转群后群成员仍被赋予了较高的权限，如：在只有一个群主的讨论组转群里，即便其他群成员不是管理员也可以随意修改群名（甚至可以扩展到其他信息）：

而对于直接创建的群来说，群名称是无法被任意群成员提交修改的：

其二：QQ客户端群名称修改注入

对于第一个问题，大家肯定会说这有啥，连个越权都算不上，利用不起来，顶多整蛊无辜群主，钓鱼诈骗都难利用起来，无意义，忽略了！（很像是SRC漏洞审核员会脱口而出的话呢）

那么，如果我顺着这个思路，触发一下客户端的注入，阁下又该如何应对？

首先可以看出QQ的客户端（包括TIM）在PC和移动端对群名称修改的实现不同：对于同一个POC，移动端将闭合字符后续的代码段全部解析，PC端收到POC的影响进行了三次群名称修改且名称不同，第一次修改可能也将闭合字符后续的代码段解析。

具体实现和步骤无，只是记录下自己发现的小问题，这个点能触发什么利用也在此不做讨论。

[Linux]讓 curl 藉由 socks5 proxy 連線時，不要反解 DNS，造成連線失敗

本文转自Ephrain 并作补充

Proxy Server链接问题

公司的專案程式通常需要支援各種 proxy server，如 HTTP proxy, socks4 和 socks5 proxy。
今天遇到一個問題，我們的程式底層會使用 libcurl 做 HTTP 連線，但連到一台 socks5 proxy 時卻不能成功…

試著用 curl 加上 -x 選項來指定 proxy server，再加 -v 選項看看詳細的錯誤訊息：

1
2
3
4
5
6
7
8
9
10

testuser@localhost ~ curl -v -x socks5://172.22.1.1:8080 https://testdomain.com

* Rebuilt URL to: https://testdomain.com/
*   Trying 172.22.1.1...
* TCP_NODELAY set
* SOCKS5 communication to testdomain.com:443
* SOCKS5 connect to IPv6 2600:1417:1b:184::23ac (locally resolved)
* Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
* Closing connection 0
curl: (7) Can't complete SOCKS5 connection to 0.0.0.0:0. (1)

可以看到訊息裡有一行 locally resolved，這行代表的是 curl 自行去查詢了 DNS，將 testdomain.com 的 IP 找出來，但因為 curl 使用的是 Happy Eyeball 的演算法，同時會發出 Type A 和 AAAA 的 DNS request 封包，因此如果 AAAA 的 DNS 回應封包先回來的話，就會拿到 testdomain.com 的對應 IPv6 位址，反之如果是 A 的 DNS 回應封包先回來的話，拿到的則是 IPv4 位址。

下面用 Wireshark 觀察一下 curl 產生出來的 DNS 封包，它送出了 A 和 AAAA 兩種 DNS 封包，以下例來說是 A (IPv4) 的回應先回來，但這個結果會依據網路狀況而有所不同，有時候是 AAAA (IPv6) 的回應先回來：

curl 自行查詢 DNS 這件事情有什麼錯誤嗎？
以這個例子來說，curl 幫忙查出 testdomain.com 的 IPv6 位址 2600:1417:1b:184::23ac，然後連線到 socks5 proxy 172.22.1.1，叫它連線到這個 IPv6 位址去。
然而，這台 socks5 proxy 所在的網路只設定了 IPv4 位址，所以 proxy server 本身是無法藉由 IPv6 位址來連線的！
因此它自然無法連線到 curl 指定的 IPv6 位址，導致連線失敗…

要解決這個問題，可以叫 curl 不要雞婆自己去查 DNS，而是讓 proxy server 自己來查 DNS，因為 proxy server 自己知道所處的網路環境，像是它不能連 IPv6 網路時，自然不會去問 Type AAAA (IPv6) 的 DNS 結果。

我們將原本的 socks5://: 改成 socks5h://:，代表要讓 proxy 自己的查詢 DNS，可以看到 curl 直接連到了 proxy server，沒有先做 DNS 查詢，而最終 proxy 也成功完成了連線：

1
2
3
4
5
6
7
8
9
10
11

testuser@localhost ~ curl -v -x socks5h://172.22.1.1:8080 https://testdomain.com

* Rebuilt URL to: https://testdomain.com/
*   Trying 172.22.1.1...
* TCP_NODELAY set
* SOCKS5 communication to testdomain.com:443
* SOCKS5 request granted.
* Connected to 172.22.1.1 (172.22.1.1) port 8080 (#0)
...
* Curl_http_done: called premature == 0
* Connection #0 to host testdomain.com left intact

不過這種雷，幾乎是每次整合一個用到 libcurl 的模組，就會再踩到一次啊…

我遇到的场景

首先，我没想到我会被台湾同胞的这篇技术博客教到很有趣的东西，其次，博主的语言和繁体配合起来更有趣了，也基于尊重保留了完整原文

公司做安全监控平台收敛内网后，外部主机关联内网服务器的数据，需要监控进程 agent 以走代理的方式进来
自然代理服务器的公网地址和内网地址不在一个网段，然后为了安全性，代理服务器内网地址虽然和监控服务器同一网段，但由于安全组的隔离两者是不能直接访问的……(´◐∀◐`)

代中代(´◐∀◐`)

很自然的 curl 即使走代理都找不到身处内网的监控服务器域名
我只能在代理服务器 host 上配一下域名解析，然后翻了许久找到了 curl 的代理访问方式原理，就是这位博主的文章，让我明白了可以让 Proxy Server 去做 curl 的进一步内网解析
泪目，乙方厂商技术整半天都解决不了的问题，后来和我说我给的命令，其他客户也有这种问题的不能装的也能装了，让我找他们销售要钱草w(“▔□▔)

希望两岸互相少点偏见吧

向阳行（Towards The Sun）

首先我得解释，我直到2023年1月17日，也就是除夕前几天，我还在更新另一篇斯卡蒂的赏金猎人之旅（SRC） 的内容
只不过一直没有push到博客上，包括现在写的这篇，今晚写的4篇，很大原因是数据传输的问题

要知道，在大公司，对员工的数据信息管得很严，要进行审查，我写的东西有很多涉及到漏洞细节
上次我把移动硬盘接电脑，里面有我的博客环境和写的文章，吓了领导一跳，以为我在拷数据啥的

那没办法，真不是我懒，不让搞啊！而且确实工作到没有时间……（那你为什么又开始写了呢？）
……
这就问得好了，“暑期大作战”开始了，周二周四都要加班到21点，周六还可能要来上班
我不想晚上继续加班，就做点自己的事情吧，晚上工作效率很低，真的
……
其实我真的搞不懂，一个人把自己全部精力投入在早上的8h里，效率真的不低了，还需要额外时间，是希望他早上8h不再那么专注，鼓励摸鱼吗？然后把东西放到晚上做？
（那肯定不是，是希望你继续做，做的更多）
那不就违背了多劳多得？甚至多劳少得、不得

所以望眼欲穿，开始思考自己的下一站；
所以望眼欲穿，期盼时间快快来到年关

这篇文章叫“向阳行”（Towards The Sun），是因为在写完这篇时，刚好随机到Rihanna的《Towards The Sun》，好一些的翻译自然是“逐日”，但是不想如此。

CSDN 不登录查看全文

闲谈

土豪：“CSDN 有点恶心啊，什么代码要登录复制，查看全文也要登录，有没有什么插件方法直接能看的？”

同事：“它这个是这样设定的，肯定要走一步这个流程给他们增加访问量还有用户啊……”

我：“……”

默默拿出方案

1
2
3

<div id="article_content" class="article_content clearfix" style="height: 2000px; overflow: hidden;">
修改成：
<div id="article_content" class="article_content clearfix" style="height: XXXXpx;">

每天一个没用小技巧 (´◐∀◐`)

雪糕角度

午饭小憩时，看到公司商业区小卖部的冰柜望而却步 (lll￢ω￢)

今天学习 SRC 相关内容的时候，看到 DoS 的引例视频Commonly Misunderstood Bugs: DDoS & DOS 中，Michael Skelton 说：
“你报告的漏洞不能只影响你的个人账户，还要想办法能够影响到其他的用户”
想来很有道理：潜移默化或不择手段地影响他人，才是标准，才是正确思路，这甚至比单独破坏企业设施更有意义。

QQ 移动端访问控制策略小窥

起因

今天在学习 SRC 发掘的时候，看到很多介绍文章其实在 Hackone 上就有应用例，然后看到一篇需要权限访问的文章，遂要求登录。

还没有个人账号，于是注册一下，到最后一步得到一个邮箱确认链接：

由于是公司电脑，没有装额外通讯软件，遂在手机 click，果不其然被 QQ 拦截了（这个做的真的不行）：

于是我把链接 copy 到 PC 上，重新访问，结果弹出该链接已经被使用了的页面，并且可以要求 Resend：

推测

我顿了一下（柯南 BGM）：这个确认链接（token）已经被访问，只有可能是我刚才手机 click 了 button 导致的，也就是发送了请求（request），但是没有收到正确回应（response）。

即 TX 是帮你请求过一次链接的（说好听点是帮你，说不好听就是劫持= =），他拦截的只是响应包。

• 这样会有两个问题：

1. 服务端是否是不分情况就去请求了这个链接的，如果换做是其他小公司的服务端这个策略应该是有问题的。
2. 你是按照什么来判断网站不合规的？证书？白名单？响应包内容？
   如果是证书，很多 http 链接就会被误报；如果是白名单，那么不需要放行请求（request）就可以判断并拦截；如果是响应（response）内容，为什么 Hackone 还是拦了？

验证

在朋友（无中生友）的提醒下，发现可以用 dnslog 一试就能验证是否是进行了请求而拦截响应：

其实我都不用打码，反正一个是 TX 的 ip，一个是电信的移动 ip

结语

也就是小小发现而已，或许还火星了，记录一下
PS：微信现在还没有拦截限制好像，从那个上面倒是可以直接访问链接