SQL = VS LIKE VS LIKE BINARY，不区分大小写

我也遇到相当怪异的行为与SQL LIKE，=和LIKE BINARYSQL = VS LIKE VS LIKE BINARY，不区分大小写

注：密码的前3个字符其实是3Vf和查询的其余部分语法上也是正确的。

SUBSTRING(password,1, 3) = "3VF"  -> returns true 
SUBSTRING(password,1, 3) = "3Vf"  -> returns true 

SUBSTRING(password,1, 3) LIKE "3VF" -> returns true 
SUBSTRING(password,1, 3) LIKE "3Vf" -> returns true

但是如果我使用LIKE BINARY，我得到区分大小写行为

SUBSTRING(password,1, 3) LIKE BINARY "3VF" -> returns false 
SUBSTRING(password,1, 3) LIKE BINARY "3Vf" -> returns true

我不明白为什么comparisions不区分大小写。考虑到密码是VARCHAR(64)。在我看到的所有资源中，它都表示=和LIKE都区分大小写。

注：我运行了完整的查询是

SELECT * from users where username="natas16" AND SUBSTRING(password,1, 3) = XX

而且，这是不是一个真实的世界应用程序，但一个NATAS水平。这是一个'黑客'游乐场。他们与你应该利用的漏洞有不同的级别。所以这不是一个真实世界的例子。

http://www.overthewire.org/wargames/natas/

来源

2013-03-19 Ahmed Aeon Axan

只是让我们很清楚的敏感，你不应该来的密码存储在数据库中。使用'PASSWORD（'Function'）'来正确存储它。虽然你描述的行为很奇怪。 https://dev.mysql.com/doc/refman/5.0/en/password-hashing.html – Colton 2013-03-19 16:09:08

你是否将passwordword保存为纯文本？使用散列键和列分类作为latin_colate_cs。 – georgecj11 2013-03-19 16:09:50

natas是一种道德黑客操场。你得到一个挑战，你应该以某种方式打破。这样做的目的是为了强制它。 – 2013-03-19 16:10:04

是否LIKE和=动作中的情况下，敏感的方式将你正在做的所述比较的字段的排序规则来确定。如果你的字段有一个非区分大小写的排序规则（就像我猜你的那样），那么你会得到不区分大小写的比较结果。如果该字段具有二进制或区分大小写的排序规则，或者如果在比较时使用BINARY关键字强制进行二进制比较，则会得到区分大小写的比较结果。

来源

2013-03-19 16:10:01

谢谢，我想这是唯一的解释。由于我不能直接看到数据库模式，我会猜测这是发生了什么。此外，这是一个常见的陷阱？我的意思是我一直认为无论如何文本比较都区分大小写。 – 2013-03-19 16:13:30

@AhmedAeonAxan如果你不明白排序规则是如何工作的，我想这可能是一个陷阱，因为你的应用程序肯定会得到意想不到的结果。不知道它有多常见的问题。大多数实际上并没有以明文形式将密码存储在数据库中，而是将其散列在具有全部小写字母（如md5散列或类似形式）的介质中，以便区分大小写不成问题。 – 2013-03-19 16:17:37

是的，我很喜欢那个。我编辑了我的帖子以包含此内容。这是纳塔斯水平的一部分。它基本上是一个带有某种你应该利用的漏洞的沙箱。所以这远非真实世界的应用。正因为如此，我无法准确地看到他们的数据库模式。但你的回答完全描述了行为所以我想这一定是它。 – 2013-03-19 16:20:31

阅读生根粉分页选项，以及如何使它的情况下从MySQL tutorial

来源

2013-03-19 16:11:34 georgecj11

SQL = VS LIKE VS LIKE BINARY，不区分大小写

回答

相关问题