Cookies是否存在安全风险?

3
假设我们有一个网站要求用户输入他的名字。然后,该网站将这个值存储在 cookie 中,在下一页中,通过 PHP 检索它并以某种方式使用它(可能会将姓名显示为文本)。用户能否修改 cookie 数据以注入恶意代码?检索脚本检索到的 cookie 数据应进行净化吗?(这是一个假想的情景,显然在这里不需要 cookie。)

1
请参阅手册中的“处理外部变量”章节,了解有关HTTP cookie和一般信息。 - mario
4个回答

4

用户能否修改cookie数据以注入恶意代码?在脚本检索cookie时,是否应对其进行净化处理?

注入恶意代码?不是PHP代码,但您是正确的,应在使用它们之前对cookie值进行净化处理。

用户可以轻松地修改、添加和删除cookie,因此应将其视为不可信的用户输入。它们与任何其他用户输入一样容易受到XSS和SQL注入漏洞的影响。

此外,除非您使用SSL,否则cookie与请求中的GET或POST数据一样容易被嗅探。恶意互联网服务可以拦截或修改cookie。还请参见Firesheep,了解cookie可能被误用和不信任的示例。


如果你从 cookie 中“运行”数据,那你就是疯了。 - user557846
嗯,让我修正那个短语的措辞。 - Charles
你能提供一个关于如何利用cookie数据进行XXS攻击的例子吗? - Peter
1
你的意思是说,例如 echo $_COOKIE['foo'] 吗?实际上,考虑到 cookie 是特定于浏览器的,对于用户来说自我 XSS 是非常愚蠢的。对于恶意的互联网服务提供商来说,修改 cookie 来执行 XSS 也很愚蠢,因为他们可以直接修改内容。 - Charles
抱歉,为什么不用PHP代码?这与drrcknlsn的答案相冲突。 - Peter
2
除非您通过评估字符串作为代码的函数(如evalassertcreate_function),或者如果您在使用变量变量变量函数时不小心,否则服务器上永远不会执行任何用户数据。仅仅将cookie数据回显给用户只是创建了一个XSS漏洞,而不是创建了一个代码注入漏洞。 - Charles

3

使用cookie本身并没有安全风险。安全风险来自于你处理cookie数据的方式,以及存储在cookie中的数据。例如,如果你这样做:

<h3>Hello, <?php echo $_COOKIE['user']; ?>!</h3>

如果你不适当地对 HTML 上下文中的 cookie 数据进行转义,则用户将能够向你的页面注入任意代码(XSS 漏洞)。为了解决这个安全问题,你必须正确地进行 cookie 数据转义:

<h3>Hello, <?php echo htmlspecialchars($_COOKIE['user']); ?>!</h3>

在第一个例子中注入可执行的PHP代码是可能的吗? - Peter
@Peter:是的,这是可能的,但并不是因为使用了cookies。而是因为缺乏适当的数据转义。如果您没有正确地转义数据,则POST、GET、SERVER、FILE、SESSION等都存在相同的漏洞。 - FtDRbwLXw6

1

在 PHP 中,所有带有 $_($_POST、$_GET、$_COOKIE、$_FILE、$_SESSION)前缀的变量在放置到页面或数据库中之前都应该进行检查。

您可以使用 htmlentities( $str ) 来保护大部分注入攻击。


htmlentities 如果不小心处理,可能会恶意篡改 Unicode。 htmlspecialchars 提供了与字符集混乱无关的相同级别的 XSS 保护。 - Charles
@Charles:htmlentities() 函数有一个可选的第三个参数来指定字符集。只有在不使用正确设置的情况下,它才会“恶意破坏”您的数据。 - FtDRbwLXw6
虽然这是真的,但它也迫使你在每个调用时都考虑字符编码,这最多是繁琐的,最糟糕的情况下是一种恼人的麻烦。 - Charles

0

Cookie是客户端的另一种输入形式,客户端可以在cookie中发送任何他们想要的内容,您的应用程序必须对cookie中提交的内容进行清理/验证,以免被攻击。

OWASP提供了有关执行数据验证的良好指导,这应该适用于应用程序中的所有输入,包括cookie,并且可以在此处找到。简而言之,要进行接受已知良好验证,其中您明确定义可接受的输入并仅接受这些输入。除此之外,还应该有黑名单来阻止已知的恶意模式(与良好的接受已知良好方法相结合,而不是替代它),这也是一个好主意。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接