安全研究员 Landon 发现了一个新披露的 7-Zip 漏洞，编号为 CVE-2025-55188。该漏洞的 CVSS 评分为 2.7，影响 25.01 之前的版本，可能允许攻击者在提取存档文件时执行任意文件写入操作——在某些情况下可能升级为任意代码执行。 根据报告，“在 25.01 之前的 7-Zip 中提取恶意制作的存档文件允许任意文件写入，可能导致任意代码执行。” 该问题源于在提取过程中对符号链接的处理不当。7-Zip 在解压存档文件时会跟随符号链接，这意味着恶意存档文件可以将提取的文件指向预期目录之外的位置——覆盖系统上的关键文件。 漏洞利用需要特定条件： Linux – 任何在 25.01 之前版本的 7-Zip 上运行的用户，提取支持符号链接格式的存档（如 .zip、.tar、.7z、.rar）都会受到影响。 Windows – 漏洞利用是可能的，但较为困难。提取过程必须具有创建符号链接的权限，可能在以下情况下发生： 7-Zip 以管理员权限运行。 Windows 处于开发者模式。 启用了其他特殊权限。 一旦触发，攻击者可能会覆盖敏感文件，如 SSH 密钥或 .bashrc，从而留下持久后门或执行命令。 虽然 CVSS 2.7 的评分可能表明严重性较低，但如果攻击者可以控制存档文件的内容和目标的提取环境，其影响可能很严重。Landon 警告称，“在一次提取过程中，攻击者可能多次尝试利用此漏洞写入敏感文件。” 此类攻击可能： 破坏安全外壳 SSH 认证。 修改启动脚本以实现持久化。 篡改配置文件以绕过安全控制。 修复已包含在 7-Zip 版本 25.01 中。用户应： 立即从官方 7-Zip 网站更新至 25.01 或更高版本。 避免从不信任来源提取存档文件。 处理未知文件时使用沙盒或隔离环境。 相关文章: CVE-2025-0411: 7-Zip 安全漏洞可导致代码执行 – 立即更新 7-Zip 中的两个漏洞可能触发拒绝服务攻击 7-Zip CVE-2025-0411 的 PoC 允许攻击者绕过 MotW 并运行恶意代码 CVE-2025-0411: 针对乌克兰的攻击中利用了 7-Zip 漏洞 CVE-2022-29072: 7-Zip 权限提升漏洞

原文：Hijacking OAUTH flows via Cookie Tossing 译者：madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 我们最近在瑞士苏黎世的Area41会议上展示了我们的 GitHub Action 研究。在会议的第一天，Thomas Houhou 进行了一个有趣的演讲，介绍了如何利用 Cookie Tossing 攻击来增强 Self-XSS 问题的影响，使其变得值得报告。这次演讲非常精彩，展示了一些新颖的 Cookie Tossing 在劫持多步骤流程中的应用。作为一种技术，Cookie Tossing 常常被忽视或不为人知，关于这一主题的发表内容也很少。 我们希望扩展目前有限的研究，看看 Cookie Tossing 攻击还可能导致哪些额外的影响。我们发现，Cookie Tossing 可以用来劫持 OAUTH 流程，并导致身份提供者（IdP）的账户接管。 什么是 Cookie Tossing? Cookie Tossing 是一种技术允许一个子域名（例如 securitylabs.snyk.io）在其父域名（例如 snyk.io）上设置 cookie。在我们查看一些问题场景之前，先来了解一下 HTTP cookie 是什么。 什么是 HTTP cookies？ 根据 RFC 6265 的定义，Cookie 是服务器与用户的网页浏览器之间交换的一小段数据。这些 Cookie 对于网络应用至关重要，因为它们能够存储有限的数据并帮助维护状态信息，从而解决 HTTP 协议固有的无状态特性。通过 Cookie，用户会话可以持续，偏好设置可以被保存，并且可以提供个性化的体验。

