我的服务器上的 SQL 注入尝试
我对 SQL 注入和 URL 解码了解一点，但是在这方面比我更专家的人可以看一下下面的字符串并告诉我它到底想做什么吗？
几周前，北京的一个孩子尝试了多种注射，如下所示。
%27%20和%20char(124)%2Buser%2Bchar(124)=0%20和%20%27%27=%27
I know a little about SQL injections and URL decode, but can someone who's more of an expert than me on this matter take a look at the following string and tell me what exactly it's trying to do?
Some kid from Beijing a couple weeks ago tried a number of injections like the one below.
%27%20and%20char(124)%2Buser%2Bchar(124)=0%20and%20%27%27=%27
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
它会猜测表单数据将被替换成的 SQL 语句的类型，并假设在整个过程中的某个步骤中该语句的清理工作会很差。考虑一个与 SQL 服务器对话的程序（纯粹是 Cish 代码的例子）：
但是，使用上面的字符串，SQL 服务器会看到：
哎呀！那不是你想要的。接下来发生的情况取决于数据库后端以及您是否打开了详细错误报告。
对于懒惰的 Web 开发人员来说，无条件地为所有客户端启用详细错误报告而不将其关闭是很常见的。 （道德：如果有的话，只为非常严格的可信网络启用详细的错误报告。）这样的错误报告通常包含一些有关数据库结构的有用信息，攻击者可以使用这些信息来确定下一步该去哪里。
现在考虑用户名
';描述表用户； SELECT 1 FROM users WHERE 'a'='。如此下去......这里有一些不同的策略，具体取决于数据的产生方式。 SQL 注入工具包可以自动执行此过程，并尝试通过不安全的 Web 界面自动转储数据库的全部内容。 Rafal Los 的博文包含更多的技术见解。您的行为也不仅限于盗窃数据；如果您可以插入任意 SQL，那么 强制性 xkcd 参考 比我更好地说明了这一点。
It's making a guess about the sort of SQL statement that the form data is being substituted into, and assuming that it will be poorly sanitised at some step along the road. Consider a program talking to an SQL server (Cish code purely for example):
However, with the above string, the SQL server sees:
Whoops! That wasn't what you intended. What happens next depends on the database back-end and whether or not you've got verbose error reporting turned on.
It's quite common for lazy web developers to enable verbose error reporting unconditionally for all clients and to not turn it off. (Moral: only enable detailed error reporting for a very tight trusted network, if at all.) Such an error report typically contains some useful information about the structure of the database which the attacker can use to figure out where to go next.
Now consider the username
'; DESCRIBE TABLE users; SELECT 1 FROM users WHERE 'a'='. And so it goes on... There are a few different strategies here depending on exactly how the data comes out. SQL injection toolkits exist which can automate this process and attempt to automatically dump out the entire contents of a database via an unsecured web interface. Rafal Los's blog post contains a little more technical insight.You're not limited to the theft of data, either; if you can insert arbitrary SQL, well, the obligatory xkcd reference illustrates it better than I can.
您可以在这里找到详细信息：
http://blogs.technet.com/b/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-肉.aspx
You'll find detailed info here:
http://blogs.technet.com/b/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx
这很奇怪..但是，请确保转义字符串，这样就不会出现 sql 注入
that's strange..however, make sure you escape strings so there will be no sql injections
其他人已经介绍了正在发生的事情，所以我将花一点时间来表现出我的傲慢，并强烈建议如果您还没有（我怀疑不是来自下面的评论），那么您使用参数化查询。。它们实际上使您免受 SQL 注入的影响，因为它们使参数和查询完全分开传输。还有潜在的性能优势，等等。
但是说真的，去做吧。
Other people have covered what's going on, so I'm going to take a moment to get on my high-horse and strongly suggest that if you're not already (I suspect not from a comment below) that you use parameterized queries. They literally make you immune to SQL injection because they cause parameters and the query to be transmitted completely separately. There's also potential performance benefits, yadda yadda, etc.
But seriously, do it.