where are you
有这样一个问题，如果构成网络的底层硬件或软件在源头上出现了漏洞或攻击该怎么办？这种日益普遍同时又不易发现的攻击形式被称为供应链攻击，通过这种方式攻击者可以利用供应商的缺陷来完成对下游链路的攻击，比如可以劫持其更新分发系统来传播木马；对于深度集成的下游软件甚至可以直接完成攻击，比如这次的Log4J漏洞。
我们知道链接是网络交互的基础，它们可以使访问者在页面之间来回跳转，可以将网络资源连接或引用来提供给用户使用。但是需要注意的是，链接往往不是永久性的，随着实践的推移，它们可能出现失效的情况，比如域名过期、短链接失效、服务器关闭、文章删除或是用户注销等等，而这些情况都会造成相关的链接失效。
那么当链接失效，安全人员就可以通过一些方法去拥有或接管当前的链接，从而完成Broken Link Hijacking，并在此之后进行各种恶意行为攻击。这种问题实际上在野已经被无数利用，而目前来看仍然有很多研究人员不了解或者企业对于此类问题不重视。本篇文章会简要分享下Broken Link Hijacking (BLH) 的形式以及危害。
聊聊从Service Mesh到Multi-Runtime的发展历程，了解其是如何形成了这样的架构模式。讨论在云原生中Multi-Runtime架构下可能带来的新的安全风险和安全研究方向。
Istio是目前最受关注的服务网格之一，越来越多的公司开始落地Service Mesh架构，并将已有的系统接入Service Mesh。同时随着零信任网络的发展，东西向，南北向流量都需要提供足够的安全保护，因为Istio自身提供了多种安全特性，所以也出现不少基于Istio的零信任架构。在安全中通常关注的重点是南北流量，而我们应该认识到，在云原生的环境下，东西流量安全也应该受到足够的重视。
在Istio默认的配置中，其在集群内暴露了许多未授权和明文传输的服务。通常情况下，这会引起攻击者的注意，当恶意攻击者进入被控制的容器或发现SSRF漏洞后，往往可以利用这些自身的服务扩大攻击范围。
分享一个Spring Boot中关于%2e的小Trick。先说结论，当Spring Boot版本在小于等于2.3.0.RELEASE的情况下，alwaysUseFullPath为默认值false，这会使得其获取ServletPath，所以在路由匹配时相当于会进行路径标准化包括对%2e解码以及处理跨目录，这可能导致身份验证绕过。而反过来由于高版本将alwaysUseFullPath自动配置成了true从而开启全路径，又可能导致一些安全问题。
随着软件架构不断的演进，更加快捷部署大型复杂应用成为了人们关注的方向。近几年Service Mesh开始不断出现在大家的视野里，越来越多的大厂开始对其进行实践。事实上在Service Mesh发展中核心就是不断对Sidecar模式配备更加完善的流量管理解决方案。
在Service Mesh中Sidecar是透明的，开发者对其无感知的，而其中对于流量最关键的一步就是Sidecar进行的流量劫持，那么Sidecar又是如何进行流量劫持呢？最常见的方式就是iptables，本文将会带你了解iptables，同时明白Istio中是如何使用iptables进行流量劫持。
Kubernetes是一个强大的容器调度系统，通常我们会使用一些声明式的定义来在Kubernetes中部署业务。但是当我们开始部署比较复杂的多层架构时，事情往往就会没有那么简单，在这种情况下，我们需要编写和维护多个YAML文件，同时在编写时需要理清各种对象和层级关系。这是一个比较麻烦的事情，所以这个时候Helm出现了。
我们熟悉的Python通过pip来管理包，Node.js使用npm管理包。那么在Kubernetes，我们可以使用Helm来管理。它降低了使用Kubernetes的门槛，对于开发者可以很方便的使用Helm打包，管理依赖关系，使用者可以在自己的Kubernetes通过Helm来一键部署所需的应用。
对于Helm本身可以研究的安全风险可以从很多角度来看比如Charts，Image等，详细的内容可以来看CNCF webinars关于Helm Security的一个分享（https://www.cncf.io/webinars/helm-security-a-look-below-deck/）
本篇文章主要讨论的是Helm2的安全风险，因为在Helm2开发的时候，Kubernetes的RBAC体系还没有建立完成，Kubernetes社区直到2017年10月份v1.8版本才默认采用了RBAC权限体系，所以Helm2的架构设计是存在一定安全风险的。Helm3是在Helm2之上的一次大更改，于2019年11月份正式推出，同时Helm2开始退出历史舞台，到2020年的11月开始停止安全更新。但是目前网络上主流依然为关于Helm2的安装配置文章，所以我们这里将对使用Helm2可能造成的安全风险进行讨论。
目前来看，密码认证方式早已成为我们一直采用的最直接的身份认证方式。但是我们应该知道的是很多大型企业都有曾出现过明文密码泄漏的事件，而且随着黑产的不断成长，钓鱼，撞库等等一系列的欺骗攻击行为都在不断涌现。由于很大一部分用户习惯于同一密码用于多个网站，这就导致了一次密码泄漏会牵连多个网站，用户密码认证的体系一直都在面临着很大的挑战。
对此而言，一种新的认证方式也已经出现在我们的视线范围内，WebAuthn在2019年3月成为了W3C推荐标准，同年的BlackHat大会上也有一篇议题专门介绍了WebAuthn，直到目前我们常见的浏览器大部分都已经支持了WebAuthn的标准，如Chrome，Safari等。可以看到各方力量都在联合推动着无密码认证的实现与发展，那么接下来我们就来一起认识一下什么是WebAuthn，以及它是如何工作的。
Java反序列化漏洞的危害不光在于普通gadgets能够带来的命令执行，由于Java应用的使用场景以及gadgets大多都是构造出单向代码执行，一般通过利用链构造出的单向代码链能做到的能力往往有限。而我们在多数场景比如需要回显，注入内存shell等情况下，实际上对可以直接运行整个class或者说运行一个全局上下文关联的多行代码来进行动态执行有极大的需求。它往往是需要反序列化利用链配合另一条能够动态代码执行的利用链，这里我们主要讨论的也是这种情况。下面会简要分享下部分相对比较常见同时能够直接动态代码上下文执行的方式。
阅读剩余部分 –“后反序列化漏洞”指的是在反序列化操作之后可能出现的攻击面。反序列化漏洞是Java中最经典的一种，所以大家可能的关注点都集中在反序列化过程中的触发点而忽略了反序列化之后的攻击面，这里我会分享一些在Java反序列化后的攻击思路。
阅读剩余部分 –之前一直有在研究Java插桩应用于安全防御以及检测方面的东西，主要分为RASP和IAST。IAST又叫交互式应用安全测试，它目前主要分为主动式(Active)和被动式(Passive)两种，上个暑假有机会重点接触了一下Passive IAST的一些研究工作。这里打算简单聊聊，也算是一个总结与思考。不会涉及太多技术细节，简单分享下我对的被动式IAST的应用以及优势还有劣势的看法以及存在的一些问题和新的思路。希望能和大家一起交流探讨。
利用Instrumentation API我们可以提供一个Agent代理用来监测和协助运行在JVM上的程序，可以在程序启动前修改类的定义。简单来说就是在运行的应用中织入一个我们的程序。而在这个程序中我们就拥有了获取当前应用的上下文，在应用运行中实时分析数据流以及调用栈的能力，同时也可以通过ASM对已经加载的class进行分析与修改。
在织入我们检测的逻辑代码后，被动式IAST主要是通过污点跟踪的方法来对漏洞进行检测，因为是实时数据流，所以这里我们称为动态污点传播分析。这是与静态扫描中污点分析的一个小区别，而其优势和劣势也主要在这里。
近期评论