我知道您需要准备好的语句来避免SQL注入,而且我已经看到对于SELECT、INSERT、UPDATE注入查询的利用存在不同的问题。
但我无法为USE语句提供一个利用漏洞的示例。假设我有一个可注入的语句,如下所示:
USE `data_from_attacker`;考虑到我正在寻找的不是选择DB (即:选择information_schema或mysql似乎无害,因为下一个查询不会工作,因为表不存在,选择不存在的DB也是无害的),如果攻击者可以使用什么数据来替代information_schema,可以使用什么数据。
另外,请考虑mysql只会解释第一个查询,因此攻击者无法注入:
mysql`; SELECT * FROM `users你能为MySQL找到这样的漏洞吗?USE语法看起来很“差”这样的注射..。
发布于 2019-08-06 21:23:09
Quote Xenos您能为MySQL找到这样的漏洞吗?对于这样的注入,使用语法似乎“很差”。
让我们跟踪USE如何在MySQL中工作,以及源代码中的MySQL需要访问哪些文件。
---
**Query #1**
SET PROFILING = 1;
There are no results to be displayed.
---
**Query #2**
USE test;
There are no results to be displayed.
---
**Query #3**
SHOW PROFILES;
| Query_ID | Duration | Query |
| -------- | ---------- | -------- |
| 1 | 0.00006425 | USE test |
---
**Query #4**
SHOW PROFILE ALL FOR QUERY 1;
| Status | Duration | CPU_user | CPU_system | Context_voluntary | Context_involuntary | Block_ops_in | Block_ops_out | Messages_sent | Messages_received | Page_faults_major | Page_faults_minor | Swaps | Source_function | Source_file | Source_line |
| -------------- | -------- | -------- | ---------- | ----------------- | ------------------- | ------------ | ------------- | ------------- | ----------------- | ----------------- | ----------------- | ----- | --------------------- | ------------ | ----------- |
| starting | 0.000038 | 0.000019 | 0.000012 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | | |
| query end | 0.000003 | 0.000002 | 0.000001 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc | 4310 |
| closing tables | 0.000003 | 0.000001 | 0.000001 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc | 4356 |
| freeing items | 0.000009 | 0.000006 | 0.000003 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | mysql_parse | sql_parse.cc | 4968 |
| cleaning up | 0.000012 | 0.000007 | 0.000005 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | dispatch_command | sql_parse.cc | 1978 |
---请参阅演示
MySQL basic lexer与yacc一起工作,因此我们首先检查文件sql_yacc.yy。下面是定义的USE关键字。
/* change database */
use:
USE_SYM ident
{
LEX *lex=Lex;
lex->sql_command=SQLCOM_CHANGE_DB;
lex->select_lex->db= $2.str;
}
;当我们检查sql_parse.cc和函数mysql_execute_command()时,我们发现
case SQLCOM_CHANGE_DB: {
const LEX_CSTRING db_str = {select_lex->db, strlen(select_lex->db)};
if (!mysql_change_db(thd, db_str, false)) my_ok(thd);
break;
}来回答这个问题。不,我找不到可能的漏洞,因为在源代码中非常清楚,USE 语句中的D12部分需要一个"string“,并且不会进一步解析、或执行一个SQL语句。
对于字符串,我指的是database_name格式为USE database_name或带有backticks。
发布于 2019-08-01 01:53:53
如果数据库中的任何架构元素的名称与SQL引擎上的其他数据库具有相同的名称,则可能会交叉查询以产生不理想的结果。
假设预期的数据库名为“PROD_DB”,但是您的开发人员在同一个SQL服务器上有另一个数据库,名为‘TEST_DB’。他们使用测试数据库来测试应用程序,所以它有相同的模式,但是充斥着只用于测试而没有人关心的垃圾数据,比如UserName ==‘test 1’、PassWord ==‘abc’、AdminFlag == 1。通过随意地将USE语句从PROD_DB更改为TEST_DB并返回,他们可以使用‘test1’凭证进行身份验证,并将其状态设置为Admin,然后翻转并使用它们的管理状态在您的生产应用程序中执行他们想做的任何事情。
https://security.stackexchange.com/questions/214415
复制相似问题