如何以编程方式检查是否存在 SQL 注入漏洞？
我看到一些黑客工具可以自动找到带有 SQL 注入漏洞的网页。
它是如何运作的？
I see some hack tools can find web pages with SQL injection vulnerability AUTOMATICALLY.
How does it work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
通常，人们可以对 SQL 代码结构做出有根据的猜测，以允许注入。
例如，对于易受攻击的用户名/密码验证代码，在大多数情况下，它会类似于：
因此黑客将尝试注入类似以下内容：
因此结果将是 count(*) 将 > > 0，因此接受登录。
Usually, one can make an educated guess about the SQL code structure, to allow the injection.
For example, with a vulnerable username/password verification code, it will be in most cases something like:
so the hacker will attempt to inject something like:
so the result would be that count(*) will be > 0, hence login accepted.
一个简单的测试可以是在输入字段中放入单引号，然后查看是否返回 mysql 错误消息。
如果您收到类似“您的 SQL 语法有错误；检查与您的 MySQL 服务器版本相对应的手册，了解在第 1 行“''''”附近使用的正确语法
，或者您是否收到 php/mysql 错误（可能可以通过其格式或常见错误消息以编程方式识别） ）那么你也知道你有一个注入漏洞。
如果您只是得到一个通用的“没有这样的用户名”或返回一个有效的空结果集，那么您很可能没有注入漏洞。
An easy test can be to just put a single quote in the input field and see if you get a mysql error message back.
If you get something like 'You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''''' at line 1 '
or if you get a php/mysql error (which could probably be programmatically recognized by its formatting or the common error message) then you also know you have an injection vulnerability.
If you just get a generic 'no such username' or a valid empty result set back, then you most likely don't have an injection vulnerability.
许多这些工具都有已知会破坏网页的参数列表。他们在多个请求中触发这些参数，将参数插入：
他们的工具通常会抓取网站，以确保访问尽可能多的网站。
其中一个棘手的问题是确定您何时找到可利用的网页。在某些情况下，Web 服务器可能需要更长的时间来重新调整页面，或者页面的某些部分可能略有不同。要检查的事项：
话虽如此，如果您确实可以访问该网站的源代码，您可以使用静态分析技术寻找漏洞。
A lot of these tools have lists of parameters that are known to break web pages. They fire these parameters off in multiple requestsm inserting the parameters in:
Their tools will usually spider the site to ensure they are hitting as much of the site as possible.
One of the tricky bits is determining when you have found an exploitable web page. In some cases the web server might take longer to retuen the page, or certain parts of the page might be slightly different. Things to check for:
Having said all that, if you actually have access to the site's source code you can use static analysis techniques to look for vulnerabilites.