代码之家 › 专栏 › 技术社区 › Strae

preg\u match在输入饱和中是安全的吗?

input-sanitization sanitization validation php

Strae · 技术社区 · 16 年前

例如,对于一个经典的“email字段”,如果我检查如下输入:

$email_pattern = "/^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)" .
    "|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}" .
    "|[0-9]{1,3})(\]?)$/";

$email = $_POST['email'];
if(preg_match($email_pattern, $email)){
    //go on, prepare stmt, execute, etc...
}else{
    //email not valid! do nothing except warn the user
}

:如前所述,我确实使用 准备好的报表

:我正在寻找没有mysql\u real\u escape\u字符串的东西;可能项目在未来会切换到Postgresql,所以需要跨数据库的验证方法;)

7 回复 | 直到 7 年前

pinkgothic sudip 16 年前

正则表达式是否足以进行过滤取决于正则表达式。如果要在SQL语句中使用该值,则正则表达式必须以某种方式禁止 ' " . 如果您想在HTML输出中使用这个值并且害怕XSS,那么您必须确保您的regex不允许 < > 和 .

不过,正如人们一再说的那样,你是这样做的想靠正则表达式,请受$神的爱,不要!使用 mysql_real_escape_string() 或 prepared statements 对于SQL语句,以及 htmlspecialchars()

编辑,以适应您的编辑:

准备好的报表== mysql\u real\u escape\u string()

您不能也不应该尝试使用正则表达式来适应“跨数据库”体系结构。同样,系统通常比你更清楚什么是危险的,什么不是危险的。准备好的陈述是好的,如果这些与变化相适应,那么你就可以安心睡觉了。没有正则表达式。

如果它们不是,那么您必须对数据库使用一个抽象层,比如自定义层 $分贝->转义() 在MySQL架构中映射到 mysql\u real\u escape\u string()

HTML格式

净化() 这是相当昂贵的,因为它解析了整个事情,并通过一套强大的规则来处理它。因此,如果您不需要保留HTML,您可以使用 htmlspecialchars()

安全旁注

事实上,我的任务就是放手仅当输入值与我的 regexp白名单;否则,把它还给我返回给用户。

reflected XSS 攻击。用户并不总是攻击者,因此当您将东西返回给用户时,请确保您仍然能够逃脱它。只是要记住一点。

instanceof me 16 年前

~~对于SQL注入,应该始终使用适当的转义,例如 mysql_real_escape_string prepared statements (甚至是ORM)以防止遗漏。~~ 你已经做过了。

其余的取决于应用程序的逻辑。你可以过滤HTML和验证,因为你需要正确的信息,但我做验证不是为了防止XSS,我只做业务验证*。

一般规则是“过滤/验证输入,转义输出”。因此,我避开了我显示的内容(或传输给第三方的内容),以防止HTML标记,而不是我记录的内容。

*不过,一个人的姓名或电子邮件地址不应该包含 < >

bobince 16 年前

注入是指获取一个原始文本字符串,并将其放入一个不同的上下文中,而没有合适的方法逃逸

它们是两个完全不同的问题,需要在不同的阶段分别加以研究。在读取输入时(通常在脚本开始时)需要进行验证;转义需要在您将文本插入到诸如SQL字符串文本、HTML页面或其他某些字符具有带外含义的上下文中时完成。

你不应该把这两个过程混为一谈,你不能同时处理这两个问题。卫生处理这个词意味着两者的混合,因此它本身就很可疑。不应对输入进行消毒,应根据应用程序的特定需要对其进行适当的验证。稍后,如果它们被转储到一个HTML页面中,它们应该在退出时被HTML转义。

在脚本开始时跨所有用户输入运行SQL或HTML转义是一个常见的错误。即使是以安全为中心的教程(由傻瓜编写)也经常建议这样做。其结果无一例外地是一场大混乱,有时还很脆弱。

htmlspecialchars() 而不必知道它只包含数字。

顺便说一下,这是一个非常糟糕的电子邮件验证正则表达式。不管怎样,Regex并不是一个很好的电子邮件验证工具;做得好是很重要的 absurdly difficult ,但这个将拒绝许多完全有效的地址,包括任何 + 在用户名中,任何在 .museum 或 .travel 或者任何IDNA域。最好对电子邮件地址开明一点。

Community Mohan Dere 9 年前

不。

去吧。不是。使用。正则表达式。为了。这个。永远不会。

RegEx to Detect SQL Injection

Java - escape string to prevent SQL injection

John Conde 16 年前

您仍然希望在将数据插入数据库之前对其进行转义。尽管验证用户输入是一件明智的事情,但针对SQL注入的最佳保护是预处理语句(自动转义数据)或使用数据库的本机转义功能转义数据。

Fletcher Moore 16 年前

有一个php函数mysql\u real\u escape\u string(),我相信为了安全起见,在提交到mysql数据库之前应该使用这个函数(而且,它更容易阅读。)

Arkh 16 年前

但是看了你的邮件,我只能回答“不”。

最好的方法是使用 filter 函数以相对安全地获取用户输入,并使您的php保持最新,以防在这些函数中发现损坏的内容。当您有原始输入时,您必须根据您对这些数据所做的操作来添加一些内容:删除电子邮件和http头的\n和\r,删除要显示给用户的html标记,使用参数化查询将其用于数据库。