用户能否修改cookie数据以注入恶意代码?在脚本检索cookie时,是否应对其进行净化处理?
注入恶意代码?不是PHP代码,但您是正确的,应在使用它们之前对cookie值进行净化处理。
用户可以轻松地修改、添加和删除cookie,因此应将其视为不可信的用户输入。它们与任何其他用户输入一样容易受到XSS和SQL注入漏洞的影响。
此外,除非您使用SSL,否则cookie与请求中的GET或POST数据一样容易被嗅探。恶意互联网服务可以拦截或修改cookie。还请参见Firesheep,了解cookie可能被误用和不信任的示例。
echo $_COOKIE['foo']
吗?实际上,考虑到 cookie 是特定于浏览器的,对于用户来说自我 XSS 是非常愚蠢的。对于恶意的互联网服务提供商来说,修改 cookie 来执行 XSS 也很愚蠢,因为他们可以直接修改内容。 - Charles使用cookie本身并没有安全风险。安全风险来自于你处理cookie数据的方式,以及存储在cookie中的数据。例如,如果你这样做:
<h3>Hello, <?php echo $_COOKIE['user']; ?>!</h3>
如果你不适当地对 HTML 上下文中的 cookie 数据进行转义,则用户将能够向你的页面注入任意代码(XSS 漏洞)。为了解决这个安全问题,你必须正确地进行 cookie 数据转义:
<h3>Hello, <?php echo htmlspecialchars($_COOKIE['user']); ?>!</h3>
在 PHP 中,所有带有 $_($_POST、$_GET、$_COOKIE、$_FILE、$_SESSION)前缀的变量在放置到页面或数据库中之前都应该进行检查。
您可以使用 htmlentities( $str )
来保护大部分注入攻击。
htmlentities
如果不小心处理,可能会恶意篡改 Unicode。 htmlspecialchars
提供了与字符集混乱无关的相同级别的 XSS 保护。 - Charleshtmlentities()
函数有一个可选的第三个参数来指定字符集。只有在不使用正确设置的情况下,它才会“恶意破坏”您的数据。 - FtDRbwLXw6Cookie是客户端的另一种输入形式,客户端可以在cookie中发送任何他们想要的内容,您的应用程序必须对cookie中提交的内容进行清理/验证,以免被攻击。
OWASP提供了有关执行数据验证的良好指导,这应该适用于应用程序中的所有输入,包括cookie,并且可以在此处找到。简而言之,要进行接受已知良好验证,其中您明确定义可接受的输入并仅接受这些输入。除此之外,还应该有黑名单来阻止已知的恶意模式(与良好的接受已知良好方法相结合,而不是替代它),这也是一个好主意。