PDO＆消毒日期/删除HTML

我让用户使用此代码更新其名称。 A）这足以消毒信息吗？ b）当我把HTML标签放在那里，如<b>name</b>它实际上在我的网站上以粗体显示！有没有可以让PDO去掉所有HTML的选项？PDO＆消毒日期/删除HTML

2011-05-23 Nikki

看起来相当健康。尽管如此，我建议使用POST而不是GET来进行破坏性/操作性操作。如果你坚持发布数据，你不太可能遭受CSRF攻击，尽管它不会让你完全免疫。

如果不真正想用户输入HTML到名称字段，不用担心在途中到数据库过滤数据。通过htmlspecialchars()或htmlentities()逃脱它。

我总是由数据应进入数据库为原料尽可能的想法站着。

编辑：差点忘了，请确保在$_GET/$_POST实际的期望值试图使用他们之前存在，如

if (isset($_POST['name'])) { 
    // now use it

2011-05-23 23:45:21 Phil

哪一个更安全？（真的不关心速度/资源） – Nikki 2011-05-23 23:50:06

@Nikki哪个“什么”更安全？ 'htmlspecialchars（）'vs'htmlentities（）'？我建议你阅读手册并确定哪一个最适合你的目的。 – Phil 2011-05-23 23:51:49

谢谢 - htmlentities是我将要使用的一个，因为它可以处理所有的html，而不仅仅是特殊字符。 – Nikki 2011-05-23 23:55:32

绝不信任用户输入！至少，将$_GET['name']包装在消毒功能中，如mysql_real_escape_string()以防止SQL注入攻击。然后，当您输出用户提供的数据时，请确保将其包装在htmlspecialchars()中以防止跨站点脚本攻击（XSS）。

2011-05-23 23:43:46 Dan

我想，当你像我上面做准备语句PDO会照顾逃避数据。 htmlspecialchars是否足以对所有XSS进行消毒？ – Nikki 2011-05-23 23:45:28

-1代表'mysql_real_escape_string（）'，使用绑定参数要好得多。 +1'htmlspecialchars（）'虽然 – Phil 2011-05-23 23:46:23

@Nikki - 是预处理语句和绑定参数比任何在消毒文本上的尝试都好。我同意Phil关于-1/+ 1 – 2011-05-23 23:51:23

A）阅读manual：

到的参数预备报表不需要引用;驱动程序会自动处理此问题。如果应用程序独占地使用预处理语句，开发人员可以肯定没有SQL注入会发生（但是，如果查询的其他部分正在兴建了转义输入，SQL注入是仍有可能 ）。

B）永远不要相信用户的数据。在输出中使用htmlspecialchars。

C）使用$ _ POST和查询，这将改变任何数据令牌，以避免CSRF。

2011-05-23 23:47:35

使用POST将不会避免CSRF。 – 2011-05-24 00:39:59

@Alix Axel使用POST可以避免大部分CSRF攻击。使用POST和令牌将有助于避免它们全部:) – 2011-05-24 00:42:14

使用带令牌的GET也可以避免任何CSRF攻击。使用POST（不带令牌）只会帮助避免不知道如何POST的人员的CSRF攻击。我认为你应该重申一下你的最后一点，因为这是一个关键问题。 – 2011-05-24 01:29:03

回答