Java - 标签 - 有价值炮灰

使用 Joern 进行漏洞挖掘

Mon, 16 Sep 2024 12:40:00 +0800

曾几何时，在代码安全审计之道一文中介绍了一些形而上学的代码审计方法论，在该文章提及未来会继续介绍一些具体的漏洞挖掘工具和技巧，即代码安全审计之术。正所谓白驹过隙，光阴荏苒，不知不觉两年多过去了，由于怠惰一直没有动笔。不过我也一直没有忘记这茬，正好最近放假就给自己补上。

本文是使用开源的 Joern 来进行漏洞挖掘的介绍。

Joern 101

Joern 是一个开源的代码分析平台，可以通过多种不同的前端将源代码转换为代码属性图(Code Property Graph)，简称 CPG，然后通过 Joern 内置的查询语法对 CPG 进行查询和分析。如果读者对 CodeQL 比较了解的话，可以将 Joern 理解成开源版的 CodeQL。

Joern 通过不同的前端引擎支持不同的代码，比如使用 CDT 支持 C/C++ 代码的 fuzzing parsing，使用 Ghidra 支持二进制文件的解析，使用 Soot 支持 Java 字节码的解析等等。不同前端的成熟度有所不同，如下表所示：

Name	Built with	Maturity
C/C++	Eclipse CDT	Very High
Java	JavaParser	Very High
JavaScript	GraalVM	High
Python	JavaCC	High
x86/x64	Ghidra	High
JVM Bytecode	Soot	Medium
Kotlin	IntelliJ PSI	Medium
PHP	PHP-Parser	Medium
Go	go.parser	Medium
Ruby	ANTLR	Medium-Low
Swift	SwiftSyntax	Medium
C#	Roslyn	Medium-Low

joern-cli

joern-cli 是我们用来构建代码属性图和进行查找的套件，可以在 github 下载 release 版本的 joern-cli.zip，也可以通过自行编译的方式构建。

后续写复杂规则需要自动补全，以及需要搜索代码查看用例，因此推荐通过源代码方式编译：

git clone https://github.com/joernio/joern
cd joern
sbt stage

安装完成后可以进行实际测试，使用一个简单的 Java 文件 Hello.java 如下：

package demo;

import a.b.c.Foo;

public class Hello {
  static Foo foo = new Foo();

  public static void main(String[] args) {
    String data = foo.bar(args[0]);
    Runtime.exec(data);
  }
}

将该源码文件构建成代码属性图数据库(cpg)可以使用 joern-parse 脚本：

joern-parse --language javasrc Hello.java -o hello.cpg

有几个注意点：

language 选择的是 javasrc 而不是 java，后者是 Soot 的前端；
可以使用 joern-parse --list-languages 列举所有支持的前端(语言)；
Hello.java 中包含外部类 a.b.c.Foo，因此实际无法编译，但是却可以正确生成 cpg；

对该 cpg 进行查询：

joern hello.cpg
joern> cpg
val res0: io.shiftleft.codepropertygraph.generated.Cpg = Cpg[Graph[136 nodes]]
# ...
joern> def source = cpg.method("main").parameter
joern> def sink = cpg.call("exec").argument
joern> sink.reachableByFlows(source).p
val res7: List[String] = List(
  """
┌─────────────────┬──────────────────────────────┬────┬──────┬────┐
│nodeType         │tracked                       │line│method│file│
├─────────────────┼──────────────────────────────┼────┼──────┼────┤
│MethodParameterIn│main(String[] args)           │8   │main  │    │
│Call             │demo.Hello.foo.bar(args[0])   │9   │main  │    │
│Call             │demo.Hello.foo.bar(args[0])   │9   │main  │    │
│Call             │demo.Hello.foo.bar(args[0])   │9   │main  │    │
│Identifier       │String data = foo.bar(args[0])│9   │main  │    │
│Identifier       │Runtime.exec(data)            │10  │main  │    │
└─────────────────┴──────────────────────────────┴────┴──────┴────┘"""
)

核心的查询就三行，查找从 main 的参数到 Runtime.exec 的参数中的数据流链路：

def source = cpg.method("main").parameter
def sink = cpg.call("exec").argument
sink.reachableByFlows(source).p

其中 cpg 是我们的代码属性图根对象，针对代码的查找都基于此对象出发进行查询。上面的查询语句实际上是合法的 scala 语句，joern-cli 本身也是一个 scala 解释器。除了 cpg 对象，还定义了一些全局的对象和方法，可以使用 help 进行查看：

joern> help
val res8: Helper = Welcome to the interactive help system. Below you find
a table of all available top-level commands. To get
more detailed help on a specific command, just type

`help.`.

Try `help.importCode` to begin with.
┌────────────────┬────────────────────────────────────────────────┬─────────────────────────┐
│command         │description                                     │example                  │
├────────────────┼────────────────────────────────────────────────┼─────────────────────────┤
│close           │Close project by name                           │close(projectName)       │
│cpg             │CPG of the active project                       │cpg.method.l             │
│delete          │Close and remove project from disk              │delete(projectName)      │
│exit            │Exit the REPL                                   │                         │
│importCode      │Create new project from code                    │importCode("example.jar")│
│importCpg       │Create new project from existing CPG            │importCpg("cpg.bin.zip") │
│open            │Open project by name                            │open("projectName")      │
│openForInputPath│Open project for input path                     │                         │
│project         │Currently active project                        │project                  │
│run             │Run analyzer on active CPG                      │run.securityprofile      │
│save            │Write all changes to disk                       │save                     │
│switchWorkspace │Close current workspace and open a different one│                         │
│workspace       │Access to the workspace directory               │workspace                │
└────────────────┴────────────────────────────────────────────────┴─────────────────────────┘

joern> cpg.help
...

joern-cli 套件除了 joern-parse 和 joern，还包含了 joern-export、joern-scan 等脚本用户导出控制流图以及批量扫描等功能，关于这些工具的使用细节，可以参考官方的 Joern Documentation。

Steps

以 cpg 为根结点，我们可以查找代码属性图中的所有结点类型，比如类、方法、调用、控制流等。这些结点都可以以属性的形式获取，比如：

cpg.method: 表示所有方法结点；
cpg.parameter: 表示所有方法的参数；
cpg.method("main").parameter: 表示所有名称为 main 的方法的参数；
cpg.typeDecl("Foo").method: 表示所有名称为 Foo 的类中的所有方法；

其中以 cpg.method 为例，其返回值是 Iterator[Method] 类型，因此可以调用所有 Scala Iterator 的方法，比如 map、filter、toList、size、head 等，后文介绍 Scala 时会也会提及。

cpg.method.parameter 实际上是拓展了 Iterator，使其支持子查询。另外 Joern 还实现了一些特殊的 Step 比如用于递归查询的 repeat、times 系列和用于数据流分析的 sink.reachableBy(source) 系列。

所有类型的 Step 可以参考文档中的 Node-Type Steps 一节。

Scala 101

前面说过，Joern 使用 Scala 编写，而且其查询语句也是 Scala 语句，因此为了熟悉 Joern 的查询，我们有必要先简单学习一下 Scala。很多同学没用过 Scala，因此一看到就觉得它像 Lisp、Haskell 一样反人类，但其实这是一个很简单的语言。

Scala 是一种基于 JVM 的语言，也就是说 .scala 源码可以像 Java 一样编译为 .class 文件，同时被 JVM 加载运行。其实可以将 Scala 当成是一个 Java 的拓展，可以使用现有的 Java 生态。如果你用过 Kotlin，那么应该会对 Scala 的语法感到熟悉。

HelloWorld

一个简单的 hello.scala 代码如下：

object hello {
  def main(args: Array[String]) = {
    println("Hello, World!")
  }
}

如果是 Scala3，则可以更简单：

@main def hello() = println("Hello, World!")

编译运行：

scalac hello.scala
scala hello

语法速通

本节主要介绍一些 Joern 查询经常用到的语法。

首先是变量定义：

var a = 1
val b = List(1, 2)
val c = 1 to 5 // 表示 1 到 5 的 Iterator

可以看到 Scala 虽然是个强类型语言，但是可以做到智能类型推导，因此在变量赋值的时候通常无需指定类型。

函数定义：

def fn(x: Any) = println(x)
def fn1(x: Int) = { x * x }
def fn2 = 1 to 5

对于函数定义来说，所有的参数还是需要声明类型的，不过返回类型可以自动推导得到。

注意 def a = 1 to 5 和 val a = 1 to 5 的差异，两者都是返回 Iterator 对象，但是前者每次返回都是新的 Iterator，而后者指向同一个 Iterator，因此后者只能遍历一次。

匿名函数和 JavaScript 类似，可以写成箭头函数 (x: R) => x * x，常用于需要传入过滤函数的场景，比如：

def it = 1 to 5
it.map(x => x * 2)
// 对于单个函数参数，可以省略括号
it.map { x =>
  val y = x * 2
  println(y)
  y
}
// 可以使用 `_` 代替单个参数：
it.map(_ * 2)

Scala 中有一些特别的语法糖，比如中缀语法糖：

case class Pair(x: Int, y: Int) {
  def plus(other: Pair): Int = x + other.x + y + other.y
}

val p1 = Pair(1, 2)
val p2 = Pair(3, 4)
val sum = p1 plus p2  // 使用中缀语法
// 等价于
val sum = p1.plus(p2)

因此下面两个表达式也是等价的：

5 + 3
5.+(3)

按照惯例，如果你调用方法是为了利用方法的“副作用”，此时写上空括号，如果方法没有任何副作用（没有修改其它程序状态），你可以省略掉括号。

(1 to 5).toList()
// 一般写成
(1 to 5).toList

类定义方面，普通类和抽象类和 Java 中的定义类似，接口则和 Rust 比较类似，用 trait 定义：

trait MyTrait {
  def method(): Unit = println("This is a trait method.")
}

案例类，用于生成不可变的数据接口，自动生成 apply、unapply、toString、equals 等方法：

case class MyCaseClass(name: String, age: Int)

对象类，也称单例类，只能有一个实例：

object MyObject {
  def method(): Unit = println("yeah.")
}

基本的语法也就这样了，更多 Scala 的语法和使用细节可以通过阅读 Joern 或其他项目的源码去熟悉(使用 Scala 的项目有 Apache Spark、Kafka、Flink 等)。毕竟语言只是一种工具，多看多写才能有所进步。

sbt

和 Java 使用 maven 进行工程管理一样，Scala 一般使用 sbt 进行工程管理。有趣的是 sbt 的管理文件 build.sbt 也是使用 Scala 编写的，一个示例如下：

ThisBuild / scalaVersion := "2.13.12"
ThisBuild / organization := "com.example"

lazy val hello = project
  .in(file("."))
  .settings(
    name := "Hello",
    libraryDependencies += "org.scala-lang" %% "toolkit-test" % "0.1.7" % Test
  )

sbt 可以和 maven 一样通过模版新建工程：

sbt new scala/scala-seed.g8

编译测试运行：

sbt compile
sbt test
sbt clean run

Joern 的工程同样是通过 sbt 进行管理，因此了解 sbt 有助于我们后续理解其架构和阅读源码。更多的 sbt 功能参考官方文档 https://www.scala-sbt.org/ 。

实战分享

学习了 Joern 的基本代码属性图和 Scala 的语法，现在可以开始编写你的第一条代码分析规则了！本节列举一些常用查询示例，以便大家熟悉 Joern 查询的风格。

我们使用两个不同的项目进行测试，分别是一个 Spring 源码应用，以及一个 Android 应用。

joern
joern> importCode("vuln-spring")
joern> importCode("xiaomi.apk")

同一个 joern-cli 可以加载多个项目，通过 workspace 命令查看所有 project，通过 workspace.openProject 打开对应的工程。

在代码图属性数据层来说，具体的查找是语言无关的，不过某些 Step 只有在特定语言才会生效(比如 annotation)，因此具体选择的语言关系并不大，你也可以用 C/C++ 或者 Python 和 JavaScript 项目来进行测试。

Web 漏洞挖掘

vuln-spring 是一个 Spring Web 应用，对于这类项目，可能我们第一个想要找的就是路由：

cpg.annotation.where(_.name(".*Mapping")).method.fullName.l

这个查询应该还算比较直观，有个需要注意的是 where，它和 filter 的主要不同点在于前者过滤函数的返回值为 Iterator 类型，而 filter 的过滤函数需要返回 Boolean 类型。末尾的 .l 实际上是 .toList 的简写(alias)，即将 Iterator 转换为 List 进行输出。

然后是找漏洞点，比如 SQL 注入。这里以 springframework JdbcTemplate 为例，查找其类方法。

根据直觉很容易写入下面的查询：

cpg.typeDecl.fullNameExact("org.springframework.jdbc.core.JdbcTemplate").method.l

其中 fullNameExcat 是一个快捷方法，相当于 typeDecl.filter(_.fullName.equals("xx"))。前面查询用到的 name("xxx") 也是类似的实现。以 name 为例，常用的简写包括：

nameExact("xxx"): 等于；
name("xxx"): 正则表达式匹配；
nameNot("xxx"): 不等于，也是正则匹配；

.filter 和 .where 也包括类似的 filterNot 和 whereNot 快捷取反匹配。

但是，上面的查询实际上会返回空列表，因为 JdbcTemplate 这个类并不是定义在代码中的，而是在 Spring 的 jar 包中外部类。我们构建 CPG 数据库的时候并没有获取依赖，因此自然也就无法得知该类下的所有方法。

这是新手很容易犯的错误，不过只要了解原理就很容易避免，正确查找外部方法的方式是：

cpg.method.fullName("org\\.springframework\\.jdbc.core\\.JdbcTemplate\\..*")
// 或者
cpg.method.filter(_.fullName.startsWith("org.springframework.jdbc.core.JdbcTemplate."))
// 或者更用的，直接找调用
cpg.call.filter(_.methodFullName.startsWith("org.springframework.jdbc.core.JdbcTemplate.")).code.l

将 source 和 sink 组合起来，就写出了我们第一条 SQL 注入查询规则：

def source = cpg.annotation.where(_.name(".*Mapping")).method.parameter
def sink = cpg.call.filter(_.methodFullName.startsWith("org.springframework.jdbc.core.JdbcTemplate.")).argument(1)
sink.reachableByFlows(source).p

.p 和 .l 一样是一个快捷方法，用于将 Iterator 以格式化文本的方式输出。上面的结果有部分误报，主要是指定了所有路由参数，其中包含一些不可控的 Model 或者 HttpSession 对象，可以进一步优化规则进行约束。

注意这里 sink 指定 argument(1) 表示第一个参数，argument(0) 一般表示方法调用的 this 对象。

sink.reachableBy(source) 返回的则是满足条件的 source，对于我们的查询而言是 Iterator[MethodParameterIn]；reachableByFlows 返回的是 Iterator[Path]，.p 会将其以表格的形式打印，如果你不喜欢默认的表格输出，也可以通过 map 方式转换为自定义的输出。

def prettyPath = (p: Path) => p.elements.map(
	e => String.format("%-20s %s", e.label, e.code)
).mkString("\n")
sink.reachableByFlows(source).map(prettyPath).mkString("\n\n===\n")

mkString 相当于 String.join 方法，将列表组合为字符串。输出示例：

METHOD_PARAMETER_IN  @RequestParam(name = "password", required = true) String password
IDENTIFIER           password          
METHOD_PARAMETER_IN  String password     
IDENTIFIER           password                       
CALL                 "SELECT * FROM users WHERE USERNAME=\"" + username + "\" AND PASSWORD=\"" + password + "\""
IDENTIFIER           query

通过这种方式我们可以结构化漏洞扫描输出，形成报告或者对接其他的后续验证逻辑。

Android 漏洞挖掘

与 Java 源码不同，有的 Jar 包只有字节码，不过 Joern 同样支持使用 Soot 去加载字节码并转换为 IR 从而将代码属性图存入数据库中。既然都是使用 Soot，那 Joern 是否支持 Android 漏洞扫描呢，答案是肯定的：

给 Joern 的第一个 PR

对于小型 APK 可以直接使用 jimple2cpg 或者 importCode 默认参数进行加载，而对于大型应用最好添加 --android 参数指定 android.jar (这是 Soot 的 API 导致的 Bug)。同时对于大型应用需要适当提高 JVM 内存。

jimple2cpg -J-Xmx30g --android $ANDROID_HOME/platforms/android-34/android.jar large.apk -o large.cpg

如果大家想要练手，可以使用一些开源的漏洞靶标应用进行测试，比如：

这里我们以一个实际漏洞为案例进行分析，即小米去年的一个系统应用命令注入漏洞。

漏洞详情可以参考 Oversecured 的博客 20 Security Issues Found in Xiaomi Devices，本节复现的是其中一个 System Tracing 应用的命令注入漏洞。对应的 APK 可以在 apkmirror 下载，见 System Tracing 1.0。

该漏洞原理在于小米动态注册了一个 AppReceiver，并且在其 onReceive 方法中通过接收的参数拼接 shell 命令执行导致命令注入。

对于漏洞挖掘而言，我们自动化挖掘该漏洞的难点在哪呢？首先在 Android 的四大组件中，BroadCastReceiver 比较特殊，它是唯一一个可以不用在 AndroidManifest.xml 中定义也可以使用的组件，即通过动态注册的方式初始化。

那么我们首要的任务就是找到所有代码中的 BroadCastReceiver 找出来，这个需求比较简单：

cpg.typeDecl.fullNameExact("android.content.BroadcastReceiver").derivedTypeDeclTransitive.fullName.l

derivedTypeDecl 及其变种 derivedTypeDeclTransitive 都是用于查找子类的辅助方法，如果自己写的话可以通过递归解析和查找 inheritsFromTypeFullName 属性来查找接口和父类。

这个查询只是找到所有 Receiver，但并不一定都有用到，所以我们进一步通过 Context.registerReceiver 查找实际注册的 Receiver 对象，并定位到实际的类型。

我们可以利用 Joern 数据流分析的能力，查找 BroadcastReceiver 的构造方法调用到 registerReceiver 的数据流，如下所示：

val baseCls = "android.content.BroadcastReceiver"
val receiverCls = cpg.typeDecl.fullNameExact(baseCls).derivedTypeDeclTransitive.fullName.l
def source = cpg.call.nameExact(Operators.alloc).filter(n => receiverCls.contains(n.typeFullName))
def sink = cpg.call.nameExact("registerReceiver").argument(1)

// 查找数据流
sink.reachableBy(source)

这个查询能够找到类似下面这种调用：

BroadcastReceiver r = new FooReceiver();
this.registerReceiver(r, filter);

但是却找不到我们这个漏洞所处于的位置，反编译代码：

public class ApplicationImpl extends Application {  
    private AppReceiver mDumpReceiver = new AppReceiver();  
  
    @Override // android.app.Application  
    public void onCreate() {  
        super.onCreate();  
        IntentFilter intentFilter = new IntentFilter();  
        intentFilter.addAction("com.android.traceur.DumpReceiver");  
        registerReceiver(this.mDumpReceiver, intentFilter);  
    }
}

这里实际上是通过属性的方式进行传递，可以看到 Joern 的数据流分析这里并没有关联上，因为 source 和 sink 分别在两个不相关的函数和 onCreate() 中，静态分析工具并不知道 onCreate 这种生命周期函数什么时候会被调用。

一种方式是修改 Joern 的前端代码，模拟 Runtime 进行生命周期方法调用，在解析代码属性图的时候为这些方法添加自定义的调用，从而补全增强控制流图(CFG)。

当然这种方式可能需要修改 Joern 源码，我们可以通过其他投机取巧的方式，观察到 source 和 sink 的连结断点主要在类属性上，那么可以尝试新建一个中间结点再做一次数据流分析。

def fieldAccess = cpg.fieldAccess.filter(fa => receiverCls.contains(fa.typeFullName) || fa.typeFullName.equals(baseCls))
// 所有 BroadCastReceiver 及其子类类型的属性读取结点
def fieldRead = fieldAccess.filter(fa => fa.argumentIndex == 2)
// 返回的是实际的 BroadCastReceiver 类型的属性
val reads = sink.reachableBy(fieldRead).toList
// 找到所有的属性名称，结果为 List[List[String]]
val fields = reads.map(r => List(r.typeDecl.fullName.head, r.fieldIdentifier.canonicalName.head))
// 匹配上述 field 的所有写入
def fieldWrite = fieldAccess
  .filter(fa => fa.argumentIndex == 1)
  .filter{fa =>
    val li = fa.map( r =>
        List(r.typeDecl.fullName.head, r.fieldIdentifier.canonicalName.head)
    )
    li.exists(fields.contains)
  }

// 数据流查询
fieldWrite.reachableByFlows(source).p

稍微解释一下：

fieldAccess.argumentIndex 表示属性在上级表达式中的参数位置，1 为写入，类似 r0.field = value，2 为读取，类似 r1 = r0.field；这个指定不是必须的，不过在代码量大的时候可以稍微提升下速度；
fieldAccess 包含所有类型为 BroadCastReceiver 及其子类的属性的访问，注意 receiverCls 中只包含子类，没包含 BroadCastReceiver 父类本身，因此需要加上以匹配多态的情况；
fields 是为了拿到所有的属性字段名称，以 List 的格式存储，包含类名和字段名，用字符串保存也是可以的；
然后在 fieldWrite 匹配对应字段的写入，这里使用了 List.exists 判断列表 li 中是否包含列表 fields 中的元素；

最后使用 reachableByFlows 找到所有原 source 到指定属性写中的链路，返回结果如下：

joern> fieldWrite.reachableByFlows(source).p
val res131: List[String] = List(
  """
┌──────────────────┬──────────────────────────────────────────────────┬────┬────────┬────────────────────────────────┐
│nodeType          │tracked                                           │line│method  │file                            │
├──────────────────┼──────────────────────────────────────────────────┼────┼────────┼────────────────────────────────┤
│Call              │new com.android.traceur.MainFragment$10           │228 │onCreate│com.android.traceur.MainFragment│
│Identifier        │$r17 = new com.android.traceur.MainFragment$10    │228 │onCreate│com.android.traceur.MainFragment│
│Identifier        │$r17.com.android.traceur.MainFragment$10(r0)      │228 │onCreate│com.android.traceur.MainFragment│
│MethodParameterIn │(this, com.android.traceur.MainFragment $r1)│227 │  │com.android.traceur.MainFragment│
│MethodParameterOut│RET                                               │227 │  │com.android.traceur.MainFragment│
│Identifier        │$r17.com.android.traceur.MainFragment$10(r0)      │228 │onCreate│com.android.traceur.MainFragment│
│Identifier        │r0.mRefreshReceiver = $r17                        │228 │onCreate│com.android.traceur.MainFragment│
│Call              │r0.mRefreshReceiver = $r17                        │228 │onCreate│com.android.traceur.MainFragment│
└──────────────────┴──────────────────────────────────────────────────┴────┴────────┴────────────────────────────────┘""",
  """
┌──────────────────┬─────────────────────────────────────────┬────┬──────┬───────────────────────────────────┐
│nodeType          │tracked                                  │line│method│file                               │
├──────────────────┼─────────────────────────────────────────┼────┼──────┼───────────────────────────────────┤
│Call              │new com.android.traceur.AppReceiver      │8   ││com.android.traceur.ApplicationImpl│
│Identifier        │$r1 = new com.android.traceur.AppReceiver│8   ││com.android.traceur.ApplicationImpl│
│Identifier        │$r1.com.android.traceur.AppReceiver()    │8   ││com.android.traceur.ApplicationImpl│
│MethodParameterIn │(this)                             │38  ││com.android.traceur.AppReceiver    │
│MethodParameterOut│RET                                      │38  ││com.android.traceur.AppReceiver    │
│Identifier        │$r1.com.android.traceur.AppReceiver()    │8   ││com.android.traceur.ApplicationImpl│
│Identifier        │r0.mDumpReceiver = $r1                   │8   ││com.android.traceur.ApplicationImpl│
│Call              │r0.mDumpReceiver = $r1                   │8   ││com.android.traceur.ApplicationImpl│
└──────────────────┴─────────────────────────────────────────┴────┴──────┴───────────────────────────────────┘"""
)

找到了两个匹配，其中第二个即为我们要找的漏洞类，第一个结果匹配的点为：

public class MainFragment extends PreferenceFragment {
	// ...
	private BroadcastReceiver mRefreshReceiver;
	@Override // androidx.preference.PreferenceFragment, android.app.Fragment
    public void onCreate(Bundle bundle) {
	    // ...
	    this.mRefreshReceiver = new BroadcastReceiver() { // from class: com.android.traceur.MainFragment.10
            @Override // android.content.BroadcastReceiver
            public void onReceive(Context context, Intent intent) {
                MainFragment.this.refreshUi();
            }
        };
    }
	@Override // androidx.preference.PreferenceFragment, android.app.Fragment
    public void onStart() {
        super.onStart();
        // ...
        getActivity().registerReceiver(this.mRefreshReceiver, new IntentFilter("com.android.traceur.REFRESH_TAGS"), 4);
        Receiver.updateTracing(getContext());
    }
}

可以看到我们这个查询语句同样也找到了基于多态的匿名类赋值，其中动态注册的类名为 com.android.traceur.MainFragment$10。虽然规则写得有点 ugly，不过已经基本能用了。

后续操作就是要继续添加规则，将两种不同的数据流合并，然后将 source 中的构造方法对应类名提取出来，再定位其 onReceive 方法，将该方法的参数作为后续阶段漏洞分析的 source，从而查找到危险函数如 Runtime.exec 等的调用。

进阶操作

从前面的分享中应该已经基本了解了 Joern 的用法和常见查询，同时也知道该工具存在一些局限性。幸运的是 Joern 同时也存在很强的拓展性，本节就来介绍一些比较有用的拓展操作。

数据流语义

在前面介绍 Web 漏洞挖掘时，我们的 SQL 查询实际上有很多误报，其中最为严重的一个误报是明明指定了 sink 是 JdbcTemplate 的方法第一个参数，但实际上参数传入了其他参数也会认为是有效路径：

def sink = cpg.call.filter(_.methodFullName.startsWith("org.springframework.jdbc.core.JdbcTemplate.")).argument(1)

这是因为 Joern 对于没有代码的外部方法，为了保持可靠性(soundness)，会将这些方法的传播规则设置为传播到所有参数和返回值，牺牲误报率以减少漏报率。

However, to remain sound, Joern will treat external methods with no semantic definitions as able to propagate taint from all arguments, to all arguments including the return value.

这无疑提高了我们分析误报的成本。那么有没有什么方法可以优化数据流分析，即对指定方法进行语义配置呢？答案是有的。我们可以指定额外的 FlowSemantic 列表，如下所示：

