AuthorFeei

硬编码密钥存在什么风险？ 密钥暴露面越多，风险就越大 密钥硬编码在代码中导致的直接结果就是代码在哪里，密钥就在哪里。研发人员电脑上存在密钥，如果电脑被攻击则密钥也会被泄漏。其次研发人员会因为没有安全意识，将代码上传至各类私有云盘或家里电脑又或是U盘中，导致风险面增大。更有甚者，将代码上传至GitHub，而忽略了代码中的硬编码密钥，从而被恶意着利用，比如我曾经发现的控制某云厂商全部管理权限。 攻击者拿到硬编码密钥后攻击成本较低 攻击者无论通过什么方式拿到你代码，首先就会去看硬编码密钥部分，尝试去利用这些代码中的明文密钥，比如存在邮箱密码则会去尝试登陆你的邮箱进一步渗透挖掘邮件中有价值的内容，有FTP账号密码则会尝试连接FTP挖掘FTP Server中有价值的文件。 硬编码意味着你不会去变更它...

通过搜索引擎、Google HTTPS证书透明度、流量代理、GitHub搜索、DNS域传送、crossdomain.xml、DNSPod、DNS查询爆破等方式来枚举子域名，并DNS服务商公布的子域名数据加上通用字典和其它子域名爆破工具的字典结合起来使用Python Asyncio协程和多进程快速的枚举子域名。

大纲 漏洞背景解决思路制度为辅技术为主内外网隔离实时监控技术方案最佳实践收集特征实践例子了解搜索特性有利于特征收集告警与响应漏洞告警实践‌ 漏洞响应实践误报与漏报误报‌漏报‌漏洞处理找得到作者找不到作者漏洞现状与未来 漏洞背景 GitHub作为开源代码平台，给程序员提供了交流学习的地方，提供了很多便利，但如果使用不当，比如将包含了账号密码、密钥等配置文件的代码上传了，导致攻击者能发现并进一步利用这些泄露的信息，就是一个典型的GitHub敏感信息泄露漏洞。 ‌ 解决思路 制度为辅...

无论是SRC还是HackerOne，发现可简单直接利用的漏洞越来越少，结合业务逻辑漏洞越来越多。之前文章提到需要基于甲方视角来建设扫描器，传统的黑盒扫描器不理解业务。一顿操作猛如虎，结果逻辑都没进。比如一个提现接口的SQL注入漏洞需要满足可信设备、行为可信、二次认证等前置条件，传统扫描器可能第一步都没通过，如何能发现漏洞，发现不了也就罢了但很有可能说漏洞不存在。满足业务前置条件还能有好的方案去实现，但如果遇到更贴近业务的越权、逻辑绕过类的漏洞就难以发现了。本文不讨论发现，主要从杜绝漏洞出现的角度，重新提下这个古老但简单有效的缓解水平越权漏洞方案。...