本文首发于安全客平台，https://www.anquanke.com/post/id/266237 笔者作为某公司的安全开发独自一人负责安全运营平台的开发，经过数个月的折腾以及其他安全同学的合作，目前该平台已经运营了几百个安全漏洞以及一些安全事件，其它一些安全能力也在慢慢地接入中。在之前的公司，笔者也是作为安全工程师负责平台架构部门的安全运营，当时我们也有几个开发来负责安全运营平台的开发。安全运营平台其实可以作为一个公司偏向应用安全的基建之一，或许可以将它看做偏向于应用安全的 SIEM。所以，基于本文，也想分享一下在安全运营平台建设和开发的过程中的经验。在整个建设过程，开发工作只是一部分，体系的建设和实现也不可或缺，所以很多做法也是需要结合公司的实际情况，并一定就能够完全通用。 开发 安全运营平台的开发技术选型其实和其它后台业务类型的系统并不会有太大的区别。目前大多数应用系统都是采用前后端分离的方式，前端大多数是类似于 vue-admin 类型的技术方案。后端框架见仁见智，选择适合内部开发的语言即可。笔者之前最早实习的时候就是干前端开发的，后来干安全也是经常会写安全工具的代码，所以常用的语言也是都略懂一些，所以也就扛起了这个平台的开发工作。 最初的技术选型是想选择 gin-vue-admin，这是个前后端分离方案。后端基于 go 的 gin 框架，前端是和 vue-admin 比较类似的前端方案。这个轮子用起来不错，有很多开箱即用的功能，权限方面管理也非常方便。不过最终还是没有采取这个方案，因为内部的大多数应用都是基于内部自研的 go 微服务框架，其部署运维也与该方案息息相关。如果不使用内部的框架在部署方面则会麻烦很多，考虑到后期的运维，最终还是选择了基于内部的微服务框架开发。不过，这样做的最大的问题就是学习成本，因为这个内部框架与外部的 web 框架差异较大，而且作为安全的唯一开发也是两眼一抹黑，只能跟在开发大佬后面跪舔，才慢慢把应用的雏形搭建起来。前端框架比较简单，主要是基于 element 的 Vue 框架。 其实在开发过程中要说技术难度有多大也不见得，和其它的业务系统其实没有太大的区别。主要就是各种和头发丝一样琐碎细小的业务需求，所以开发过程就好比把这些头发丝一根根捡起来捋直了，所以有时候也是比较痛苦的过程。前端的用户体验和设计也是痛点之一，本身安全在开发就比较缺乏，尤其是设计方面。不过安全运营平台主要面向的也是内部的用户，主要就是安全工程师和开发，所以和面向外部客户的应用相比，要求也会稍微低一点。 需求建设 对于安全运营平台的大致规划是按照下面的框架来进行划分的，大多数公司的安全运营平台也会比较类似。安全运营平台的核心是应用安全的运营，漏洞管理作为安全运营平台的核心之一，也往往是安全运营平台被开发所熟知的方面之一。另外一方面就是集成各种安全工具的数据，包括像扫描工具，包括 SAST 以及 DAST 的扫描，将这些数据能够转换成实际的漏洞来推动。 漏洞管理 漏洞管理作为安全运营平台的最基础的一方面，同时也是其核心。漏洞的本质其实也是一个 bug，只不过它被赋予了安全这一属性，摇生一变被称为漏洞。那么漏洞自然就和开发日常处理的 bug 会稍微有一些不同。Bug 的处理流程相对来说会简单一点，测试把 bug 提给开发，开发确认之后修复完成，测试验证通过就可以了。安全漏洞的处理过程其实也是基于这一个过程的演化，这也是因为安全漏洞的特殊性，安全漏洞是一种特殊的 bug。一方面，安全漏洞的机密性要求更高，漏洞的可见范围越小越好，一般仅限定为要处理的人及它的直属领导，而不是任意一个人都可以查看漏洞，这样也是为了避免万一有人通过漏洞信息来进行利用。另外一方面，漏洞的处理流程相对来说会更复杂一点。在现实业务中，可能会有各种各样的场景。正常来说，一个应用应该具备测试环境、UAT 环境、生产环境。漏洞应该在之前的环境中被验证通过后，再进行下个环境的验证，这样的好处也是避免一开始就没有修复，导致返工，也降低了风险。但是往往也有不少应用并不同时都有这些环境，比如第三方采购的应用，一般都没有前两个环境，大多数是布在生产上的。也有的应用可能也没有 UAT 环境，就只有测试环境和生产环境。我们的做法是有提供两种模式给开发选择，开发可以选择默认模式，则这三种环境都有，开发也可以选择不带 UAT 环境的。针对于只有一种环境，我们的做法是把主动权交给安全工程师，安全工程师在复测完成后可以直接关闭漏洞，不过这个的弊端就是有时候安全工程师忘记直接关闭这个漏洞。 漏洞在被确认之前可能还有一些例外情况，包括像漏洞的忽略以及漏洞的接受。漏洞的忽略主要是漏洞的一些误报，这个主要是安全工程师可能对于业务有些了解还不充分导致的一些信息差，另外还有就是有些漏洞可能就是正常的业务需求。漏洞的接受则是这的确是一个漏洞，但往往漏洞修复非常困难，或者漏洞修复对业务的影响非常大，但是漏洞的危害程度没有达到高危及以上的那种程度。其实对于这种情况一般有两种处理，一种就是安全把漏洞提给开发，但是开发就是不太愿意修复这个漏洞，这个漏洞状态就一直保持着，如果哪天开发憋不住了，或者状态场景发生了变化，他们就完成了这个漏洞的修复。另外一种情况就是业务方接受漏洞并且不修复，这种可以理解为风险接受。其实在 CISSP 中的风险管理中就有这样的概念，如果采取安全措施的代价大于资产的实际价值，那么业务方可以选择接受风险。不过对于这种情景，是需要经过业务方领导的审批，确保业务方能够明确意识到这个漏洞潜在的风险。 漏洞另外一个重要的内容就是和资产的联动。一个成熟的 cmdb 对于安全来说真的太重要了。因为这可以帮助安全迅速的定位到明确的责任人，从而确保漏洞的及时修复，其实这也涵盖其它的安全内容，包括像安全事件，甚至在安全应急响应中，好的 cmdb 对于安全来说真的非常重要。不过，安全往往不是作为 cmdb 的第一责任人，一般 cmdb 的运维职责是落在运维方，安全起到的作用是反馈和治理。安全在使用数据的过程中，及时反馈，从而帮助数据修正，这样达到一个良性进化的过程。 事件管理 事件管理和漏洞管理也不太相同，所以事件管理的流程会被单独作为另外一个流程来进行管理。事件不同于漏洞，它往往也没有上文提到的各种的环境。事件的处理往往也是一个点对点的过程，安全工程师确认了安全事件，将事件上报给对应的处理人，处理人处理完毕，安全工程师验证没有问题，安全事件就可以关闭了。目前的安全事件的功能还是比较弱化的，主要还是用于事件的处理流程。不过未来事件流程最重要的方面是和其它安全平台的对接，包括与 SIME、IDS 等安全产品对接，并且能够将事件直接分发给对应的处理人，提高事件的处理效率。 安全能力 作为安全运营平台，SAST 以及 DAST 也是作为应用安全重要的补充能力。SAST 以及 DAST 市面上都有很多成熟的产品，也有很多公司采取自研方案。对于这两种产品最重要的能力就是数据的打通，如何将这两种产品扫描出来的漏洞直接转化为实际有效的漏洞。前期对于这种漏洞比较好的处理方式，可能是先同步数据，然后安全运营平台作为一个审核平台，这些数据经过安全工程师的审核和加工，有效的数据将转化为漏洞进行上报。另外一个重要的方面就是组件成分分析，这也是近几年非常火的一个概念。因为目前的软件开发都是大概率依赖于第三方组件，不管是商业的还是开源的、前端的、后端的以及各种语言的，这些组件的风险都有可能会对你自己应用带来风险。做好应用的组件分析，知道应用的依赖关系，能够快速地在紧急安全漏洞爆发初做到较快的响应处置。当然，这些都建立在资产都能够与这些信息打通的基础上，这样才能做联动响应，根据资产去盘点漏洞，同时也能够根据漏洞去看哪些资产受影响。 安全运营平台除了这些大的方面，其实也有很多细节方面需要考虑。比如像漏洞级别的定级，不同级别的漏洞对应着不同的威胁程度，那么其要求的修复时间也是不相同的。对于漏洞的响应时间应该是按照自然日来算的，因为攻击者并不会因为是休息日就鸣金收兵的。对于漏洞的定级，其实业界有一个比较成熟的定级模型，叫做 DREAD，即：

