您所在的位置:网络安全 > 数据保护 > 加密解密 > Padding Oracle攻击实例分析(2)

Padding Oracle攻击实例分析(2)

2011-01-26 12:56 赵劼 译 blog.zhaojie.me 字号:T | T
一键收藏,随时查看,分享好友!

在《2010年扬名的十大WEB黑客技术》和《浅谈ASP.NET的Padding Oracle攻击》中,我们都提到了Padding Oracle Attack的相关内容,也对其进行了一些简单的了解。接下来,通过这篇译文,我们再来对其进行一下深入的学习吧。

AD:

一个基本的Padding Oracle Attack场景

作为一个具体例子,请考虑以下场景:

http://sampleapp/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6

某个应用程序使用Query String参数来传递一个用户加密后的用户名,公司ID及角色ID。参数使用CBC模式加密,每次都使用不同的初始化向量(IV,Initialization Vector)并添加在密文前段。

当应用程序接受到加密后的值以后,它将返回三种情况:

接受到正确的密文之后(填充正确且包含合法的值),应用程序正常返回(200 - OK)。

接受到非法的密文之后(解密后发现填充不正确),应用程序抛出一个解密异常(500 - Internal Server Error)。

接受到合法的密文(填充正确)但解密后得到一个非法的值,应用程序显示自定义错误消息(200 - OK)。

上述的场景体现了一个典型的Padding Oracle(填充提示),我们可以利用应用程序的行为轻易了解某个加密的值是否填充正确。这里的单词Oracle代表了一种机制,用于了解某个测试是否通过。

既然已经给出了场景,那么我们便来查看应用程序所使用的一个加密后的参数。这个参数保存了使用分号隔离的一系列值,在我们的示例中,则是用户名(BRIAN),公司ID(12)及角色ID(12):因此这里的明文是“BRIAN;12;2;”。以下则是经过加密的Query String实例,请注意加密后的UID参数使用了ASCII十六进制表示法。

在实际情况中,攻击者并不会知道这里所对应的明文是多少,不过作为示例,我们已经知道了明文、填充、以及加密后的值(如下表)。正如之前所提到的那样,IV添加在密文的前段,即最前面8个字节。

攻击者可以根据加密后值的长度来推测出数据块的大小。由于长度(这里是24)能被8整除但不能被16整除,因此可以得知数据块的大小是8个字节。现在我们来观察下加密和解密的内部实现,下图便展示了字节级别的运算方式,这对以后攻击方式的讨论很有帮助。请注意,其中带圆圈的加号表示XOR(异或)操作。

加密过程:

解密过程:

同样值得指出的是,解密之后的最后一个数据块,其结尾应该包含正确的填充序列。如果这点没有满足,那么加/解密程序就会抛出一个填充异常。

内容导航



分享到:

热点职位

更多>>

热点专题

更多>>

读书

精通Spring 2.0
本书是关于Spring 2.0的权威教程,是Java/Java EE开发者必备的参考书。本书详尽系统地介绍了Java EE的基础知识、Spring 2.0的各

51CTO旗下网站

领先的IT技术网站 51CTO 领先的中文存储媒体 WatchStor 中国首个CIO网站 CIOage 中国首家数字医疗网站 HC3i 51CTO学院