import io.joern.dataflowengineoss.layers.dataflows.{OssDataFlow, OssDataFlowOptions}
import io.shiftleft.semanticcpg.layers.LayerCreatorContext
import io.joern.dataflowengineoss.semanticsloader.FlowSemantic

val extraFlows = List(
    FlowSemantic.from(
        "^path.*\\.sanitizer$", // Method full name
        List((1, 1)), // Flow mappings
        regex = true  // Interpret the method full name as a regex string
    )
)

val context = new LayerCreatorContext(cpg)
val options = new OssDataFlowOptions(extraFlows = extraFlows)
new OssDataFlow(options).run(context)

数据流映射通过数字 Tuple 实现：

1, -1 表示第一个参数数据流会传播给返回值；
1, 2 表示第一个参数数据流会传播给第二个参数；
1, 0 表示第一个参数数据流会传播给示例对象(this)；
1, 1 表示第一个参数数据流会传播给自身，通常用于表示数据流是否中断，即用于指定 sanitizer；

比如如下代码：

x = source()
foo(x) // "foo" 1->1 表示数据流继续向下传播，否则会中断
sink(x)

除了以上面的代码形式指定，Joern 也支持使用 semanticsloader/Parser 加载语义文件，每行表示一条 extraFlows，包含多个 FlowSemantic，以空格分隔，例如：

"foo" 1->-1 2->3

每个参数都需要带有位置标识，不过对于某些语言可以指定命名参数：

"foo" 1 "param1"->2 3 -> 2 "param2"

对于一般的数据流分析，会认为默认参数间不互相污染，并且参数会污染返回值。因为大家写得比较多，所以 Joern 也提供了特殊的规则即 PASSTHROUGH:

"foo" PASSTHROUGH 0 -> 0

使用 scala 代码为：

FlowSemantic("foo", List(PassThroughMapping))

从语义上来说等价于 foo(1, 2) = 1 -> 1, 2 -> 2, 1 -> -1, 2 -> -1，即所有参数会污染自身和函数的返回值，注意没有 0 -> 0，因此 this 对象不会污染自身。

我们可以通过 context.semantics.elements 查看当前默认的 FlowSemantic 列表。前面添加语义使用的 val context = new LayerCreatorContext(cpg) 会覆盖当前的 context 对象。

从实践上来看，创建语义的方式有多种，可以自行选取适合的方式：

import io.joern.dataflowengineoss.semanticsloader.{FlowSemantic, PassThroughMapping, Parser}
// 调用构造方法
val s = FlowSemantic("org\\.springframework.*", List(PassThroughMapping), true)
// 调用静态方法
val s = FlowSemantic.from("org\\.springframework.*", List((1, -1)), true)
// 使用 Parser
val parser = Parser()
// 从字符串加载单条或者多条语义，返回列表
val extraFlows = parser.parse(""" "foo" PASSTHROUGH 0 -> 0 """)
// 从文件中加载
val extraFlows = parser.parseFile("semantics.txt")

更多细节可以查看官方的文档介绍 Dataflow Semantics 或者查看源码。

控制流增强

不同于数据流分析，有时候我们仅仅关注控制流，比如下面的语句可以递归查找调用：

cpg.method.name("exec").repeat(_.caller)(_.emit.dedup).fullName.sorted

对于我们之前 Android 漏洞挖掘的例子，数据流分析在面对 Android 运行时的一些回调函数时无法进行跟踪，本质也是因为控制流没有关联上。由于 Joern 本身是基于 Scala 的查询，而且也把所有数据结构暴露给了用户，那其实也可以像自定义数据流语义一样添加新的控制流规则。

伪代码如下：

val methods = cpg.method
val node1 = methods.next
val node2 = methods.next
node1.addEdge(EdgeTypes.AST, node2)

可基于 joern-cli 的自动补全查看支持的边类型：

joern> EdgeTypes.
ALIAS_OF             AST                  CALL                 CDG                  CONTAINS             IMPORTS              PARAMETER_LINK       REACHING_DEF         SOURCE_FILE
ALL                  BINDS                CAPTURE              CFG                  DOMINATE             INHERITS_FROM        POINTS_TO            RECEIVER             TAGGED_BY
ARGUMENT             BINDS_TO             CAPTURED_BY          CONDITION            EVAL_TYPE            IS_CALL_FOR_IMPORT   POST_DOMINATE        REF

这是旧版本的用法，新版本中使用 diffGraph 对象，类型为 DiffGraphBuilder，使用 diffGraph.addEdge 可以直接新增控制流边。

考虑一个最常见的多线程调用场景：

class ThreadDemo {
  public static void main(String args[]) throws Exception {
    final String cmd = String.format("sh -c \"%s\"", args[0]);
    Thread th = new Thread(new Runnable() {
      @Override
      public void run() {
        System.out.println("Running in a new thread");
        try {
          System.out.println("return: " + Runtime.getRuntime().exec(cmd));
        } catch(Exception ignore) {}
      }
    });
    th.start();
    Thread.sleep(1000);
  }
}

正如前面所说，如果使用正常的静态分析，是无法识别到输入到输出的数据流的：

def source = cpg.method.nameExact("main").parameter
def sink = cpg.call.nameExact("exec").argument
sink.reachableBy(source)

针对这个用例，我们需要让程序知道 Thread.start 会调用到 Runnable.run，因此可以直接添加一条边：

val call = cpg.call("start").head
val target = cpg.method("run").head
diffGraph.addEdge(call, target, EdgeTypes.CALL)
run.commit

然后再运行 sink.reachableBy 就能找到正确的调用链了：

