我对SQL注入和URL解码有一点了解,但是在这个问题上比我更专业的人可以看看下面的字符串并告诉我它究竟要做什么?
几周前,北京的一些孩子尝试了一些像下面那样的注射。
%27%20于是%20char(124)%2Buser%2Bchar(124)= 0%20于是%20%27%27 = 27%
答案 0 :(得分:4)
它正在猜测表单数据被替换成的SQL语句的类型,并假设它在路上的某个步骤将被很差地清理。考虑一个与SQL服务器通信的程序(仅作为Cish代码):
fprintf(sql_connection, "SELECT foo,bar FROM users WHERE user='%s';");
但是,使用上面的字符串,SQL服务器会看到:
SELECT foo,bar FROM users WHERE user='' and char(124)+user+char(124)=0 and ''='';
糟糕!那不是你想要的。接下来会发生什么取决于数据库后端以及您是否已启用详细错误报告。
对于懒惰的Web开发人员来说,无条件地为所有客户端启用详细错误报告并且不关闭它是很常见的。 (道德:只为非常紧密的可信网络启用详细的错误报告,如果有的话。)这样的错误报告通常包含一些有关数据库结构的有用信息,攻击者可以使用这些信息来确定下一步该去哪里。
现在考虑用户名'; DESCRIBE TABLE users; SELECT 1 FROM users WHERE 'a'='
。它继续......这里有一些不同的策略,具体取决于数据的确切方式。存在SQL注入工具包,可以自动执行此过程并尝试通过不安全的Web界面自动转储数据库的全部内容。 Rafal Los's blog post包含更多技术洞察力。
您也不仅限于盗窃数据;如果你可以插入任意SQL,那么obligatory xkcd reference比我能更好地说明它。
答案 1 :(得分:2)
您可以在此处找到详细信息:
这些行是双重编码的 - 第一组编码字符,其中 将由IIS翻译,是 用%XX表示。例如,%20是a 空间。第二组并不意味着 被翻译,直到他们到达 SQL Server和他们使用char(xxx) SQL中的函数。
答案 2 :(得分:2)
' and char(124)+user+char(124)=0 and ''='
这很奇怪..但是,请确保你转义字符串,这样就不会有sql注入
答案 3 :(得分:2)
其他人已经介绍了正在发生的事情,所以我会花一点时间来抓住我的高马并强烈建议如果你还没有(我怀疑不是下面的评论)你使用参数化查询。它们确实使您免受SQL注入的影响,因为它们会导致参数和查询完全分开传输。还有潜在的性能优势,yadda yadda等。
但严肃地说,做吧。