2016-11-20 99 views
2

TLDR:将$ _POST数组序列化为文件并将其读回到另一个请求或不同脚本的$ _POST变量中是否安全?

我意识到这是不寻常的。这是有原因的,并且需要十几页文字来解释为什么我正在考虑在特殊情况下做这件事,至少在此期间。

归结过程:

file_put_contents('sample.post', serialize($_POST)); 

$_POST = unserialize(file_get_contents('sample.post')); 

我已经为可变后的实际内容中所广泛筛选。我的问题是序列化和反序列化整个$ _POST数组的过程是否给恶意用户一种攻击方法。如果你的代码不能在unserialize()中传递,那么反序列化可能会导致代码被加载并执行,这是由于对象的实例化和自动加载,而恶意用户可能会利用它。

我发现这些文章描述这种攻击方法。但它们似乎取决于用户能够指定要直接反序列化的字符串,IE反序列化($ _ POST ['value'])。

https://www.notsosecure.com/remote-code-execution-via-php-unserialize/ https://heine.familiedeelstra.com/security/unserialize

我是正确,只要我序列化和反序列化,对象不能在反序列化过程中产生的,对不对?

我的印象是$ _POST数组只会包含字符串(虽然我无法找到在PHP文件,明确提到的)下。

据我所知,即使有人提供一个字符串匹配的序列化对象的格式,将“存储”作为序列化过程中的字符串,具有显式长度(字节长度)。所以它只会在反序列化时被指定为一个字符串。这似乎是因为在序列化过程中字符串的长度与它们一起存储,所以不能像使用SQL注入一样从输入中破坏序列化字符串的结构。我试图用一些无效的多字节字符来欺骗它,但没有运气。但是,我无法做到这一点,经验丰富的黑客能够做到这一点是两件不同的事情。

我无法找到任何关于其他攻击方法。

请让我知道如果我失去了一些东西!我刚刚读了几条评论,说'你永远不应该这样做',所以我很紧张,我误解了一些东西。

+0

看起来像你有你的基地覆盖 – 2016-11-20 04:36:59

回答

0

我认为如果没有进一步的攻击发送一些POST变量来利用unserialize()稍后在场景中的调用是不可能的,但其他人可能有一个想法。这可能是一个问题,如果$ _POST有一些不可序列化的东西,但我认为这可能不会发生。无论是在$ _ POST,它已经在内存中一次,所以假设serialize()unserialize()正常工作,它应该是安全的做这样的事情

$serialized = serialize($userinput); 
unserialize($serialized); 

但是,你插图中保存这些数据到磁盘。在利用不同的漏洞并访问你的文件(或者像“IT设计人员”那样“通过设计”访问)之后,攻击者可能会修改已保存的序列化数据,并可能在那里注入攻击。这样它显然是脆弱的。

所以这确实是一个风险,尽管可能不是很高。请注意,此解决方案的安全性很大程度上取决于您保存的序列化内容的安全性。

+0

有人可以请仁慈解释downvote?如果你告诉我为什么这是错误的,我很乐意修改或删除我的答案。 –