假设我们有一个网站询问用户他的名字。
网站然后将此值存储在cookie中,并在下一页上通过PHP检索它并以某种方式使用它(可能页面将名称显示为文本)。
用户是否可以修改cookie数据以注入恶意代码?是否应该通过脚本检索cookie数据进行清理?
(这是一个假设情景。显然,这里不需要cookie。)
答案 0 :(得分:4)
用户是否可以修改cookie数据以注入恶意代码?是否应该通过脚本检索cookie进行消毒?
注入恶意代码?不是PHP代码,但你应该在使用之前清理cookie值。
用户可以轻松修改,添加和删除Cookie,应将其视为不受信任的用户输入。它们与任何其他用户输入一样容易受到XSS和SQL注入的影响。
此外,除非您使用SSL,否则Cookie与请求中的GET或POST数据一样容易嗅探。恶意互联网服务可以拦截或修改cookie。另请参阅Firesheep以获取有关如何滥用和不信任cookie的示例。
答案 1 :(得分:3)
使用Cookie不存在固有的安全风险。安全风险来自您对cookie数据的处理以及您在cookie中存储的数据。例如,如果您执行以下操作:
<h3>Hello, <?php echo $_COOKIE['user']; ?>!</h3>
...然后用户将能够将任意代码注入您的页面(XSS漏洞)。要解决此安全问题,您必须正确转义HTML上下文的cookie数据:
<h3>Hello, <?php echo htmlspecialchars($_COOKIE['user']); ?>!</h3>
答案 2 :(得分:1)
在将名称前面的$ _($ _POST,$ _GET,$ _COOKIE,$ _FILE,$ _SESSION)放在页面或数据库中之前,应检查PHP中的所有变量。
您可以使用htmlentities( $str )
来保护大部分注射。
答案 3 :(得分:0)
Cookie只是来自客户端的另一种形式的输入,因为客户端可以在cookie中向您发送任何他们想要的内容,并且您的应用程序在您清理/验证之前不得信任cookie中提交的内容。
执行数据验证的良好指导,应该适用于应用程序的所有输入,包括Cookie,由OWASP和can be found here提供。简短形式是:接受已知的良好验证,您可以清楚地定义可接受的输入并仅接受这些输入。除了阻止已知的坏模式之外还有一个黑名单(与良好的接受已知良好方法一致,不替换它)也是一个好主意。