前言 最近翻了一下自己的博客，感觉像是在翻一个大型考古现场。 有些文章现在看还挺有意思，有些文章则属于“当年我为什么会写这个”的系列。早期有不少内容就是学习笔记，甚至有些只是把一个小问题解决了顺手记一下。现在再把这些文章全部端上来，其实没什么意义。毕竟人总不能一直回味自己当年怎么配置环境、怎么写第一个 demo。 所以这篇文章不打算做一个完整目录。完整目录这种东西博客本身已经有了，再写一遍除了显得勤奋，其实也没啥用。这里更像是笔者给自己做一次“技术路线复盘”：哪些文章代表了一个阶段，哪些东西后来真的影响了我的方向，哪些坑虽然当时痛苦，但现在回头看也挺值。 简单来说，这篇文章不是“我的全部文章总结”，而是“我觉得还值得拿出来说几句的文章”。 安全：从看热闹到修系统 安全应该是这个博客后面最主要的内容。最开始写 XSS、CSRF、SSRF 的时候，更多还是在分析一个个具体漏洞。这个参数怎么进来的，为什么能打到页面，为什么这里能绕过，为什么框架没有兜住。那时候写漏洞文章，会有一种解谜的快感。 但写着写着就会发现，漏洞分析最有意思的地方不是 payload 本身，而是背后的错误假设。开发以为这里不会被外部访问，浏览器以为自己只负责执行规则，框架以为开发者知道自己在干什么，最后大家都觉得自己没问题，问题就出来了。 比如 XSS 这类问题，很多时候不是“不知道要过滤”这么简单，而是你要理解数据从输入到展示到底经过了多少层。富文本、模板、DOM、编码、浏览器解析，每一层都可能有自己的脾气。SSRF 和开放重定向也类似，它们会不断提醒你：系统边界从来不是你画在架构图上的那条线。 后来写 MyBatis、GORM、Kibana、Webpack 这些文章，关注点就更偏开发侧了。很多漏洞并不是因为技术多高深，而是大家太相信默认行为了。ORM 很好，框架也很好，但框架不会替你理解业务，也不会替你判断输入是否可信。这个道理听起来简单，真到代码里就不一定了。 相关文章导航： XSS 漏洞知解 123 富文本场景下的 XSS 偶遇 XSS 漏洞 跨站请求伪造（CSRF）攻击 服务端请求伪造（SSRF）攻击 白名单，被谁饶过了？ MyBatis 和 SQL 注入的恩恩怨怨 AI 审代码，靠谱吗？ 让你的SQL盲注快起来 Kibana 任意代码执行漏洞 hey,我能看到你的源码哎 黑产代码解密–利用canvas加载代码 使用浏览器作为代理从公网攻击内网 ChatGPT账户接管 - 通配符网页缓存欺骗 通过 Cookie Tossing 劫持 OAUTH 流程 安全工程：不只是把洞挖出来 只会发现漏洞是不够的。这个道理说起来很简单，但真正做企业安全的时候会特别明显。 如果一个漏洞提上去之后没人修，或者责任人不准，或者状态没人跟，或者修完没人验证，那这个漏洞和写在本子上的愿望差不多。安全真正麻烦的地方，往往不是技术本身，而是怎么把事情推进下去。 这也是为什么我后来写了 GShark、安全运营平台、被动扫描器、Burp 插件、Zeek、Qradar、SAST 这些内容。它们看起来不像单个漏洞那么刺激，但更接近实际工作。安全运营平台那篇其实印象挺深，倒不是因为技术多复杂，而是因为需求太碎。各种角色、权限、状态、通知、资产、漏洞、事件，像一堆线头缠在一起。你不把它们一根根捋顺，后面就会一直打结。 GShark 也是类似。一开始只是想监测 GitHub 敏感信息，后面慢慢就会想到 GitLab、SearchCode、权限、任务、前端体验、误报处理。安全工具做着做着，最后都会变成工程问题。工具能不能长期跑，能不能让别人愿意用，能不能降低处理成本，这些问题比写一个扫描规则更难。 相关文章导航： GShark-监测你的 Github 敏感信息泄露 多平台的敏感信息检测工具-GShark 被动扫描器之插件篇 如何写一个 burp 插件 安全运营平台从0到1 网络安全分析的瑞士军刀–zeek Qradar SIEM–查询利器 AQL SAST 测试中要测量的三个参数 CPE 获取指南 Go 的漏洞管理 考试、靶机和训练 Hack The Box、OSWE、PWK/OSCP、CISSP 这些文章，更像是某个阶段的训练记录。