在學 SQL 注入的時候，自己寫了個 php 文件做測試，結果就出現單引號被轉義的事情，導致無法產生單引號報錯。
初探 sqli-labs-master 靶機的時候（還是在第一關）又出現這個問題。。。
是時候出手了!
事件還原
昨夜西風凋敝樹，獨上高樓，望盡天涯路
本來豪情壯志想在 sqli-labs-master 上大展手腳的時候，卻出師不利。
① 正常顯示 ?id=1
② 單引號注入
居然沒報錯！！！不正常，難道被過濾了？不慌，且看看。
③ 布爾注入 ?id=1 and 1=1
按理來說，and 前後爲真，輸出肯定正常。
④ ?id=1 and 1=2
1=2 爲 false，正常情況下應該會報錯，可是。。。
至此，判斷一個點是否爲 SQL 注入點的基本三步驟都不奏效，難道源碼的過濾措施已經如此到位？但也不應該啊，sqli-labs-master 本來就是一個 SQL 注入的練習場，本該有漏洞，而且還是第一關。。。
衣帶漸寬終不悔，爲伊消得人憔悴
① 不能盲猜，代碼審計走起。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Less-1 **Error Based- String**</title>
</head>
<body bgcolor="#000000">
<div style=" margin-top:70px;color:#FFF; font-size:23px; text-align:center">Welcome <font color="#FF0000"> Dhakkan </font><br>
<font size="3" color="#FFFF00">
<?php
//including the Mysql connect parameters.
include("../sql-connections/sql-connect.php");
error_reporting(0);
// take the variables
if(isset($_GET['id']))
{
$id=$_GET['id'];
//logging the connection parameters to a file for analysis.
$fp=fopen('result.txt','a');
fwrite($fp,'ID:'.$id."\n");
fclose($fp);
$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";
$result=mysql_query($sql);
$row = mysql_fetch_array($result);
if($row)
{
echo "<font size='5' color= '#99FF00'>";
echo 'Your Login name:'. $row['username'];
echo "<br>";
echo 'Your Password:' .$row['password'];
echo "</font>";
}
else
{
echo '<font color= "#FFFF00">';
print_r(mysql_error());
echo "</font>";
}
}
else { echo "Please input the ID as parameter with numeric value";}
?>
</font> </div></br></br></br><center>
<img src="../images/Less-1.jpg" /></center>
</body>
</html>
結果驚奇得發現，毫無破綻，完全沒有對特殊字符做轉義或者過濾，代碼都是原滋原味地拼接成 SQL 語句然後查詢數據庫的，完全符合尋常 SQL 漏洞的代碼佈局啊。
② 初露端倪
審計源碼的時候發現了一個有趣的東西，它的作用在於把輸入保存在一個 result.txt 文件裏面。
③ 發現癥結
在保存到輸入裏面，找到我之前輸入的單引號，居然被轉義了，難怪不報錯！！！但是爲什麼會被轉義呢？
④思考
冷靜地理一下思路。
第一：從客觀上來講，sqli-labs-master 這個靶場在第一關肯定會產生單引號報錯，教程上也是這解法。
第二：從技術層面上看，常見的判斷 SQL 注入點的三步驟都不奏效，可見此處和靶場的設定有出入。
第三：從源碼上看，存在很明顯的 SQL 注入漏洞。
綜上所述，問題的根源絕非源代碼出錯。那是瀏覽器的問題？靶場能在瀏覽器上正常運行，應該不是。那是環境配置的問題？有可能。
衆裏尋他千百度，慕然回首，那人卻在燈火闌珊處
自己實在不能解決，那就得藉助網絡的力量，在一番查詢下，問題的癥結終現端倪。
① 瞭解搭建的環境
此處是用了 phpstudy2013 搭建的環境，它集成了 MySQL + apache + php。
②配置
大概瞭解php和apache的配置，主要用到php.ini和httpd.conf ，而此處主要了解的是php.ini的配置。
一般情況下，爲了對 PHP 代碼的安全加固和防止 SQL 注入，在php.ini中safe_mode = On，就是返回php執行錯誤的 display_errors 這會返回很多有用的信息。
其次就是另外一個配置選項 magic_quotes_gpc，高版本的默認都是magic_quotes_gpc＝On，它會把提交的變量中所有的 ’ (單引號), " (雙引號), \ (反斜線) 和 空字符會自動轉爲含有反斜線的轉義字符，例如把’變成了’,把\變成了\。
③ 解決
可以關閉 magic_quotes_gpc ，然後重啓一下apache，或者在源碼中加入以下代碼。意思是判斷 magic_quotes_gpc，如果是開啓的話，調用 stripcslashes 函數，刪除在被轉義字符前面添加的反斜槓。
if(get_magic_quotes_gpc())
{
$id = stripcslashes($id);
}
④ 驗證 ?id=1’
尾聲
即便是單引號被轉義，也是可以有繞過的方法，但是此舉也是爲了還原 sqli-labs-master 靶場原本的運行環境，實乃無奈之舉。
共勉！！！
豬頭
2019.12.9
