不安全的反序列化
本文最后更新于875天前,其中的信息可能已经有所发展或是发生改变。

什么是反序列化?

有些时候我们需要把应用程序中的数据以另一种形式进行表达,以便于将数据存储起来,并在未来某个时间点再次使用,或者便于通过网络传输给接收方。这一过程我们把它叫做序列化。典型的例子是,用户数据被序列化后存储到数据库中,另一个例子是在Stateless架构下,用户登陆后的身份数据被序列化存储到了浏览器中。

不安全的反序列化

反序列化和序列化是两个正好相反的过程。当我们要再次使用这些数据的时候,应用程序读取序列化之后的数据,并将其恢复成应用程序中的数据。例如服务器端从Redis中读出一个键值对,其内容是JSON格式的字符串,代表了某个用户的个人资料,并将其恢复成应用程序可使用的数据。

反序列化有什么安全问题?

尽管反序列化最严重可导致远程代码执行(RCE,Remote Code Execution),但最常见的反序列化安全问题却是通过修改序列化之后的数据字段,从而进行提权或越权操作。

举例来说,服务器端为了能快速横向扩展而被设计成了后端无服务状态架构,这也就意味着用户登陆后,其身份信息(例如用户ID,姓名,角色,登陆时间戳等)被保存到了浏览器cookie当中,在后续的请求里将会被自动发往服务器。

不安全的反序列化

图:用户登陆后,服务器将用户身份信息存储在浏览器cookie中

存储于cookie中的这份数据的格式是应用程序自定义的,但攻击者通过探索尝试后发现,修改其中的某个字段就能将用户从普通用户修改为管理员。

存储于cookie中的原始数据:
Cookie: 3844998|AliceM|y|27|*NU*|active|null|201809

经过修改后的数据
Cookie: 3844998|AliceM|y|27|*ADMIN*|active|null|201809

由于缺乏对数据完整性的校验,服务器端在收到被修改过的这段数据后,就把当前用户当作ADMIN用户来处理了。

这些地方有反序列化安全问题

上面举的例子是浏览器存储cookie中的数据可能遭受反序列化的攻击,但还有其他很多地方也可能发生这样的攻击。例如HTTP请求body中的表达了某个或某些数据的JSON字符串,甚至Form表单中的数据某种程度上也是数据经过反序列化后的表达形式。

抽象来看,只要是从Application之外读取或接收数据,并将其反序列化成Application或API中的对象,都可能存在反序列化安全问题。

因此,下面这些地方同样可能存在反序列化安全隐患,但很可能不常被关注到:

  • 自定义的HTTP Header
  • 存储在Redis、MongoDB、MySQL等数据库里的数据,可能被不怀好意的员工修改
  • 存储在服务器本地,或者某个远程文件服务器里的文件,可能被攻击者替换
  • 缓存服务器中的数据可能被攻击者污染

怎么防御反序列化攻击?

治病需要除根,能从根本上阻止反序列化安全问题的防御方案就是完整性校验,而最常见的例子之一就是JWT。

我们知道JWT由3部分组成:Header,Payload,Verify Signature。最后的签名部分其实就是对数据进行完整性校验的关键部分。

不安全的反序列化

图:JWT基本结构

服务器端在接受到JWT之后,首先用secret对数据部分进行哈希计算,随后检查计算出来的哈希值是否和请求中的JWT签名部分的哈希值相同。若两者一致则认为数据完整性没有被破坏,若两者有差异则说明数据被修改过。

如果攻击者想要凭空伪造一个JWT,或者想修改JWT中的数据,但由于计算哈希值的secret只有服务器端才知道,因此攻击者无法伪造出合法的签名字段,进而这样有问题的JTW很容易就能被服务器端识别出来。

值得注意的是,完整性校验还需要把数据结构也包含进来,这是因为攻击者可能会修改序列化后的数据的结构,而不仅仅只是数据。

其他防御措施

除此之外其他有助于防御反序列化安全问题的措施,但并不能完美的做到事前预防,例如:

  • 反序列化之前,先进行严格的数据类型校验。由于校验规则容易被攻击者探索出来,进而容易被绕过,因此防御不能仅依赖这一个手段,但可以作为完整性校验防御方案的补充。
  • 对反序列化过程进行详尽的日志记录,用以安全审计或调查。
  • 监控反序列化过程,在发现疑似反序列化攻击时进行警报。

误区

HTTPS自带了完整性校验,一旦有人修改或替换了请求内容,就会被识别出来,所以作为开发团队,是不是就可以不用关心反序列化防御了?

HTTPS确实为数据传输提供了强有力的安全保护,但它只能对传输中的数据进行保护,能避免出现中间人攻击(Man-In-The-Middle),然而反序列化攻击却往往是在数据传输之前进行的,因此HTTPS并不能提供足够的防护。

这就犹如HTTPS只是一个尽心尽力的快递公司,它能安全的把货物从甲地运送到乙地,它可以保证递送过程中货物不被人调包,但如果攻击者交给快递公司的货物就是有问题的,那快递公司对此也无能为力,只要不是违禁品,它只能老老实实的把有问题的货物递交给收货方。

点击数:105

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