Update SQL注入笔记.md

Author: zh0u9527

SQL注入笔记/SQL注入笔记.md

@@ -144,7 +144,7 @@ SELECT * FROM nowcoder;
 
 假设有这样一个场景：A知道一个秘密，但是碍于各种原因，不能直接告诉B，此时B要求A将秘密告诉C，B再从C处获得秘密即可。这便是OOB(Out-Of-Band)，意为请求外带，在渗透测试中，若目标服务器上A的关键数据无法直接回显，安全人员可以让安全服务器主动对另一台受控制的服务器C发出请求，并将关键数据写在请求中（通常是URL中），安全人员通过查看C上的访问记录，便可从URL中获取关键数据了。
 
-![图片说明](.\SQL注入笔记.assets\3505471_1575266075435_1F22147D22EDE8447F757A4279548A20.png)
+![图片说明](./SQL注入笔记.assets/3505471_1575266075435_1F22147D22EDE8447F757A4279548A20.png)
 
 
 
@@ -279,7 +279,7 @@ mysql_query("SELECT title FROM passage WHERE uname = '$uname'");
 
 此时第4行中$uname的值为刚刚存入的' or updatexml(1,concat(0x7e,(user())),0) or '，那个具有闭合功能的单引号又回来了！
 
-![图片说明](.\SQL注入笔记.assets\3505471_1575263736543_AAE222732061C0009D4ED5B74AC398A3.png)
+![图片说明](./SQL注入笔记.assets/3505471_1575263736543_AAE222732061C0009D4ED5B74AC398A3.png)
 
 于是最后执行：
 
@@ -306,7 +306,7 @@ mysql_query("SELECT * FROM nowcoder WHERE id = $id");
 
 黑客在地址栏传入`%df%27`，其中`%27`是`'`的URL编码。当addslashes侦测到引号时，进行转义，添加一个反斜杠(`%5c`)，变为`%df%5c%27`。而Mysql在解析SQL语句时使用了多字节的GBK编码，当首个字节（高位）的ASCII码大于128时，就被认为是一个汉字，每个汉字占两字节，而`%df`正好符合这一要求。于是`%df%5c%27`被解析为`%df%5c`%27，即`運'`，成功吃掉转义引号的反斜杠，造成单引号逃逸。
 
-![图片说明](.\SQL注入笔记.assets\3505471_1575264948123_3450E4A84AAF66E6CB5143139BD82168.jpeg)
+![图片说明](./SQL注入笔记.assets/3505471_1575264948123_3450E4A84AAF66E6CB5143139BD82168.jpeg)
 
 那么，将Mysql连接层编码设为UTF-8就可以完全避免宽字节注入了吗？看下面这个例子：
 
@@ -318,7 +318,7 @@ mysql_query("SELECT * FROM nowcoder WHERE id = $id");
 
 这里Mysql连接层使用了UTF-8编码，为了避免乱码，使用iconv函数将用户提交的GBK字符经addslashes过滤后，先转为UTF-8，再拼入SQL语句，此时黑客只需在地址栏传入`%e5%5c%27`，即可再次使单引号逃逸，过成如下：
 
-![图片说明](.\SQL注入笔记.assets\3505471_1575265375490_41857CDE5786D99304E51B7EAA7E72D9.jpeg)
+![图片说明](./SQL注入笔记.assets/3505471_1575265375490_41857CDE5786D99304E51B7EAA7E72D9.jpeg)
 
 可以理解为只要在低位中含有`%c5`的编码中，都是可以进行注入的。