Rei*_*ica 18 php security encoding utf-8 mbstring
从这个优秀的" UTF-8一直到 "的问题,我读到了这个:
不幸的是,在尝试存储或在任何地方使用它之前,您应该将每个提交的字符串验证为有效的UTF-8.PHP的mb_check_encoding()可以解决问题,但你必须虔诚地使用它.真的没办法解决这个问题,因为恶意客户端 可以用他们想要的任何编码提交数据,而且我还没有找到让PHP可靠地为你做这件事的技巧.
现在,我还在学习编码的怪癖,我想知道恶意客户端可以做些什么来滥用编码.一个人可以实现什么？有人能举个例子吗？假设我将用户输入保存到MySQL数据库中,或者我通过电子邮件发送,如果我不使用该mb_check_encoding功能,用户怎么会造成伤害呢？
bob*_*nce 13
如果我不使用mb_check_encoding功能,用户怎么能造成伤害呢？
这是关于过长的编码.
由于UTF-8设计的一个不幸的怪癖,有可能产生字节序列,如果用一个朴素的位打包解码器解析,将产生与较短字节序列相同的字符 - 包括一个ASCII字符.
例如,字符<通常表示为字节0x3C,但也可以使用超长UTF-8序列0xC0 0xBC(或甚至更冗余的3或4字节序列)来表示.
如果您使用此输入并在基于Unicode的遗忘的基于字节的工具中处理它,则可以避免在该工具中使用的任何字符处理步骤.规范的例子是向PHP提交0x80 0xBC,它具有本机字节字符串.由于预期的字节序列0x3C不存在,因此对htmlspecialchars字符进行HTML编码的典型用法<将失败.所以脚本的输出仍然包括过长编码<,并且任何浏览器读取该输出都可能读取序列0x80 0xBC 0x73 0x63 0x72 0x69 0x70 0x74 as <scriptand hey presto!XSS.
从一开始就禁止使用overlongs,现代浏览器不再允许使用它们.但这对IE和Opera来说是一个真正的问题很长一段时间,而且不能保证每个浏览器都能在未来做到正确.当然,这只是一个例子 - 任何一个面向字节的工具处理Unicode字符串的地方,你可能会遇到类似的问题.因此,最好的方法是在最早的输入阶段删除所有切入点.
| 归档时间： |
|
| 查看次数： |
1425 次 |
| 最近记录： |