joern> sink.reachableByFlows(source).p
val res4: List[String] = List(
  """                                                                                                                  
┌──────────────────┬────────────────────────────────────────────────────────────────────────────┬────┬──────┬────┐     
│nodeType          │tracked                                                                     │line│method│file│   
├──────────────────┼────────────────────────────────────────────────────────────────────────────┼────┼──────┼────┤
│MethodParameterIn │main(String[] args)                                                         │2   │main  │    │
│Call              │.arrayInitializer                                                 │3   │main  │    │
│Call              │.arrayInitializer                                                 │3   │main  │    │
│Call              │String.format("sh -c \"%s\"", args[0])                                      │3   │main  │    │
│Identifier        │String cmd = String.format("sh -c \"%s\"", args[0])                         │3   │main  │    │
│Identifier        │new Runnable() { @Override public void run() { System.out.println("Running  │4   │main  │    │
│                  │in a new thread"); try { System.out.println("return: " +                    │    │      │    │
│                  │Runtime.getRuntime().exec(cmd)); } catch (Exception ignore) { } } }         │    │      │    │
│MethodParameterIn │(this, cmd)                                                           │4   ││    │
│Identifier        │this.cmd = cmd                                                              │4   ││    │
│Call              │this.cmd = cmd                                                              │4   ││    │
│MethodParameterOut│RET                                                                         │N/A ││    │
│Identifier        │new Runnable() { @Override public void run() { System.out.println("Running  │4   │main  │    │
│                  │in a new thread"); try { System.out.println("return: " +                    │    │      │    │
│                  │Runtime.getRuntime().exec(cmd)); } catch (Exception ignore) { } } }         │    │      │    │
│Block             │$obj0                                                                       │4   │main  │    │
│Identifier        │new Thread(new Runnable() { @Override public void run() {                   │4   │main  │    │
│                  │System.out.println("Running in a new thread"); try {                        │    │      │    │
│                  │System.out.println("return: " + Runtime.getRuntime().exec(cmd)); } catch    │    │      │    │
│                  │(Exception ignore) { } } })                                                 │    │      │    │
│Identifier        │th.start()                                                                  │13  │main  │    │
│MethodParameterIn │run(this)                                                                   │5   │run   │    │
│Call              │Runtime.getRuntime().exec(cmd)                                              │9   │run   │    │
└──────────────────┴────────────────────────────────────────────────────────────────────────────┴────┴──────┴────┘""",

注意 diffGraph 只是一个临时的差分图，需要 commit 之后才能将差异提交到 cpg 中。这只是一种简单的示例，代码中还没关联 Thread 对应的具体 Runable 类，这就留给读者进行完善了。

如果需要对代码属性图做复杂的操作，比如针对反射实现数据流跟踪等，可以使用自定义 Pass，参考下一节的介绍。

CpgPass

前面我们提到了 diffGraph，笔者其实是通过搜索代码找到的，发现在 ghidra2cpg 的 JumpPass.scala 中就有类似的操作：

class JumpPass(cpg: Cpg) extends ForkJoinParallelCpgPass[Method](cpg) {

  override def generateParts(): Array[Method] =
    cpg.method.toArray
  override def runOnPart(diffGraph: DiffGraphBuilder, method: Method): Unit = {
    method.ast
      .filter(_.isInstanceOf[Call])
      .map(_.asInstanceOf[Call])
      .nameExact(".goto")
      .where(_.argument.order(1).isLiteral)
      .foreach { sourceCall =>
        sourceCall.argument.order(1).code.l.headOption.flatMap(parseAddress) match {
          case Some(destinationAddress) =>
            method.ast.filter(_.isInstanceOf[Call]).lineNumber(destinationAddress).foreach { destination =>
              diffGraph.addEdge(sourceCall, destination, EdgeTypes.CFG)
            }
          case _ => // Ignore for now
          /* TODO: Ask ghidra to resolve addresses of JMPs */
        }
      }
  }

  private def parseAddress(address: String): Option[Int] = {
    Try(Integer.parseInt(address.replaceFirst("0x", ""), 16)).toOption
  }
}

Pass 是 Joern 中用于后处理 CPG 图数据库的结点，比如生成 CFG(Control Flow Graph) 和 DDG(Data Dependency Graph) 等。

针对上一节提到的控制流增强，笔者写了个简单的 DemoPass：

import io.shiftleft.codepropertygraph.generated.{Cpg, EdgeTypes, PropertyNames}
import io.shiftleft.codepropertygraph.generated.nodes.{Call, Method, StoredNode, Type, TypeDecl}
import io.shiftleft.passes.CpgPass


class DemoPass(cpg: Cpg) extends CpgPass(cpg) {

  override def run(diffGraph: DiffGraphBuilder): Unit = {
    val call = cpg.call("start").head
    val target = cpg.method("run").head
    val targetNode = methodFullNameToNode(target.fullName).get
    diffGraph.addEdge(call, targetNode, EdgeTypes.CALL)
    println(s"Add Edge: $call -> $targetNode")
  }

  private def nodesWithFullName(x: String): Iterator[StoredNode] =
    cpg.graph.nodesWithProperty(PropertyNames.FULL_NAME, x).cast[StoredNode]

  private def methodFullNameToNode(x: String): Option[Method] =
    nodesWithFullName(x).collectFirst { case x: Method => x }
}

通过以下方式加载：

new DemoPass(cpg).createAndApply()
run.commit

和 Pass 对应的是 Overlay，Joern 首次加载 CPG 或者使用 joern-parse 生成数据库的时候会默认执行一部分 pass，按照不同的层次依次执行。我们可以通过 project.appliedOverlays 查看当前生效的 Pass：

joern> project.availableOverlays
joern> project.appliedOverlays
res0: Seq[String] = IndexedSeq("base", "controlflow", "typerel", "callgraph", "dataflowOss")

以负责数据流分析的 dataflowOss 为例，其代码实现在 OssDataFlow.scala，会首先执行 ReachingDefPass，同时加上了 extraFlows 实现自定义的数据流控制。

我们可以参考其代码实现自己的 Overlay 来增强 Joern 的功能，这也是其强拓展性的一个表现。

其他

在编写 Joern 代码查询规则的过程中，一个必备的知识就是需要了解其支持的 API，我们可以通过 joern-cli 的 help 命令查看 cpg 的具体 Step 以及后继支持的 Step 和简单介绍：

cgp.help
cpg.method.help
cpg.typeDecl.help

也可以通过下面的文档进行查阅：

Node Type Steps - Reference Card - 官方的文档；
queries.joern.io - joern-query 的示例查询规则；

但不管是 joern-cli 的 help 命令还是官方文档，都没有完全覆盖所有的 Step，比如我们上面用到查询装饰的 annotation 和用于查询所有子类的 derivedTypeDecl。那么笔者是如何得知这些 API 的呢？一个方法是在社区里看别人的提问和回复，但这显然效率太低。另一个方法就是通过查询源码的方式找到这些信息。

在 Joern 的主仓库 joernio/joern 中有许多单元测试，比如我们查看一些递归搜索的示例，可以搜索 .repeat( 从而查看具体选项例如 .emit、maxDepth 等用法。

另外 Joern 的图数据库基座是 joernio/flatgraph，其前身是 overflowdb，最近 4.0 版本才完成切换。在该仓库中可以找到每个 Step 的实现。从中我们发现递归搜索 .repeat 默认为深度优先，可以通过 .bfs 设置为广度优先，等等诸如此类的 Trick。

从代码中我们能找到一些比较实用的 Step，比如 collectAll 用于返回指定类型的节点。scala 中的 collect 相当于 filter+map 的结合：

.collectAll[Call]
// 相当于
.collect { case x: Call => x }
// 相当于
.filter(_.isInstanceOf[Call]).map(_.asInstanceOf[Call])

自定义 Step

我们之前用到的这些 Step，其实也可以自定义，比如我们想要在 method 中新增一个 fooStep 查询，可以使用以下方法：

implicit class MyMethodTraversals(method: Traversal[Method]) {
  def fooStep = method.fullName(".*org.example.*").isPublic
}

cpg.method.fooStep

这使用了 Scala 的 implicit 隐式类类特性，用于通过隐式转换为现有类型添加新方法。隐式类通常用于增强现有类型的功能，而无需直接修改这些类型的定义。

可视化

有时编写规则的时候对于某些条件不太好判断，但是将全部结点打印出来又不直观，Joern 提供了一系列绘图方法可以打印指定结点的流图：

joern> cpg.method("main").plotDot
plotDotAst     plotDotCdg     plotDotCfg     plotDotCpg14   plotDotDdg     plotDotPdg

各种图的定义如下：

AST: Abstract Syntax Tree，抽象语法树；
CDG: Control Dependence Graph，控制依赖图，主要包含 if/else 等控制结构的依赖关系；
CFG: Control Flow Graph，控制流图，程序执行的所有可能路径；
DDG: Data Dependency Graph，数据依赖图，包含属于依赖关系；
PDG: Program Dependence Graph，程序依赖图，包含控制依赖和数据依赖关系；

plotDotXXX 会直接打开默认的图片预览工具，如果是没有图形界面的环境，可以通过 dotXXX 获取 dot 图片的 digraph 文本格式：

cpg.method("main").dotAst.head #> "/tmp/main.dot"

其中使用了自定义的操作符 #> 来将字符串重定向到文件中，也算是一个比较有用的小特性。还有其他用法就有待大家继续深入挖掘了。

总结

通过上面的分享，相信大家对 Joern 也有了比较直观的了解。先说说使用的缺点，首先是文档不完善，很多接口需要查看源代码或者在社区里找答案；另一个广为诟病的是其数据流引擎，存在很多误报和漏报的情况。上面的代码中看到它名字叫 ossdataflow，只实现了非常简单的数据流，和 CodeQL 等商业软件相比还有差距。这不禁让人想起隔壁村的 radare2，以及一张开源梗图：

不过 Shiftleft(Joern 所属公司) 还有一款商业的代码扫描工具，名为 ocular，其中大部分功能和 joern 一致，只不过其数据流引擎是优化过的，而且增加了许多接口的建模，感兴趣的可以参考 joern-vs-ocular。由此可见不是没有能力做好，只是由于利益关系注定不会在上面投入太多。

虽然有很多缺点，但 Joern 也有其优势。首先是其架构设计比较优雅，可以基于不同的前端加入新的语言支持，除了源码还支持字节码和二进制程序(汇编)；其次是其查询语言基于成熟的编程语言 Scala 来实现，具备很强的灵活性，可以实现各种复杂的查询；最后就是作为开源软件，主打一个 “自主可控”，只要具备一定编码能力那么基本各种需求都能够实现，从而克服前面说到的诸多缺点。

参考资料

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/09/16/using-joern/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

Java 应用安全之 JEB Floating License 绕过

Fri, 03 May 2024 12:40:00 +0800

最近一朋友单位采购了 JEB Pro 用于 Android 逆向，但使用的是 Floating License，因此只能在公司内网中使用。这样一来朋友在节假日就没法卷了，于是找到了我看有没有兴趣研究一下。虽然笔者之前搞过一段时间 Java 逆向，但那主要针对 Android 应用，对于 PC 应用那是大姑娘坐花轿 —— 头一回。本着学习新知识的心态，就接下了这个任务。

前言

以防有朋友不了解，JEB 是一个逆向工程工具，主要用于 Android APK 的逆向分析，针对 smali 字节码反编译的功能类似于 JADX，但是也支持对 SO 等二进制程序的逆向分析。

一般来说 JEB Pro 采用订阅机制，根据使用的机器进行收费，一机一密。但对于企业而言通常采用浮动授权，即 Floating License，允许一个或者多个不固定的机器同时使用。JEB floating controller 是官方用于运行在服务端的私有浮动授权服务器，其本质上是一个 HTTP 服务器，运行后直接访问会显示授权信息。

JEB Floating Controller

客户端则需要在 jeb-client.cfg 中配置 .ControllerInterface 和 .ControllerPort 等信息，或者在启动 JEB Pro 的时候填入服务端地址，从而实现授权。

逆向分析

对于静态分析而言，和 Android 应用中的静态分析流程基本一致，都是拖到 JADX 中然后搜索某些关键字，比如授权失败的提示信息，或者配置的信息。

首先我们将授权服务的地址指定为 127.0.0.1:23477，然后用 NC 监听该地址，启动后很快收到了请求：

Listening on 0.0.0.0 23477
Connection received on localhost 52330
POST /probe HTTP/1.1
User-Agent: PNF Software UP
Content-Type: application/x-www-form-urlencoded
Content-Length: 189
Host: 127.0.0.1:23477
Connection: Keep-Alive
Accept-Encoding: gzip

data=5400000035E5...

可见 JEB Pro 和浮动授权服务器是通过 HTTP 请求进行通讯的。

$ zipgrep /probe bin/app/jeb.jar
grep: (standard input): binary file matches

直接搜索请求的路径 /probe，可以定位到下面的代码：

/* loaded from: jeb.jar:com/pnfsoftware/jebglobal/ga.class */  
public class ga {  
    private static String nz = cns.nz("1150...");  
    private static String Fj = cns.nz(new byte[]{117, 90, 69, 74, 69}, 2, 120);  
    private Net jU;  
    private String Fx;  
    private int tQ;  
    private String Fh;  
  
    public ga(Net net, String str, int i, int i2) {  
        if (net == null) {  
            throw new IllegalArgumentException();  
        }  
        if (str == null || str.isEmpty()) {  
            throw new IllegalArgumentException("Controller Interface is not set");  
        }  
        if (i <= 0 || i >= 65535) {  
            throw new IllegalArgumentException("Illegal Controller Port value must be between 0 and 65535");  
        }  
        this.jU = net;  
        this.Fx = str;  
        this.tQ = i;  
        Object[] objArr = new Object[3];  
        objArr[0] = i2 == 1 ? "https" : NetProxyInfo.TYPE_HTTP;  
        objArr[1] = str;  
        objArr[2] = Integer.valueOf(i);  
        this.Fh = Strings.ff("%s://%s:%d/probe", objArr);  
    }
    // ...
    public String nz(String str) {  
        return JebNet.post(this.jU, this.Fh, str);  
    }  
  
    public void Fj(String str) {  
        JebNet.post(this.jU, this.Fh, str);  
    }
}

看起来像是通过的 JebNet.post 发送请求的。接下来有两个策略，一是继续静态分析不断查看交叉应用来来定位请求发送点，二是使用动态分析来验证该处是否确实被调用。懒人首选必然是后者。

动态分析

说起动态分析就有点怀念移动端常用的 frida 了。针对 Android 应用可以通过 hook 某些特定函数去检查参数、调用栈，并且对参数和返回值进行修改。理论上 frida 在 PC 端也是可以使用的，但是只支持了一部分版本的 OpenJDK，实测笔者的 JDK 17 支持并不是很好。

由于前一段时间研究过 Java Web 应用，那时用得最多的工具要数 arthas 了。这是一个阿里巴巴开源的线上 Java 诊断利器，基于 JVMTI 注入应用，避免了调试器中断的繁琐流程。该工具使用 ASM 来动态修改 Java 字节码，不同于 frida 基于二进制的注入，ASM 对于 JDK 而言有很高的兼容性。

由于 arthas 使用 OGNL 作为表达式，因此对于 hook 的过滤和修改也具备很强的灵活性。关于其具体的使用方法可以参考官方文档，这里就不再赘述了。

直接使用 as.sh 指定 JEB 的进程 ID，然后 hook JebNet.post 方法，查看调用堆栈：

[arthas@70354]$ stack com.pnfsoftware.jeb.client.JebNet post params.length==3
Press Q or Ctrl+C to abort.
Affect(class count: 1 , method count: 2) cost in 53 ms, listenerId: 4
ts=2024-04-02 13:21:06;thread_name=Thread-9;id=1a;is_daemon=true;priority=5;TCCL=jdk.internal.loader.ClassLoaders$AppClassLoader@531d72ca
    @com.pnfsoftware.jeb.client.JebNet.post()
        at com.pnfsoftware.jebglobal.ga.nz(SourceFile:71)
        at com.pnfsoftware.jebglobal.aW.jU(SourceFile:194)
        at com.pnfsoftware.jebglobal.aW.run(SourceFile:81)
        at java.lang.Thread.run(Thread.java:833)

果然是这里，核心的 jU 方法如下：

/* loaded from: jeb.jar:com/pnfsoftware/jebglobal/aW.class */  
public class aW implements Runnable {
    private long jU() {  
        Fg Fj2;  
        try {  
            ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();  
            LEDataOutputStream lEDataOutputStream = new LEDataOutputStream(byteArrayOutputStream);  
            lEDataOutputStream.writeInt(0);  
            lEDataOutputStream.writeLong(this.sM);  
            lEDataOutputStream.writeLong(this.Pm);  
            lEDataOutputStream.close();  
            String nz2 = this.Fh.nz(Fg.nz(Fg.nz(te.Fj(), byteArrayOutputStream.toByteArray(), new int[1])));  
            if (nz2 == null || (Fj2 = Fg.Fj(Fg.nz(nz2.trim()))) == null) {  
                return -1L;  
            }  
            this.fR = Fj2.tQ();  
            LEDataInputStream lEDataInputStream = new LEDataInputStream(new ByteArrayInputStream(Fj2.dv()));  
            if (lEDataInputStream.readInt() != 1) {  
                return -1L;  
            }  
            return lEDataInputStream.readLong();  
        } catch (Exception e) {  
            nz.catching(e);  
            return -1L;  
        }  
    }
    // ...
}

aW 这个类本身是个 Runnable，是使用一个额外的线程进行启动的，这里请求被调用的地方如下：

  
    @Override // java.lang.Runnable  
    public void run() {  
        int i = 0;  
        int i2 = 0;  
        boolean z = false;  
        while (true) {  
            long jU2 = jU();  
            try {  
                if (jU2 == 0 || jU2 == 2) {  
                    if (jU2 == 2 && !z) {  
                        nz.warn(cns.nz(new byte[]{26, 54, 26, 7, 82, 106, 15, 7, 98, 67, 15, 5, 12, 11, 26, 84, 73, 26, 83, 79, 3, 8, 1, 23, 82, 84, 28, 9, 15, 78, 84, 28, 13, 69, 67, 12, 1, 26, 6, 29, 3, 0, 9, 23, 82, 89, 22, 26, 85, 65, 19, 23, 69, 67, 12, 1, 0, 11, 6, 23, 17, 1, 68, 84, 27, 78, 1, 116, 59, 79, 65, 23, 25, 6, 13, 68, 85, 27, 11, 29, 8, 21, 6, 23, 17, 1, 68, 66, 7, 13, 9, 23, 31, 6, 29, 94, 12, 89, 22, 26, 85, 83, 27, 7, 26, 25, 8, 68, 85, 5, 20, 5, 21, 17, 69, 89, 22, 26, 7, 82, 83, 28, 9, 18, 3, 22, 19, 23}, 1, 67), new Object[0]);  
                        z = true;  
                    }  
                    if (i != 0 || i2 != 0) {  
                        nz.warn(...);  
                    }  
                    i = 0;  
                    i2 = 0;  
                } else {  
                    nz.warn(...);  
                    boolean z2 = false;  
                    if (jU2 <= -1) {  
                        i++;  
                        if (i >= 3) {  
                            z2 = true;  
                        }  
                    } else {  
                        z2 = true;  
                    }  
                    if (z2) {  
                        //...
                        nz.info("trycnt=%d", Integer.valueOf(i3));  
                        AbstractContext.terminate();  
                    }  
                }  
                Thread.sleep(10000L);  
            } catch (InterruptedException unused2) {  
                return;  
            }  
        }

简单来说：

这个线程会一直循环执行，且每隔 10 秒执行一次；
当 jU 的返回结果不为 0 时，且到达了最大的重试次数后，会发送失败事件，并关闭 JEB；
弹窗相关的文字以及日志信息是经过加密的，即 cns.nz 方法，猜测主要是为了防止黑客搜索关键字。不过并没有对所有字符串都进行加密，所以我们还是能搜到 HTTP 路径信息；

Patch

这里的 patch 思路就很多了，我们可以直接把线程 nop 掉，也可以只针对请求的地方，这里我们选择后者。

patch 方案也有几种，一是直接修改 class 字节码，不过这个流程相对复杂。我们可以先使用 arthas 生成 Java 代码，然后修改反编译的 Java 代码后重新进行编译、加载，如下所示：

jad --source-only com.pnfsoftware.jebglobal.aW > /tmp/aW.java
# 修改 aW.java jU 方法返回 0
# 重新编译
mc /tmp/aW.java
# 加载
redefine com/pnfsoftware/jebglobal/aW.class

如果想要进行持久化，那么只需要将 jeb.jar 解压并替换掉 aW.class 重新打包即可。

Java Agent

虽然重打包可以修改原始的程序代码逻辑，但却对原始代码进行了修改，jar 包的签名也进行了改变。如果目标程序本身有完整性校验很可能被检测出来。更好的方法就是使用 Java Agent 去对目标代码进行动态修改，即使用 JVM 本身的 -javaagent 参数注入一个 jar 去动态修改原始程序逻辑(或者通过动态 attach 的方式)。arthas 本身和常用的 RASP 都是基于这个原理。

关于 Java Agent 可以参考官方的文档，对于开发者而言只需要关注几个重点：

编译的 agent jar 通过 -javaagent:agent.jar 的方式进行指定，可以在程序启动之前加载；
agent.jar 中需要再 Manifest 指定 Premain-Class，指定的类包含 premain 方法，会在启动时被 JVM 调用；

一个示例 Agent 如下所示：

public class Agent {

    public static void log(String fmt, Object ...args) {
        System.out.printf("[agent] " + fmt + "\n", args);
    }

    public static void premain(String agentArgs, Instrumentation inst) {
        log("premain called.");
        if (!inst.isRetransformClassesSupported()) {
            log("Class retransformation is not supported.");
            return;
        }

        HookTransformer.replace(inst, "com.pnfsoftware.jebglobal.aW", "jU",
        """
        {
            System.out.println("[agent-hook] skip check.");
            return 0;
        }
        """);
    }

}

HookTransformer 是笔者写的一个粗糙的 ClassFileTransformer 实现。主要使用 javassist 动态生成字节码，并覆写 transform 方法替换目标 Class 的字节码，从而修改目标方法的实现。

完整的代码可以参考 HookAgent，为了方便以后每次逆向破解新项目的时候不用频繁编译，将待劫持的类名、方法名和方法体使用参数进行传递，同时将修改后的方法体保存在新文件中。

基于上述 HookAgent.jar，修改 JEB 自带的命令行参数 jvmopt.txt 即可实现注入：

cat jvmopt.txt
-Xmx16G --add-opens java.base/java.lang=ALL-UNNAMED -Xverify:none -javaagent:HookAgent.jar=className=com.pnfsoftware.jebglobal.aW;methodName=jU;methodImplFile=hook.js

随后启动 JEB 观察日志可以看到 agent 成功注入，并且 agent 的日志也每隔 10 秒输出一次：

./jeb_linux.sh
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
[agent] premain enter, agentArgs=className=com.pnfsoftware.jebglobal.aW;methodName=jU;methodImplFile=hook.js
[agent] Parsing hook options from agentArgs: className=com.pnfsoftware.jebglobal.aW;methodName=jU;methodImplFile=hook.js
[agent] Reading methodImpl from hook.js
[agent] Loaded com.pnfsoftware.jebglobal.aW->jU: {
    System.out.println("[agent-hook] skip check: " + new java.util.Date());
    return 0;
}
...
[agent] CtMethod: javassist.CtMethod@31736c[private jU ()J]
[agent] byteCode size: 5899
[agent] Hooked: com.pnfsoftware.jebglobal.aW->jU
[I] JEB 5.12.xxx (jeb-pro-floating) is starting...
[I] Memory Usage: 44.1M used (475.9M free, 16.0G max)
[agent] transform: com.pnfsoftware.jebglobal.aW->jU
[agent-hook] skip check: Thu May 02 20:15:49 CST 2024
[agent-hook] skip check: Thu May 02 20:15:59 CST 2024

这里是将循环检查的方法返回值固定成了 0，但实际上可以选择的点很多，比如直接 hook 这个 Runnable 的 run 方法也是可以的。

总结

本文主要以 JEB Floating License 的校验过程为例，学习了 Java PC 客户端应用的一般分析方法。在反编译和逆向分析的基础上，配合动态调试或者 Arthas 等动态分析框架，可以快速找到目标执行路径。随后可以使用静态重打包或者 Java Agent 动态注入的方式去实现代码逻辑修改的持久化，从而实现“破解”的效果。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/05/03/java-agent/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

初探 Struts2 框架安全

Wed, 01 Nov 2023 08:40:00 +0800

最近分析 confluence 的漏洞，发现是基于 Struts 框架的，其中有很多相关知识点并不了解，因此专门来学习一下 Struts 2。

背景

在网上一搜 Struts 2 资料发现介绍漏洞的文章比介绍开发的还多，少数开发者的声音也是 “Struts 过时了吗？” 之类的疑问，事实上这个框架也确实是过时了，现在Java Web 开发早已是 Spring 全家桶一统江山的局面。但我们也不能不承认曾经 Struts 的地位。Struts2 + Spring + Hibernate 三大框架在当年组合号称 SSH，对 Java Web 应用生态产生了深远的影响，以至于现在有许多知名应用中还有 Struts 的影子。

因此，即便 Struts 已经日薄西山，对于 Java 安全研究者而言也是需要深入了解的目标，就像二进制研究员需要理解 “过时” 的 jmp esp 栈溢出利用方法一样。

Struts 101

分析 Struts 内部细节之前我们先从开发的角度看 Struts 应用的基本构建和使用过程。

在 Struts 官网中提供了对应的开发文档，如 Getting Start。同时也提供了具体的代码示例。

值得一提的是 Struts 的文档还提供了针对开发者的一些预备知识，见 Key Technologies Primer。其中包括了许多 JavaEE 的基本知识，想当初刚出门 Java 的时候要是能看到这份文档估计能少走不少弯路。

基本结构

Struts 应用也是一个 JavaEE 应用，因此同样基于 Servlet API。有趣的是它不像 Spring 等其他 Web 框架将功能插入到 Servlet 中(DispatchServlet)，而是插入到 Filter 中，如下所示:


 id="WebApp_ID" version="2.4"
	xmlns="http://java.sun.com/xml/ns/j2ee" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
	Basic Struts2
	
		struts2
		org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter
	

	
		struts2
		/*
	

	
		index

插入的 StrutsPrepareAndExecuteFilter 同样也可以实现接管所有请求的目的。在接管所有请求后，使用 struts.xml 作为 Struts 自身的路由映射配置，一个简单的示例如下:


    "-//Apache Software Foundation//DTD Struts Configuration 2.5//EN"
    "http://struts.apache.org/dtds/struts-2.5.dtd">



     name="struts.devMode" value="true" />

     name="basicstruts2" extends="struts-default">
         name="index">
            /index.jsp

注意该文件保存在 src/main/resources 中，类似于 log4j2.xml。上述配置指定 /index、/index.action 都会被路由到 index.jsp 上。

设计模式

看 Struts 的示例代码可以很明显的 MVC 设计风格，以 helloworld 为例，其中包含一个 Controller，又称为 Action:

import com.opensymphony.xwork2.ActionSupport;

public class HelloWorldAction extends ActionSupport {

    private MessageStore messageStore;

    public String execute() {
        messageStore = new MessageStore() ;
        
        return SUCCESS;
    }

    public MessageStore getMessageStore() {
        return messageStore;
}

Action 中通常包含具体的数据源，比如上面的 MessageStore (POJO)，这个数据源即是 Model。在 struts.xml 中指定 Action 的路由，并链接到具体的 JSP 上，此为 View 部分:

 name="hello" class="org.apache.struts.helloworld.action.HelloWorldAction" method="execute">
     name="success">/HelloWorld.jsp

如果没有指定，会默认访问 execute 返回值对应的 JSP，如 WEB-INF/content/hello-success.jsp。

标签表示如果 HelloWorldAction.execute 返回 “success” (即 Action.SUCCESS)，就将结果映射到 HelloWorld.jsp 上。

至此，Model-View-Controller 三要素都全了，访问 /hello 后即可进入到 Action 准备好数据，绑定到 JSP 的上下文中并根据需要渲染出来，HelloWorld.jsp 如下:


<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
<%@ taglib prefix="s" uri="/struts-tags" %>

  
    
    Hello World!

其中使用 JavaBean 风格的表达式获取获取具体的属性 messageStore.message，其背后访问的是 Java 对象的 getter 方法。

内部实现

接下来我们深入到 Struts 的内部实现中。先粘贴一个经典的图片:

前面我们说过，Struts 应用的 web.xml 会添加一个 Filter StrutsPrepareAndExecuteFilter，因此用户请求进来的时候是依照 FilterChain 的顺序依次调用注册的 Filter，直到 Struts 的 Filter。随后从左边开始，Struts 会将请求的 URL 转换为对应的 ActionProxy 去进行调用，这里有一步使用 ConfiguarationManager 去加载我们的配置 struts.xml，这里可能意味着一次懒加载，我们后文再根据实际的代码去分析。

调用 ActionProxy 的时候，会在开发者实际定义的 Action 前后依次调用 Interceptor，实现诸如过滤参数、打印日志、记录请求时间等操作。可以看到这里的架构设计还是很优雅的，开发者也可以定义和注册自己的 Interceptor 去实现鉴权等业务逻辑。

大致的调用流程就是这样，接下来我们通过代码去分析具体的调用逻辑。由于代码比较多，我们需要有的放矢，因此主要聚焦于 Struts 的调用逻辑实现、路由查找等关键功能。

如无特别说明，本文所涉及代码都基于 struts2-core-6.2.0 版本。

Filter

首先看详细的调用流程。我们可以从 StrutsPrepareAndExecuteFilter 的 doFilter 开始，也可以直接在 Controller 打个断点去至顶向下分析。不过我们这里用另一个方法, 在设置应用 struts.devMode=true 的情况下，访问一个不存在的 URL 会返回带调用栈的出错信息，如下所示:

com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:183)
org.apache.struts2.factory.StrutsActionProxy.prepare(StrutsActionProxy.java:57)
org.apache.struts2.factory.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:32)
com.opensymphony.xwork2.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:60)
org.apache.struts2.dispatcher.Dispatcher.createActionProxy(Dispatcher.java:694)
org.apache.struts2.dispatcher.Dispatcher.prepareActionProxy(Dispatcher.java:679)
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:642)
org.apache.struts2.dispatcher.ExecuteOperations.executeAction(ExecuteOperations.java:79)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.handleRequest(StrutsPrepareAndExecuteFilter.java:157)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.tryHandleRequest(StrutsPrepareAndExecuteFilter.java:140)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:128)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
...

可以看到末尾如我们所料，从 Tomcat 调用到了 StrutsPrepareAndExecuteFilter.doFilter，虽然这是一个 Filter 但却做的是 Servlet 的事情。顾名思义，其作用主要是准备和执行，准备和执行什么呢？当然是 Action，即 Controller。

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) res;

    try {
        prepare.trackRecursion(request);
        String uri = RequestUtils.getUri(request);
        if (prepare.isUrlExcluded(request, excludedPatterns)) {
            LOG.trace("Request: {} is excluded from handling by Struts, passing request to other filters", uri);
            chain.doFilter(request, response);
        } else {
            tryHandleRequest(chain, request, response, uri);
        }
    } finally {
        prepare.cleanupRequest(request);
    }
}

excludedPatterns 是 java.util.regex.Pattern 的列表，在此列表中的路径不会被 Struts 接管，而是直接放行到后续的 Filter 和 Servlet 处理。这里获取请求 URI 是通过 RequestUtils.getUri，并且以此 Uri 作为后续路由的重要依据。

getUri

org.apache.struts2.RequestUtils#getUri 的主要实现如下:

public static String getUri(HttpServletRequest request) {
    // handle http dispatcher includes.
    String uri = (String) request.getAttribute("javax.servlet.include.servlet_path");
    if (uri != null) {
        return uri;
    }

    uri = getServletPath(request);
    if (StringUtils.isNotEmpty(uri)) {
        return uri;
    }

    uri = request.getRequestURI();
    return uri.substring(request.getContextPath().length());
}

public static String getServletPath(HttpServletRequest request) {
    String servletPath = request.getServletPath();
    
    String requestUri = request.getRequestURI();
    // Detecting other characters that the servlet container cut off (like anything after ';')
    if (requestUri != null && servletPath != null && !requestUri.endsWith(servletPath)) {
        int pos = requestUri.indexOf(servletPath);
        if (pos > -1) {
            servletPath = requestUri.substring(requestUri.indexOf(servletPath));
        }
    }

    if (StringUtils.isNotEmpty(servletPath)) {
        return servletPath;
    }
    
    int startIndex = request.getContextPath().equals("") ? 0 : request.getContextPath().length();
    int endIndex = request.getPathInfo() == null ? requestUri.length() : requestUri.lastIndexOf(request.getPathInfo());

    if (startIndex > endIndex) { // this should not happen
        endIndex = startIndex;
    }

    return requestUri.substring(startIndex, endIndex);
}

按顺序看，其获取 URI 的优先级如下:

request.getAttribute(“javax.servlet.include.servlet_path”);
request.getServletPath();
request.getRequestURI() 通过 request.getServletPath() 计算的子字符串；
request.getRequestURI() 通过 request.getContextPath() 和 request.getPathInfo() 计算的子字符串；
request.getRequestURI() 通过 request.getContextPath() 计算的子字符串；

其中大部分情况下会落到 2 或者 3 的返回结果上。getServletPath 是容器最终用于寻址 Servlet 的路径，即经过 normalize 和删除路径参数等操作的结果，在 Tomcat 中还进行了 URL 解码，可以认为是相对安全的。但 Struts 拓展了 getServletPath 方法，还是从 requestURI 进行了一次判断并执行 substring 操作，因此我们可以很大程度上控制 getUri 的返回结果，至于有什么影响要看后面具体的路由逻辑。

请求处理

handleRequest 主要分成两个阶段，先是处理静态资源文件，然后才是对于动态路由的处理，如下所示:

private void tryHandleRequest(FilterChain chain, HttpServletRequest request, HttpServletResponse response, String uri) throws IOException, ServletException {
    LOG.trace("Checking if: {} is a static resource", uri);
    boolean handled = execute.executeStaticResourceRequest(request, response);
    if (!handled) {
        LOG.trace("Uri: {} is not a static resource, assuming action", uri);
        handleRequest(chain, request, response, uri);
    }
}

我们分别对二者进行分析。

静态资源

静态资源的处理逻辑主要是 executeStaticResourceRequest:

public boolean executeStaticResourceRequest(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
    // there is no action in this request, should we look for a static resource?
    String resourcePath = RequestUtils.getServletPath(request);

    if ("".equals(resourcePath) && null != request.getPathInfo()) {
        resourcePath = request.getPathInfo();
    }

    StaticContentLoader staticResourceLoader = dispatcher.getContainer().getInstance(StaticContentLoader.class);
    if (staticResourceLoader.canHandle(resourcePath)) {
        staticResourceLoader.findStaticResource(resourcePath, request, response);
        // The framework did its job here
        return true;

    } else {
        // this is a normal request, let it pass through
        return false;
    }
}

其中值得关注的点是对于静态资源路径，这里使用的是没有经过其他处理的 getServletPath。通过 StaticContentLoader 先判断是否可以处理对应路径:

// org.apache.struts2.dispatcher.DefaultStaticContentLoader#canHandle
public boolean canHandle(String resourcePath) {
    return serveStatic && resourcePath.startsWith(uiStaticContentPath + "/");
}

uiStaticContentPath 默认是 /static，可以由开发者自行配置。因此这里仅判断请求路径是否以 /static/ 开头，而没有判断文件是否存在。注意一旦 canHandle 返回 true，那么后续即便找不到资源也不会继续后续的动态路由查找，而是直接返回 404 结束请求。

DefaultStaticContentLoader#findStaticResource 基本上是使用 ClassLoader.getResource，但有一些特殊的处理:

public void findStaticResource(String path, HttpServletRequest request, HttpServletResponse response)
    throws IOException {
    String name = cleanupPath(path);
    for (String pathPrefix : pathPrefixes) {
        URL resourceUrl = findResource(buildPath(name, pathPrefix));
        if (resourceUrl != null) {
            InputStream is = null;
            try {
                //check that the resource path is under the pathPrefix path
                String pathEnding = buildPath(name, pathPrefix);
                if (resourceUrl.getFile().endsWith(pathEnding))
                    is = resourceUrl.openStream();
            } catch (IOException ex) {
                // just ignore it
                continue;
            }

            //not inside the try block, as this could throw IOExceptions also
            if (is != null) {
                process(is, path, request, response);
                return;
            }
        }
    }
    response.sendError(HttpServletResponse.SC_NOT_FOUND);
}

首先是 cleanupPath 对路径又做了一次清理，作用是删除 /static 前缀:

protected String cleanupPath(String path) {
    if (path.startsWith(uiStaticContentPath)) {
        return path.substring(uiStaticContentPath.length());
    } else {
        return path;
    }
}

然后是通过 pathPrefixes 数组去构建实际的资源路径去循环进行查找，动态调试 pathPrefixes 的值有:

org/apache/struts2/static/
template/
static/
org/apache/struts2/interceptor/debugging/

buildPath 的实现比较有意思:

protected String buildPath(String name, String packagePrefix) throws UnsupportedEncodingException {
    String resourcePath;
    if (packagePrefix.endsWith("/") && name.startsWith("/")) {
        resourcePath = packagePrefix + name.substring(1);
    } else {
        resourcePath = packagePrefix + name;
    }

    return URLDecoder.decode(resourcePath, encoding);
}

其中对组合的 URL 路径又进行了一次 URL 解码。根据我们之前的文章可知，HttpServletRequest.getServletPath 已经是经过一次 URL 解码的了，因此这里实际上进行了二次解码！

因此这里可能会出现路径穿越的问题，不过这里已经进行了额外的判断:

String pathEnding = buildPath(name, pathPrefix);
if (resourceUrl.getFile().endsWith(pathEnding))
    is = resourceUrl.openStream();

根据 commit 日志，发现这个修改确实也是为了修复路径穿越的问题，详见 WW-2779 Directory traversal vulnerability while serving static content。

不过，即便能绕过这里的检查，在 Servlet 容器层还有一层校验，以 Tomcat 为例，其会对超出根路径的静态资源请求抛出异常:

java.lang.IllegalArgumentException: 资源路径[/WEB-INF/classes/static/../../../../../etc/hosts]已规范化为无效的[null]
org.apache.catalina.webresources.StandardRoot.validate(StandardRoot.java:258)
org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:207)
org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:220)
org.apache.catalina.loader.WebappClassLoaderBase.findResource(WebappClassLoaderBase.java:954)
org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1078)
com.opensymphony.xwork2.util.ClassLoaderUtil.getResource(ClassLoaderUtil.java:108)
org.apache.struts2.dispatcher.DefaultStaticContentLoader.findResource(DefaultStaticContentLoader.java:305)
org.apache.struts2.dispatcher.DefaultStaticContentLoader.findStaticResource(DefaultStaticContentLoader.java:213)
org.apache.struts2.dispatcher.ExecuteOperations.executeStaticResourceRequest(ExecuteOperations.java:59)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.tryHandleRequest(StrutsPrepareAndExecuteFilter.java:137)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:128)

从中也可以看到 getResource 确实是通过 Tomcat 的 ClassLoader 实现的。

路由查找

如果前面判断目标路由不是静态资源，那么就会进行实际的路由查找和调用:

private void handleRequest(FilterChain chain, HttpServletRequest request, HttpServletResponse response, String uri) throws ServletException, IOException {
    prepare.setEncodingAndLocale(request, response);
    prepare.createActionContext(request, response);
    prepare.assignDispatcherToThread();

    HttpServletRequest wrappedRequest = prepare.wrapRequest(request);
    try {
        ActionMapping mapping = prepare.findActionMapping(wrappedRequest, response, true);
        if (mapping == null) {
            LOG.trace("Cannot find mapping for: {}, passing to other filters", uri);
            chain.doFilter(request, response);
        } else {
            LOG.trace("Found mapping: {} for: {}", mapping, uri);
            execute.executeAction(wrappedRequest, response, mapping);
        }
    } finally {
        prepare.cleanupWrappedRequest(wrappedRequest);
    }
}

这里看似分成了两步，findActionMapping 查找路由，executeAction 执行路由。但实际上 ActionMapping 只是一个简单的封装类，保存请求的路由(action)、命名空间(namespace)、后缀、请求参数等数据。实际从 URI 到 Action 的映射还是在 executeAction 中实现。

ActionMapping

findActionMapping 核心实现为 org.apache.struts2.dispatcher.mapper.DefaultActionMapper#getMapping:

public ActionMapping getMapping(HttpServletRequest request, ConfigurationManager configManager) {
    ActionMapping mapping = new ActionMapping();
    String uri = RequestUtils.getUri(request);

    int indexOfSemicolon = uri.indexOf(';');
    uri = (indexOfSemicolon > -1) ? uri.substring(0, indexOfSemicolon) : uri;

    uri = dropExtension(uri, mapping);
    if (uri == null) {
        return null;
    }

    parseNameAndNamespace(uri, mapping, configManager);
    handleSpecialParameters(request, mapping);
    extractMethodName(mapping, configManager);
    return parseActionName(mapping);
}

关键点如下:

使用 RequestUtils.getUri 获取 URI，前面介绍过这个方法，存在一定的可利用性；
手动删除分号，即删除最后一个分号及其之后的所有内容；
dropExtension 删除 URI 中的后缀，并设置 mapping.extension；
parseNameAndNamespace 负责设置设置 mapping.name 和 mapping.namespace；

parseNameAndNamespace 中通过遍历 Configuration#getPackageConfigs 里所有的 PackageConfig 配置，查找 URI 可能匹配的目标，然后获取其 namespace；而获取 actionName 的时候，是通过获取最后一个 / 之后的字符串作为名称，也就是说 URI / 之前的内容是不影响路由结果的:

// ...
if (!allowSlashesInActionNames) {
    int pos = actionName.lastIndexOf('/');
    if (pos > -1 && pos < actionName.length() - 1) {
        actionName = actionName.substring(pos + 1);
    }
}
mapping.setNamespace(cleanupNamespaceName(actionNamespace));
mapping.setName(cleanupActionName(actionName));

最后调用 setter 之前还调用了以下 cleanup 方法，这其中对名称进行了正则检查，以 cleanupActionName 为例:

protected String cleanupActionName(final String rawActionName) {
    if (allowedActionNames.matcher(rawActionName).matches()) {
        return rawActionName;
    } else {
        LOG.warn("{} did not match allowed action names {} - default action {} will be used!", rawActionName, allowedActionNames, defaultActionName);
        return defaultActionName;
    }
}

allowedActionNames 是 [a-zA-Z0-9._!/\-]*，对于不匹配的字符串，会直接返回默认的 defaultActionName，即 index。

handleSpecialParameters 使用前缀匹配请求参数的方式对一些特殊参数进行处理，主要是 org.apache.struts2.dispatcher.mapper.DefaultActionMapper 默认构造函数中注册的 action:* 以及 method:* 参数，用于调用自定义的 action 和方法。但是这两个默认配置都是不启用的，即便开启了动态调用，也需要开发者手动在中指定允许调用的方法名称。

parseActionName 中也有类似处理，如果支持动态方法(allowDynamicMethodCalls)，那么 actionName 可以是 foo!method 格式，通过感叹号指定要调用的方法。同时方法名通过 mapping.setMethod 进行设置。

ActionProxy

findActionMapping 提取出对应的 ActionMapping 信息之后，开始通过 executeAction 进行调用。回顾我们开头 404 页面返回的堆栈信息，可知在 ActionProxy.prepare 时进行实际 Controller(Action) 的查找。所谓 ActionProxy 实际是我们定义的 Action 的封装。

实际路由查找通过 DefaultConfiguration.RuntimeConfigurationImpl#getActionConfig 实现:

public ActionConfig getActionConfig(String namespace, String name) {
    ActionConfig config = findActionConfigInNamespace(namespace, name);

    // try wildcarded namespaces
    if (config == null) {
        NamespaceMatch match = namespaceMatcher.match(namespace);
        if (match != null) {
            config = findActionConfigInNamespace(match.getPattern(), name);

            // If config found, place all the matches found in the namespace processing in the action's parameters
            if (config != null) {
                config = new ActionConfig.Builder(config)
                        .addParams(match.getVariables())
                        .build();
            }
        }
    }

    // fail over to empty namespace
    if (config == null && StringUtils.isNotBlank(namespace)) {
        config = findActionConfigInNamespace("", name);
    }

    return config;
}

其中执行最终查找 ActionConfig 的方法是 findActionConfigInNamespace。注意上面的代码中依次有三种查找策略:

直接在 namespace 中精确查找 name；
如果没有找到，则判断是否定义正则匹配 patternMatcher，如果存在则使用模糊(正则)查找；
如果还没找到，则会在默认的空命名空间中查找。

在 Struts 官方文档中也有提及，见 Namespace Configuration 一节:

The default namespace is "" - an empty string. The default namespace is used as a “catch-all” namespace. If an action configuration is not found in a specified namespace, the default namespace is also be searched.

这个特性的目的是为了实现 local/global 的设计模式，即先查找局部路由实现，如果找不到就使用全局实现。注意这只是二阶段的查找，如果存在多级的命名空间如 /foo/bar/demo.action，在 /foo/bar 中查找不到 demo.action 后会直接跳到默认命名空间去查找，而不是跳到命名空间 /foo 进行查找。

private ActionConfig findActionConfigInNamespace(String namespace, String name) {
    ActionConfig config = null;
    if (namespace == null) {
        namespace = "";
    }
    Map<String, ActionConfig> actions = namespaceActionConfigs.get(namespace);
    if (actions != null) {
        config = actions.get(name);
        // Check wildcards
        if (config == null) {
            config = namespaceActionConfigMatchers.get(namespace).match(name);
            // fail over to default action
            if (config == null) {
                String defaultActionRef = namespaceConfigs.get(namespace);
                if (defaultActionRef != null) {
                    config = actions.get(defaultActionRef);
                }
            }
        }
    }
    return config;
}

这里主要是使用一个二级哈希表(namespaceActionConfigs)进行查找，其中第一级的 key 为 namespace，第二级的 key 则是实际路由的路径。

注意 namespaceActionConfigs 这个哈希表中包含 namespace 对应的所有 action，除了包含当前中定义的 action，还包括通过 extends 属性继承的父 package 中的所有 action。这也是一个路由的变异特性，后面我们介绍 Confluence 的 CVE-2023-22518 时会详细分析。

当然也不仅仅是哈希表的精确匹配，二级的 action 查找也支持使用 ActionConfigMatchers 去进行通配符匹配。ActionConfig 中包含了执行 action 所需要的所有信息，包括 Action 的类名、方法名、结果映射、拦截器列表等。

org.apache.struts2.dispatcher.Dispatcher#serviceAction 可以理解为分发请求的枢纽，获取到 ActionProxy 后负责进行调用并处理可能的异常结果:

    public void serviceAction(HttpServletRequest request, HttpServletResponse response, ActionMapping mapping)
        throws ServletException {
// ...
try {
    ActionProxy proxy = prepareActionProxy(extraContext, actionNamespace, actionName, actionMethod);
    if (mapping.getResult() != null) {
        Result result = mapping.getResult();
        result.execute(proxy.getInvocation());
    } else {
        proxy.execute();
    }

    } catch (ConfigurationException e) {
        logConfigurationException(request, e);
        sendError(request, response, HttpServletResponse.SC_NOT_FOUND, e);
    } catch (Exception e) {
        if (handleException || devMode) {
            if (devMode) {
                LOG.debug("Dispatcher serviceAction failed", e);
            }
            sendError(request, response, HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e);
        } else {
            throw new ServletException(e);
        }
    }
}

在 DefaultActionInvocation#invoke 中进行了拦截器和 Action 的调用:

public String invoke() throws Exception {
    // ...
    if (interceptors.hasNext()) {
        // 见下节 ...
    } else {
        resultCode = invokeActionOnly();
    }
}

Interceptors 依次调用完后，后续会调用 invokeActionOnly 去调用我们实际的 Action，这里贴一下后续的调用栈，Register 为我们定义的 ActionSupport 示例:

execute:26, Register (org.apache.struts.register.action)
invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
invoke:566, Method (java.lang.reflect)
invokeMethodInsideSandbox:1245, OgnlRuntime (ognl)
invokeMethod:1230, OgnlRuntime (ognl)
callAppropriateMethod:1958, OgnlRuntime (ognl)
callMethod:68, ObjectMethodAccessor (ognl)
callMethodWithDebugInfo:98, XWorkMethodAccessor (com.opensymphony.xwork2.ognl.accessor)
callMethod:90, XWorkMethodAccessor (com.opensymphony.xwork2.ognl.accessor)
callMethod:2034, OgnlRuntime (ognl)
getValueBody:97, ASTMethod (ognl)
evaluateGetValueBody:212, SimpleNode (ognl)
getValue:258, SimpleNode (ognl)
getValue:586, Ognl (ognl)
getValue:550, Ognl (ognl)
lambda$callMethod$2:593, OgnlUtil (com.opensymphony.xwork2.ognl)
execute:-1, 1400623756 (com.opensymphony.xwork2.ognl.OgnlUtil$$Lambda$300)
compileAndExecuteMethod:636, OgnlUtil (com.opensymphony.xwork2.ognl)
callMethod:593, OgnlUtil (com.opensymphony.xwork2.ognl)
invokeAction:434, DefaultActionInvocation (com.opensymphony.xwork2)
invokeActionOnly:307, DefaultActionInvocation (com.opensymphony.xwork2)
invoke:259, DefaultActionInvocation (com.opensymphony.xwork2)
// ...

值得一提的是，对于 Action 的调用，实际也是通过 OGNL 执行的:

protected String invokeAction(Object action, ActionConfig actionConfig) throws Exception {
    String methodName = proxy.getMethod();

    LOG.debug("Executing action method = {}", methodName);
    Object methodResult;
    methodResult = ognlUtil.callMethod(methodName + "()", getStack().getContext(), action);
    // ...
}

这样的好处是提供一定的灵活性，可以在配置文件中或者动态指定所要调用的 Action 方法，但同时也引入了一定的安全隐患。最初这里是使用 OgnlUtil::getValue() 来进行调用，在 S2-032、S2-033 和 S2-037 这几个漏洞之后才使用 callMethod 进行替换。callMethod 内部会执行 checkSimpleMethod 检查从而防止 OGNL 注入攻击，详见 CVE-2018-11776: How to find 5 RCEs in Apache Struts with CodeQL。

Interceptors

回顾本节开头的大图，在 ActionProxy 调用过程中，Interceptors(拦截器) 起到了重要的作用，关于拦截器的实现和作用可以参考官方的资料:

前文说过在 DefaultActionInvocation#invoke 中进行了拦截器和 Action 的调用:

public String invoke() throws Exception {
    // ...
    if (interceptors.hasNext()) {
        final InterceptorMapping interceptorMapping = interceptors.next();
        Interceptor interceptor = interceptorMapping.getInterceptor();
        if (interceptor instanceof WithLazyParams) {
            interceptor = lazyParamInjector.injectParams(interceptor, interceptorMapping.getParams(), invocationContext);
        }
        if (interceptor instanceof ConditionalInterceptor) {
            resultCode = executeConditional((ConditionalInterceptor) interceptor);
        } else {
            LOG.debug("Executing normal interceptor: {}", interceptorMapping.getName());
            resultCode = interceptor.intercept(this);
        }
    } else {
        resultCode = invokeActionOnly();
    }
}

Interceptors 依次调用完后，后续会调用 invokeActionOnly 去调用我们实际的 Action。

这里 interceptors 属性是个 InterceptorMapping 数组，只有三个关键属性:

public class InterceptorMapping implements Serializable {
    private String name;
    private Interceptor interceptor;
    private final Map<String, String> params;
}

一部分拦截器是开发者注册的，另外一部分则是 Struts 框架默认加入的，定义在 struts-default.xml 中。name 为拦截器的友好名称，params 则提供了一定程度上针对该拦截器的配置能力。

上述调用看似是循环，但实际上却使用的是递归，因为在 Interceptor 中为了实现分别在 action 之前和之后执行代码，会调用 ActionInvocation.invoke()，即 intercept() 的第一个参数，用于调用下一个拦截器或者是 Action。

以我们最常见的 ParametersInterceptor 为例，其继承自 MethodFilterInterceptor，最终会调用到下述 doIntercept 方法:

public String doIntercept(ActionInvocation invocation) throws Exception {
    // ...
    ActionContext ac = invocation.getInvocationContext();
    HttpParameters parameters = retrieveParameters(ac);
    if (parameters != null) {
        Map<String, Object> contextMap = ac.getContextMap();
        try {
            ReflectionContextState.setCreatingNullObjects(contextMap, true);
            ReflectionContextState.setDenyMethodExecution(contextMap, true);
            ReflectionContextState.setReportingConversionErrors(contextMap, true);

            ValueStack stack = ac.getValueStack();
            setParameters(action, stack, parameters);
        } finally {
            ReflectionContextState.setCreatingNullObjects(contextMap, false);
            ReflectionContextState.setDenyMethodExecution(contextMap, false);
            ReflectionContextState.setReportingConversionErrors(contextMap, false);
        }
    }
    return invocation.invoke();
}

setParameters 经过一系列调用，最终使用 ognl.Ognl#setValue 对请求上下文进行赋值，即通过请求参数实现调用 Action 中定义的 setter 设置对应 POJO 对象的值，从而完成从 HTTP 到 Java 的参数绑定。

// com.opensymphony.xwork2.ognl.OgnlUtil#setValue
public void setValue(final String name, final Map<String, Object> context, final Object root, final Object value) throws OgnlException {
    compileAndExecute(name, context, (OgnlTask<Void>) tree -> {
        if (isEvalExpression(tree, context)) {
            throw new OgnlException("Eval expression/chained expressions cannot be used as parameter name");
        }
        if (isArithmeticExpression(tree, context)) {
            throw new OgnlException("Arithmetic expressions cannot be used as parameter name");
        }
        Ognl.setValue(tree, context, root, value);
        return null;
    });
}

注意其中使用了 OGNL 作为参数绑定的实现，因此在参数名、参数值中都可能出现 OGNL 注入。相较之下 Spring Framework 则是通过反射来实现参数绑定，虽然代码实现更繁琐，但也确实更安全一些。

OGNL

Struts 在许多地方都用到了 OGNL 作为表达式去实现功能，历史上也出现过许多 OGNL 注入相关的漏洞。

除了修复漏洞点本身，Strtus 也对 OGNL 引擎做了一些拓展，比如实现 ognl.MemberAccess 为 SecurityMemberAccess 来管理 OGNL 的一些敏感操作。

关于 Struts OGNL 相关漏洞以及修复历史，已经有很多优秀的介绍文章了，感兴趣可以参考:

我们直接说现状，在当前版本中，SecurityMemberAccess 包含一系列黑名单来防止敏感类、包名的访问，同时配置禁止访问静态变量:

public class SecurityMemberAccess implements MemberAccess {
    private final boolean allowStaticFieldAccess;
    private Set<Pattern> excludeProperties = Collections.emptySet();
    private Set<Pattern> acceptProperties = Collections.emptySet();
    private Set<Class> excludedClasses = Collections.emptySet();
    private Set<Pattern> excludedPackageNamePatterns = Collections.emptySet();
    private Set<String> excludedPackageNames = Collections.emptySet();
    private Set<Class> excludedPackageExemptClasses = Collections.emptySet();
    private boolean disallowProxyMemberAccess;
    // ...
}

SecurityMemberAccess#isAccessible 中指定了访问的 member(Method) 限制:

禁止访问非 public 的 member；
禁止访问静态 field member，即静态属性，可通过 disallowProxyMemberAccess 配置；
禁止访问静态 method member，即静态方法；
检查 isClassExcluded 黑名单；
检查 isPackageExcluded 黑名单；
禁止访问 ProxyMember，可通过 disallowProxyMemberAccess 配置；

这些名单的设置是在 OgnlUtil#createDefaultContext 中:

protected Map<String, Object> createDefaultContext(Object root, ClassResolver classResolver) {
    ClassResolver resolver = classResolver;
    if (resolver == null) {
        resolver = container.getInstance(CompoundRootAccessor.class);
    }

    SecurityMemberAccess memberAccess = new SecurityMemberAccess(allowStaticFieldAccess);
    memberAccess.setDisallowProxyMemberAccess(disallowProxyMemberAccess);

    if (devMode) {
        if (!warnReported.get()) {
            warnReported.set(true);
            LOG.warn("Working in devMode, using devMode excluded classes and packages!");
        }
        memberAccess.setExcludedClasses(devModeExcludedClasses);
        memberAccess.setExcludedPackageNamePatterns(devModeExcludedPackageNamePatterns);
        memberAccess.setExcludedPackageNames(devModeExcludedPackageNames);
        memberAccess.setExcludedPackageExemptClasses(devModeExcludedPackageExemptClasses);
    } else {
        memberAccess.setExcludedClasses(excludedClasses);
        memberAccess.setExcludedPackageNamePatterns(excludedPackageNamePatterns);
        memberAccess.setExcludedPackageNames(excludedPackageNames);
        memberAccess.setExcludedPackageExemptClasses(excludedPackageExemptClasses);
    }

    return Ognl.createDefaultContext(root, memberAccess, resolver, defaultConverter);
}

调用时机是第一次使用 OgnlUtil 设置属性即应用启动并载入 struts.xml 中的 interceptors 的时候。这些列表的值通过属性定义在 struts 源码的配置文件中: core/src/main/resources/struts-excluded-classes.xml。例如 excludedClasses:

 name="struts.excludedClasses"
            value="
            java.lang.Object,
            java.lang.Runtime,
            java.lang.System,
            java.lang.Class,
            java.lang.ClassLoader,
            java.lang.Shutdown,
            java.lang.ProcessBuilder,
            java.lang.Thread,
            sun.misc.Unsafe,
            com.opensymphony.xwork2.ActionContext"/>

当然更严格的限制还是 excludedPackageNames，通过包名前缀去限制 OGNL 的访问。注意 excludedPackageNamePatterns 目前实际上是无用的，属于是历史遗留产物，因为前者现在已经替代了正则表达式的黑名单。

历史上的 OGNL 攻防花样百出，有尝试通过调用构造函数执行命令的，有尝试通过 OGNL 修改配置开启静态方法的，也有通过配置修改黑名单的，本质上还是想绕过上述 isAccessible 的限制。从目前的情况来看，Struts 对于 OGNL 的防御还是基于黑名单，那么是否能够完全防御代码注入攻击呢？这个就见仁见智了。

如果想要测试 Struts 的 OGNL 沙箱，可以在 struts.devMode 为 true 的情况下，直接通过请求任意路由加 debug 参数去执行 OGNL 代码:

curl 'http://localhost:8888/basic_struts_war/index.action' --data-raw 'debug=command&expression=3*4'

CVE-2023-22515

文章开头的时候说了，笔者研究 Struts 主要是因为最近碰到了 confluence 的这个漏洞。confluence 由 Atlassian 开发是一个知识库管理服务，支持本地部署，其 Web 框架主要基于 Struts 2。

关于该漏洞的详细分析可以参考下面的文章:

这里笔者对其中的细节就不过多复述了，而是结合 Struts 的特性来补充一些前置知识。

前面说过，Struts 中有许多 Interceptors 在 Action 前后会被进行调用，其中 ParametersInterceptor 尤为特殊，因为其会自动将 HTTP 的请求参数绑定到 Java bean 上，这是 XWork 框架的一大特性，但同时也带来了潜在的安全问题。因为这种情况下用户定义的 Action 中只要有 public getter 的属性都可能被 HTTP 请求进行访问和修改，甚至支持多级复杂的操作。

Confluence 的开发者作为 Struts 资深用户，自然早已知道这个问题，因此特地引入了 SafeParametersInterceptor 用于替换原始的 ParametersInterceptor。按照其设想，只有主动添加了 @ParameterSafe 的参数才能进行复杂操作，这个 annotation 可以加在 POJO 类的定义上，也可以加到 Action 中的 getter 上，比如:

@ParameterSafe
public FormData getFormData() { 
   return formData; 
}

或者:

@ParameterSafe
public class FormData {
   // ...
}

详见 XWork Plugin Complex Parameters and Security - Atlassian Developer。

只可惜，在近期的某个版本更新中，SafeParametersInterceptor 的实现出现了逻辑错误，导致参数过滤实际并不生效。因此攻击者通过查找合适的 Action，并且通过其中的 getter/setter 逐级访问，最终修改了重要的内存设置，使得攻击者可以成功发起添加管理员的请求。

虽然漏洞已经修复，但从中我们依然可以学习到一些重要的经验:

对于 Struts Action 公开 getter 属性所返回的对象要重点关注，尤其注意这些对象中带有的 setter 方法；
有些对象可能带有隐含的 getter 和 setter 方法，比如 Lombok 修饰的对象或者 Spring Bean 等，这类属性可能会被开发者忽略；
单元测试/回归测试很重要，如果 SafeParametersInterceptor 带有正确的单元测试，那将可以将这类严重的逻辑问题扼杀在摇篮中；

CVE-2023-22518

我们在前面分析 ActionProxy 查找时说到 namespaceActionConfigs 哈希表中包含 namespace 对应的所有 action，除了包含当前中定义的 action，还包括通过 extends 属性继承的父 package 中的所有 action。

例如，对于 CVE-2023-22518 漏洞而言，在 struts.xml 中有以下配置:

 name="default">
 name="setup" extends="default" namespace="/setup">
     name="setup-restore" class="com.atlassian.confluence.importexport.actions.SetupRestoreAction">
    

 name="admin" extends="setup" namespace="/admin">
     name="console" class="com.atlassian.confluence.admin.actions.AdministrationConsoleAction" method="doDefault">
    

 name="json" extends="admin" namespace="/json">

那么请求 /json/console 实际上可以路由到 /admin/console，而请求 /json/setup-restore 也可以路由到 /setup/setup-restore! 这显然不是开发者所预期的 URI 路径，因此如果鉴权时没有考虑这个场景，就有可能造成漏洞。

在本次更新中，对于这类问题的修复是增加了两个注解 @SystemAdminOnly 和 @WebSudoRequired，例如对于 SetupRestoreAction 的更新如下:

diff --git a/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java b/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java
index 8b64751..6c307ce 100644
--- a/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java
+++ b/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java
@@ -1,5 +1,6 @@
 package com.atlassian.confluence.importexport.actions;

+import com.atlassian.confluence.impl.security.SystemAdminOnly;
 import com.atlassian.confluence.importexport.DefaultImportContext;
 import com.atlassian.confluence.importexport.ImportExportException;
 import com.atlassian.confluence.importexport.impl.ExportDescriptor;
@@ -8,6 +9,7 @@ import com.atlassian.confluence.importexport.impl.UnexpectedImportZipFileContent
 import com.atlassian.confluence.tenant.OpenTenantGateLongRunningTask;
 import com.atlassian.confluence.util.HtmlUtil;
 import com.atlassian.core.task.longrunning.LongRunningTask;
+import com.atlassian.sal.api.websudo.WebSudoRequired;
 import com.atlassian.xwork.HttpMethod;
 import com.atlassian.xwork.PermittedMethods;
 import com.atlassian.xwork.RequireSecurityToken;
@@ -16,6 +18,8 @@ import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;

 @Deprecated
+@WebSudoRequired
+@SystemAdminOnly
 public class SetupRestoreAction extends RestoreAction {
    private static final Logger log = LoggerFactory.getLogger(SetupRestoreAction.class);

当然还有很多其他的 Action 也做了修复，关于该漏洞的细节比如 Confluence 的鉴权实现和漏洞利用流程，可以参考其他的文章，本文仅讨论 Struts 本身。除了上面这类继承导致的路由错配，还有前面说过的默认命名空间作为兜底也会匹配其他命名空间找不到的 action，这对自己实现 URI 鉴权的开发者而言是一个需要注意的陷阱。

Debugging Tips

前面大致介绍了 Struts 的内部实现，从中我们可以通过对框架的深入理解来给日常的工作进行提效。例如在对基于 Struts 的应用进行安全审计时，一个常见的任务是获取所有路由列表。根据前面的分析，我们有两个地方可以选择，一是在 PrepareOperations.findActionMapping 初步查找映射时，二是在 Dispatcher.prepareActionProxy 实际获取 ActionProxy 的时候。

这二者本质上都是从 ConfigurationManager 获取到实际的配置:

configManager.getConfiguration().getPackageConfigs()

getPackageConfigs 返回的 Map 对应每个 PackageConfig 及其名称。PackageConfig 表示的是 XML 配置中标签内的所有内容，其中就包括路由映射和拦截器配置等信息。其中一些 getter 定义如下:

getActionConfigs() - 返回 ActionConfig 列表即所有的路由信息；
getAllActionConfigs() - 同上，但同时包含父结点的路由信息；
getInterceptorConfigs()、getAllInterceptorConfigs() - 返回所有拦截器信息；
getNamespace() - 返回命名空间，在路由 URI 的前半部分，以最后一个 / 分隔，为空表示默认命名空间；
…

因此，只要能够获得 com.opensymphony.xwork2.config.Configuration 实例就能获取所有的 PackageConfig 信息，从而获得所有路由和拦截器信息。

Struts2 实际查找路由的实现是在下面的方法中:

com.opensymphony.xwork2.config.impl.DefaultConfiguration.RuntimeConfigurationImpl#getActionConfig

因此调试时候如果不确定请求的路由对应哪个 Action，可以在这里进行动态分析。

后记

一开始只是想要分析一下近期出现的 Confluence 漏洞 CVE-2023-22515 和 CVE-2023-22518，但分析过程中发现有许多 Struts 相关的知识点并不了解，因此就从头开始学习了一遍 Struts 的文档和部分源码实现。虽然现在该框架在新项目中使用不多，但也有一些亮眼的地方，比如拦截器的架构和参数绑定的功能，这些设计思想在许多后继者如 SpringMVC 中也继续发扬光大；但也有一些弊病比如强依赖 OGNL 和迷之路由查找也导致了许多安全问题，也许这就是其日渐衰落的原因吧。

Reference

EoF

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/11/01/struts2-internal/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

Fuzzing 在 Java 漏洞挖掘中的应用

Sat, 09 Sep 2023 12:40:00 +0800

前段时间泛微发布了 10.58.6 补丁，修复好几个笔者之前储备的 0day，本文就来介绍其中一系列比较有意思的漏洞，以及分享一下相关的挖掘思路。

背景

最近几个月笔者都在研究 Java Web 方向，一方面是工作职责的调整，另一方面也想挑战一下新的领域。对于漏洞挖掘而言，选择一个具体目标是非常重要的，经过一段时间供应链和生态的学习以及同事建议，兼顾漏洞挖掘难度和实战效果选择了泛微OA作为第一个漏洞挖掘的目标。

代码审计

虽然本文介绍的是 Fuzzing，但之前也说过很多次，自动化漏洞挖掘只能作为一种辅助手段，是基于自身对代码结构的理解基础上的提效方式。

在真正开始挖漏洞之前，笔者花了好几周的时间去熟悉目标的代码，并且对一些不清晰的动态调用去进行运行时分析，最终才能在 20G 代码之中梳理出大致的鉴权和路由流程。

本文介绍的就是其中红框中的漏洞

通过分析 JavaEE 应用注册的路由，注意到其中一个映射:

ServletMapping[url-pattern=/services/*, name=XFireServlet] ^/services(?=/)|^/services\z]

其对应的类为 org.codehaus.xfire.transport.http.XFireConfigurableServlet:


    XFireServlet
    XFire Servlet
    org.codehaus.xfire.transport.http.XFireConfigurableServlet


    XFireServlet
    /services/*

XFire 考古

XFire 并不是泛微自己的业务代码，而是一个 SOAP Web 服务框架，它是作为 Apache Axis 的有效替代方案而开发的。除了通过使用 StAX 实现良好性能的目标外，XFire 的目标还包括通过各种插件机制实现灵活性，API 的直观操作以及与通用标准的兼容性。此外 XFire 非常适合集成到基于 Spring Framework 的项目中。

值得一提的是，XFire 目前已经不再进行开发，其官方继任者是 Apache CXF。

XFire 的用法比较简单，首先在 META-INF/xfire/services.xml 中定义需要导出的服务，比如:



 xmlns="http://xfire.codehaus.org/config/1.0">
    
        WorkflowService
        webservices.services.weaver.com.cn
        weaver.workflow.webservices.WorkflowService
        weaver.workflow.webservices.WorkflowServiceImpl
        org.codehaus.xfire.annotations.AnnotationServiceFactory

这样 weaver.workflow.webservices.WorkflowService 就被认为是导出服务。

可以直接被客户端进行调用。调用方式主要是通过 SOAP 请求到 XFireServlet，例如调用上述服务可以发送 POST 请求到 /services/WorkflowService:


  
    
evilpan
2333

表示以指定参数调用服务的 getUserId 方法。

SQL 注入

接下来回到漏洞本身，WorkflowService 服务的具体实现为 WorkflowServiceImpl，例如其中的 getUserId 就是服务导出的一个方法，其具体实现为:

@Override
public String getUserId(String var1, String var2) {
    if (Util.null2String(var2).equals("")) {
        return "-1";
    } else if (Util.null2String(var1).equals("")) {
        return "-2";
    } else {
        RecordSet var3 = new RecordSet();
        var3.executeQuery("select id from HrmResource where " + var1 + "=? and status<4 ", var2);
        return !var3.next() ? "0" : Util.null2s(var3.getString("id"), "0");
    }
}

可以看到，一个教科书式的 SQL 注入就已经找到了。

Service 鉴权

现在漏洞点找到了，触发路径也找到了，可实际测试的时候发现这个接口有些特殊的鉴权，其鉴权逻辑为判断请求地址是否是内网地址，如果是的话就放行。

考虑到很多系统是集群部署的，且前面有一层或者多层负载均衡，因此实际请求服务的可能是经过反向代理的请求，此时客户端的真实 IP 只能通过 X-Forward-For 等头部获取。

这本来无可厚非，但是 HTTP 请求头是可以被攻击者任意设置的，因此泛微在此基础上进行了复杂的过滤，精简后的伪代码如下:

private String getRemoteAddrProxy() {
    String ip = null;
    String tmpIp = null;
    tmpIp = this.getRealIp(this.request.getHeaders("RemoteIp"), ipList);
    if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
        ip = tmpIp;
    }
    boolean isInternalIp = IpUtils.internalIp(ip);
    if (isInternalIp) {
    ipList.add(this.request.getRemoteAddr());
    tmpIp = IpUtils.getRealIp(ipList);
    if (!IpUtils.internalIp(tmpIp)) {
        ip = tmpIp;
    }
    }

    return ip != null && ip.length() != 0 && !"unknown".equalsIgnoreCase(ip) ? ip : null;
}

IpUtils#internalIp 的判断更为复杂，连 byte[] 都出来了:

public static boolean internalIp(String ip) {
    if (ip != null && !ip.equals("127.0.0.1") && !ip.equals("::1") && !ip.equals("0:0:0:0:0:0:0:1")) {
    if (ip.indexOf(":") != -1 && ip.indexOf(":") == ip.lastIndexOf(":")) {
        ip = ip.substring(0, ip.indexOf(":"));
    }

    byte[] addr = (byte[])null;
    if (isIpV4(ip)) {
        addr = textToNumericFormatV4(ip.trim());
    } else {
        addr = textToNumericFormatV6(ip.trim());
    }

    return addr == null ? false : internalIp(addr);
    } else {
    return true;
    }
}

public static boolean internalIp(byte[] addr) {
  byte b0 = addr[0];
  byte b1 = addr[1];
  byte SECTION_1 = true;
  byte SECTION_2 = true;
  byte SECTION_3 = true;
  byte SECTION_4 = true;
  byte SECTION_5 = true;
  byte SECTION_6 = true;
  switch (b0) {
    case -84:
      if (b1 >= 16 && b1 <= 31) {
        return true;
      }
    case -64:
      switch (b1) {
        case -88:
          return true;
      }
    default:
      return false;
    case 10:
      return true;
  }
}

其逻辑是对 getRemoteAddrProxy 取出来的 IP，如果路径匹配 webserviceList 且 IP 匹配 webserviceIpList 前缀，就认为是内网地址的请求从而进行放过:

webserviceList = [
   "/online/syncOnlineData.jsp",
   "/services/",
   "/system/MobileLicenseOperation.jsp",
   "/system/PluginLicenseOperation.jsp",
   "/system/InPluginLicense.jsp",
   "/system/InMobileLicense.jsp"
];

webserviceIpList = [
   "localhost",
   "127.0.0.1",
   "192.168.",
   "10.",
   "172.16.",
   "172.17.",
   "172.18.",
   "172.19.",
   "172.20.",
   "172.21.",
   "172.22.",
   "172.23.",
   "172.24.",
   "172.25.",
   "172.26.",
   "172.27.",
   "172.28.",
   "172.29.",
   "172.30.",
   "172.31."
]

根据上面的代码，你能发现鉴权绕过的漏洞吗？

Fuzzing

也许对代码比较敏感的审计人员可以通过上述鉴权代码很快发现问题，但说实话我一开始并没有找到漏洞。于是我想到这个鉴权逻辑是否能单独抽离出来使用 Fuzzing 的思路去进行自动化测试。

之前发现 Java 也有一个基于 libFuzzer 的模糊测试框架 Jazzer，但是试用之后发现比较鸡肋，因为和二进制程序会自动 Crash 不同，Java 的 fuzz 需要自己指定 Sink，令其在触达的时候抛出异常来构造崩溃。

虽然说没法发现通用的漏洞，但是对于现在这个场景来说正好是绝配，我们可以将目标原始的鉴权代码抠出来，然后在未授权通过的时候抛出一个异常即可。构建的 Test Harness 代码如下:

public static void fuzzerTestOneInput(FuzzedDataProvider data) {
    String poc = data.consumeRemainingAsString();
    fuzzIP(poc);
}

public static void fuzzIP(String poc) {
    if (containsNonPrintable(poc)) return;
    XssRequestWeblogic x = new XssRequestWeblogic();
    String out = x.getRemoteAddr(poc);
    boolean check2 = check2(out);
    if (check2) {
        throw new FuzzerSecurityIssueHigh("Found IP [" + poc + "]");
    }
}

public static boolean check2(String ipstr) {
    for (String ip: webserviceIpList) {
        if (ipstr.startsWith(ip)) {
            return true;
        }
    }
    return false;
}

其中精简了一些泛微代码中读取配置相关的依赖，将无关的逻辑进行手动剔除。

编译好代码后，使用以下命令开始进行 fuzz:

$ ./jazzer --cp=target/Test-1.0-SNAPSHOT.jar --target_class=org.example.App

不多一会儿，就已经有了一个成功的结果！

可以看到图中给出了 127.0.0.10 这个 payload，可以触发 IP 鉴权的绕过！反过来分析这个 PoC，可以发现之所以能绕过是因为 webserviceIpList 只检查了前缀，而 127.0.0.10 可以在 internalIp 返回 False，即认为不是内部 IP，但实际上 webserviceIpList 却认为是内部 IP，从而导致了绕过。

如果只是从代码上去分析的话，可能一时半会并不一定能发现这个问题，可是通过 Fuzzing 在覆盖率反馈的加持下，却可以在几秒钟之内找到正解，这也是人工审计无法比拟的。

漏洞补丁

通过 IP 的鉴权绕过和 XFire 组件的 SQL 注入，笔者实现了多套前台的攻击路径，并且在 HW 中成功打入多个目标。因为当时提交的报告中带了漏洞细节，因此这个漏洞自然也就被官方修补了。如果没有公开的话这个洞短期也不太会被撞到。

漏洞修复的关键补丁如下:

diff --git a/src/weaver/security/webcontainer/IpUtils.java b/src/weaver/security/webcontainer/IpUtils.java
index 6b3d8efc..e7482511 100644
--- a/src/weaver/security/webcontainer/IpUtils.java
+++ b/src/weaver/security/webcontainer/IpUtils.java
@@ -48,12 +48,16 @@ public class IpUtils {
    }

    public static boolean internalIp(String ip) {
-      if (ip != null && !ip.equals("127.0.0.1") && !ip.equals("::1") && !ip.equals("0:0:0:0:0:0:0:1")) {
+      if (ip == null || ip.equals("127.0.0.1") || ip.equals("::1") || ip.equals("0:0:0:0:0:0:0:1")) {
+         return true;
+      } else if (ip.startsWith("127.0.0.")) {
+         return true;
+      } else {
          if (ip.indexOf(":") != -1 && ip.indexOf(":") == ip.lastIndexOf(":")) {
             ip = ip.substring(0, ip.indexOf(":"));
          }

其中把 equals 换成了 startsWith，并且还过滤了我们之前使用的 WorkflowService 组件。当然还是沿袭泛微一贯的漏洞修复原则，不改业务代码，只增加安全校验，这也是对历史遗留问题的一种妥协吧。

总结

对于 Java 这样的内存安全编程语言也是可以 fuzz 的，只不过目的是找出逻辑漏洞而不是内存破坏；
漏洞挖掘初期花时间投入到代码审计中是有必要的，有助于理解项目整体结构并在后期进行针对性覆盖；
漏洞挖掘的时候重点关注边界的系统和服务，处于信任边界之外的组件更有可能过于信任外部输入导致安全问题；
对于看起来很复杂的数据处理模块，可以充分利用 Fuzzing 的优势，帮助我们快速找出畸形的 payload；
模块化 Fuzzing 的难点在于抽离代码并构建可编译或者可以独立运行的程序，即构建 Test Harness，跑起来测试用例你就已经成功了 90%；
软件开发和漏洞挖掘正好相反。开发者会出于厌恶情绪刻意避开复杂的历史遗留代码，而这些代码却是更可能出现问题的地方。因此安全研究员要学会克服自己的厌恶情绪，做到 —— “明知山有屎，偏向屎山行”。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/09/09/java-fuzzing/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

URL 解析与鉴权中的陷阱 —— Spring 篇

Sat, 19 Aug 2023 12:40:00 +0800

在上一篇文章中介绍了 Java Web 应用中 URL 解析与鉴权认证中的常见陷阱，但主要针对 Servlet 容器进行分析。前文末尾也提到了，当前 Web 应用多是使用 Spring 全家桶进行开发，其路由匹配方式又与传统 Web 容器有所差异，因此本文就对其进行分析。

DispatcherServlet

新建一个 Spring 项目，通过 start.spring.io 去勾选需要的依赖，然后下载 Maven 或者 Gradle 的工程目录文件，在其中添加自己的业务代码去构建应用。在本节中主要使用 spring-boot-starter-web 为起始工程进行代码编写和分析。

国内用户可以通过 start.springboot.io 镜像进行加速。

默认的项目使用的是 Tomcat 作为 Servlet 容器，因此我们可以利用前一篇文章的知识去快速定位容器中的路由情况。在 org.apache.catalina.mapper.Mapper#internalMapWrapper 中打下断点，查看所有已经注册的 Servlet，发现 exactWrappers、wildcardWrappers、extensionWrappers 等都为空数组，因此路由时会进入到 defaultWrapper，其对应类名为 org.springframework.web.servlet.DispatcherServlet。

我写了个简单的 Controller，如下所示:

@RestController
@RequestMapping("/bind")
public class BinderController {
    @GetMapping("str")
    String bindString(String p) {
        return "Bind: " + p;
    }
}

在 bindString 中下断点，触发后查看调用栈，截取前半部分如下:

bindString:25, BinderController (com.example.springbootdemo)
invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:77, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
invoke:568, Method (java.lang.reflect)
doInvoke:207, InvocableHandlerMethod (org.springframework.web.method.support)
invokeForRequest:152, InvocableHandlerMethod (org.springframework.web.method.support)
invokeAndHandle:118, ServletInvocableHandlerMethod (org.springframework.web.servlet.mvc.method.annotation)
invokeHandlerMethod:884, RequestMappingHandlerAdapter (org.springframework.web.servlet.mvc.method.annotation)
handleInternal:797, RequestMappingHandlerAdapter (org.springframework.web.servlet.mvc.method.annotation)
handle:87, AbstractHandlerMethodAdapter (org.springframework.web.servlet.mvc.method)
doDispatch:1081, DispatcherServlet (org.springframework.web.servlet)
doService:974, DispatcherServlet (org.springframework.web.servlet)
processRequest:1011, FrameworkServlet (org.springframework.web.servlet)
doGet:903, FrameworkServlet (org.springframework.web.servlet)
service:564, HttpServlet (jakarta.servlet.http)
service:885, FrameworkServlet (org.springframework.web.servlet)
service:658, HttpServlet (jakarta.servlet.http)
// ...

DispatcherServlet 继承自 FrameworkServlet，实现了标准的 Java EE Servlet 接口，因此最初是调用到了 HttpServlet 的 service 方法接口。实际预处理请求以及路由(分发)的方法为 doService，关键代码如下:

protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception {
    logRequest(request);
    // ...
    if (this.parseRequestPath) {
		previousRequestPath = (RequestPath) request.getAttribute(ServletRequestPathUtils.PATH_ATTRIBUTE);
		ServletRequestPathUtils.parseAndCache(request);
	}
	try {
		doDispatch(request, response);
	}
    // ...
}

parseAndCache 中对使用 setAttribute 保存请求 URL:

public static RequestPath parseAndCache(HttpServletRequest request) {
    RequestPath requestPath = ServletRequestPath.parse(request);
    request.setAttribute(PATH_ATTRIBUTE, requestPath);
    return requestPath;
}

属性的 key 为 PATH_ATTRIBUTE，对应字符串是 org.springframework.web.util.ServletRequestPathUtils.PATH，在后面 doDispatch 进行路由查找的时候使用 getAttribute 获取对应 URL 再进行查找。

在实际调试的时候发现，如果一次 HTTP 请求出错的话，doService 会调用两次，这是因为 Spring 在遇到错误时会将 response 设置为错误返回，然后 Tomcat 会根据配置的自定义错误页面进行再次分发，相应的逻辑在 org.apache.catalina.core.StandardHostValve#invoke:

public void invoke(Request request, Response response) throws IOException, ServletException {
    // ...
    if (!response.isErrorReportRequired()) {
        context.getPipeline().getFirst().invoke(request, response); // 第一次调用
    }
    response.setSuspended(false);
    Throwable t = (Throwable) request.getAttribute(RequestDispatcher.ERROR_EXCEPTION);
    // Look for (and render if found) an application level error page
    if (response.isErrorReportRequired()) {
        // If an error has occurred that prevents further I/O, don't waste time
        // producing an error report that will never be read
        AtomicBoolean result = new AtomicBoolean(false);
        response.getCoyoteResponse().action(ActionCode.IS_IO_ALLOWED, result);
        if (result.get()) {
            if (t != null) {
                throwable(request, response, t);
            } else {
                status(request, response); // 第二次调用
            }
        }
    }
}

错误请求的路由是 /error，因此在第二次请求时会看到 getRequestURI 返回的就是 /error。

doDispatch

DispatcherServlet#doDispatch 的核心简化实现如下:

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
    processedRequest = checkMultipart(request);
    HandlerExecutionChain mappedHandler = getHandler(processedRequest);
    if (mappedHandler == null) {
        noHandlerFound(processedRequest, response);
        return;
    }
    HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
    ModelAndView mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
    processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}

关键步骤就是三步:

查找 handler；
查找 HandlerAdapter；
调用 handler；

这里介绍下背景知识。在 Spring 中提供了多种定义路由的方法，每一类方法可以使用一个 HandlerMapping 表示，该接口通过 getHandler 获取具体的业务代码对象。

public interface HandlerMapping {
	HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
}

handler 对象封装在 HandlerExecutionChain 类中，其类型是通用的 Object 类。封装类中还包含可选的 HandlerInterceptor 数组，用于给开发者自定义在 handler 之前执行的代码，比如认证或者语言/主题的设置等。

实际调用 handler 即用户定义路由需要通过 HandlerAdapter 实现。这样做的目的主要是为了让 DispatcherServlet 代码中无需知晓 handler 的具体类型，从而具备可拓展的抽象能力。

public interface HandlerAdapter {
    boolean supports(Object handler);
	ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
}

handle 接口通过将 handler 转换成实际的类型并进行调用，将结果统一返回为 ModelAndView 类型，然后根据需要进行渲染并将结果写入到 response 完成响应提交的返回。

HandlerMapping

可见，获取对应 HandlerMapping 是路由的重要一步，DispatcherServlet#getHandler 的实现就是从 this.handlerMappings 数组中依次遍历并调用 mapping.getHandler，如果返回不为空则返回对应的 handler 对象。

protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    if (this.handlerMappings != null) {
        for (HandlerMapping mapping : this.handlerMappings) {
            HandlerExecutionChain handler = mapping.getHandler(request);
            if (handler != null) {
                return handler;
            }
        }
    }
    return null;
}

handlerMappings 数组中包含多个 HandlerMapping 的实现，根据开发者具体定义的路由确定。这里测试时注册的映射有以下这些:

这些映射都是 AbstractHandlerMapping 的子类，在基类中实现了 getHandler 接口，实际返回的 handler 如果是字符串类型则认为是 Bean 的名称，否则认为是实际的 handler:

public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    Object handler = getHandlerInternal(request);
	if (handler == null) {
		handler = getDefaultHandler();
	}
	if (handler == null) {
		return null;
	}
	// Bean name or resolved handler?
	if (handler instanceof String handlerName) {
		handler = obtainApplicationContext().getBean(handlerName);
	}
	HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);
	return executionChain;
}

大致的类结构如下所示，每个版本略有不同，仅作参考:

在基类中最终会调用到 lookupHandler:

protected Object lookupHandler(
		RequestPath path, String lookupPath, HttpServletRequest request) throws Exception {

	Object handler = getDirectMatch(lookupPath, request);
	if (handler != null) {
		return handler;
	}

	// Pattern match?
	List<PathPattern> matches = null;
	for (PathPattern pattern : this.pathPatternHandlerMap.keySet()) {
		if (pattern.matches(path.pathWithinApplication())) {
			matches = (matches != null ? matches : new ArrayList<>());
			matches.add(pattern);
		}
	}
	if (matches == null) {
		return null;
	}
	if (matches.size() > 1) {
		matches.sort(PathPattern.SPECIFICITY_COMPARATOR);
		if (logger.isTraceEnabled()) {
			logger.trace("Matching patterns " + matches);
		}
	}
	PathPattern pattern = matches.get(0);
	handler = this.pathPatternHandlerMap.get(pattern);
	if (handler instanceof String handlerName) {
		handler = obtainApplicationContext().getBean(handlerName);
	}
	validateHandler(handler, request);
	String pathWithinMapping = pattern.extractPathWithinPattern(path.pathWithinApplication()).value();
	pathWithinMapping = UrlPathHelper.defaultInstance.removeSemicolonContent(pathWithinMapping);
	return buildPathExposingHandler(handler, pattern.getPatternString(), pathWithinMapping, null);
}

总结:

先使用 getDirectMatch 进行直接匹配，查找 this.handlerMap 中的路由；
后使用模式匹配，依次匹配 this.pathPatternHandlerMap 中的路由，具体匹配方法见下节；
查找完成后对所有匹配进行排序，选出最佳匹配的 handler 进行返回；

由于注册的路由大多数都继承自 AbstractHandlerMapping，因此如果我们想要在运行时查看目标 Spring 应用的所有路由，可以首先断点在 DispatcherServlet#doDispatch，然后遍历其中的 this.handlerMappings，最后读取每个 mapping 中的 handlerMap 和 pathPatternHandlerMap 属性，即可枚举出所有的路由 Pattern。

PathPattern

不同的 HandlerMapping 针对不同的映射类型。主要分为两大类:

AbstractHandlerMethodMapping: 用于将请求映射到 HandlerMethod；
AbstractUrlHandlerMapping: 用于针对 URL 的映射，比如精确匹配或者模式匹配(PathPattern、AntPathMatcher)，多个匹配满足时采用最优(最长)匹配的结果；

一些具体的实现包括但不限于:

WebMvcEndpointHandlerMapping: 将请求映射到 Spring MVC 控制器方法，用于 Spring Actuator 的端点，如 /actuator/health 和 /actuator/info 等；之所以有这个映射是因为项目中使用了 actuator 模块 (spring-boot-starter-actuator)；
ControllerEndpointHandlerMapping: 同上，也是 actuator 中的；
RequestMappingHandlerMapping: 查找使用 @Controller 修饰的类中的 @RequestMapping 方法，返回方法级别的映射；
SimpleUrlHandlerMapping: 将 URL 映射到 Bean 实例或者 Bean 的名称；
BeanNameUrlHandlerMapping: 将 URL 映射到以 / 开头的 bean，类似于 Struts 将 URL 映射到 action；

我们关心的是 URL 路径到 Handler 的路由或者说匹配规则，因此还需要选择其中几个实现进行深入的跟踪。

以前面定义的 /bind/str 路由为例，其调用路径较深，经过一顿 F7 之后最终可以看到使用 PathPattern.matches 进行匹配，调用栈如下:

matches:42, SeparatorPathElement (org.springframework.web.util.pattern)
matches:216, PathPattern (org.springframework.web.util.pattern)
getMatchingPatterns:203, PathPatternsRequestCondition (org.springframework.web.servlet.mvc.condition)
getMatchingCondition:195, PathPatternsRequestCondition (org.springframework.web.servlet.mvc.condition)
getMatchingCondition:397, RequestMappingInfo (org.springframework.web.servlet.mvc.method)
getMatchingMapping:110, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
getMatchingMapping:68, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
addMatchingMappings:447, AbstractHandlerMethodMapping (org.springframework.web.servlet.handler)
lookupHandlerMethod:407, AbstractHandlerMethodMapping (org.springframework.web.servlet.handler)
getHandlerInternal:382, AbstractHandlerMethodMapping (org.springframework.web.servlet.handler)
getHandlerInternal:126, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
getHandlerInternal:68, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
getHandler:505, AbstractHandlerMapping (org.springframework.web.servlet.handler)
getHandler:1275, DispatcherServlet (org.springframework.web.servlet)

PathPattern 是以斜杠 / 为间隔的路径模式，遵循以下规则:

? 匹配单个字符；
* 匹配单个路径段(path segment)之间的零个或者多个字符；
** 匹配零个或者多个路径段，直至路径结尾；
{spring}: 匹配一个路径段并且捕捉该段保存为变量 “spring”；
{spring:[a-z]+}: 同上，但要求路径段满足正则表达式 [a-z]+；
{*spring}: 类似于 **，但将匹配的路径段保存为变量 “spring”；

其规则类似于与我们之前介绍 Shiro 时用的 Ant 风格路径匹配(Ant Style Path Matcher)。

Ant 指的是最早在 Apache Ant 使用的匹配方法，不同于正则表达式，主要是为了实现 JavaEE Servlet 的路径匹配规则。

PathPattern 内部包含一个 PathElement 格式的 head 属性，以双链表的形式保存了所有路径段和分隔符，head 指向路径的开头即 SeparatorPathElement Separator(/)。

public boolean matches(PathContainer pathContainer) {
    if (this.head == null) {
        return !hasLength(pathContainer) ||
            (this.matchOptionalTrailingSeparator && pathContainerIsJustSeparator(pathContainer));
    }
    else if (!hasLength(pathContainer)) {
        if (this.head instanceof WildcardTheRestPathElement || this.head instanceof CaptureTheRestPathElement) {
            pathContainer = EMPTY_PATH; // Will allow CaptureTheRest to bind the variable to empty
        }
        else {
            return false;
        }
    }
    MatchingContext matchingContext = new MatchingContext(pathContainer, false);
    return this.head.matches(0, matchingContext);
}

head.matches 不断匹配下一级路径或者分隔符(this.next)，并调用其 matches 方法进行匹配。head 即 SeparatorPathElement 的实现如下:

public boolean matches(int pathIndex, MatchingContext matchingContext) {
    if (pathIndex < matchingContext.pathLength && matchingContext.isSeparator(pathIndex)) {
        if (isNoMorePattern()) {
            if (matchingContext.determineRemainingPath) {
                matchingContext.remainingPathIndex = pathIndex + 1;
                return true;
            }
            else {
                return (pathIndex + 1 == matchingContext.pathLength);
            }
        }
        else {
            pathIndex++;
            return (this.next != null && this.next.matches(pathIndex, matchingContext));
        }
    }
    return false;
}

其他的 PathElement 接口实现包括:

org.springframework.web.util.pattern.SeparatorPathElement
org.springframework.web.util.pattern.WildcardPathElement
org.springframework.web.util.pattern.SingleCharWildcardedPathElement
org.springframework.web.util.pattern.WildcardTheRestPathElement
org.springframework.web.util.pattern.CaptureVariablePathElement
org.springframework.web.util.pattern.CaptureTheRestPathElement
org.springframework.web.util.pattern.LiteralPathElement
org.springframework.web.util.pattern.RegexPathElement

比如 /foo 就包含一个 SeparatorPathElement 和一个 LiteralPathElement，后者的 value 为 foo。LiteralPathElement 的实现如下:

public boolean matches(int pathIndex, MatchingContext matchingContext) {
    if (pathIndex >= matchingContext.pathLength) {
        // no more path left to match this element
        return false;
    }
    Element element = matchingContext.pathElements.get(pathIndex);
    if (!(element instanceof PathSegment pathSegment)) {
        return false;
    }
    String value = pathSegment.valueToMatch();
    if (value.length() != this.len) {
        // Not enough data to match this path element
        return false;
    }

    if (this.caseSensitive) {
        if (!this.text.equals(value)) {
            return false;
        }
    }
    pathIndex++;
    // ...
    return (this.next != null && this.next.matches(pathIndex, matchingContext));
}

其他的 PathElement 都有不同实现，这里就不一一介绍了。

PathContainer 也是类似的数据结构，其中 elements 数组中包含了所有解析的路径段和分隔符，类型为 Element；对于路径段使用子接口 PathSegment 表示，拥有返回路径参数以及解码路径值的能力。

interface PathSegment extends Element {

    /**
     * Return the path segment value, decoded and sanitized, for path matching.
     */
    String valueToMatch();
    char[] valueToMatchAsChars();

    /**
     * Path parameters associated with this path segment.
     * @return an unmodifiable map containing the parameters
     */
    MultiValueMap<String, String> parameters();
}

从中我们可以看出路径匹配的算法:

应用启动时解析所有的 Controller 等各种路由映射，将其以 PathPattern 的格式存储在不同 HandlerMapping 中；
收到请求时，DispatcherServlet 会将请求路径解析为 PathContainer，将路径中的元素(Path Element)保存到列表中，元素包含路径分隔符和每一级路径的内容；其中路径内容使用 PathSegment 表示，其 valueToMatch 返回的是不带路径参数且 URL 解码后的内容，精确匹配时会使用 String.equals 进行对比；
实际比较时，PathContainer 会被封装成 MatchingContext，包括当前比对的位置等信息，方便使用 .next 遍历链表时保存比较的上下文信息；
路径比对会从表头开始，依次调用 next.matches，直至最后一级，此时 next 为 null；

就 RequestMappingHandlerMapping 而言，我们能够针对路径做的变异如下，假设原始路径为 /api/flag:

/api/%66%6C%61%67: 基于 valueToMatch 返回 URL 解码后的的 segment 值；
/api;a=b/flag: 基于 valueToMatch 返回不包含路径参数的值；

注意 /api/./flag 或者 /api/../api/flag 这种请求时无法路由到目标 Handler 的，因为匹配时会将 dot-segment 当成一般的路径去进行精确匹配，因此只能路由到 @GetMapping("/./flag) 对应的 Handler 上。

参考资料:

ResourceHttpRequestHandler

对于常规 Servlet 容器，在所有定义的路由都无法匹配时，会尝试从磁盘文件或者 jar 中的资源文件进行匹配，即所说的 DefaultServlet。Spring MVC 也有类似的行为，当前面所有的 HadlerMapping 都找不到匹配时，会尝试查找对应的资源文件，负责处理这部分操作的是最后一个 SimpleUrlHandlerMapping，其 beanName 为 resourceHandlerMapping。

其中的 pathPatternHandlerMap 默认包含两个 PathPattern，分别是:

/webjars/** -> ResourceHttpRequestHandler [classpath [META-INF/resources/webjars/]]
/** -> ResourceHttpRequestHandler [classpath [META-INF/resources/], classpath [resources/], classpath [static/], classpath [public/], ServletContext [/]]

/** 是一个 PathElement，称为 WildcardTheRestPathElement，用于匹配所有 / 开头的路径。

最后调用 handler 的是 HttpRequestHandlerAdapter，实现比较简单，就是直接调用 handler.handleRequest:

public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {

    ((HttpRequestHandler) handler).handleRequest(request, response);
    return null;
}

handleRequest

读取资源文件的 handleRequest 实现如下:

public void handleRequest(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    // For very general mappings (e.g. "/") we need to check 404 first
    Resource resource = getResource(request);
    if (resource == null) {
        logger.debug("Resource not found");
        response.sendError(HttpServletResponse.SC_NOT_FOUND);
        return;
    }
    // Supported methods and required session
    checkRequest(request);
    // Header phase
	// Apply cache settings, if any
	// Check the media type for the resource
	// Content phase
	if (request.getHeader(HttpHeaders.RANGE) == null) {
        this.resourceHttpMessageConverter.write(resource, mediaType, outputMessage);
    } else {
        ServletServerHttpRequest inputMessage = new ServletServerHttpRequest(request);
        List<HttpRange> httpRanges = inputMessage.getHeaders().getRange();
        response.setStatus(HttpServletResponse.SC_PARTIAL_CONTENT);
        this.resourceRegionHttpMessageConverter.write(
        HttpRange.toResourceRegions(httpRanges, resource), mediaType, outputMessage);
    }
}

请求只支持 GET 和 OPTIONS 方法，并且支持 HTTP 缓存，对于未修改的资源可以返回 304；此外还有个值得注意的点是这里还支持了 HTTP Range 头，即从指定偏移开始读取文件。

资源分为两种，一种是 classpath resource，即 Jar 包中的文件，另一种是 ServletContext resource，即 Web 目录中的磁盘文件。是否能够定位到对应文件的关键是 getResource 是否能成功返回对于资源:

protected Resource getResource(HttpServletRequest request) throws IOException {
	String path = (String) request.getAttribute(HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE);
	if (path == null) {
		throw new IllegalStateException("Required request attribute '" +
				HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE + "' is not set");
	}

	path = processPath(path);
	if (!StringUtils.hasText(path) || isInvalidPath(path)) {
		return null;
	}
	if (isInvalidEncodedPath(path)) {
		return null;
	}

	Assert.state(this.resolverChain != null, "ResourceResolverChain not initialized.");
	Assert.state(this.transformerChain != null, "ResourceTransformerChain not initialized.");

	Resource resource = this.resolverChain.resolveResource(request, path, getLocations());
	if (resource != null) {
		resource = this.transformerChain.transform(request, resource);
	}
	return resource;
}

首先关注局部变量 path，该值是之前保存到属性中的。回顾之前 HandlerMapping 一节中 lookupHandler 的代码末尾。pathWithinMapping，这个参数会在 buildPathExposingHandler 中使用，最终会创建一个拦截器 PathExposingHandlerInterceptor，而这个拦截器会在 DispatcherServlet 中调用 handler 前调用，即 mappedHandler.applyPreHandle()。该拦截器会使用 request 的属性保存该 URL，且这个 URL 就是这里寻址资源时用到的 path 值:

String pathWithinMapping = pattern.extractPathWithinPattern(path.pathWithinApplication()).value();
pathWithinMapping = UrlPathHelper.defaultInstance.removeSemicolonContent(pathWithinMapping);
return buildPathExposingHandler(handler, pattern.getPatternString(), pathWithinMapping, null);

buildPathExposingHandler 中设置属性:

request.setAttribute(PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE, pathWithinMapping);

因此，这里的 path 会经过一部分预处理。

预处理

PathPattern#extractPathWithinPattern 中的处理方法还是从 path element 的维度去处理，如果其中有连续的分隔符会进行合并，随后会返回从第一个非分隔符的元素一直到最后一个非分隔符的元素，因此路径 /foo//bar/ 处理后会变成 foo/bar。

removeSemicolonContent 则是删除 URL 中的路径参数。

仅从这个预处理的代码片段来看，路径 /foo/;/bar 处理后依旧会保留连续的分隔符形成 foo//bar，当然具体影响还要看后续的处理代码。

processPath

在获得部分处理的路径后，会继续经过 processPath 过滤，代码如下:

protected String processPath(String path) {
    path = StringUtils.replace(path, "\\", "/");
    path = cleanDuplicateSlashes(path);
    return cleanLeadingSlash(path);
}
private String cleanLeadingSlash(String path) {
    boolean slash = false;
    for (int i = 0; i < path.length(); i++) {
        if (path.charAt(i) == '/') {
            slash = true;
        }
        else if (path.charAt(i) > ' ' && path.charAt(i) != 127) {
            if (i == 0 || (i == 1 && slash)) {
                return path;
            }
            return (slash ? "/" + path.substring(i) : path.substring(i));
        }
    }
    return (slash ? "/" : "");
}

将 \ 替换为了 /；
删除重复的 /，比如 //；
删除路径前部的 /，准确来说是所有 / 和控制符(00-1F, 7F)的组合；

注意 cleanLeadingSlash 的实现，会从第一个字符开始查找，直到找到第一个大于 \x20 且不等于 \x7F 的字符，返回此后的子字符串，根据期间是否出现过 / 来判断结果是否要在前方添加 /。

isInvalidPath

processPath 之后会判断路径是否为空且是否为合法的路径，判断方法为:

protected boolean isInvalidPath(String path) {
	if (path.contains("WEB-INF") || path.contains("META-INF")) {
		return true;
	}
	if (path.contains(":/")) {
		String relativePath = (path.charAt(0) == '/' ? path.substring(1) : path);
		if (ResourceUtils.isUrl(relativePath) || relativePath.startsWith("url:")) {
			return true;
        }
    }
	if (path.contains("..") && StringUtils.cleanPath(path).contains("../")) {
		return true;
    }
	return false;
}

其中对请求资源的路径做了几个限制:

不能包含 WEB-INF 或者 META-INF；
不能是 URL；
对于包含 .. 的路径，使用 cleanPath 不能再包含 ../；

ResourceUtils.isUrl 的实现的伪代码如下:

public static boolean isUrl(String resourceLocation) {
    if (resourceLocation.startsWith("classpath:")) {
        return true;
    }	
    try {
        new URL(location);
        return true;
    } catch (MalformedURLException ex) {
        return false;
    }
}

除了以 classpath: 开头的路径，其他都依赖于 java.net.URL 构造函数中的处理，即如果能成功调用 URL 的构造函数就认为是一个 URL。根据官方文档，URL 构造函数抛出异常的条件是:

if no protocol is specified, or an unknown protocol is found, or spec is null.

感觉这里还是有点操作空间的，比如从源码中对比一下 Spring 支持而 URL 不支持的协议。

StringUtils.cleanPath 的作用主要是将路径进行归一化，不过考虑到 path 可能包含特殊的协议头，要考虑的情况就变得相对复杂了:

public static String cleanPath(String path) {
	String normalizedPath = replace(path, WINDOWS_FOLDER_SEPARATOR, FOLDER_SEPARATOR);
	String pathToUse = normalizedPath;

    // 去除协议部分
	int prefixIndex = pathToUse.indexOf(':');
	String prefix = "";
	if (prefixIndex != -1) {
		prefix = pathToUse.substring(0, prefixIndex + 1);
		if (prefix.contains(FOLDER_SEPARATOR)) {
			prefix = "";
		}
		else {
			pathToUse = pathToUse.substring(prefixIndex + 1);
		}
	}
	if (pathToUse.startsWith(FOLDER_SEPARATOR)) {
		prefix = prefix + FOLDER_SEPARATOR;
		pathToUse = pathToUse.substring(1);
	}

    // 处理路径树
	String[] pathArray = delimitedListToStringArray(pathToUse, FOLDER_SEPARATOR);
	Deque<String> pathElements = new ArrayDeque<>(pathArray.length);
	int tops = 0;
	for (int i = pathArray.length - 1; i >= 0; i--) {
		String element = pathArray[i];
		if (".".equals(element)) {
			// Points to current directory - drop it.
		} else if ("..".equals(element)) {
			// Registering top path found.
			tops++;
		} else {
			if (tops > 0) {
				// Merging path element with element corresponding to top path.
				tops--;
			}
			else {
				// Normal path element found.
				pathElements.addFirst(element);
			}
		}
	}
	// All path elements stayed the same - shortcut
	if (pathArray.length == pathElements.size()) {
		return normalizedPath;
	}
	// Remaining top paths need to be retained.
	for (int i = 0; i < tops; i++) {
		pathElements.addFirst(TOP_PATH);
	}
	// If nothing else left, at least explicitly point to current path.
	if (pathElements.size() == 1 && pathElements.getLast().isEmpty() && !prefix.endsWith(FOLDER_SEPARATOR)) {
		pathElements.addFirst(CURRENT_PATH);
	}

	final String joined = collectionToDelimitedString(pathElements, FOLDER_SEPARATOR);
	// avoid string concatenation with empty prefix
	return prefix.isEmpty() ? joined : prefix + joined;
   }

cleanPath 中使用的算法是将路径以 / 分隔，并将列表从后往前进行处理，最后将列表重新组合成新的路径。值得注意的是该方法只是将路径中的 . 去除以及将路径中间的 .. 移动到前方，比如 foo/../../bar 会变成 ../bar，因此该方法的注释中也说了不能讲其作为安全校验来防止路径穿越。这也是为什么要对 cleanPath 之后的路径再次检查是否存在 ../ 的原因。这样过滤的好处是可以找出归一化后以 ../ 开头的路径，即目录穿越到 web 应用 context-root 之外的路径。

回顾 isInvalidPath 的实现，此时 path 虽然经过了一定的处理，但现在还是包含 URL 编码字符的，因此猜测这里并不是唯一的安全校验，否则可以被比较容易地绕过。不过从这个判断的实现上来看，我们可以学习到 Spring 对于资源请求的一些设计，比如支持 URL、classpath: 和 url: 格式的资源，以及 WEB-INF 路径中的文件被认为是敏感信息等。

isInvalidEncodedPath

接着看下一个判断，isInvalidEncodedPath，根据其实现正好验证了我们上节的猜想，即 path 如果包含 URL 编码，需要对解码后的路径再次进行安全判断:

private boolean isInvalidEncodedPath(String path) {
    if (path.contains("%")) {
        try {
            // Use URLDecoder (vs UriUtils) to preserve potentially decoded UTF-8 chars
            String decodedPath = URLDecoder.decode(path, StandardCharsets.UTF_8);
            if (isInvalidPath(decodedPath)) {
                return true;
            }
            decodedPath = processPath(decodedPath);
            if (isInvalidPath(decodedPath)) {
                return true;
            }
        }
        catch (IllegalArgumentException ex) {
            // May not be possible to decode...
        }
    }
    return false;
}

URL 解码后的路径进行了两次判断，第一次是针对解码后的原始 URL，第二次是 processPath 之后的 URL，判断和前面一样都是通过 isInvalidPath。

Resource

在经过一系列前置判断后，最后开始使用 resolveResource 查找资源。基于 getLocations() 返回的 classpath resource 或者 context resource 分别进行查找:

// org.springframework.web.servlet.resource.PathResourceResolver#getResource()
for (Resource location : locations) {
    String pathToUse = encodeOrDecodeIfNecessary(resourcePath, request, location);
    Resource resource = getResource(pathToUse, location);
    if (resource != null) {
        return resource;
    }
}

encodeOrDecodeIfNecessary 对请求的路径进行了 URL 解码。当然主要取决于对应请求的 HandlerMapper 配置，对于大部分映射而言只要请求使用 PathContainer 封装就需要进行解码；在一些特殊的 HandlerMapper 中可能会已经对请求进行解码，因此这里反而会需要进行编码。

getResource 使用 Resource.createRelative 获取指定资源文件，并且在获取到后还使用 checkResource 进行了额外的防御性检查:

protected Resource getResource(String resourcePath, Resource location) throws IOException {
    Resource resource = location.createRelative(resourcePath);
    if (resource.isReadable()) {
        if (checkResource(resource, location)) {
            return resource;
        }
        else if (logger.isWarnEnabled()) {
            Resource[] allowed = getAllowedLocations();
            logger.warn(LogFormatUtils.formatValue(
                "Resource path \"" + resourcePath + "\" was successfully resolved " +
                "but resource \"" + resource.getURL() + "\" is neither under " +
                "the current location \"" + location.getURL() + "\" nor under any of " +
                "the allowed locations " + (allowed != null ? Arrays.asList(allowed) : "[]"), -1, true));
        }
    }
    return null;
}

Resource 是 Spring 中一个真的资源的抽象接口，具有多种实现，包括前面介绍过的，比如:

ClassPathResource: 使用 Class.getResource 或者 ClassLoader.getResource 接口去读取对应文件；
ServletContextResource: 使用 ServletContext.getResource 或者 ServletContext.getRealPath 读取 web 应用目录下相对路径的文件；
FileSystemResource: 使用 java.io.File 接口读取磁盘文件；
…

每种资源的实现各不相同，但总的来说 createRelative 大都是通过 StringUtils.applyRelativePath(this.path, relativePath) 构造新的 Resource。

至于 checkResource 的实现这里就不展开了，除非你已经绕过了 getResource 之前对路径的重重校验。这里主要是进行防御性的检查，判断新的资源是否在原始资源目录之下，根据资源类型的不同可能会调用 getURL 或者 getPath 作为资源的路径，并使用 String.startsWith 对整理后的路径进行比较。

Bypass Tricks

通过上面对 Spring MVC 路由代码的分析可以看出，对于大多数 HandlerMethodMapping，Spring 使用 PathPattern 去进行路径匹配，类似于 Ant 风格的最优匹配方式，因此对指定路由的变异相比于 Tomcat 等 Web 容器而言会少很多；但是对于资源文件的路由则可以使用更多变种。

假设存在资源文件 resources/static/secret.txt，对应的路由是 /secret.txt，可以使用下面的变体:

/secret.txt/: 预处理时候会变成 secret.txt 删除前方以及末尾的分隔符；
/;/secret.txt: 预处理时候删除连续的分隔符，和 // 的差别是处理阶段不同；
/secret.txt;a=b: 预处理时候会删除路径参数；
\secret.txt: 基于 processPath 中将 \ 替换成 / 的变异；
//secret.txt: 基于 cleanDuplicateSlashes 的变异，因此前面遗留的连续分隔符不会影响；
/ / // secret.txt: 基于 cleanLeadingSlash 的变异；
/secret.%74%78%74: 寻找文件前会通过 encodeOrDecodeIfNecessary 进行 URL 解码；
/foo/.././/secret.txt: createRelative 中会组合路径，并将其当做最终路径；

这些路径变异方式可以组合进行使用，从而根据需要构造出更加复杂的变异。当然值得注意的是其中某些变异可能会在 Web 容器就被拦截，比如 Tomcat 在碰到路径中包含(未编码的)空格时会直接返回 400 错误。

Spring Security

前面详细分析了 Spring MVC 的路由实现，在实际的 Spring 应用中通常配套使用 Spring-Security 作为认证和鉴权方案，因此本节将二者结合起来看，以加深对鉴权逻辑的理解。另外也会分析一些历史上出现过的 Spring Security 鉴权绕过漏洞，结合实际案例进行分析。

如无特别说明，本节使用的安全配置代码如下:

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.csrf().disable()
                .authorizeHttpRequests((requests) -> requests
                        .requestMatchers("/secret.txt").hasRole("USER")
                        .requestMatchers("/api/flag").hasRole("USER")
                        .requestMatchers("/**").permitAll()
                )
                .formLogin((form) -> form
                        .loginPage("/login").permitAll()
                )
                .logout(LogoutConfigurer::permitAll);
        return http.build();
    }
}

本文使用的版本是 spring-security-web 6.0.3

通用防御

首先构造一个简单的变异 /api/flag;xxx 进行请求后发现结果直接返回 400，在 DispatcherServlet 中直接看到请求的是 /error 界面。因此猜测在 Spring Security 引入的某个 Filter 中拦截了请求。

调试方式还是在 org.apache.catalina.core.ApplicationFilterChain#internalDoFilter 中遍历每个 filter 时进行断点，最终发现在 org.springframework.web.filter.DelegatingFilterProxy#doFilter 中触发了 response.setError，从而跳出循环并查找自定义错误页面进行输出。

在 org.springframework.security.web.FilterChainProxy#doFilter 中内部抛出了异常并被捕捉，异常类的详细信息如下:

org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL contained a potentially malicious String ";"
	at org.springframework.security.web.firewall.StrictHttpFirewall.rejectedBlocklistedUrls(StrictHttpFirewall.java:535)
	at org.springframework.security.web.firewall.StrictHttpFirewall.getFirewalledRequest(StrictHttpFirewall.java:505)
	at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:211)
	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:191)
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:352)
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:268)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
	at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)

即核心在于 StrictHttpFirewall 的拦截。下面是调用方的代码:

// org.springframework.security.web.FilterChainProxy
private void doFilterInternal(ServletRequest request, ServletResponse response, FilterChain chain)
		throws IOException, ServletException {
	FirewalledRequest firewallRequest = this.firewall.getFirewalledRequest((HttpServletRequest) request);
	HttpServletResponse firewallResponse = this.firewall.getFirewalledResponse((HttpServletResponse) response);
	List<Filter> filters = getFilters(firewallRequest);
	if (filters == null || filters.size() == 0) {
		if (logger.isTraceEnabled()) {
			logger.trace(LogMessage.of(() -> "No security for " + requestLine(firewallRequest)));
		}
		firewallRequest.reset();
		this.filterChainDecorator.decorate(chain).doFilter(firewallRequest, firewallResponse);
		return;
	}
	if (logger.isDebugEnabled()) {
		logger.debug(LogMessage.of(() -> "Securing " + requestLine(firewallRequest)));
	}
	FilterChain reset = (req, res) -> {
		if (logger.isDebugEnabled()) {
			logger.debug(LogMessage.of(() -> "Secured " + requestLine(firewallRequest)));
		}
		// Deactivate path stripping as we exit the security filter chain
		firewallRequest.reset();
		chain.doFilter(req, res);
	};
	this.filterChainDecorator.decorate(reset, filters).doFilter(firewallRequest, firewallResponse);
}

在请求 firewall.getFirewalledRequest 时抛出了异常:

public FirewalledRequest getFirewalledRequest(HttpServletRequest request) throws RequestRejectedException {
    rejectForbiddenHttpMethod(request);
    rejectedBlocklistedUrls(request);
    rejectedUntrustedHosts(request);
    if (!isNormalized(request)) {
        throw new RequestRejectedException("The request was rejected because the URL was not normalized.");
    }
    rejectNonPrintableAsciiCharactersInFieldName(request.getRequestURI(), "requestURI");
    return new StrictFirewalledRequest(request);
}

对于请求的拦截包括:

rejectForbiddenHttpMethod: 拦截非法的请求方法，默认允许的方法为 HEAD, DELETE, POST, GET, OPTIONS, PATCH, PUT 这 7 个；
rejectedBlocklistedUrls: 拦截 URL 中的特殊字符,
- encodedUrlBlocklist: //, \x00, %2F2F, %00, %25, \n, \r, %5C, %3B, %0A, %2E, %2F, %0D, ;, \;
- decodedUrlBlocklist: //, \x00, %2F2F, %00, %, \u2028, \u2029 \n, \r, %5C, %3B, %0A, %2F, %0D, ;, \;
rejectedUntrustedHosts: 拦截不可信的请求域名 (request.getServerName);
isNormalized: 拦截包含 ./, /../, /. 字符的路径；
rejectNonPrintableAsciiCharactersInFieldName: 拦截 getRequestURI 中包含不可打印字符的请求，即小于 \x20 或者大于 \x7e 的字符；

在 2 中两个 Blocklist 略有不同，二者都检查了 getContextPath 的值，但前者检查的是 getRequestURI，而后者检查的是 getPathInfo 的值；这里列举的字符我删除了一些大小写的变体，具体分类如下:

public StrictHttpFirewall() {
    urlBlocklistsAddAll(FORBIDDEN_SEMICOLON);
    urlBlocklistsAddAll(FORBIDDEN_FORWARDSLASH);
    urlBlocklistsAddAll(FORBIDDEN_DOUBLE_FORWARDSLASH);
    urlBlocklistsAddAll(FORBIDDEN_BACKSLASH);
    urlBlocklistsAddAll(FORBIDDEN_NULL);
    urlBlocklistsAddAll(FORBIDDEN_LF);
    urlBlocklistsAddAll(FORBIDDEN_CR);

    this.encodedUrlBlocklist.add(ENCODED_PERCENT);
    this.encodedUrlBlocklist.addAll(FORBIDDEN_ENCODED_PERIOD);
    this.decodedUrlBlocklist.add(PERCENT);
    this.decodedUrlBlocklist.addAll(FORBIDDEN_LINE_SEPARATOR);
    this.decodedUrlBlocklist.addAll(FORBIDDEN_PARAGRAPH_SEPARATOR);
}

在 4 中检查的路径包括 getRequestURI、getContextPath、getServletPath 以及 getPathInfo；

可见在当前版本的默认配置下，Spring Security 拦截了很多 URL 的变体，从而在后续鉴权检查的时候避免了许多潜在的绕过。其中大部分选项都可以配置关闭，比如使用 setAllowSemicolon 来允许分号(路径参数)，详见 StrictHttpFirewall 中的接口。一个重要的例外是 isNormalized 的检查无法关闭，官方文档中的解释是:

There is no way to disable this as it is considered extremely risky to disable this constraint. A few options to allow this behavior is to normalize the request prior to the firewall or using DefaultHttpFirewall instead. Please keep in mind that normalizing the request is fragile and why requests are rejected rather than normalized.

另外其实针对可打印字符的拦截也是无法关闭的，只不过这里的检查并没有考虑对这些字符 URL 编码的情况。

AuthorizationFilter

在本节开头的 SecurityConfig 中放了一个类型为 SecurityFilterChain 的 bean，并设置了以下规则:

.requestMatchers("/api/flag").hasRole("USER")

直接请求 /api/flag 会返回 302 跳转到配置的登录地址。想要分析这背后的原理可以和之前一样继续在 FilterChainProxy 中跟踪返回的每个 filter:

List<Filter> filters = getFilters(firewallRequest);

这里直接说结论，最终检查上述规则的 Filter 是 AuthorizationFilter，使用 AuthorizationManager#check 来对路径进行权限检查。

// org.springframework.security.web.access.intercept.AuthorizationFilter#doFilter
AuthorizationDecision decision = this.authorizationManager.check(this::getAuthentication, request);
this.eventPublisher.publishAuthorizationEvent(this::getAuthentication, request, decision);
if (decision != null && !decision.isGranted()) {
    throw new AccessDeniedException("Access Denied");
}
chain.doFilter(request, response);

AuthorizationDecision 只是 bool 的简单封装，保存 isGrant 即认证的结果是否通过。RequestMatcherDelegatingAuthorizationManager#check 的关键实现如下:

public AuthorizationDecision check(Supplier<Authentication> authentication, HttpServletRequest request) {
    this.logger.trace(LogMessage.format("Authorizing %s", request));
	for (RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>> mapping : this.mappings) {
		RequestMatcher matcher = mapping.getRequestMatcher();
		MatchResult matchResult = matcher.matcher(request);
		if (matchResult.isMatch()) {
			AuthorizationManager<RequestAuthorizationContext> manager = mapping.getEntry();
            this.logger.trace(LogMessage.format("Checking authorization on %s using %s", request, manager));
			return manager.check(authentication,
					new RequestAuthorizationContext(request, matchResult.getVariables()));
		}
	}
    this.logger.trace(LogMessage.of(() -> "Denying request since did not find matching RequestMatcher"));
	return DENY;
}

this.mappings 保存了 RequestMatcherEntry 类型的列表，请求是否命中规则的判断使用 RequestMatcher#matcher 进行匹配，命中匹配后再使用 AuthorizationManager#check 判断权限是否满足，这里我们显然主要关注前者。

RequestMatcher 接口是 Spring Security 中用于匹配请求的关键接口，具体实现有 antMatchers、regexMatchers 等，这里 /api/flag 对应的是 MvcRequestMatcher，实现如下:

public MatchResult matcher(HttpServletRequest request) {
	if (notMatchMethodOrServletPath(request)) {
		return MatchResult.notMatch();
	}
	MatchableHandlerMapping mapping = getMapping(request);
	if (mapping == null) {
		return this.defaultMatcher.matcher(request);
	}
	RequestMatchResult result = mapping.match(request, this.pattern);
	return (result != null) ? MatchResult.match(result.extractUriTemplateVariables()) : MatchResult.notMatch();
}

其中实际使用了 org.springframework.web.servlet.handler.MatchableHandlerMapping 去进行路径匹配，这个类正是 Spring MVC 中使用的，该映射类通过内省的方式获取，因此避免了检查和路由不一致的问题，从而防止各种路径变异导致的绕过。当然只能说顶层设计是这样的，但具体实现可能依然有些阴暗的角落，这个可以从近期的一些案例中看到。

历史案例

在 Spring {Boot,Data,Security} 历史漏洞研究一文中提及到相关的漏洞，这里再深入分析一下。早期 Spring Security 的配置支持 antMatchers, mvcMatchers, 以及 regexMatchers 等多种路径匹配方式，但这些匹配方法多少还是和 Spring MVC 中的路由匹配规则是有差异的。

比如在 SEC-2534 漏洞中，Spring Security 的 antMatchers("/link") 配置与 Spring MVC 的 @RequestMapping("/link") 配置可以被 /link.html 绕过。

在 CVE-2016-5007 中，可以在路径中加入空格来绕过 Spring Security 的判断(早期 Spring Framework 使用 AntPathMatcher 可配置忽略空格且默认开启)。

在 CVE-2022-22975/CVE-2022-22978 中，基于正则表达式的 RegexRequestMatcher 在使用点号 . 比如 .* 时可以被换行符绕过。这是一个正则表达式常见的陷阱，一般使用 Pattern.DOTALL 来指明点号匹配包括换行符的所有字符。

这些漏洞的核心在于，Spring 框架对于路径匹配的规则提供了相比于 Spring Security 更加丰富的配置方法，而用户可以轻易地在二者之间开启不同的配置，导致二者不匹配产生鉴权绕过。针对这类问题，当时开发组提出了一种与 Spring MVC 对齐的匹配方法，即 MvcRequestMatcher。该类使用了 Spring MVC 中的 HandlerMappingIntrospector 来匹配路径和提取变量，从而根治了鉴权和路由不一致的问题。

在新版 Spring Security 的官方文档中也提到，建议开发者使用新的 requestMatcher 接口，并将历史接口的废弃提上日程:

In Spring Security 5.8, the antMatchers, mvcMatchers, and regexMatchers methods were deprecated in favor of new requestMatchers methods. https://docs.spring.io/spring-security/reference/5.8/migration/servlet/config.html

除此之外还有一些鸡肋漏洞，比如 Spring Security 与 WebFlux 的匹配，或者应用在使用 Spring 的基础上还使用了其他 Servlet，又或者是一些特殊配置下的鉴权绕过，这里就不展开介绍了。

参考资料:

Shiro

在前文中介绍了 Shiro 针对 Java EE 应用的基本配置以及 URL 路径的过滤和匹配代码实现。实际上在 Shiro 中 Spring 也是一等公民，有单独的配置选项，见: Integrating Apache Shiro into Spring-Boot Applications。

针对 Spring MVC 的路径鉴权匹配实现和针对一般 Java Web 应用的实现大同小异，回顾前文的代码片段:

// org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain
final String requestURI = getPathWithinApplication(request);
final String requestURINoTrailingSlash = removeTrailingSlash(requestURI);
for (String pathPattern : filterChainManager.getChainNames()) {
  if (pathMatches(pathPattern, requestURI)) {
    return filterChainManager.proxy(originalChain, pathPattern);
  } else {
    // 针对 Spring Web 的处理
    pathPattern = removeTrailingSlash(pathPattern);
      if (pathMatches(pathPattern, requestURINoTrailingSlash)) {
        return filterChainManager.proxy(originalChain, pathPattern);
      }
  }
}

其中针对 Spring Web 会进行额外处理，即删除 pathPattern 中末尾的分隔符再进行一次比对。值得注意的是 getPathWithinApplication 中使用的路径并不是 getRequestURI 而是 getServletPath + getPathInfo，这几个常见路径的官方介绍如下:

getRequestURI: 原始 HTTP 请求路径部分在请求参数(即?)之前部分的内容，这是最原始的数据，包含原样的用户输入；
getContextPath: 对应 Context 的路径，即 Web 容器挂载对应应用的前缀；
getServletPath: 调用对应 Servlet 时的(相对)路径，不包含 Context 部分，且删除了路径参数；
getPathInfo: 额外设置的路径信息，默认为 null；

不管如何，Shiro 会尝试使用“干净”的路径去匹配鉴权规则，这在 Spring MVC 项目中与 Spring Security 比起来就多了很多潜在的鉴权路由不匹配风险。基本上 Spring Security 出现过的问题很可能也会在 Shiro 中出现。

比如，Spring Security 中 CVE-2016-5007，通过在路径添加空格的方式绕过鉴权，在 Shiro 中就有 CVE-2020-17510 和 CVE-2020-17523 等针对 AntPathMatcher 的绕过方式；

又比如，Spring Security 中 regexMatcher 正则表达式 DOTALL 问题导致的 CVE-2022-22978，在 Shiro 中也有几乎一样的 CVE-2022-32532，针对 RegExPatternMatcher 的绕过方式；

关于更多 Shiro 的历史漏洞介绍和分析，可以参考已有的优秀文章，比如 Shiro 历史漏洞分析。

总结

相比于传统的 JavaEE Web 应用，Spring 基于全匹配的 DispatcherServlet 实现了一套应用层的路由方案，并且在依赖注入的加持下使得业务开发和配置变得更加方便。这一套路由方案屏蔽了底层 Servlet 容器的解析差异，但同时也引入了 Spring 特有的解析陷阱。在不断的更新过程中，Spring Security 逐渐与 MVC 对齐，使用相同的路径匹配方法，从而避免鉴权和路由不一致的问题，但是 Shiro 就没那么幸运了，作为 “外拨秧” 缺乏官方的支持，只能寻求更为通用的解决方案，但未来这类不匹配的问题可能还是依旧会出现。

通过最近两篇文章针对 URL 路径鉴权的分析，对解析路径时会遇到的陷阱也算有了基本了解。虽然文章只介绍了 Java Web 生态的 URL 鉴权实现，但对于其他应用也是类似的。核心在于 TOCTOU 即判断和最终使用的变量不一致问题。这一类问题不仅出现在 Web 中，在二进制世界经常也是导致条件竞争、UAF 之类漏洞的元凶，值得我们在漏洞挖掘时重点关注。

参考链接

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/08/19/url-gotchas-spring/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

浅谈 URL 解析与鉴权中的陷阱

Sat, 29 Jul 2023 12:40:00 +0800

最近一段时间都在审计 Java 代码，也算是积累了一些各式各样小技巧，但总感觉不够体系化。因此有必要先停下来，跳出业务逻辑并后退一步，更加深入地思考一下漏洞背后的成因。

前言

说到 URL 解析，想必关注 Web 安全的朋友们都看过 Orange 那篇 A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages，其中对不同语言中的 URL Parser 做了较为详尽的分析。该议题主要关注不同 Parser 处理 URL 时的域名部分，以实现针对 SSRF 的绕过和后利用。

本文的关注点则有所不同，主要是针对 URL 解析的路径部分。因为 URL 的路径部分通常涉及到资源和服务的路由，以及对应的鉴权校验。通常我们在漏洞挖掘和渗透测试时都收集过一些鉴权绕过的 “Tricks”，但很多时候并不了解其所以然，每每测试结束后总觉得缺少了些什么。这些绕过的 payload 是否覆盖了所有场景？是否还有其他可能的变种？其实也不能完全肯定。

因此就有了这篇文章，一方面记录和整理笔者遇到过的鉴权绕过技巧，另一方面也尝试分析这些绕过背后的原理，希望对大家有所启发。

威胁模型

本文主要以 JavaEE 的 Web 网络框架举例，这是因为 Java 目前在国内有着庞大的使用率和 Web 生态。不过我相信在许多其他 Web 框架下如 PHP、NodeJS 中也是可以举一反三的。

回顾 Java 安全研究初探一文中提到的 Java Web 应用的请求流程，大致可以抽象成如下的链路:

Client -> Filter_1 -> Filter_2 -> ... -> Filter_n -> Servlet

即客户端的请求会经过一个或者多个 Filter，然后再到达实际处理请求的 Servlet 中。通常 Filter 以级联方式运作，称为 FilterChain，而出于低耦合的设计模式考虑，开发者一般会将重要的鉴权逻辑放在 Filter 中实现。一旦认证失败，可以提前终止请求，这对于 Servlet 而言是透明的。

因此，所谓的鉴权绕过，很多情况下就是鉴权 Filter 中的逻辑错误。而 Filter 中的鉴权，大部分情况下也是 URL 粒度的鉴权，毕竟在一个网站中总是会有无需认证的前台界面(如登录界面)，以及需要认证的后台服务(如管理后台)。

从代码上看，Filter 中鉴权使用的多是 HttpServletRequest.getRequestURI() 接口，判断对应路径是否需要鉴权，如果需要则进行 Session 的判断和认证，对于鉴权失败的请求则返回 403 拒绝访问或者 302 跳转到登录界面。

绕过 Filter 中的 URL 的鉴权认证只是第一步，而更为重要的一步是如何在构造畸形 URL 的同时依然能寻址到正确的 Servlet，从而正确处理业务请求。因此本文也正是从这两方面出发，分别探寻 URL 解析中的隐秘。

Servlet 容器

首先要明确的是，不管构造的 URL 再怎么花里胡哨，如果 URL 路径寻址不到正确的 Servlet，那都是没有意义的，只能获得一个空虚的 404 聊以自慰。因此我们先从 Servlet 的寻址开始，尝试在正常寻址的基础上进行变异。

URL 的路由在不同的 Servlet 容器中的实现各不相同，这里仅选择两个笔者最近在看的容器去进行分析。

Tomcat

首先是最常见的 Tomcat 容器。关于 Tomcat 的源码分析在网上已经有过很多文章了，我们只需要关注其中 URL 到业务代码的路由映射过程。最简单的方式就是使用调试器在 Servlet 中打上一个断点去反向追踪源码的相关部分。业务代码如下:

@WebServlet(name = "flagServlet", value = "/api/flag")
public class FlagServlet extends HttpServlet {
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        PrintWriter out = response.getWriter();
        out.println(String.format("YOU WIN: [%s]", request.getRequestURI()));
    }
}

在成功访问后返回请求的 RequestURI 的值。在 doGet 打个断点，请求 /api/flag 后触发的堆栈信息如下:

doGet:17, FlagServlet (com.example.tc)
service:529, HttpServlet (javax.servlet.http)
service:623, HttpServlet (javax.servlet.http)
internalDoFilter:209, ApplicationFilterChain (org.apache.catalina.core)
doFilter:153, ApplicationFilterChain (org.apache.catalina.core)
doFilter:51, WsFilter (org.apache.tomcat.websocket.server)
internalDoFilter:178, ApplicationFilterChain (org.apache.catalina.core)
doFilter:153, ApplicationFilterChain (org.apache.catalina.core)
doFilter:20, AdminFilter (com.example.tc)
doFilter:53, HttpFilter (javax.servlet.http)
internalDoFilter:178, ApplicationFilterChain (org.apache.catalina.core)
doFilter:153, ApplicationFilterChain (org.apache.catalina.core)
invoke:167, StandardWrapperValve (org.apache.catalina.core)
invoke:90, StandardContextValve (org.apache.catalina.core)
invoke:481, AuthenticatorBase (org.apache.catalina.authenticator)
invoke:130, StandardHostValve (org.apache.catalina.core)
invoke:93, ErrorReportValve (org.apache.catalina.valves)
invoke:673, AbstractAccessLogValve (org.apache.catalina.valves)
invoke:74, StandardEngineValve (org.apache.catalina.core)
service:343, CoyoteAdapter (org.apache.catalina.connector)
service:390, Http11Processor (org.apache.coyote.http11)
process:63, AbstractProcessorLight (org.apache.coyote)
process:926, AbstractProtocol$ConnectionHandler (org.apache.coyote)
doRun:1791, NioEndpoint$SocketProcessor (org.apache.tomcat.util.net)
run:52, SocketProcessorBase (org.apache.tomcat.util.net)
runWorker:1191, ThreadPoolExecutor (org.apache.tomcat.util.threads)
run:659, ThreadPoolExecutor$Worker (org.apache.tomcat.util.threads)
run:61, TaskThread$WrappingRunnable (org.apache.tomcat.util.threads)
run:829, Thread (java.lang)

注: 这里使用的 Tomcat 为 9.0.78 版本，是文章编写时 Tomcat9 的最新版本。之所以选择 Tomcat9 而不是 Tomcat10 是因为目前其存量应用相对较多(听说)。

CoyoteAdaptor

AdminFilter 是我自己写的一个 Filter，这里先无需在意。Tomcat 在进入第一个 FIlter 之前就已经确定了路由的目标。注意上述调用栈中的 CoyoteAdapter，实际方法为 org.apache.catalina.connector.CoyoteAdapter#service:

@Override
public void service(org.apache.coyote.Request req, org.apache.coyote.Response res) throws Exception {
    // ...
    postParseSuccess = postParseRequest(req, request, res, response);
    if (postParseSuccess) {
        // Calling the container
        connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);
    }
}

postParseRequest 的调用时机是在 TCP 的 HTTP 请求头接收完之后，并且在 Body 读取之前，也正是在其中处理了 URL 的映射。在 Tomcat 中请求对应的路由是存放在 request.mappingData 中的。对于上述请求，会依次调用:

postParseRequest
org.apache.catalina.mapper.Mapper#map
org.apache.catalina.mapper.Mapper#internalMap

internalMap 的关键代码片段如下:

private void internalMap(CharChunk host, CharChunk uri, String version, MappingData mappingData) throws IOException {
    if (uri.isNull()) {
        // Can't map context or wrapper without a uri
        return;
    }
    uri.setLimit(-1);

    // Context mapping
    ContextList contextList = mappedHost.contextList;
    MappedContext[] contexts = contextList.contexts;
    int pos = find(contexts, uri);
    if (pos == -1) {
        return;
    }
    // Wrapper mapping
    if (!contextVersion.isPaused()) {
        internalMapWrapper(contextVersion, uri, mappingData);
    }

}

contexts 数组中包含一系列 org.apache.catalina.mapper.Mapper.MappedContext#MappedContext，表示 URL 路由的上下文，说简单点就是 URL 的前缀。一般一个 Context 前缀代表一个 JavaEE 应用，在 Tomcat 中其实还注册了几个默认的应用，对应的前缀(ContextRoot)分别是:

/docs
/examples
/manager
/host-manager

我们这次请求的 URI 为 /api/flag，且部署的 ContextRoot 为空，因此命中的就是我们的应用。一个完整的 URL 如下所示:

http://host:port/context-root[/url-pattern]

如果 ContextRoot 为 /demo 的话，示例的 Servlet 会映射到 /demo/api/flag。

Mapper

定位到 context 之后，接下来就是在对应 context 下查找具体的路由。这个过程称为 “Wrapper mapping”，Wrapper 可以理解为 Servlet 的封装。所调用的方法为 org.apache.catalina.mapper.Mapper#internalMapWrapper。

关键代码如下:

private void internalMapWrapper(ContextVersion contextVersion, CharChunk path, MappingData mappingData) throws IOException {
    // Rule 1 -- Exact Match
    MappedWrapper[] exactWrappers = contextVersion.exactWrappers;
    internalMapExactWrapper(exactWrappers, path, mappingData);
    // Rule 2 -- Prefix Match
    MappedWrapper[] wildcardWrappers = contextVersion.wildcardWrappers;
    if (mappingData.wrapper == null) {
        internalMapWildcardWrapper(wildcardWrappers, contextVersion.nesting, path, mappingData);
    }
    // Rule 3 -- Extension Match
    MappedWrapper[] extensionWrappers = contextVersion.extensionWrappers;
    if (mappingData.wrapper == null && !checkJspWelcomeFiles) {
        internalMapExtensionWrapper(extensionWrappers, path, mappingData, true);
    }
    // Rule 4 -- Welcome resources processing for servlets
        // Rule 4a -- Welcome resources processing for exact macth
        // Rule 4b -- Welcome resources processing for prefix match
        // Rule 4c -- Welcome resources processing

    /*
    * welcome file processing - take 2 Now that we have looked for welcome files with a physical backing, now look
    * for an extension mapping listed but may not have a physical backing to it. This is for the case of index.jsf,
    * index.do, etc. A watered down version of rule 4
    */

    // Rule 7 -- Default servlet
}

在深入代码之前，我们先插播一条关于 JavaEE Servlet 标准的回忆录。

Servlet 标准

在前面的文章也简单提到过，Servlet 映射查找是依据 JSR 340: Java Servlet 3.1 Specification 中的第 12 章 Mapping Requests to Servlets 的介绍而实现的。其中关键的寻址逻辑笔者总结如下:

首先尝试查找 Servlet 路由的 精确匹配；
递归查找最长前缀匹配，以 / 字符为每一级目录树的分隔，即前缀匹配的单位是目录；
如果 URL 路径的最后一个片段(Segment)包含后缀，容器会尝试使用后缀匹配对应的 Servlet，比如对于 .jsp 后缀使用 JspServlet；
如果上述规则都没有成功匹配，容器将会尝试根据请求的 URL 去匹配对应的资源，这通常会使用一个容器自带的默认 Servlet 去处理。

在标准中还提到了几个值得注意的点:

在匹配 ContextRoot 的时候也是使用最长前缀匹配；
在 URL 进行匹配时候都是 大小写敏感的；

对于配置映射的，有以下规则:

映射值以 / 开头且以 /* 结尾的用于前缀匹配映射；
映射值以 *. 开头的使用后缀匹配；
空字符是一个特殊的映射值，指向 context-root；
仅包含字符 / 的映射值表示对应应用的默认 Servlet；
其他所有的值都被认为是精确匹配；

因此，对于应用中定义的不同映射，都可以根据寻址逻辑按照顺序找到最佳的匹配。

Wrappers

回忆杀结束，继续回到上述 internalMapWrapper 的代码中。按照查找的顺序，Tomcat 会依次从下面的 Wrapper 中进行匹配:

exactWrappers: 用于精确匹配的 Wrapper，比如值为 /api/flag 的 FlagServlet；
wildcardWrappers: 用于(最长)前缀匹配的通配符 Wrapper，比如值为 /admin/* 的 Servlet；
extensionWrappers: 用于后缀匹配的 Wrapper，比如值为 *.txt 的 Servlet。在 Tomcat 中默认有两个，分别是 jsp 和 jspx，都对应 org.apache.jasper.servlet.JspServlet；
welcomeResources: 如果 URL 的最后一个字符是 /，则会尝试匹配欢迎页面，默认是 index.html、index.htm、index.jsp；对于没有物理文件的欢迎页面，比如 index.do、index.jsf 等，会根据后缀匹配的方式在内置资源文件中查找；
defaultWrapper: 在前面都没有匹配的情况下，使用 Tomcat 的默认 Servlet 去进行处理，对应类是 org.apache.catalina.servlets.DefaultServlet，用于请求磁盘文件或者 jar 包中的文件。

大体来说，每一个 Servlet 对应一个 Wrapper 实例，而根据 URL 查找 Wrapper 的过程也就是对应 Servlet 路由查找的过程。

decodeURI

值得注意的是，在进行 Wrapper 查找的时候，所使用的 uri 是已经进行过处理的，还是在 CoyoteAdapter#postParseRequest 方法中:

protected boolean postParseRequest(){
    MessageBytes decodedURI = req.decodedURI();
    // Parse (and strip out) the path parameters
    parsePathParameters(req, request);
    // URI decoding
    // %xx decoding of the URL
    req.getURLDecoder().convert(decodedURI.getByteChunk(),
            connector.getEncodedSolidusHandlingInternal());
    // Normalization
    if (normalize(req.decodedURI())) {
        // Character decoding
        convertURI(decodedURI, request);
    }
}

decodedURI 只是 req.decodedUriMB 的一个指针(引用)，在后续处理中有时没有直接指定 decodeURI 而是使用了 req 进行传参，但效果都是对 decodedURI 进行修改。

首先是第一步，parsePathParameters，该方法会解析 Path Parameter 即路径参数，后面介绍 URL 标准文档的时候会详细说到。路径参数是针对每一级 URL 目录的参数，形如 /api;a=b/flag;c=d，使用分号 ; 进行指定，并以等号 = 指定 key 和 value。解析路径参数之后会将其使用 Request.addPathParameter 加入到请求信息中，并且将其从 decodeURI 中删除。

第二步，URL Decode，正常的 URL 解码。

第三步，Normalization，主要针对 URL 中包含 “", “//”, “/./” 以及 “/../” 的情况，操作过程如下:

将 \ 替换为 /；
将 // 替换为 /；
对于 /. 或者 /.. 结尾的 URI，先在末尾额外添加一个 /；
递归解析 URI 中的 /./ 字符串，将其替换为 /；
递归解析 URI 中的 /../ 字符串，移动相应的目录；

在解析 /../ 时如果超出了根目录会直接返回 false。此外一些其他的错误也会返回 false，比如 CoyoteAdapter#ALLOW_BACKSLASH 为 false 却包含反斜杠，路径不以 / 或者 \ 开头等。

第四步，Character decoding，使用 convertURI 对路径进行字符解码。因为此时的路径还是以 ByteChunk 的格式进行存储的，这一步会将其转换为 CharChunk；

在依次经过上述处理后，最终的 URI 才会用来进行 Servlet 路由查找。

Bypass Tricks

据此，我们可以得到一系列 “Bypass Tricks”，即用不同的方式路由到同一个 Servlet 中，比如目标路由是 /api/flag 的话，以下请求都能寻址到目标:

/api;a=b/flag: 通过 Path Parameter 路径参数变异；
/api/%66%6C%61%67: 通过 URL 编码进行变异；
\api\flag: 通过 Normalization 1 变异，当前需要 Tomcat 配置 ALLOW_BACKSLASH 为 true；
//api/flag: 通过 Normalization 2/3 变异;
/api/./flag: 通过 Normalization 4 变异；
/foo/api/../api/flag: 通过 Normalization 5 变异；

这些变异方法可以相互组合进行使用，另外配合 DefaultServlet 针对磁盘文件和资源的路由也可以组合出其他的 URI。

Resin

虽然 Tomcat 相对常用，但实际场景中也有许多其他的 Web 容器实现。正所谓兼听则明，偏信则暗，因此这里选取另外一个 Web 容器 Resin 作为对比，看看二者对 URL 的处理和路由有何异同。之所以选择 Resin 只不过是因为笔者最近正好看到而已。

这里选择的 Resin 版本是 4.0.58

还是老方法，直接在 Servlet 中下断点，观察 Resin 的请求调用栈如下:

doGet:17, FlagServlet (com.example.resin)
service:120, HttpServlet (javax.servlet.http)
service:97, HttpServlet (javax.servlet.http)
doFilter:109, ServletFilterChain (com.caucho.server.dispatch)
doFilter:21, AdminFilter (com.example.resin)
doFilter:127, HttpFilter (javax.servlet.http)
doFilter:89, FilterFilterChain (com.caucho.server.dispatch)
doFilter:156, WebAppFilterChain (com.caucho.server.webapp)
doFilter:95, AccessLogFilterChain (com.caucho.server.webapp)
service:304, ServletInvocation (com.caucho.server.dispatch)
handleRequest:840, HttpRequest (com.caucho.server.http)
dispatchRequest:1367, TcpSocketLink (com.caucho.network.listen)
handleRequest:1323, TcpSocketLink (com.caucho.network.listen)
handleRequestsImpl:1307, TcpSocketLink (com.caucho.network.listen)
handleRequests:1215, TcpSocketLink (com.caucho.network.listen)
handleAcceptTaskImpl:1011, TcpSocketLink (com.caucho.network.listen)
runThread:117, ConnectionTask (com.caucho.network.listen)
run:93, ConnectionTask (com.caucho.network.listen)
handleTasks:175, SocketLinkThreadLauncher (com.caucho.network.listen)
run:61, TcpSocketAcceptThread (com.caucho.network.listen)
runTasks:173, ResinThread2 (com.caucho.env.thread2)
run:118, ResinThread2 (com.caucho.env.thread2)

前部分的调用为 FilterChain 调用，逐个调用已注册的 Filter。进入第一个 Filter 之前的调用为我们关心的路由解析完成之时。其方法为 com.caucho.server.http.HttpRequest#handleRequest，大致调用代码如下:

public boolean handleRequest() throws IOException {
  startRequest();
  if (! parseRequest()) {
      return false;
  }
  CharSequence host = getInvocationHost();
  Invocation invocation = getInvocation(host, _uri, _uriLength);

  startInvocation();
  invocation.service(requestFacade, getResponseFacade());
}

其中，startRequest 方法会读取 _uri、_headerKeys、_headerValues 等属性；parseRequest 将 buffer 中的请求方法、URI、HTTP 协议以及后续的 HTTP 头逐行解析并保存。

在 readRequest 即 HTTP 的第一行时读取 URI，有相关的代码片段:

// skip 'http:'
if (ch != '/') {
}
// read URI
while (! isHttpWhitespace[ch]) {
  uriBuffer[uriLength++] = (byte) ch;
  if (readTail <= readOffset) {
    uriBuffer = _uri;
    uriLength = _uriLength;
}
  ch = readBuffer[readOffset++] & 0xff;
}

其中如果第一个字符不是 / 会跳到 URL 路径中进行读取。

Invocation

与 Tomcat 的 Wrapper 对应的数据结构在 Resin 中称为 Invocation，获得了 Invocation 也就获得了对应 Servlet 的路由映射。因此我们重点关注 getInvocation 方法的实现，调用过程如下:

com.caucho.server.http.AbstractHttpRequest#getInvocation
- com.caucho.server.dispatch.InvocationServer#getInvocation
- com.caucho.util.LruCache#get
com.caucho.server.http.AbstractHttpRequest#buildInvocation

简单来说，AbstractHttpRequest#getInvocation 会先尝试从 InvocationServer._invocationCache 缓存中获取 Invocation 对象，如果不存在则会使用 buildInvocation 新建一个并放入缓存中。_invocationCache 是个 LRU 缓存，键为 com.caucho.server.http.InvocationKey 类型。InvocationKey 中包含 host、port、uri 三元组以及 isSecure 标志位，这么做的好处是节约路由查找时间，对于大型项目而言路由映射往往成百上千，每次请求都进行查找显然比较耗时。

com.caucho.server.http.AbstractHttpRequest#buildInvocation
com.caucho.server.dispatch.InvocationDecoder#splitQueryAndUnescape

splitQueryAndUnescape 中对 Invocation 的 URI 进行了处理和赋值，代码比较重要，所以这里直接把完整的代码贴出来:

public void splitQueryAndUnescape(Invocation invocation,
                                  byte []rawURI, int uriLength)
  throws IOException
{
  for (int i = 0; i < uriLength; i++) {
    if (rawURI[i] == '?') {
      i++;

      // XXX: should be the host encoding?
      String queryString = byteToChar(rawURI, i, uriLength - i,
                                      "ISO-8859-1");
      invocation.setQueryString(queryString);

      uriLength = i - 1;
      break;
    }
  }

  String rawURIString = byteToChar(rawURI, 0, uriLength, "ISO-8859-1");
  invocation.setRawURI(rawURIString);

  String decodedURI = normalizeUriEscape(rawURI, 0, uriLength, _encoding);

  if (_sessionSuffix != null) {
    int p = decodedURI.indexOf(_sessionSuffix);

    if (p >= 0) {
      int suffixLength = _sessionSuffix.length();
      int tail = decodedURI.indexOf(';', p + suffixLength);
      String sessionId;

      if (tail > 0)
        sessionId = decodedURI.substring(p + suffixLength, tail);
      else
        sessionId = decodedURI.substring(p + suffixLength);

      decodedURI = decodedURI.substring(0, p);

      invocation.setSessionId(sessionId);

      p = rawURIString.indexOf(_sessionSuffix);
      if (p > 0) {
        rawURIString = rawURIString.substring(0, p);
        invocation.setRawURI(rawURIString);
      }
    }
  }
  else if (_sessionPrefix != null) {
    if (decodedURI.startsWith(_sessionPrefix)) {
      int prefixLength = _sessionPrefix.length();

      int tail = decodedURI.indexOf('/', prefixLength);
      String sessionId;

      if (tail > 0) {
        sessionId = decodedURI.substring(prefixLength, tail);
        decodedURI = decodedURI.substring(tail);
        invocation.setRawURI(rawURIString.substring(tail));
      }
      else {
        sessionId = decodedURI.substring(prefixLength);
        decodedURI = "/";
        invocation.setRawURI("/");
      }

      invocation.setSessionId(sessionId);
    }
  }

  String uri = normalizeUri(decodedURI);

  invocation.setURI(uri);
  invocation.setContextURI(uri);
}

提炼一下关键点，URI 的处理流程如下:

找到第一个 ? 符号并将之后的设置为 queryString；
normalizeUriEscape: 对路径进行 URI 解码；
sessionSuffix 提取: 如果 URI 末尾的路径参数是对应的后缀，则从中提取并设置 SessionID，默认的后缀是 ;jsessionid。注意此时 sessionid 参数及其之后的数据都会从 rawURI 中移除；
sessionPrefix 提取: 默认为空即不需要操作；
normalizeUri: 对路径进行归一化操作，后面细说；

normalizeUriEscape 的 URL 解码除了传统的 %dd 解码，还支持 Resin 特殊的 URL 编码，其实现如下:

private static int scanUriEscape(ByteToChar converter,
                                 byte []rawUri, int i, int len)
  throws IOException
{
  int ch1 = i < len ? (rawUri[i++] & 0xff) : -1;

  if (ch1 == 'u') {
    ch1 = i < len ? (rawUri[i++] & 0xff) : -1;
    int ch2 = i < len ? (rawUri[i++] & 0xff) : -1;
    int ch3 = i < len ? (rawUri[i++] & 0xff) : -1;
    int ch4 = i < len ? (rawUri[i++] & 0xff) : -1;

    converter.addChar((char) ((toHex(ch1) << 12) +
                              (toHex(ch2) << 8) + 
                              (toHex(ch3) << 4) + 
                              (toHex(ch4))));
  }
  else {
    int ch2 = i < len ? (rawUri[i++] & 0xff) : -1;

    int b = (toHex(ch1) << 4) + toHex(ch2);;

    converter.addByte(b);
  }

  return i;
}

即 %u0067 这种类型的解码。

注意这里处理完后的 URI 除了删除 jsessionid，依然带有其他的 Path Parameter 路径参数，这部分处理要在后面进行操作。不过在此之前还是按顺序先看 normalizeUri 的实现。

normalizeUri

从参数来看，InvocationDecoder.normalizeUri 的实现会根据当前 JVM 运行的操作系统来执行不同的归一化操作，由于这是我们 URI 变异的重点，因此直接将完整的方法实现贴出来:

public String normalizeUri(String uri, boolean isWindows)
  throws IOException
{
  CharBuffer cb = new CharBuffer();

  int len = uri.length();

  if (_maxURILength < len)
    throw new BadRequestException(L.l("The request contains an illegal URL because it is too long."));

  char ch;
  if (len == 0 || (ch = uri.charAt(0)) != '/' && ch != '\\')
    cb.append('/');

  for (int i = 0; i < len; i++) {
    ch = uri.charAt(i);

    if (ch == '/' || ch == '\\') {
    dots:
      while (i + 1 < len) {
        ch = uri.charAt(i + 1);

        if (ch == '/' || ch == '\\')
          i++;
        else if (ch != '.')
          break dots;
        else if (len <= i + 2
                 || (ch = uri.charAt(i + 2)) == '/' || ch == '\\') {
          i += 2;
        }
        else if (ch != '.')
          break dots;
        else if (len <= i + 3
                 || (ch = uri.charAt(i + 3)) == '/' || ch == '\\') {
          int j;

          for (j = cb.length() - 1; j >= 0; j--) {
            if ((ch = cb.charAt(j)) == '/' || ch == '\\')
              break;
          }
          if (j > 0)
            cb.setLength(j);
          else
            cb.setLength(0);
          i += 3;
        } else {
          throw new BadRequestException(L.l("The request contains an illegal URL."));
        }
      }

      while (isWindows && cb.getLength() > 0
             && ((ch = cb.getLastChar()) == '.' || ch == ' ')) {
        cb.setLength(cb.getLength() - 1);

        if (cb.getLength() > 0
            && (ch = cb.getLastChar()) == '/' || ch == '\\') {
          cb.setLength(cb.getLength() - 1);
          // server/003n
          continue;
        }
      }

      cb.append('/');
    }
    else if (ch == 0)
      throw new BadRequestException(L.l("The request contains an illegal URL."));
    else
      cb.append(ch);
  }

  while (isWindows && cb.getLength() > 0
         && ((ch = cb.getLastChar()) == '.' || ch == ' ')) {
    cb.setLength(cb.getLength() - 1);
  }

  return cb.toString();
}

如无特别说明则认为分隔符是 / 或者 \。这里实现路径归一化的算法是新建一个 CharBuffer，然后逐字符解析 URI，对于正常字符直接加入到 cb 中，而遇到分隔符后需要考虑特殊的情况。

首先如果 URI 首个字母不是分隔符，则会先在 cb 中添加 /；
对于遇到分隔符的情况:
1. 如果后 1 个字符还是分隔符，则往前进 2 个字符；
2. 如果后 2 个字符是 . + 分隔符，则往前进 2 个字符；
3. 如果后 3 个字符是 .. + 分隔符，则往前进 3 个字符，并且 cb 中回退一级目录，如果超出了根目录会将 cb 置空；如果后 2 个字符是 .. 但第 3 个字符不是分隔符，会直接抛异常；
4. 其他情况下 cb 中添加一个分隔符 /；但是在添加之前，对于 Windows 系统，如果 cb 中末尾的字符是 . 或者空格，会将其删除，同时会删除末尾的分隔符；
对于其他字符，直接加入 cb 中；
遍历完成后，对于 Windows 系统，删除 cb 中末尾的 . 和空格；

这里 normallize 方法的实现还是比较特别的，据此我们可以得到一些特殊的变异方式，具体在后文提及。

ServletMapper

前面获取到 Invocation 中的 URI 经过了 URL 解码和路径归一化，随后调用 InvocationServer#buildInvocation 获取对应 Server 的 Invocation 实例。最终会进入到 ServletMapper 的 mapServlet 进行 Servlet 映射查找。其中经过了 Host、Container 以及 WebApp 的查找，调用栈如下:

mapServlet:234, ServletMapper (com.caucho.server.dispatch)
buildInvocation:4154, WebApp (com.caucho.server.webapp)
buildInvocation:798, WebAppContainer (com.caucho.server.webapp)
buildInvocation:753, Host (com.caucho.server.host)
buildInvocation:319, HostContainer (com.caucho.server.host)
buildInvocation:1064, ServletService (com.caucho.server.cluster)
buildInvocation:250, InvocationServer (com.caucho.server.dispatch)
buildInvocation:223, InvocationServer (com.caucho.server.dispatch)
buildInvocation:1610, AbstractHttpRequest (com.caucho.server.http)
getInvocation:1583, AbstractHttpRequest (com.caucho.server.http)
handleRequest:822, HttpRequest (com.caucho.server.http)

mapServlet 是实际进行 Servlet 查找的实现，其大致代码如下:

public FilterChain mapServlet(ServletInvocation invocation) throws ServletException {
    String servletName = null;
    String contextURI = invocation.getContextURI();
    if (_servletMap != null) {
        cleanUri = Invocation.stripPathParameters(contextURI);
        ServletMapping servletMap = _servletMap.map(cleanUri, vars);

        if (servletMap != null) {
            servletName = servletMap.getServletName();
        }
    }

    if (servletName == null) {
        InputStream is;
        is = _webApp.getResourceAsStream(contextURI);
        if (is != null) {
            is.close();
            servletName = _defaultServlet;
        }
    }
    MatchResult matchResult = null;
    if (matchResult == null && contextURI.endsWith("j_security_check")) {
      servletName = "j_security_check";
    }

    if (servletName == null) {
      servletName = _defaultServlet;
      vars.clear();
      if (matchResult != null)
        vars.add(matchResult.getContextUri());
      else
        vars.add(contextURI);
      addWelcomeFileDependency(invocation);
    }

    if (servletName == null) {
      log.fine(L.l("'{0}' has no default servlet defined", contextURI));
      return new ErrorFilterChain(404);
    }

    String servletPath = vars.get(0);
    invocation.setServletPath(servletPath);
    invocation.setPathInfo(/*...*/);

    if (servletName.equals("invoker"))
      servletName = handleInvoker(invocation);

    invocation.setServletName(servletName);
    ServletConfigImpl newConfig = _servletManager.getServlet(servletName);
    if (newConfig != null) config = newConfig;

    FilterChain chain = _servletManager.createServletChain(servletName, config, invocation);

    if (chain instanceof PageFilterChain) {
      PageFilterChain pageChain = (PageFilterChain) chain;
      chain = PrecompilePageFilterChain.create(invocation, pageChain);
    }

    return chain;
}

