如何确认SQL注入

发布于 2024-08-13 07:33:16 字数 38 浏览 4 评论 0原文

有什么方法可以确认特定的安全漏洞是通过 SQL 注入完成的吗?

Is there any way to confirm that a particular breach of security was done through SQL injection?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

层林尽染 2024-08-20 07:33:16

这里没有简单的方法,但是如果您启用了用于记录每个 SQL 语句的 SQL 服务器,那么我会这样做。

通常,当我在某处进行 SQL 注入时,我会在结束前一个字符串后使用其中一个作为始终为 true 的语句来传递Where 子句。

1=1 
0=0

两者都用作:

blahblahblah' or 1=1 --

您不会在日常代码中使用此子句。因此,如果你在你的历史中发现其中之一,那么它就是一个很好的候选者。测试 sql 历史记录以查找:

(space)(number)(optional spaces)(equal)(optional spaces)(same number)(space)

请记住,这是启发式,并且并不总是有效,但可能是在发生后给出提示的唯一方法。另外,如果您对 SQL 注入有疑问,您应该检查代码中的字符串连接和参数的使用。

There is no easy way here, but if you have the enabled the SQL server you use to log every single sql statement, here is what I would do.

Normally, when I SQL inject somewhere, i use one of these as my always true statement for passing throgh the Where clause, after ending the former string.

1=1 
0=0

both being used as :

blahblahblah' or 1=1 --

You would not use this clauses in everyday code. So if you spot one of these in your history, well, it is a high candidate. Test the sql history to find :

(space)(number)(optional spaces)(equal)(optional spaces)(same number)(space)

Keep in mind that is heuristical, and will not always work, but could be the only way to give a hint after it had happened . Also, if you are in doubt about SQL injection, you should check the code for string concatenation and use of parameters.

也只是曾经 2024-08-20 07:33:16

在袭击已经发生之后?不。没有。
您必须检查所有 sql serevr 访问点是否存在潜在风险。
您可以使用一些工具。检查 此处位于 SQL 注入工具部分。

after the attack has already happened? no. there isn't.
you'll have to check all your sql serevr access point for potential risk.
tere are some tools you can use. Check here under SQL Injection tools section.

乖乖 2024-08-20 07:33:16

每当您将查询传递回数据库时,SQL 注入都可能发生。

SQL 注入

SQL injection can happen any time you pass a query back to the database.

SQL Injection

ゝ杯具 2024-08-20 07:33:16

从现在开始,使用 mod_security 记录 POST 请求并安装入侵检测系统来记录/停止可疑活动。如果您只是寻找漏洞点,记录每个 SQL 请求是一项开销。

如今 IDS 有开源替代品。我对所有 PHP 应用程序使用 PHPIDS

Use mod_security to log POST requests and install an Intrusion Detection System to log/stop suspicious activity from now on. Logging every SQL request is an overhead if you are just looking for the breach points.

There are open source alternatives for IDS these days. I use PHPIDS for all my PHP applications.

分开我的手 2024-08-20 07:33:16

只有一种可靠的方法可能是分析 SQL 日志文件。这些应该由能够快速发现问题的 DBA 来完成,因为日志的大小会很大。


最好防止这些。

有一些工具可以实现这一点,但最好的工具是开发商。

坚持一个简单的规则 - 生成 SQL 查询时始终使用参数
只需进行代码审查,如果您发现字符串连接 - 这就是 SQL 注入的第一个且极有可能发生的地方。

Only one reliable way is probably analysing the SQL log files. Those should be done by a DBA who can spot things quickly as the size of logs would be huge.


It is better to prevent those.

There are some tools for that but the best one is the brain of the developer.

Stick with one simple rule - always use parameters when generating SQL query.
Just do the code review and if you find string cocatenations - that is first and highly possible place for SQL Injection.

秋心╮凉 2024-08-20 07:33:16

您可以记录所有 http 请求并检查请求的页面以进行 GET/POST sql 注入尝试。

You can log all http requests and check the requested pages for GET/POST sql injection tryouts.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文