Strive for lofty goals
最近看了几个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...
为什么总是被外部发现该发现但遗漏的漏洞？为什么各种黑白灰扫描器老有各种原因遗漏的漏洞？如何解决人工渗透测试带来的遗漏、效率问题？你是否也遇到这些问题，本文会讲讲我理解的漏洞发现，并基于该理论延伸的甲方漏洞发现最佳实践初探。 甲白乙黑：打破乙方思维，找到甲方优势 早期为了发现漏洞需要手工一个个参数去尝试各种Payload，后来用黑盒漏洞扫描器来逐渐替换掉那些重复性的手工操作。我们总在说，不知攻焉知防，但现实所见全是用攻的思维做防。白帽子们进入甲方开始建设企业安全时，也自然而然把黑盒漏洞扫描器搬了过来，甚至作为主要漏洞发现手段。...
客观面对结果，哪怕获得0失分也并不代表做得好，并不代表能防御国家级有组织的黑客队伍，有可能是被分到有软柿子的组，攻击队为获得更好的积分排名不一定会盯着你不放。此外客观来看，虽然防守方会被多个攻击队攻击，但同样每一个攻击队的目标也是多个，会导致他的精力有限无法发挥出全部效果。同时防守方一般会为了比赛，做大量的防御工事，其中还会有很多临时性手段，比赛结束可能就拆除了，平时的黑盒可没有这些限制，企业的安全水位想要再上一个台阶，达到常态化HW水平是必然趋势。 为避免不必要的麻烦，下文用实战攻防赛代替HVV。本文仅代表个人想法，和所在公司无关。 实战攻防赛是将小概率安全事件常态化的赛场，双方在既定规则下进行博弈与演化，攻击方为争夺第一而明争暗斗，防御方为抵消攻击者不对等的优势而不断进化建设理念，双方源源不断的从场中汲取经验作为新能量，帮助我们认知实战、理解实战，进而应对实战、掌控实战。...
第一章 总则 第一条 为规范银保监会监管数据安全管理工作，提高监管数据安全保护能力，防范监管数据安全风险，依据《中华人民共和国网络安全法》《中华人民共和国银行业监督管理法》《中华人民共和国保险法》《工作秘密管理暂行办法》等法律法规及有关规定，制定本办法。 第二条 本办法所称监管数据是指银保监会在履行监管职责过程中，依法定期采集,经监管信息系统记录、生成和存储的，或经银保监会各业务部门认定的数字、指标、报表、文字等各类信息。 本办法所称监管信息系统是指以满足监管需求为目的开发建设的，具有数据采集、处理、存储等功能的信息系统。 第三条 本办法所称监管数据安全是指监管数据在采集、处理、存储、使用等活动（以下简称监管数据活动）中，处于可用、完整和可审计状态，未发生泄露、篡改、损毁、丢失或非法使用等情况。 第四条 银保监会及受托机构开展监管数据活动，适用本办法。...
作为面试者如何做一场完美面试？作为面试官如何识别面试者真实能力和缺陷？
第一条 为了确保关键信息基础设施供应链安全，维护国家安全，依据《中华人民共和国国家安全法》《中华人民共和国网络安全法》，制定本办法。 第二条 关键信息基础设施运营者（以下简称运营者）采购网络产品和服务，影响或可能影响国家安全的，应当按照本办法进行网络安全审查。 第三条 网络安全审查坚持防范网络安全风险与促进先进技术应用相结合、过程公正透明与知识产权保护相结合、事前审查与持续监管相结合、企业承诺与社会监督相结合，从产品和服务安全性、可能带来的国家安全风险等方面进行审查。 第四条...
Strive for lofty goals