按照执行顺序，简单总结一下:

首先使用 ServletInvocation#stripPathParameters 删除前面提到剩下的路径参数，即删除 ; 到 / 之间或者到 URI 末尾的内容，得到的 cleanUri 是最终用于路由查找的 URI；
使用 _servletMap.map 查找对应的 Servlet；
如果没找到，使用 _webApp.getResourceAsStream 查找对应磁盘文件或者资源文件是否存在，_defaultServlet 为 resin-file；
如果 contextURI 以 j_security_check 结尾，则路由到名称为 j_security_check 的 Servlet；
最后查找 welcom file，默认包括 index.html、index.jsp 和 index.php；

_servletMap 是 UrlMap 类型，其中有一个 RegexEntry 数组，包含了所有(当前应用)已经注册的 Servlet 映射和路由。

在 Resin 中，每个路由都使用正则表达式来进行匹配，如果多个 Servlet 都匹配中了同一个 URI，则会根据匹配的精度选择最佳结果，从而符合 Java EE Servlet 标准中的路由映射定义。

对于精确匹配，比如 /hello，对应的正则是 ^/hello$；
对于路径匹配，比如 /admin/*，对应的正则是 ^/admin(?=/)|^/admin\z；
对于后缀匹配，比如 *.jsp，对应的正则是 ^.*\.jsp(?=/)|^.*\.jsp\z；

其中精确匹配的末尾是 $，而后缀匹配的末尾是 \z，这二者有何不同？经过翻阅文档得知，\z 表示字符串末尾，而 $ 表示行末，因此 \z 可以匹配换行符而 $ 不能！

继续往下看，getResourceAsStream 查找磁盘或者资源文件的实现如下:

public InputStream getResourceAsStream(String uripath)
{
  Path rootDirectory = getRootDirectory();
  Path path = rootDirectory.lookupNative(getRealPath(uripath));

    if (path.canRead())
      return path.openRead();
    else {
      String resource = "META-INF/resources" + uripath;
      return getClassLoader().getResourceAsStream(resource);
    }
}

这和预料中的差不多，后面确定 Servlet 都使用了字符串名称，比如 resin-file、j_security_check，实际查找是通过 _servletManager.getServlet(servletName) 获取对应的 Servlet 实例，由此我们得知 ServletManager#_servlets 字典中保存了所有注册的 Servlet:

j_security_check -> com.caucho.server.security.FormLoginServlet
resin-xtp -> com.caucho.jsp.XtpServlet
resin-jsp -> com.caucho.jsp.JspServlet
resin-jspx -> com.caucho.jsp.JspServlet
resin-file -> com.caucho.servlets.FileServlet
resin-php -> com.caucho.quercus.servlet.QuercusServlet
Hello -> com.example.resin.HelloServlet
txtServlet -> com.example.resin.TxtServlet
flagServlet -> com.example.resin.FlagServlet
adminServlet -> com.example.resin.AdminServlet

后四个是笔者自己写的 Servlet，其他的都是 Resin 默认添加的。默认的 Servlet resin-file 对应 FileServlet，也负责读取静态文件或者资源的 Servlet。至此就完成了 Servlet 的查找和映射，随后只需要构建 FilterChain 并逐级调用 Filter 后即可到达对应的业务代码中。

Bypass Tricks

类似于 Tomcat，根据对上述 Resin 源码的分析，我们也可以得出一些 Bypass Tricks，在原始 URI /api/flag 的基础上进行变异以实现正常路由到相同 Servlet 的目的:

hack/api/flag: 基于 readRequest 中判断 URI 的第一个字符不为 / 的变异；
/api/fla%67: 基于 normalizeUriEscape 解码的变异；
/api/fla%u0067: 基于 scanUriEscape 中特殊 URL 编码的变异；
/api//flag: 基于 normalizeUri 2.1 的变异；
/api/./flag: 基于 normalizeUri 2.2 的变异；
../api/flag: 基于 normalizeUri 2.3 的变异；
/api\flag: 基于 normalizeUri 2.4 的变异，对于分隔符都会转换为 /；
/api/flag%20(空格)，/api/flag.: 基于 normalizeUri 2.4 的变异，仅在 Windows 系统中有效；
/api/flag;a=b: 针对 stripPathParameters 的变异；
/api/flag%0a: 基于正则表达式 $ 不匹配换行的变异；

这些变异可以组合使用，从而形成更加丰富的 URI 结果。

小结

通过分析 Tomcat 和 Resin 的 URI 解析流程，我们可以发现很多共同点，比如都会进行 URL Decode、都会进行路径归一化以及删除路径参数。同时值得注意的是不同的 Web 容器实现上又有一定差异，比如 Tomcat 在路径归一化时超出根目录的会报错，而 Resin 则会静默保留到根目录；Tomcat 与 Resin 的路由方式不同，前者严格按照 Servlet 标准实现，而后者则简化成正则表达式实现。因此在分析不同的 Web 容器时，除了尝试常见的 URI 变异方法，还可以针对性地分析对应容器的内部实现，从而找到隐藏更深的问题。

文件系统

在前面分析 Tomcat 和 Resin 容器的时候，可以发现有一个共同点，即路由在查找所有 Servlet 都失败的情况下，会使用默认的 Servlet 去进行处理，这个默认 Servlet 的作用就是读取本地磁盘或者资源中的文件。

因此仅从读文件的情况下看，我们是否可以利用文件系统寻址文件的特性来变异文件名呢？答案是肯定的。按照惯例来说应该查看对应文件系统的实现来看，但是这涉及到内核源码的分析，稍微超出了本 Java Boy 的能力范围，所以这里我直接写了一个简单的 Fuzzer 来进行文件名变异:

private void checkName(int i, String filename) {
    File f = new File(filename);
    if (f.exists())
    System.out.println(String.format("%06x pass: [%s]", i, filename));
}

public void fuzzFilename(String originFile) {
    File file = new File(originFile);
    if ( !file.exists() ) {
        return;
    }
    System.out.println(originFile + " exists.");
    Path filePath = Paths.get(originFile);
    String name = filePath.getFileName().toString();
    Path parentPath = filePath.getParent();
    String dirName = parentPath != null ? parentPath.toString() : "";
    System.out.println(String.format("dirName: %s, name: %s", dirName, name));

    for (int i = 0; i <= 0x10FFFF; i++) {
        // if (!Character.isValidCodePoint(i)) continue;
        String fuzzChar = new String(Character.toChars(i));
        checkName(i, originFile + fuzzChar);
        checkName(i, fuzzChar + originFile);
        checkName(i, dirName + fuzzChar + name);
        checkName(i, dirName + fuzzChar + File.separator + name);
        checkName(i, dirName + File.separator + fuzzChar + name);
    }
}

在 Linux/MacOS 中，输出如下:

dirName: /tmp, name: 1.txt
00002f pass: [/tmp/1.txt/]
00002f pass: [//tmp/1.txt]
00002f pass: [/tmp//1.txt]

值得注意的只有第一个，即在文件末尾加上 / 依然可以寻址到文件。

在 Windows 就比较丰富了，输出如下:

test\1.txt exists.
dirName: test, name: 1.txt
000020 pass: [test\1.txt ]
00002e pass: [test.\1.txt]
00002e pass: [test\1.txt.]
00002f pass: [test/1.txt]
00002f pass: [test/\1.txt]
00002f pass: [test\/1.txt]
00002f pass: [test\1.txt/]
00005c pass: [test\1.txt\]
00005c pass: [test\1.txt]
00005c pass: [test\\1.txt]

可以看到，在 Windows 中，文件名末尾加空格，.、/ 以及 \ 都不影响文件的定位，甚至目录末尾也可以加 . 号，这对于请求变异来说无疑增加了许多可能。假设 URL 原本要请求的文件是 /ppp/secret.txt，那么在 Windows 中请求就可以变异成:

/ppp/SERET.TXT (大小写不敏感)
/ppp/secret.txt%20
/ppp.\seret.txt
/ppp/seret.txt%2e
/ppp/seret.txt/
…

值得一提的是，在 Windows 常用的 NTFS 文件系统中，还有一种特殊的文件表示成为备用数据流(Alternate Data Streams)，简称 ADS。NTFS 中每个文件都有至少一个数据流，即主数据流，数据流的完整表示方法为:

<文件名>:<数据流名>:<数据流类型>

默认数据流名称为空，因此对于文件 foo.txt 而言其默认数据流的全称应该是 foo.txt::$DATA，其中数据流名为空，类型为 $DATA。对于目录而言，不存在默认数据流，但是有默认的目录流(directory stream)。目录流类型为 $INDEX_ALLOCATION，默认的流名称为 $I30，因此下面的目录表示都是等价的:

C:\Users
C:\Users:$I30:$INDEX_ALLOCATION
C:\Users::$INDEX_ALLOCATION

该特性可以使我们在 Windows 中寻址文件和目录时候使用更加隐晦的变异方法。

参考文档:

URI 标准

既然上面在讨论的都是 URL，那自然免不了 “官方” 的解释。不管是 Servlet 容器还是 HTTP Server，所遵循的都是同一个标准，即:

RFC3986 - Uniform Resource Identifier (URI): Generic Syntax

关于该标准相信其他师傅多少都有提及过，只是各自的关注点不同。对于本文而言，关注点在路径部分。在 3.3 节中指明，path 以第一个问号 ? 或者井号 # 终止，或者是到 URI 的结尾。各部分的示意图如下所示:

  foo://example.com:8042/over/there?name=ferret#nose
  \_/   \______________/\_________/ \_________/ \__/
   |           |            |            |        |
scheme     authority       path        query   fragment
   |   _____________________|__
  / \ /                        \
  urn:example:animal:ferret:nose

所以一般路由寻址的时候是不包含 ? 后面的参数的，但其他的部分实现各有不同，Tomcat 在路径中包含 # 时会报错，但 Resin 则会当成合法的路径一部分去进行路由查找。

路径部分的 ABNF 定义如下:

path          = path-abempty    ; begins with "/" or is empty
              / path-absolute   ; begins with "/" but not "//"
              / path-noscheme   ; begins with a non-colon segment
              / path-rootless   ; begins with a segment
              / path-empty      ; zero characters

path-abempty  = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty    = 0

segment       = *pchar
segment-nz    = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
            ; non-zero-length segment without any colon ":"

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

路径由段(segments)组成，不同段之间使用斜杠 / 进行分隔。

. 和 .. 称为 dot-segments，在对路径进行路由之前需要先去除这些段，在 5.2 章 Relative Resolution 中详细介绍了如何解析包含 dot-segment 的路径，甚至还给出了伪代码实现。

另外 path segment 中通常可以包含保留字符用来提供一些子组件，比如前面提到过的使用分号 ; 和等号 = 来为每个 segment 提供参数。标准中提到逗号 , 通常也有类似的作用，不过我们之前分析源码的时候发现 Tomcat 和 Resin 都对逗号没有特殊的处理。

鉴权案例

前面提到过，为了降低代码的耦合性，鉴权一般放到 Filter 中实现而不是在 Servlet 中实现。对于一般的开发者而言，可以很简单的写出一个鉴权 Filter，比如:

@WebFilter(filterName = "AdminFilter", urlPatterns = "/*")
public class AdminFilter extends HttpFilter {
    @Override
    public void doFilter(HttpServletRequest req, HttpServletResponse res, FilterChain chain) throws IOException, ServletException {
        String uri = req.getRequestURI();
        if (uri.startsWith("/api/flag")) {
            res.setStatus(403);
            res.getWriter().write("YOU SHALL NOT PASS: " + uri);
        } else {
            chain.doFilter(req, res);
        }
    }
}

看了前面的 Bypass Tricks，我们知道仅使用 startsWith 做鉴权是多么地不堪一击，但令人惊讶的是现实中确实存在着许多类似的鉴权代码。不仅有 startsWith，endsWith，甚至还有使用 indexOf 去比较 URI 进行鉴权的。

某 OA

当然，这类应用在红队一次又一次的毒打中逐渐成长了起来，也知道了在对 URI 鉴权之前需要先对其进行一定的清洗和过滤。下面是一个某知名 OA 应用中鉴权部分对 URI 的预处理代码:

public String path(String path) {
   path = this.uriDecode(path);
   if (path != null && path.indexOf("\\") != -1) {
      path = StringUtil.replace(path, "\\", "/", false);
   }

   if (path != null && path.indexOf("..") != -1) {
      path = StringUtil.replace(path, "\\.{2,}", "");
   }

   if (path != null && path.indexOf("./") != -1) {
      path = StringUtil.replace(path, "./", "", false);
   }

   if (path != null && path.indexOf(";") != -1) {
      path = StringUtil.replace(path, ";.*?/", "/");
   }

   if (path != null && path.indexOf(";") != -1) {
      path = StringUtil.replace(path, ";.*", "");
   }

   if (path != null && path.indexOf("//") != -1) {
      path = StringUtil.replace(path, "/{2,}", "/");
   }

   if (path != null) {
      path = StringUtil.replace(path, "\\s", "");
   }

   if (!path.equals("") && !path.startsWith("/")) {
      path = "/" + path;
   }

   return path;
}
private String uriDecode(String path) {
  try {
      if (path != null && path.indexOf("%") != -1) {
        return URLDecoder.decode(path);
      }
  } catch (Exception var3) {
      this.writeLog("uri decode error:" + path, true);
      this.writeError(var3);
  }

  return path;
}

首先 URI 解码，然后替换反斜杠，也别管 URI 的标准了，.. 直接删掉，路径参数也直接删掉，还有空格、// 之类的都进行了处理，看起来是不是无懈可击？但是其实仔细看一下会发现还是有一些问题，比如:

uriDecode 中可能会失败，导致根本没解码成功而返回原始的路径；
URI 解码之后，路径可能会存在大写，如果是 WIndows 中请求 JSP 等文件可以正确路由；
路径参数的删除在 ./ 之后，所以 .;xxx/ 处理后依旧存在 ./；
删除空格 \s 在归一化 // 之后，所以 /%20/ 依旧可以绕过替换返回 //；
…

可见尽管有时候开发者知道要过滤什么字符，但是手指也不听大脑使唤，导致写出的代码依旧漏洞百出。因此，更为科学的方案是使用知名的、经过检验的鉴权框架，而不是尝试自己处理。

Shiro

Apache Shiro 是一个简单易用的认证和鉴权管理框架，虽然本身支持许多场景，但常用于 Web 应用中的身份认证和路径鉴权。

web.xml 的配置比较简单，只需要引入 ShiroFilter 并将其映射到所有 URL，注意 filter-mapping 一般要在其他 Filter 之前:


    org.apache.shiro.web.env.EnvironmentLoaderListener



    ShiroFilter
    org.apache.shiro.web.servlet.ShiroFilter



    ShiroFilter
    /*
    REQUEST
    FORWARD
    INCLUDE
    ERROR
    ASYNC

具体的配置通过配置文件实现，默认在 WEB-INF/shiro.ini，一个示例如下:

[main]
authc.loginUrl = /login.jsp
filterChainResolver.globalFilters = null

[urls]
/login/* = anon
/admin/* = authc
/api/flag = authc

[users]
evilpan=111111

urls 中使用优先匹配，而不是最佳匹配，左边指定 URL 模式，右边指定对应的 Filter 名称。Shiro 中支持的 Filter 如下:

anon: org.apache.shiro.web.filter.authc.AnonymousFilter
authc: org.apache.shiro.web.filter.authc.FormAuthenticationFilter
authcBasic: org.apache.shiro.web.filter.authc.BasicHttpAuthenticationFilter
authcBearer: org.apache.shiro.web.filter.authc.BearerHttpAuthenticationFilter
invalidRequest: org.apache.shiro.web.filter.InvalidRequestFilter
logout: org.apache.shiro.web.filter.authc.LogoutFilter
noSessionCreation: org.apache.shiro.web.filter.session.NoSessionCreationFilter
perms: org.apache.shiro.web.filter.authz.PermissionsAuthorizationFilter
port: org.apache.shiro.web.filter.authz.PortFilter
rest: org.apache.shiro.web.filter.authz.HttpMethodPermissionFilter
roles: org.apache.shiro.web.filter.authz.RolesAuthorizationFilter
ssl: org.apache.shiro.web.filter.authz.SslFilter
user: org.apache.shiro.web.filter.authc.UserFilter

一般常用的是 authc 表示 SESSION 认证的 Filter，anon 表示可匿名访问即无需认证的 Filter。对于配置文件的其他字段及其解释可以参考官方文档，这里就不详细介绍了。

我们这里主要关心的是 Shiro 鉴权之前对 URL 路径做了什么样的处理。篇幅原因这里直接说结论，处理的方法为 org.apache.shiro.web.util.WebUtils#getPathWithinApplication，调用链路回溯如下所示:

getPathWithinApplication:114, WebUtils (org.apache.shiro.web.util)
getPathWithinApplication:105, PathMatchingFilter (org.apache.shiro.web.filter)
pathsMatch:124, PathMatchingFilter (org.apache.shiro.web.filter)
preHandle:195, PathMatchingFilter (org.apache.shiro.web.filter)
doFilterInternal:131, AdviceFilter (org.apache.shiro.web.servlet)
doFilter:154, OncePerRequestFilter (org.apache.shiro.web.servlet)
doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:458, AbstractShiroFilter (org.apache.shiro.web.servlet)
call:373, AbstractShiroFilter$1 (org.apache.shiro.web.servlet)
doCall:90, SubjectCallable (org.apache.shiro.subject.support)
call:83, SubjectCallable (org.apache.shiro.subject.support)
execute:387, DelegatingSubject (org.apache.shiro.subject.support)
doFilterInternal:370, AbstractShiroFilter (org.apache.shiro.web.servlet)
doFilter:154, OncePerRequestFilter (org.apache.shiro.web.servlet)
internalDoFilter:178, ApplicationFilterChain (org.apache.catalina.core)

getPathWithinApplication 的代码为:

public static String getPathWithinApplication(HttpServletRequest request) {
    return normalize(removeSemicolon(getServletPath(request) + getPathInfo(request)));
}

主要经过两步，分别是 removeSemicolon 去除分号以及 normalize 路径归一化。removeSemicolon 的实现只考虑路径末尾的分号:

private static String removeSemicolon(String uri) {
    int semicolonIndex = uri.indexOf(';');
    return (semicolonIndex != -1 ? uri.substring(0, semicolonIndex) : uri);
}

不过 normalize 的实现倒是比较完善，注释中也说明这是从 Tomcat 中 “借鉴” 的:

Normalize operations were was happily taken from org.apache.catalina.util.RequestUtil in Tomcat trunk, r939305

值得注意的是，这里传入的并不是原始的 URI，而是 getServletPath + getPathInfo，二者分别是:

HttpServletRequest.getServletPath()，在 Tomcat 中对应 mappingData.wrapperPath.toString()；
HttpServletRequest.getPathInfo()，在 Tomcat 中对应 mappingData.pathInfo.toString()；

在前面介绍 Tomcat 中路由映射的时候提到，mappingData 中的 wrapper 是在路由之后确定的，也就是说此时 wrapperPath 已经是 Web 容器处理之后的 URI，如果能寻址到 flagServlet，那么其值必然是 /api/flag，优雅地解决了 TOCTOU 不一致的问题。

当然这也不意味着无懈可击，否则 Shiro 也不会再加一层 removeSemicolon 和 normalize。因为 Web 容器具有多样性，不同路由策略的碎片化同样也可能造成 Shiro 的绕过。而现在的 getPathWithinApplication 也不是一开始就是这样的，而是在 CVE-2020-13933 出现之后才改成这样子，详情可以参考: ANNOUNCE CVE-2020-13933 Apache Shiro 1.6.0 released。

在对路径完成这一步过滤后，使用 pathMatches 进行匹配:

// org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain
final String requestURI = getPathWithinApplication(request);
final String requestURINoTrailingSlash = removeTrailingSlash(requestURI);
for (String pathPattern : filterChainManager.getChainNames()) {
  if (pathMatches(pathPattern, requestURI)) {
    return filterChainManager.proxy(originalChain, pathPattern);
  } else {
    // 针对 Spring Web 的处理
    pathPattern = removeTrailingSlash(pathPattern);
      if (pathMatches(pathPattern, requestURINoTrailingSlash)) {
        return filterChainManager.proxy(originalChain, pathPattern);
      }
  }
}

注意这里针对 Spring 应用进行了特殊处理，因为在 Spring 中 /resource/data 和 /resource/data/ 都能路由到同一个资源，但 Shiro 的 /resource/data 无法匹配到后者，因此将路径和 pathPattern 都删除了末尾的 / 去进行二次匹配。这应该是针对 CVE-2021-41303 的补丁，可见即便是成熟的鉴权框架也依然会踩到 URL 鉴权的陷阱。

后记

本文介绍了使用 URL 进行鉴权的一类威胁模型，并以两个符合标准的 Servlet 容器 Tomcat 和 Resin 为例介绍了二者的路由查找方法，根据路由查找的过程提出了一系列可能的 URL 变异方式；然后对几个现实中的鉴权案例进行分析，包括某典型应用手搓的鉴权代码以及成熟的鉴权方案 Shiro，其中都存在或者出现过鉴权绕过的场景，从中我们可以加深对 URL 鉴权的理解，从而写出更加健壮和安全的代码。

另外，本文只是介绍了 Servlet 标准应用的路由特性，而现代 Java Web 应用中更多是基于 Spring 生态的全家桶方案，Spring MVC 包揽了 Web 容器的所有路由并使用自身的寻址实现，且配合 Spring Security 也形成一套 URL 鉴权方案。这部分限于篇幅原因并未在本文中提及，后续有机会的话会另起一篇文章进行介绍。

彩蛋🥚: 在分析 Resin 路由的时候，其实暴露了一个 “0day”，涉及到路径处理的核心顺序错误，不知道读者是否能够发现？

LINKS

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/07/29/url-gotchas/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.