富文本编辑器是一个常见的业务场景，一般来说，通过富文本编辑器编辑的内容最终也会 html 的形式来进行渲染，比如 VUE，一般就会使用 v-html 来承载富文本编辑的内容。因为文本内容需要通过 html 来进行渲染，那么显然普通的编码转义不适合这种场景了，因为这样最终的呈现的效果就不是我们想要的了。针对于这种场景，显然过滤是唯一的解决方案了，不过过滤其实可以在后端和前端都是可以做的，后端做的话，一般是在数据存储在数据库之前。前端做的话，则是在数据最终在页面渲染之前做过滤。 前端的过滤方案，可以尝试使用开源的 [js-xss](https://github.com/leizongmin/js-xss)。先介绍一下这个库的使用方法，这个库可以在 nodejs 中使用，同样也可以在浏览中直接引入使用。 // nodejs 中使用 var xss = require("xss"); var html = xss('<script>alert("xss");</script>'); console.log(html); // 浏览器中使用 <script src="https://rawgit.com/leizongmin/js-xss/master/dist/xss.js"></script> <script> // apply function filterXSS in the same way var html = filterXSS('<script>alert("xss");</scr' + "ipt>"); alert(html); </script> 一般在 vue 的项目中，通过 webpack 也可以直接通过 CommonJS 的方式引入，与 nodejs 的引入方式基本一致。值得注意的一个问题是，默认情况下会去禁用 style 属性，这样会导致富文本的样式展示异常，需要禁用 css 过滤或者使用白名单的方式来进行过滤。 const xssFilter = new xss.FilterXSS({ css: false }); html = xssFilter.process('<script>alert("xss");</script>'); const xssFilter = new xss.FilterXSS({ css: { whiteList: { position: /^fixed|relative$/, top: true, left: true, }, }, }); html = xssFilter.process('<script>alert("xss");</script>'); 其实 js-xss 的原理并不是很复杂，如果去扒一下源码，原理其实主要就是实现标签和属性的白名单过滤，这样的方案简单有效。因为默认配置了大部分标签以及属性的白名单方案，所以一般可以做到开箱即用，当然如果有定制化的需求需要进一步定制化函数。

GShark has beem maintained for alomost two years as an open source sensitive infomation detection tool. This tool is utilized in my own company and sparetime, multi information sensi GShark 作为一款开源的敏感信息监测工具其实差不多维护也有两年多的时间。这款产品其实笔者在自己的公司或者平常都在使用，也通过这个工具发现多多起内部的信息泄露事件以及外部的一些的信息泄露事件。其实这种类似的开源工具数不胜数，大家的核心功能其实就是监控 Github 上面的信息，但是笔者要想把这种产品做得更好一点，就要从功能性、易用性角度来做进一步拓展。最近，对 GShark 做了较大的重构，前后端都完成了比较大的重构，之前老的版本也有写过文章介绍，所以关于这个工具的起源就不多介绍了，主要对这次重构和新的架构做介绍。 架构 目前 GShark 已经是一个前后端分离的项目，之前因为前端通过后端模板直接渲染的，所以在前端的功能性以及美观性都会差很多。新的重构是基于 gin-vue-admin，技术栈是后端通过 gin 实现，前端通过 vue-elemment 来实现。 所以架构主要就分为前端和后端两个部分，而后端则分为 web 服务以及敏感信息的扫描服务。新的架构具有以下特点： 细粒度的权限控制，更好的安全性，包括菜单的权限设置以及 API 的权限设置 丰富的前端功能，CRUD 更简单 搜索源和之前保持一致，支持 github, gitlab 以及 searchcode 部署 之前就有想使用 GShark 的同学来和我反映，其实之前的编译就已经很简单了。但是因为有些人不太熟悉 go，所以觉得编译还是有一些问题。这一次，笔者专门写了一个脚本来发布三个操作系统下的工具包，所以直接使用即可，开箱即用，即使你不安装 go 也无所谓。 rm -rf ./releases/* cd web npm run build cd ../ # build for mac cd server GOOS=darwin GOARCH=amd64 go build cd ../releases mkdir gshark_darwin_amd64 cd gshark_darwin_amd64 mv ../../server/gshark . cp -rf ../../server/resource . cp ../../server/config-temp.yaml config.yaml cd ../../ cp -rf ./web/dist ./releases/gshark_darwin_amd64 7z a -r ./releases/gshark_darwin_amd64.zip ./releases/gshark_darwin_amd64/ # build for windows cd server GOOS=windows GOARCH=amd64 go build cd ../releases mkdir gshark_windows_amd64 cd gshark_windows_amd64 mv ../../server/gshark.exe . cp -rf ../../server/resource . cp ../../server/config-temp.yaml config.yaml cd ../../ cp -rf ./web/dist ./releases/gshark_windows_amd64 7z a -r ./releases/gshark_windows_amd64.zip ./releases/gshark_windows_amd64/ # build for linux cd server GOOS=linux GOARCH=amd64 go build -o gshark cd ../releases mkdir gshark_linux_amd64 cd gshark_linux_amd64 mv ../../server/gshark . cp -rf ../../server/resource . cp ../../server/config-temp.yaml config.yaml cd ../../ cp -rf ./web/dist ./releases/gshark_linux_amd64 7z a -r ./releases/gshark_linux_amd64.zip ./releases/gshark_linux_amd64 rm -rf ./releases/gshark*/ 这个是 build 的脚本，主要是实现跨平台的编译并且将前端文件夹打包进去，然后拿到这个安装包解压即可使用。目前 GShark 的发布应该只需要两个前提条件：

正如题目，本文的也很直白，主要就是围绕这个问题展开。JavaScript 能否修改 Referer 请求头？现在 JavaScript 的能力越来越强大，JavaScript 似乎无所不能，修改一个小小的 Referer 请求头似乎看来不在话下（本文讨论的 JavaScript 仅限于在浏览器中执行，不包括 Nodejs）。 其实不然，在 web 浏览器中，绝大多数浏览器都禁止了 JavaScript 直接去操作 Referfer 请求头，当然这一方面也是出于安全方面的考虑。当然除了 Referer 请求头之外，还有其它请求头也被禁止通过 JavaScript 操作。 Referer 请求头属于 Forbidden header，这种请求头无法通过程序来修改，浏览器客户端一般会禁止这种行为。以 Proxy- 和 Sec- 开头的请求头都属于 Fobidden header name，还包括以下这些请求头： Accept-Charset Accept-Encoding Access-Control-Request-Headers Access-Control-Request-Method Connection Content-Length Cookie Cookie2 Date DNT Expect Feature-Policy Host Keep-Alive Origin Proxy- Sec- Referer TE Trailer Transfer-Encoding Upgrade Via 可以通过一段简单的 demo 来进行验证。可以通过 Chrome 的开发者工具来进行验证，创建一个 xhr 请求，并且尝试来设置请求头。 可以看出，如果设置 content-type，浏览器没有阻止，但是如果设置 Referer 的话，浏览器则不允许，提示 Refused to set unsafe header "Referer"。

原文：微软 open sources CodeQL queries used to hunt for Solorigate activity 译者：madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT Solorigate 攻击的一个关键方面是供应链攻击，这使攻击者可以修改 SolarWinds Orion 产品中的二进制文件。这些经过修改的二进制文件是通过以前合法的更新渠道分发的，并允许攻击者远程执行恶意活动，例如窃取凭据，提权和横向移动，以窃取敏感信息。该事件提醒组织不仅要考虑是否准备好应对复杂的攻击，还需要考虑自己代码库的弹性。 微软坚信以透明的方式进行领导并与社区共享情报，从而改善整个行业的安全实践和状况。在此博客中，我们将分享审查代码库的过程，重点介绍一种特定的技术：使用 CodeQL 查询来大规模分析我们的源代码，并排除存在代码级别的危威胁情报（IoCs）和与 Solorigate 相关的代码模式。我们正在将本次本调查中使用的 CodeQL 查询开源，以便其他组织可以执行类似的分析。请注意，我们在此博客中介绍的查询仅可用于查找与 Solorigate 植入程序中的源代码具有相似之处的源代码，无论是在语法元素（名称，字面量等）还是功能上。两者可能在良性代码中同时发生，因此所有发现都需要进行审查以确定它们是否可行。此外，不能保证恶意行为者在其他操作中被约束为相同的功能或编码风格，因此这些查询可能无法检测到与在 Solorigate 植入代码中看到的策略有明显差异的其他植入代码。这些应被视为只针对攻击审计技术的一部分。 长期以来，微软一直采用完整性控制来验证分发给我们的服务器和客户的最终编译二进制文件在开发和发布周期的任何时候都没有被恶意修改。例如，我们验证编译器生成的源文件哈希是否与原始源文件匹配。尽管如此，在微软，我们仍然秉承 “assume breach” 的理念，该理念告诉我们，无论我们的安全实践多么勤奋和广泛，潜在的对手都可以同样地聪明并拥有大量资源。作为 Solorigate 调查的一部分，我们使用了自动和手动技术来验证我们的源代码，构建环境以及生产二进制文件和环境的完整性。 微软在 Solorigate 调查期间的贡献反映了我们对 Githubification of InfoSec 中描述的基于社区的共享愿景的承诺。为了保持我们对防御者知识的了解并加快社区对复杂威胁的响应的愿景，微软团队在此次事件期间公开透明地共享了威胁情报，详细的攻击分析和 MITER ATT＆CK 技术，高级狩猎查询，事件响应指南以及风险评估工作簿。微软鼓励其他安全组织开源自己的威胁知识和防御者技术来共享 “Githubification” 愿景，以加速防御者的洞察力和分析。如前所述，我们已在 https://aka.ms/solorigate 上收集了全面的资源，以提供有关攻击的技术详细信息，威胁情报和产品指南。作为微软全面调查 Solorigate 的一部分，我们检查了自己的环境。正如我们之前所分享的那样，这些调查发现有少量内部帐户存在活动，并且一些帐户已用于查看源代码，但是我们没有发现任何对源代码，构建基础结构，已编译的二进制文件或生产环境进行任何修改的证据。 CodeQL 入门以及微软如何使用它 CodeQL 是一种功能强大的语义代码分析引擎，现在已经是 GitHub 的一部分。与许多分析解决方案不同，它在两个不同的阶段工作。首先，作为将源代码编译为二进制文件的一部分，CodeQL 建立了一个捕获编译代码模型的数据库。对于解释型语言，由于没有编译器，因此它将解析源并构建自己的抽象语法树模型。其次，该数据库一旦构建，便可以像其他任何数据库一样反复查询。CodeQL 语言是专用于构建可轻松从数据库中选择复杂的代码条件。

原文来自于安全客，https://www.anquanke.com/post/id/217301 终于收到了 Offsensive Security 的官方邮件通知最终结果，我的 OSWE 之旅也算是尘埃落定。打算以本文回顾一下自己的 OSWE 的准备过程，包括 AWAE 课程的学习和准备以及我在考试过程中踩得一些坑，希望对 OSWE 有兴趣的人能有所帮助。 初识 AWAE Offsensive Security，作为安全圈的人应该都熟悉这家公司，Kali 就是他们家的。他们家最广为人知的课程也是 Pentration Testing with Kali Linux(PWK)，其对应的考试为 Offsensive Security Certified Professional(OSCP)。我最初结识 Offsec 也是通过 OSCP，认识了一些考 OSCP 的小伙伴，结果一直因为没(bao)有(ming)准(fei)备(tai)好(gui)，迟迟没有报名。结果大佬们一个个都通过了，报名费也从799美元涨到了999美元。 所以，当 AWAE 去年年末打折的时候，我毫不犹豫的就报名了。因为相对于 OSCP 来说，我也更喜欢 OSWE，因为自己毕竟是开发出身，对于代码审计也很感兴趣。疫情期间，的确有更多的时间可以看课程。有一个建议就是，当你的 lab 开始之后，可以第一时间就预约考试，因为 OSWE 相对来说考试可以选的场次更少，越早越好，一共有3次可以重新预约考试的机会。Lab 结束之后，我也一直拖了好久，主要当时认识了几个小伙伴考试都失利了，所以我也没啥信心。最后还是硬着头皮预约了考试。 AWAE 课程 AWAE(Advanced Web Attacks and Exploitation) 是一门关于应用安全的审计课程。AWAE 经常被拿来和 OSCP 的 PWK 来进行比较，官方也有暗示 OSWE 是 OSCP 的进阶版本，OSCP 注重于漏洞的利用，而 OSWE 则更进一步，侧重于市从白盒角度去审计代码，发现安全漏洞。不过 OSCP 并不是 OSWE 的先决条件，有人认为必须先考 OSCP 才能考 OSWE，这是不正确的。因为我就没有报考 OSCP 直接考的 OSWE。不过，另外一方面，如果你通过了 OSCP，对于 OSWE 绝对是有帮助的。我也在考试过程中体会到正因为我缺乏 OSCP 的经验，导致我犯了一些低级错误。

最近 Burp Suite 社区有在收集赏金猎人对于新手的一些建议。其实，相对于国外来说，国内的白帽子的生存环境还是比较恶劣的，和国外相比，国内的白帽子的生存环境还需要进一步提高。如果想全职在中国做一名白帽子还是比较困难的，但国外全职的白帽子就比较多。自己其实在安全方面也不能算老手，之前也不是做安全挖洞出身的。自己当初第一个提交给 SRC 的漏洞还是在内网做代码审计发现的开源框架的 XSS 漏洞，当初是阿里和大众点评各一个。虽然漏洞不值钱，但当时还是比较开心的。后面也都是偶然发现的一些信息泄露，SRC 的项目也没怎么做过，不敢和那些挖洞大佬比。他们收集的一些建议我觉得有的还是非常有价值的，而且 Burp Suite 社区真的算是业界良心，且不说 Burp 作为每个安全工程师必备工具之一，他们出品的 Web Security Acedemy 简直就是业界良心，这么优秀的应用安全学习资源，居然还免费！！！ 理解过程 脚本小子一时爽，一直当，一直爽。这个其实不一定是好的，对于新手来说，建议可以关注一种漏洞类型，然后深入挖掘，并且可以在一些项目中尝试去挖掘。 @0x1ntegral 专注某种特性类型漏洞 阅读这种漏洞类型的报告 在项目中寻找这种类型漏洞 当你找到一个漏洞，更改漏洞类型并重复步骤 1 @Troll_13 不要把事情过度复杂化。可以先做一些容易理解的，即使你的第一份漏洞赏金比较少，后面比较多的赏金会让你更开心。 探寻未知领域 这其实是一个对于挖掘漏洞的一个比较通用的建议，一般来说，特别老的应用或者特别新的应用都是比较容易挖到漏洞的。往往有些老的应用，经常会有一些地方会被忽视掉。 永远不要停止学习 不管你是做安全还是做开发，学习对于你来说，是永远都不能丢掉的。坚持这一点可以让你在技术的世界走得更远。 @root4loot 多读文章 @shail_official 读代码，先专注于公开的部分。阅读单元测试。 坚持尝试，不要停止。使用 burp 去现实世界中挖掘漏洞。Apache 的一系列漏洞，配置错误，反射型 XSS 以及敏感信息泄露。 总结 对于安全的技术学习，实践往往非常重要。所以向 Web Security Academy, Penteserlab, Hack the Box，这种平台都非常有意义。对于挖漏洞这件事情来说，如果作为全职职业的确非常困难，但它却是安全行业的找工作里面一个非常重要的门槛。尽管我自己也是挖漏洞也很菜，希望自己以后也可以多花点时间放在这一方面，能多挖些漏洞。实在不行，混个月饼呗。 Reference https://portswigger.net/blog/finding-your-first-bug-bounty-hunting-tips-from-the-burp-suite-community

本文首发于 Freebuf 平台，https://www.freebuf.com/sectool/235587.html，转载请注明来自FreeBuf.COM Zeek (Bro) 是一款大名鼎鼎的开源网络安全分析工具。通过 Zeek 可以监测网络流量中的可疑活动，通过 Zeek 的脚本可以实现灵活的分析功能，可是实现多种协议的开相机用的分析。本文主要是将 Zeek 结合被动扫描器的一些实践的介绍，以及 Zeek 部署的踩过的一些坑。 安装 Zeek 的安装还是比较简单的，笔者主要是在 Mac 上以及 Linux 上安装。这两个操作系统的安装方式还是比较类似的。对于 Linux 而言，需要安装一些依赖包： sudo yum install cmake make gcc gcc-c++ flex bison libpcap-devel openssl-devel python-devel swig zlib-devel 这里我有遇到一个问题就是可能你的 Redhat 镜像源里面没有包含 libpcap-devel，因为这个包在可选的范围内，而内网的服务器又没有互联网连接。可以通过手工下载相应版本的 libpcap 以及 libpcap-devel 即可。 Mac 上需要的依赖更少一点，首先需要确保安装了 xcode-select，如果没有安装，可以通过 xcode-select --install 来进行安装。Mac 上只需要安装依赖 cmake, swig, openssl, bison 即可，可以通过 Homebrew 来进行安装。 依赖包安装完毕之后就可以安装 Zeek，其实是可以通过包管理工具来进行安装的，不过这里我推荐使用基于源码的安装方式，安装比较简单而且还容易排查问题。从 Zeek 的 Github Release 即可下载源码包，目前我安装的是 3.0.0 版本，注意一点是，如果使用最新的版本，可能需要 7.0 以上版本的 cmake，因为需要 C++17 的语言特性。而一般镜像源默认的 cmake 版本是4+版本，所以如果你的服务器也无法上互联网，建议可以安装 3.0.0 版本。