假设我们有一个网站询问用户他的名字。
网站然后将此值存储在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提供。简短形式是：接受已知的良好验证，您可以清楚地定义可接受的输入并仅接受这些输入。除了阻止已知的坏模式之外还有一个黑名单（与良好的接受已知良好方法一致，不替换它）也是一个好主意。