在我的服务器上尝试SQL注入

它猜测的是将表单数据替换成的SQL语句的类型,并假设在某一阶段它的消毒效果很差。考虑一个与SQL Server对话的程序(例如cish代码):

fprintf(sql_connection, "SELECT foo,bar FROM users WHERE user='%s';");

但是,使用上述字符串,SQL Server可以看到:

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 比我更能说明这一点。

您可以在这里找到详细信息:

http://blogs.technet.com/b/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx

这些行是双重编码的 第一组编码字符,其中 将由IIS翻译,是 用%xx表示。例如,%20是 空间。第二盘不是故意的 翻译到 SQL Server和它们使用char(xxx) SQL中的函数。

' and char(124)+user+char(124)=0 and ''='

这很奇怪……但是,请确保转义字符串,这样就不会有SQL注入。

其他人已经报道了正在发生的事情,所以我要花点时间站起来,强烈建议如果你还没有(我怀疑不是来自下面的评论),你应该 使用参数化查询 . 它们实际上使您对SQL注入免疫,因为它们会导致参数和查询完全分开传输。还有潜在的性能优势,雅达,雅达等。

但说真的,去做吧。