常见的攻击模式枚举和分类

所需的确切响应从一个utf - 8解码器无效输入不一致定义的标准。一般来说,有几种方法utf - 8解码器可能表现在一个无效的字节序列的事件:

• 1。插入一个替换字符(如。”?’”)。
• 2。忽略了字节。
• 3所示。根据不同解释字节字符编码(通常是iso - 8859 - 1字符地图)。
• 4所示。没有注意到和解码的字节是一些类似的utf - 8。
• 5。停止解码并报告一个错误(可能继续给调用者)。

一个译码器有可能以不同的方式表现为不同类型的无效输入。

RFC 3629只要求utf - 8解码器不能解码“太长的序列”(在多字节字符编码比需要的地方,但仍坚持上面的形式)。Unicode标准需要看到,解码器”……对待任何不规范的代码单元序列作为一个错误条件。这可以保证它将既不理解也不发出一个不规范的代码单元序列。”

太长的形式是最麻烦的utf - 8数据类型之一。当前RFC说他们不能解码,但老规格utf - 8只给了一个警告,许多简单的解码器将愉快地解码它们。太长的形式被用来绕过安全验证高调产品,包括微软的IIS web服务器。因此,必须非常小心避免安全问题如果从utf - 8验证之前执行转换,和通常更简单的处理太长的形式输入验证之前就完成了。

维护安全无效输入的情况下,有两个选项。第一个是解码utf - 8之前做任何输入验证检查。第二是使用一个解码器,如果无效输入,返回一个错误或文本应用程序认为是无害的。另一个可能性是完全避免转换的utf - 8,但这依赖于任何其他软件的数据传递给安全处理无效数据。

另一个考虑是错误恢复。保证正确的复苏后腐败或丢失字节,解码器必须能够认识到铅和小道字节之间的区别,而不是假设字节类型允许的将他们的立场。

也许最著名的utf - 8的攻击是针对应用补丁的Microsoft Internet Information Server (IIS) 4和5 IIS服务器。如果攻击者制造这样的请求

服务器没有正确处理% c0%af URL。你认为% c0%af意味着什么吗?11000000 10101111的二进制;如果是拆分使用utf - 8的映射规则,我们得到了这个:11000000 10101111。因此,人物是00000101111,或者0 x2f,反斜杠(/)字符!% c0%af是无效/字符的utf - 8表示。这样一个无效的utf - 8逃避通常被称为一个太长的序列。

所以当攻击者请求URL,污染他们访问

换句话说,他们走出了脚本的虚拟目录,这是标记允许程序执行,根和下到system32系统目录中,在那里他们可以通过命令来命令shell,用于cmd . exe。