MySQL`WHERE`正在为匹配的0提供未过期的结果
我有MySQL`WHERE`正在为匹配的0提供未过期的结果,mysql,sql,select,where,Mysql,Sql,Select,Where,我有用户信息表格说明如下 Field Type null Type Extra usr_id int(11) NO PRI auto_increment f_name varchar(50) NO l_name varchar(50) YES user_name Varchar(45) NO
用户信息表格说明如下
Field Type null Type Extra
usr_id int(11) NO PRI auto_increment
f_name varchar(50) NO
l_name varchar(50) YES
user_name Varchar(45) NO
password varchar(128) NO
email varchar(50) NO
type enum('a','s','c') NO
表内数据
0 admin admin admin d033e22ae348aeb5660fc2140aec35850c4da997 admin@oww.com a
1 staff Staffer staff d033e22ae348aeb5660fc2140aec35850c4da997 staff@oww.com s
2 staff2 stafer staff2 d033e22ae348aeb5660fc2140aec35850c4da997 staff2@oww.com s
10 Shanoop Pattanath shan123456 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 shan@shan.com s
SQL查询
SELECT
*
FROM
(`user_info`)
WHERE
`user_name` = 0 -- wrong input
AND `password` = 0 -- wrong input
ORDER BY `usr_id`;
此查询的结果
0 admin admin admin d033e22ae348aeb5660fc2140aec35850c4da997 admin@oww.com a
1 staff Staffer staff d033e22ae348aeb5660fc2140aec35850c4da997 staff@oww.com s
2 staff2 stafer staff2 d033e22ae348aeb5660fc2140aec35850c4da997 staff2@oww.com s
这个查询如何与所有数据匹配?这个查询不应该给出任何结果,是吗?我在这里做错了什么?详细的答案很受欢迎MySQL版本:5.5.35-0ubuntu0.13.10.2(Ubuntu)
所有用户名、密码和电子邮件都是虚构的
更新
我知道0
必须在引号内。我这样做解决了这个问题。但是MySQL为什么会提供这种有线输出呢 检查这个
问题是user\u name
是varchar
,而0
是INT
不能比较INT
和字符串
通过练习,你应该把它放在qoutes中,比如:
`user_name` = '0' -- wrong input
AND `password` = '0' -- wrong input
但是如果您希望确保比较的数据始终是字符串。
您可以尝试以下方法:
WHERE `user_name` = CAST(0 AS CHAR);
如果你愿意
SELECT *
FROM supportContacts
WHERE type = 1;
它不会归还任何东西
为什么??这是因为它正在将列转换为整数。任何没有有效整数的字段都将等于0。您应该确保只将字符串字段与字符串值进行比较。执行的比较似乎是int
与int
之间的比较
MySQL正在将user\u name
和password
中的文本转换为int
,以便进行比较。MySQL文档表明,在这种操作中,varchar
将被转换为int
如果您查看此项,您将看到在用户名
和密码
字段上使用CONVERT
使其int
将输出0,从而使您的比较为真
如果要对两个varchar
值进行比较,请确保使用单引号将标准括起来:
user_name = '0'
AND password = '0'
好问题,顺便说一句 喜欢你的问题。。。。非常好而且奇怪的查询输出在0周围添加引号('0'
)修复了这个问题,你应该这样做。@user1153551这几乎在我的网站上造成了巨大的安全问题。我找到SQL注入的新方法了吗?@FDL我知道,但为什么会有这样的结果?因为你在比较一个整数和一个字符串值。当SQL将字符串转换为整数进行比较时,很可能转换为0。是的,谢谢你的回答,这个问题也让我困惑。现在ok@majimboo当我们尝试匹配错误的数据类型时,它必须给出SQL错误。相反,这会给出结果。有趣的是,它并没有给出最后一排,你们注意到了吗?@Shanoop是的,这很奇怪。即使在小提琴上,它也可以复制。但这可能是因为给定的int是0
。我会进一步调查的。这是MySQL burg??我在PostgreSQL上尝试了它的返回类型cast error。@user1153551:MySQL更喜欢返回“一些可能是你想要的结果”,而不是抛出一个错误,告诉你你在比较苹果和桔子。哇,我不知道这一点,非常感谢你的知识<代码>选择“5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8”=0代码>给出0,这就是跳过最后一行的原因。我们有没有办法避免这种类型的铸造?我认为这可能会导致sql注入。当我们编写用户代码点火器输入类时。