chore: 尝试切换到 ali oss
This commit is contained in:
camera-2018
@@ -34,7 +34,7 @@ def check_pass(username, password):
|
||||
|
||||
从 `users` 表中查出 `username` 对应的 `password` 的哈希值，将其与用户传入的密码哈希值进行比对，若相等则意味着用户传入的密码与数据库中储存的密码相吻合，于是返回准许登录
|
||||
|
||||
|
||||
|
||||
|
||||
那么问题来了，在语句
|
||||
|
||||
@@ -144,7 +144,7 @@ mysql> select group_concat(id,username separator '_') from users;
|
||||
|
||||
现在我们传入 `Liki4'` 这个字符串
|
||||
|
||||
|
||||
|
||||
|
||||
很遗憾，报错了，这个查询因为 SQL 语句存在语法错误而无法完成。
|
||||
|
||||
@@ -154,7 +154,7 @@ mysql> select group_concat(id,username separator '_') from users;
|
||||
|
||||
那如果我们传入 `Liki4';#` 这个字符串，那么在拼接后的查询又是什么结果呢
|
||||
|
||||
|
||||
|
||||
|
||||
很显然，`#` 号将原本语句的 `';` 注释掉了
|
||||
|
||||
@@ -166,7 +166,7 @@ mysql> select group_concat(id,username separator '_') from users;
|
||||
|
||||
`raw_sql_danger' UNION SELECT password FROM users WHERE username = 'Liki5';#`
|
||||
|
||||
|
||||
|
||||
|
||||
<strong>真是惊人的壮举！我完全不认识这个叫 Liki5 的家伙，但我居然知道了他的密码对应的哈希值！</strong>
|
||||
|
||||
@@ -273,7 +273,7 @@ if __name__ == "__main__":
|
||||
|
||||
接下来我们进行一次常规查询
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到我们成功从数据库中查出了 `username` 和 `password`，并显示在返回中
|
||||
|
||||
@@ -293,7 +293,7 @@ def query(username):
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到，实际执行的语句为
|
||||
|
||||
@@ -307,7 +307,7 @@ SELECT * FROM users WHERE username = '123' UNION SELECT 1, 2;#'
|
||||
|
||||
构造语句 `123' UNION SELECT DATABASE(), @@version;#`
|
||||
|
||||
|
||||
|
||||
|
||||
我们就能看到返回中包含了当前数据库名与当前数据库版本
|
||||
|
||||
@@ -317,13 +317,13 @@ SELECT * FROM users WHERE username = '123' UNION SELECT 1, 2;#'
|
||||
|
||||
> `information_schema` 库是一个 MySQL 内置数据库，储存了数据库中的一些基本信息，比如数据库名，表名，列名等一系列关键数据，SQL 注入中可以查询该库来获取数据库中的敏感信息。
|
||||
|
||||
|
||||
|
||||
|
||||
我们可以发现，当前数据库中还存在一张叫 `secret` 的表，让我们偷看一下里面存的是什么
|
||||
|
||||
构造语句 `123' UNION SELECT 1, secret_string FROM secret;#`
|
||||
|
||||
|
||||
|
||||
|
||||
好像得到了什么不得了的秘密 :-)
|
||||
|
||||
@@ -363,7 +363,7 @@ if __name__ == "__main__":
|
||||
|
||||
这样一来我们就只能知道自己是否登录成功，并不能看到查询返回的结果了
|
||||
|
||||
|
||||
|
||||
|
||||
那也就是说，我们无法直观地查看数据库中的数据了，即便查出了不该查的也看不到了 :-(
|
||||
|
||||
@@ -396,7 +396,7 @@ else:
|
||||
|
||||
> rlike 是 MySQL 中的一个关键字，是 regex 和 like 的结合体
|
||||
|
||||
|
||||
|
||||
|
||||
这里实际执行的语句就变成了
|
||||
|
||||
@@ -404,13 +404,13 @@ else:
|
||||
SELECT password FROM users WHERE username = 'Liki4' AND if(@@version rlike '^5',1,0);
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
```sql
|
||||
SELECT password FROM users WHERE username = 'Liki4' AND if(@@version rlike '^8',1,0);
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
也就是说，当 if 语句中的条件为真时，这个查询才会将 password 查询出来
|
||||
|
||||
@@ -480,7 +480,7 @@ if __name__ == "__main__":
|
||||
exp()
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
####
|
||||
|
||||
@@ -523,7 +523,7 @@ if __name__ == "__main__":
|
||||
|
||||
如果想要让布尔盲注不可用，我们可以做一个假设，假设我们并不知道账户的密码，也就无法通过登陆验证，这个时候就失去了布尔盲注最大的依赖，也就无法得知 if 表达式的真或假了。
|
||||
|
||||
|
||||
|
||||
|
||||
但，真的没办法了吗？
|
||||
|
||||
@@ -600,7 +600,7 @@ if __name__ == "__main__":
|
||||
exp()
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
### 基于报错的 SQL 注入 (TODO)
|
||||
|
||||
@@ -640,7 +640,7 @@ if __name__ == "__main__":
|
||||
main()
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
这样一来如果 SQL 语句执行报错的话，错误信息就会被打印出来
|
||||
|
||||
@@ -671,9 +671,9 @@ MySQL 8.0 doc: [https://dev.mysql.com/doc/refman/8.0/en/](https://dev.mysql.com/
|
||||
|
||||
`Liki4';INSERT INTO users VALUES ('Liki3','01848f8e70090495a136698a41c5b37406968c648ab12133e0f256b2364b5bb5');#`
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
INSERT 语句也被成功执行了，向数据库中插入了 Liki3 的数据
|
||||
|
||||
@@ -776,7 +776,7 @@ INSERT 语句也被成功执行了，向数据库中插入了 Liki3 的数据
|
||||
在 GB2312、GBK、GB18030、BIG5、Shift_JIS 等编码下来吃掉 ASCII 字符的方法，可以用来绕过 `addslashes()`
|
||||
`id=0%df%27%20union%20select%201,2,database();`
|
||||
|
||||
|
||||
|
||||
|
||||
### information_schema 被过滤
|
||||
|
||||
@@ -795,7 +795,7 @@ select table_name from mysql.innodb_index_stats where database_name=<em>database
|
||||
select table_name from mysql.innodb_table_stats where database_name=<em>database</em>();
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
##### MySQL 5.7 的新特性
|
||||
|
||||
@@ -812,7 +812,7 @@ select table_name from sys.schema_table_statistics_with_buffer where table_schem
|
||||
select table_name from sys.x$schema_table_statistics_with_buffer where table_schema=<em>database</em>();
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
### 无列名注入
|
||||
|
||||
@@ -820,7 +820,7 @@ select table_name from sys.x$schema_table_statistics_with_buffer where table_sch
|
||||
|
||||
`select a,b from (select 1 as a, 2 as b union select * from users)x;`
|
||||
|
||||
|
||||
|
||||
|
||||
## 超脱 MySQL 之外 (TODO)
|
||||
|
||||
|
||||
@@ -45,7 +45,7 @@ ESP 定律的原理在于利用程序中堆栈平衡来快速找到 OEP.
|
||||
|
||||
还是上一篇的示例, 入口一句 `pushad`, 我们按下 F8 执行 `pushad` 保存寄存器状态, 我们可以在右边的寄存器窗口里发现 `ESP` 寄存器的值变为了红色, 也即值发生了改变.
|
||||
|
||||
|
||||
|
||||
|
||||
我们鼠标右击 `ESP` 寄存器的值, 也就是图中的 `0019FF64`, 选择 `HW break[ESP]` 后, 按下 `F9` 运行程序, 程序会在触发断点时断下. 如图来到了 `0040D3B0` 的位置. 这里就是上一篇我们单步跟踪时到达的位置, 剩余的就不再赘述.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user