phpsql預編譯

① php 普通sql語句，處理成預處理語句

PHP MySQL 預處理語句
預處理語句對於防止 MySQL 注入是非常有用的。
預處理語句及綁定參數
預處理語句用於執行多個相同的 SQL 語句，並且執行效率更高。
預處理語句的工作原理如下：
預處理：創建 SQL 語句模板並發送到資料庫。預留的值使用參數 "?" 標記 。例如：
INSERT
INTO MyGuests (firstname, lastname, email) VALUES(?, ?, ?)

資料庫解析，編譯，對SQL語句模板執行查詢優化，並存儲結果不輸出。
執行：最後，將應用綁定的值傳遞給參數（"?" 標記），資料庫執行語句。應用可以多次執行語句，如果參數的值不一樣。
相比於直接執行SQL語句，預處理語句有兩個主要優點：
預處理語句大大減少了分析時間，只做了一次查詢（雖然語句多次執行）。
綁定參數減少了伺服器帶寬，你只需要發送查詢的參數，而不是整個語句。
預處理語句針對SQL注入是非常有用的，因為參數值發送後使用不同的協議，保證了數據的合法性。
MySQLi 預處理語句
以下實例在 MySQLi 中使用了預處理語句，並綁定了相應的參數:
實例 (MySQLi 使用預處理語句)
<?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDB";

// 創建連接
$conn = new mysqli($servername, $username, $password, $dbname);

// 檢測連接
if ($conn->connect_error) {
die("連接失敗: " . $conn->connect_error);
}

// 預處理及綁定
$stmt = $conn->prepare("INSERT INTO MyGuests (firstname, lastname, email) VALUES(?, ?, ?)");
$stmt->bind_param("sss", $firstname, $lastname, $email);

// 設置參數並執行
$firstname = "John";
$lastname = "Doe";
$email = "[email protected]";
$stmt->execute();

$firstname = "Mary";
$lastname = "Moe";
$email = "[email protected]";
$stmt->execute();

$firstname = "Julie";
$lastname = "Dooley";
$email = "[email protected]";
$stmt->execute();

echo "新記錄插入成功";

$stmt->close();
$conn->close();
?>

解析以下實例的每行代碼:
"INSERT INTO MyGuests (firstname, lastname, email) VALUES(?, ?, ?)"
在 SQL 語句中，我們使用了問號 (?)，在此我們可以將問號替換為整型，字元串，雙精度浮點型和布爾值。
接下來，讓我們來看下 bind_param() 函數：
$stmt->bind_param("sss", $firstname, $lastname, $email);
該函數綁定了 SQL 的參數，且告訴資料庫參數的值。 "sss" 參數列處理其餘參數的數據類型。s 字元告訴資料庫該參數為字元串。
參數有以下四種類型:
i - integer（整型）
d - double（雙精度浮點型）
s - string（字元串）
b - BLOB（binary large object:二進制大對象）
每個參數都需要指定類型。
通過告訴資料庫參數的數據類型，可以降低 SQL 注入的風險。

注意： 如果你想插入其他數據（用戶輸入），對數據的驗證是非常重要的。

PDO 中的預處理語句
以下實例我們在 PDO 中使用了預處理語句並綁定參數:
實例 (PDO 使用預處理語句)
<?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDBPDO";

try {
$conn = new PDO("mysql:host=$servername;dbname=$dbname", $username, $password);
// 設置 PDO 錯誤模式為異常
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

// 預處理 SQL 並綁定參數
$stmt = $conn->prepare("INSERT INTO MyGuests (firstname, lastname, email)
VALUES (:firstname, :lastname, :email)");
$stmt->bindParam(':firstname', $firstname);
$stmt->bindParam(':lastname', $lastname);
$stmt->bindParam(':email', $email);

// 插入行
$firstname = "John";
$lastname = "Doe";
$email = "[email protected]";
$stmt->execute();

// 插入其他行
$firstname = "Mary";
$lastname = "Moe";
$email = "[email protected]";
$stmt->execute();

// 插入其他行
$firstname = "Julie";
$lastname = "Dooley";
$email = "[email protected]";
$stmt->execute();

echo "新記錄插入成功";
}
catch(PDOException $e)
{
echo $sql . "<br>" . $e->getMessage();
}
$conn = null;
?>

② php在5.1.*和5.2.*之間pdo資料庫操作中的不同

資料庫連接代碼都一樣.

?

$protol = 'mysql:host=localhost;dbname=test';

$username = 'monty';

$passwd = '0818';

$dbh = new PDO($protol, $username, $passwd);

以下是一些測試。注意裡面的SQL和for或者foreach語句!

測試1(用key值進行綁定)

?

$stmt = $dbh->prepare('select * from t1 where name=:name');

$params = array();

$params['name'] = 'rentao';

foreach($params
as $k=>$v){

$stmt->bindParam($k, $v);

}

$stmt->execute();

$item = array();

while($row
= $stmt->fetch(PDO::FETCH_ASSOC)){

var_mp($row);

}

$stmt = null;

$dbh = null;

總結

PHP在使用PDO做資料庫預編譯操作的時候，盡量避免使用limit, order by, group by
做預編譯處理。綁定變數我們盡量使用統一標准，要不然都使用「？」，要不然使用「：key」。

有用的命令，我在php5.1.*進行測試，測試完了，我通過scp把文件傳輸到php5.2.*伺服器上

?

scp -P9888 index.php [email protected]:/home/rentao

③ 如何實現php的安全最大化怎樣避免sql注入漏洞和xss跨站腳本攻擊漏洞

使用php安全模式

伺服器要做好管理，賬號許可權是否合理。

假定所有用戶的輸入都是「惡意」的，防止XSS攻擊，譬如：對用戶的輸入輸出做好必要的過濾

防止CSRF，表單設置隱藏域，post一個隨機字元串到後台，可以有效防止跨站請求偽造。

文件上傳，檢查是否做好效驗，要注意上傳文件存儲目錄許可權。

防禦SQL注入。

避免SQL注入漏洞

1.使用預編譯語句

2.使用安全的存儲過程

3.檢查輸入數據的數據類型

4.從資料庫自身的角度考慮，應該使用最小許可權原則，不可使用root或dbowner的身份連接資料庫。若多個應用使用同一個資料庫，也應該為資料庫分配不同的賬戶。web應用使用的資料庫賬戶，不應該有創建自定義函數，操作本地文件的許可權。

避免XSS跨站腳本攻擊

1.假定所有用戶輸入都是「邪惡」的

2.考慮周全的正則表達式

3.為cookie設置HttpOnly,防止cookie劫持

4.外部js不一定可靠

5.出去不必要的HTML注釋

6. 針對非法的HTML代碼包括單雙引號等，使用htmlspecialchars()函數。

④ 有關java,php

這就要求用一些跨平台相當好的軟體+工具+語言，所以選擇只能是這么幾個。最後我的決定是php+java，一個前台一個後台，理由如下：php和java在開源社區的活躍度嚴重超過了其他的語言，使用人數也都是相當之多；活躍的開發工程師們能夠給我幫助，且這倆都能很好的跨平台，不用花費大量的人力物力去維護我也做過一個物聯網的網關網站，比較復雜，當時採用的是jsp+java，復雜程度可想而知，單單說開發過程，網站部分繁瑣，每次想查看結果運行網站的時候還需要重新打包部署一下，嚴重影響了哦的開發效率，每天的時間都是在等待（因為網站比較復雜，打包部署需要浪費一些時間）。相對來說呢，php就沒有了，php靈活，好學，上手快，容易修改，容易發布，關鍵是熱部署，這個真讓哦眼睛大亮。當然看待任何事物都需要兩種眼光，php也會有缺點，比如沒有太好的開發IDE，所以拼寫錯誤很正常，且php的sql注入危險較大點，執行效率不高，安全性不如java。還有一些理由，來自知乎的米米們給的建議：Java的優點則是穩定可靠、運行效率高（尤其是JIT的出現之後差距更大了）、不容易犯錯（強類型、預編譯、必須攔截異常等等），缺點是開發和發布的效率相對較低。盡管優秀的工程師能在一定程度上改變以上的問題，但通常而言，哪能到處都是高手多如狗的夢之隊？從MVC的層次結構上說，在一般網站項目的開發周期中，需求變更最頻繁、調整最多的是View，其次是Controller，最後是Model。這非常好理解，沒事干誰天天改數據結構？每次版本升級控制結構都要改的啦，或多或少而已。再次是兩者之間的通信，目前RPC技術已經足夠成熟，無論是WebService/Hessian/RESTfulAPI都能夠讓開發人員專注在功能開發上，而不需要過多的考慮異構平台的差異和通訊的細節。這也就意味著在大公司里同時應用兩種語言的方案並不會引入過多的復雜度和工作量。當然，文檔量的下限倒是因此被拔高了不少，但事實上大部分團隊對此其實都是喜聞樂見的：別每天說文檔重要但沒空了，你不寫其他同事怎麼配合？靠近用戶的前端，使用PHP能夠更快的完成前端頻繁而瑣碎的更新，自如的應對各種需求的變化。頁面的結構調整、用戶輸入內容的基本驗證、僅只和用戶交互有關的簡單邏輯等都很適合使用PHP來開發，甚至可以通過類似Smarty等模板技術將其頁面的變動遷移到前端團隊。而基本的業務邏輯和數據的更新採用Java開發，可以有效的提高復用度、提升性能和吞吐能力、規避安全問題等。而開發效率稍有降低換來的是可維護性的提升，發布速度慢就更不是問題了，因為通常對於基礎業務邏輯的調整往往都是整體修改，並層層測試確認才能發布的。所以，大型網站前端採用PHP後端採用Java，既好招人又好維護、系統穩定還性能高、連安全性都大大增加。代碼復用、文檔完備度居然也都改善了。讓你在以上這些好處觸手可及時，對架構師知識譜系在廣度上要求更高一些這事根本就不是個問題。單一方案其實一樣可以做良好的隔離，PHP同樣可以提供Service，而性能問題其實很多時候是演算法和架構的問題而不是語言差異的問題。如Velocity或JSTL等也是很優秀的隔離方案。但這些方案在高壓力下會暴露出很多問題而體現雙語言的優勢，這些在上面其實都提到，詳細說明一些很難得到改變的點：1.PHP由於其動態腳本語言的特性，包括類、函數、常量在內都需要在每次請求周期中重復執行後才能建立運行環境；為了保證解析速度而犧牲編譯質量；應用了FastCGI但僅僅只是復用進程處理請求減少fork成本而不是像其他語言，初始化完畢後通過FastCGI的介面獲得數據並以對應介面返回數據等幾個原因，基本上已經不可能在性能上追回當初更爛現在開著JIT牌跑車的Java了。2.在PHP里是如此的容易犯錯而難以發現，即使你用實質上出自官方的ZendStudio，也無法改變一個事實：要保證你的程序高質量無大錯，得要有充足的經驗、足夠的嚴謹、以及——負責任的QA。淘寶的黃裳就曾經拿IDE這事開過玩笑。而玩笑背後的那個原因「缺乏中間件」最近幾年有不少的改善，主要是不少中間件的支持變得更廣泛了從而讓PHP得益，但發展的根源其實還是在C和Java社區。性能和易犯錯則是語言特性造成的技術難點，也是用來換取靈活、快捷的必要代價，很難去指望有根本的改善。3.Java的世界裡也有JSTL、Velocity和Freemaker等，但和PHP靈活而強大的動態能力、豐富的函數和類庫、輕松的學習成本、多到令人發指的文檔相比，簡直就是渣，就是渣啊！JSTL改完了要重啟Context啊有木有？Velocity不關緩存也要重啟啊有木有？Velocity開緩存性能低下啊有木有？即使這些都不管，調整下某個數據校驗規則要改Action也要重啟有木有？實際工作中性能問題可以通過良好的架構解決，容易犯錯的問題可以通過框架和規范以及全面的測試來解決，中間件選擇少些但其實該有的都有了，Java的靈活性一樣有不少可供考慮的解決方案哪怕是挫得要死的摘掉節點重啟，完成後重新上節點的策略。所以，大家會看到單一語言的技術團隊也很多，這個問題的真正考慮還是在團隊自身的特點、積累等等。用了雙語言的，也知道自己為什麼要用這些，不用的也清楚自己的路該怎麼走。

⑤ php防sql注入的代碼

一、 注入式攻擊的類型
可能存在許多不同類型的攻擊動機，但是乍看上去，似乎存在更多的類型。這是非常真實的-如果惡意用戶發現了一個能夠執行多個查詢的辦法的話。本文後面，我們會對此作詳細討論。
如
果你的腳本正在執行一個SELECT指令，那麼，攻擊者可以強迫顯示一個表格中的每一行記錄-通過把一個例如"1=1"這樣的條件注入到WHERE子句中，如下所示(其中，注入部分以粗體顯示)：
SELECT * FROM wines WHERE variety = 』lagrein』 OR 1=1;』

正如我們在前面所討論的，這本身可能是很有用的信息，因為它揭示了該表格的一般結構(這是一條普通的記錄所不能實現的)，以及潛在地顯示包含機密信息的記錄。
一條更新指令潛在地具有更直接的威脅。通過把其它屬性放到SET子句中，一名攻擊者可以修改當前被更新的記錄中的任何欄位，例如下面的例子（其中，注入部分以粗體顯示）：
UPDATE wines SET type=』red』，』vintage』=』9999』 WHERE variety = 』lagrein』

通過把一個例如1=1這樣的恆真條件添加到一條更新指令的WHERE子句中，這種修改范圍可以擴展到每一條記錄，例如下面的例子（其中，注入部分以粗體顯示）：
UPDATE wines SET type=』red』，』vintage』=』9999 WHERE variety = 』lagrein』 OR 1=1;』

最危險的指令可能是DELETE-這是不難想像的。其注入技術與我們已經看到的相同-通過修改WHERE子句來擴展受影響的記錄的范圍，例如下面的例子（其中，注入部分以粗體顯示）：
DELETE FROM wines WHERE variety = 』lagrein』 OR 1=1;』

二、 多個查詢注入
多個查詢注入將會加劇一個攻擊者可能引起的潛在的損壞-通過允許多條破壞性指令包括在一個查詢中。在使用MySQL資料庫時， 攻擊者通過把一個出乎意料之外的終止符插入到查詢中即可很容易實現這一點-此時一個注入的引號(單引號或雙引號)標記期望變數的結尾；然後使用一個分號終 止該指令。現在，一個另外的攻擊指令可能被添加到現在終止的原始指令的結尾。最終的破壞性查詢可能看起來如下所示：
SELECT * FROM wines WHERE variety = 』lagrein』;
GRANT ALL ON *.* TO 』BadGuy@%』 IDENTIFIED BY 』gotcha』;』

這個注入將創建一個新的用戶BadGuy並賦予其網路特權（在所有的表格上具有所有的特權）；其中，還有一個"不祥"的口令被加入到這個簡單的SELECT語句中。如果你遵循我們在以前文章中的建議－嚴格限制該過程用戶的特權，那麼，這應該無法工作，因為web伺服器守護程序不再擁有你撤回的GRANT特權。但是從理論上講，這樣的一個攻擊可能給予BadGuy自由權力來實現他對你的資料庫的任何操作。
至 於這樣的一個多查詢是否會被MySQL伺服器處理，結論並不唯一。這其中的一些原因可能是由於不同版本的MySQL所致，但是大多數情況卻是由於多查詢存 在的方式所致。MySQL的監視程序完全允許這樣的一個查詢。常用的MySQL GUI-phpMyAdmin，在最終查詢之前會復制出以前所有的內容，並且僅僅這樣做。
但是，大多數的在一個注入上下文中的多查詢都是由PHP的mysql 擴展負責管理的。幸好，默認情況下，它是不允許在一個查詢中執行多個指令的；試圖執行兩個指令(例如上面所示的注入)將會簡單地導致失敗-不設置任何錯 誤，並且沒有生成任何輸出信息。在這種情況下，盡管PHP也只是"規規矩矩"地實現其預設行為，但是確實能夠保護你免於大多數簡單的注入式攻擊。
PHP5中的新的mysqli擴展(參考http://php.net/mysqli)，就象mysql一樣，內在地也不支持多個查詢，不過卻提供了一個mysqli_multi_query()函數以支持你實現多查詢-如果你確實想這樣做的話。
然而，對於SQLite-與PHP5綁定到一起的可嵌入的SQL資料庫引擎(參考http://sqlite.org/和http://php.net/sqlite) 情況更為可怕，由於其易於使用而吸引了大量用戶的關注。在有些情況下，SQLite預設地允許這樣的多指令查詢，因為該資料庫可以優化批查詢，特別是非常 有效的批INSERT語句處理。然而，如果查詢的結果為你的腳本所使用的話（例如在使用一個SELECT語句檢索記錄的情況下）， sqlite_query()函數卻不會允許執行多個查詢。三、 INVISION Power BOARD SQL注入脆弱性
Invision Power Board是一個著名的論壇系統。2005年五月6號，在登錄代碼中發現了一處SQL注入脆弱性。其發現
者為GulfTech Security Research的James Bercegay。
這個登錄查詢如下所示：
$DB->query("SELECT * FROM ibf_members WHERE id=$mid AND password=』$pid』");

其中，成員ID變數$mid和口令ID變數$pid被使用下面兩行代碼從my_cookie()函數中檢索出：
$mid = intval($std->my_getcookie(』member_id』));
$pid = $std->my_getcookie(』pass_hash』);

在此，my_cookie()函數使用下列語句從cookie中檢索要求的變數：
return urldecode($_COOKIE[$ibforums->vars[』cookie_id』].$name]);

【注意】從該cookie返回的值根本沒有被處理。盡管$mid在使用於查詢之前被強制轉換成一個整數，但是$pid卻保持不變。因此，它很容易遭受我們前面所討論的注入類型的攻擊。
因此，通過以如下方式修改my_cookie()函數，這種脆弱性就會暴露出來：
if ( ! in_array( $name，array(』topicsread』， 』forum_read』，』collapseprefs』) ) )
{
return $this->
clean_value(urldecode($_COOKIE[$ibforums->vars[』cookie_id』].$name]));
else
{
return urldecode($_COOKIE[$ibforums->vars[』cookie_id』].$name]);
}

經過這樣的改正之後，其中的關鍵變數在"通過"全局clean_value()函數後被返回，而其它變數卻未進行檢查。
現 在，既然我們大致了解了什麼是SQL注入，它的注入原理以及這種注入的脆弱程度，那麼接下來，讓我們探討如何有效地預防它。幸好，PHP為我們提供了豐富 的資源，因此我們有充分的信心預言，一個經仔細地徹底地使用我們所推薦的技術構建的應用程序將會從你的腳本中根本上消除任何可能性的SQL注入-通過在它 可能造成任何損壞之前"清理"你的用戶的數據來實現。
四、 界定你的查詢中的每一個值
我們推薦，你確保界定了你的查詢中的每一個值。字元串值首當其沖，以及那些你通常期望應該使用"單"(而不是"雙")引號的內容。一方面，如果你使用雙引 號來允許PHP在字元串內的變數替代，這樣可以使得輸入查詢更為容易些；另一方面，這(無可否認，只是極少量地)也會減少以後PHP代碼的分析工作。
下面，讓我們使用我們一開始使用的那個非注入式查詢來說明這個問題：
SELECT * FROM wines WHERE variety = 』lagrein』

或以PHP語句表達為：
$query = "SELECT * FROM wines WHERE variety = 』$variety』";

從技術上講，引號對於數字值來說是不需要使用的。但是，如果你並不介意用引號把例如葡萄酒這樣的一個域相應的一個值括起來並且如果你的用戶把一個空值輸入到你的表單中的話，那麼，你會看到一個類似下面的查詢：
SELECT * FROM wines WHERE vintage =

當然，這個查詢從語法上講是無效的；但是，下面的語法卻是有效的：
SELECT * FROM wines WHERE vintage = 』』

第二個查詢將(大概)不會返回任何果，但是至少它不會返回一個錯誤消息。
五、 檢查用戶提交的值的類型
從前面的討論中我們看到，迄今為止，SQL注入的主要來源往往出在一個意料之外的表單入口上。然而，當你經由一個表單向用戶提供機會提交某些值時，你應該有相當的優勢來確
定 你想取得什麼樣的輸入內容-這可以使得我們比較容易地檢查用戶入口的有效性。在以前的文章中，我們已經討論過這樣的校驗問題；所以，在此，我們僅簡單地總 結當時我們討論的要點。如果你正在期望一個數字，那麼你可以使用下面這些技術之一來確保你得到的真正是一個數字類型：
�6�1 使用is_int()函數(或is_integer()或is_long())。
�6�1 使用gettype()函數。
�6�1 使用intval()函數。
�6�1 使用settype()函數。
為 了檢查用戶輸入內容的長度，你可以使用strlen()函數。為了檢查一個期望的時間或日期是否有效，你可以使用strtotime()函數。它幾乎一定 能夠確保一位用戶的入口中沒有包含分號字元(除非標點符號可以被合法地包括在內)。你可以藉助於strpos()函數容易地實現這一點，如下所示：if( strpos( $variety， 』;』 ) ) exit ( "$variety is an invalid value for variety!" );

正如我們在前面所提到的，只要你仔細分析你的用戶輸入期望，那麼，你應該能夠很容易地檢查出其中存在的許多問題。
六、 從你的查詢中濾去每一個可疑字元
盡管在以前的文章中，我們已經討論過如何過濾掉危險字元的問題；但是在此，還是讓我們再次簡單地強調並歸納一下這個問題：
�6�1 不要使用magic_quotes_gpc指令或它的"幕後搭擋"-addslashes()函數，此函數在應用程序開發中是被限制使用的，並且此函數還要求使用額外的步驟-使用stripslashes()函數。
�6�1 相比之下，mysql_real_escape_string()函數更為常用，但是也有它自己的缺點。

⑥ php中防止SQL注入的最好方法是什麼

使用預備義語句和參數化查詢。對於帶有任何參數的sql語句都會被發送到資料庫伺服器，並被解析！對於攻擊者想要惡意注入sql是不可能的！ 實現這一目標基本上有兩種選擇： 1.使用PDO(PHP Data Objects )：$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name'); $stmt->execute(array(':name' => $name)); foreach ($stmt as $row) { // do something with $row }2.使用mysqli:$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?'); $stmt->bind_param('s', $name); $stmt->execute(); $result = $stmt->get_result(); while ($row = $result->fetch_assoc()) { // do something with $row }PDO(PHP數據對象) 注意當使用PDO訪問MySQL資料庫真正的預備義語句並不是默認使用的！為了解決這個問題，你必須禁用模擬准備好的語句。使用PDO創建連接的例子如下： $dbConnection = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'pass'); $dbConnection->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); $dbConnection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);在上面例子中錯誤模式ERRMODE不是嚴格必須的，但是建議添加它。當運行出錯產生致命錯誤時，這種方法腳本不會停止。並給開發人員捕捉任何錯誤的機會（當拋出PDOException異常時）。 setAttribute()那一行是強制性的，它告訴PDO禁用模擬預備義語句，使用真正的預備義語句。這可以確保語句和值在發送給MySQL資料庫伺服器前不被PHP解析(攻擊者沒有機會注入惡意的SQL). 當然你可以在構造函數選項中設置字元集參數，特別注意'老'的PHP版本（5.3.6）會在DSN中忽略掉字元集參數。 這里最重要的是，該參數值是和預編譯的語句結合的，而不是和一個SQL字元串.SQL注入的工作原理是通過欺騙手段創建的SQL腳本包括惡意字元串發送到資料庫.因此，通過發送實際的分開的sql參數,你會降低風險.使用准備好的語句時，你發送的任何參數，將只被視為字元串（雖然資料庫引擎可能會做一些參數的優化，當然最終可能會為數字）.在上面的例子中，如果變數$name包含'sarah';DELETE * FROM employees,結果只會是一個搜索的字元串"'sarah';DELETE * FROM employees",你不會得到一個空表。 使用准備好的語句的另一個好處是，如果你在同一會話中多次執行相同的語句，這將只被解析和編譯一次，給你一些的速度增長。

⑦ SQL注入的防範 使用預編譯語句

預編譯語句PreparedStatement是 java.sql中的一個介面，繼承自Statement 介面。通過Statement對象執行SQL語句時，需要將SQL語句發送給DBMS，由 DBMS先進行編譯後再執行。而預編譯語句和Statement不同，在創建PreparedStatement對象時就指定了SQL語句，該語句立即發送給DBMS進行編譯，當該編譯語句需要被執行時，DBMS直接運行編譯後的SQL語句，而不需要像其他SQL語句那樣先將其編譯。引發SQL注入的根本原因是惡意用戶將SQL指令偽裝成參數傳遞到後端資料庫執行。作為一種更為安全的動態字元串的構建方法，預編譯語句使用參數佔位符來替代需要動態傳入的參數，這樣攻擊者無法改變SQL語句的結構，SQL語句的語義不會發生改變，即便用戶傳入類似於前面' or '1'='1這樣的字元串，資料庫也會將其作為普通的字元串來處理。

⑧ PHP的SQL漏洞修復！【中危漏洞】SQL_Injection_Vulnerability【編號：3303280】

攻擊方法就在：

request:{"body":"ClassID=1+and%281%3D1%29","header":"POST /m/dianhua.asp HTTP 1.1
Content-Length: 24

/m/dianhua.asp這里，即你要修復的位置。

⑨ 如何防範SQL注入漏洞及檢測

以下是OMG我為大家收集整理的文章，希望對大家有所幫助。

SQL注入(SQLInjection)漏洞攻擊是目前網上最流行最熱門的黑客腳本攻擊方法之一，那什麼是SQL注入漏洞攻擊呢?它是指黑客利用一些Web應用程序(如：網站、論壇、留言本、文章發布系統等)中某些存在不安全代碼或SQL語句不縝密的頁面，精心構造SQL語句，把非法的SQL語句指令轉譯到系統實際SQL語句中並執行它，以獲取用戶名、口令等敏感信息，從而達到控制主機伺服器的攻擊方法。

1. SQL注入漏洞攻擊原理

1. 1 SQL注入漏洞攻擊實現原理

SQL(Structured Query Language)是一種用來和資料庫交互的語言文本。SQL注入的攻擊原理就是攻擊者通過Web應用程序利用SQL語句或字元串將非法的數據插入到伺服器端資料庫中，獲取資料庫的管理用戶許可權，然後將資料庫管理用戶許可權提升至操作系統管理用戶許可權，控制伺服器操作系統，獲取重要信息及機密文件。

SQL注入漏洞攻擊主要是通過藉助於HDSI、NBSI和Domain等SQL注入漏洞掃描工具掃描出Web頁面中存在的SQL注入漏洞，從而定位SQL注入點，通過執行非法的SQL語句或字元串達到入侵者想要的操作。下面以一段身份驗證的.NET代碼為例，說明一下SQL 注入攻擊的實現方法。

SqlConnectionnwConn = new SqlConnection((string)ConfigurationSettings.AppSettings["DBconnStrings"]); string queryStr = "SELECT userid,userpwd, username,type FROM users where userid='" + Txtusername.Text +"'";

DataSet userSet = new DataSet();

SqlDataAdapter userAdapter = newSqlDataAdapter(queryStr, nwConn);

userAdapter.Fill(userSet, "Users");

Session["UserID"] =Txtusername.Text.ToString();

Session["type"] =type.Text.ToString();

Response.Redirect("/Myweb/admin/login.aspx");

從上面的代碼中可以看出,程序在與資料庫建立連接得到用戶數據之後,直接將username的值通過session傳給login.aspx，沒有進行任何的過濾和處理措施, 直接用來構造SQL 語句, 其危險系數是非常高的, 攻擊者只要根據SQL 語句的編寫規則就可以繞過身份驗證，從而達到入侵的目的。

1. 2 SQL注入漏洞攻擊分析

SQL注入可以說是一種漏洞，也可以說是一種攻擊。當程序中的變數處理不當，沒有對用戶提交的數據類型進行校驗，編寫不安全的代碼，構造非法的SQL語句或字元串，都可能產生這個漏洞。

例如Web系統有一個login頁面，這個login頁面控制著用戶是否有權訪問，要求用戶輸入一個用戶名和口令，連接資料庫的語句為：

“select * from users where username = 'username' andpassword = 'password'”

攻擊者輸入用戶名為aa or 1=1口令為1234 or 1=1之類的內容。我們可以看出實際上攻擊者並不知道真正的用戶名、口令，該內容提交給伺服器之後，伺服器執行攻擊者構造出的SQL命令，但由於攻擊者輸入的內容非常特殊，所以最後得到的SQL命令變成：

“select * from users where username = 'aa' or 1=1 andpassword = '1234' or 1=1”

伺服器執行查詢或存儲過程，將用戶輸入的身份信息和資料庫users表中真實的身份信息進行核對，由於SQL命令實際上已被修改，存在永遠成立的1=1條件，因此已經不能真正驗證用戶身份，所以系統會錯誤地授權攻擊者訪問。

SQL 注入是通過目標伺服器的80埠進行的，是正常的Web訪問，防火牆不會對這種攻擊發出警告或攔截。當Web伺服器以普通用戶的身份訪問資料庫時，利用SQL注入漏洞就可能進行創建、刪除、修改資料庫中所有數據的非法操作。而當資料庫以管理用戶許可權的身份進行登錄時，就可能控制整個資料庫伺服器。

SQL注入的方法很多，在以手動方式進行攻擊時需要構造各種各樣的SQL語句，所以一般攻擊者需要豐富的經驗和耐心，才能繞過檢測和處理，提交語句，從而獲得想要的有用信息。這個過程需要花費很多的時間，如果以這種手動方式進行SQL注入漏洞攻擊，許多存在SQL注入漏洞的ASP、JSP、PHP、JAVA等網站就會安全很多了，不是漏洞不存在了，而是手動入侵者需要編程基礎，但現在攻擊者可以利用一些現成的黑客工具來輔助SQL注入漏洞攻擊，加快入侵的速度，使SQL注入變得輕而易舉。

由於SQL注入漏洞攻擊利用的是通用的SQL語法，使得這種攻擊具有廣泛性。理論上說，對於所有基於SQL語言的資料庫管理系統都是有效的，包括MSSQLServer、Oracle、DB2、Sybase和MySQL等。當然，各種系統自身的SQL擴展功能會有所不同，因此最終的攻擊代碼可能不盡相同。

1. 3 SQL注入漏洞攻擊過程

(1)繞過身份驗證

如一個login界面，需要輸入用戶名和口令，然後Post到另一個頁面，進行身份驗證,因此攻擊者只需在用戶名和口令的輸入框中都輸入aa or’1’=’1’的內容，那麼攻擊者就可以通過欺騙的驗證方式而直接進入下一個頁面，並擁有和正常登錄用戶一樣的全部特權。原因是什麼呢? 我們比較一下正常用戶登錄和攻擊者登錄時的兩種SQL語句：

1)正常用戶(如用戶名為admin，口令為1234567) ：

SQL= " selectfrom users where username = ’admin’and password= ’1234567’ ";

2)攻擊者(用戶名和口令都為aa or’1’=’1’) ：

SQL= " select * from users where username='aa or’1’=’1’'and password = ' aa or’1’=’1’'";

可以看到由and連接的兩個條件都被一個永遠成立的1=1所代替，執行的結果為true，資料庫會認為條件恆成立，會返回一個true，讓攻擊者以合法身份登錄進入下一個頁面。

(2)執行非法操作

如一個查詢頁面select1.asp? id=1，編程人員原本設計意圖是顯示id為1的查詢信息，而攻擊者利用程序中沒有對id內容進行檢查的機制，插入自己的代碼。

從select1.asp中摘錄一段關鍵代碼：

SQL= " select *from photo where photoid= 'id'";

可以看到，id沒有進行任何的處理，直接構成SQL語句並執行，而攻擊者在知道該系統資料庫中表名及欄位名的情況下，利用SQL語句特性(分號是將兩句SQL 語句分開的符號)，直接向資料庫Tuser表中添加記錄：

select1.asp? id= 1;Insertinto Tuser (username,password,type) values ('hack','1234567','管理員')，然後攻擊者就可以直接用hack進行登錄了。通過這樣的方法，攻擊者還可以對系統做任何的事情，包括添加、刪除、修改系統資源的操作。

(3)執行系統命令

如果Web主機使用MSSQL資料庫管理系統，那麼攻擊者就可以用到xp_cmdshell這個擴展存儲過程，xp_cmdshell是一個非常有用的擴展存儲過程，用於執行系統命令，比如dir、net等，攻擊者可以根據程序的不同，提交不同的語句：

execmaster.dbo.xp_cmdshell " dir "; exec master.dbo.xp_cmdshell" net user hack 1234567 /add ";

execmaster.dbo.xp_cmdshell " net localgroup administrators hack /add ";

這樣就可以向Web主機系統中成功添加了一個管理員帳戶。

2. SQL注入漏洞攻擊的檢測方式及方法

2. 1檢測方式

SQL注入漏洞攻擊檢測分為入侵前的檢測和入侵後的檢測。入侵前的檢測，可以通過手工方式，也可以使用SQL注入漏洞掃描工具軟體。檢測的目的是為預防SQL注入漏洞攻擊，而對於SQL注入漏洞攻擊後的檢測，主要是針對審計日誌的查看，SQL注入漏洞攻擊成功後，會在Web Service和資料庫的審計日誌中留下“痕跡”。

2. 2檢測方法

(1)動態SQL檢查

動態的SQL語句是一個進行資料庫查詢的強大的工具，但把它和用戶輸入混合在一起就使SQL注入成為了可能。將動態的SQL語句替換成預編譯的SQL或者存儲過程對大多數應用程序是可行的。預編譯的SQL或者存儲過程可以將用戶的輸入作為參數而不是命令來執行，這樣就限制了入侵者的行動。當然，它不適用於存儲過程中利用用戶輸入來生成SQL命令的情況。在這種情況下，用戶輸入的SQL命令仍可能得到執行，資料庫仍然存在SQL注入漏洞攻擊的危險。

(2)有效性校驗

如果一個輸入框只可能包括數字，那麼要通過驗證確保用戶輸入的都是數字。如果可以接受字母，檢查是不是存在不可接受的字元，那就需要設置字元串檢查功能。確保應用程序要檢查以下字元：分號、等號、破折號、括弧以及SQL關鍵字。

(3)數據表檢查

使用SQL注入漏洞攻擊工具軟體進行SQL注入漏洞攻擊後，都會在資料庫中生成一些臨時表。通過查看資料庫中最近新建的表的結構和內容，可以判斷是否曾經發生過SQL注入漏洞攻擊。

(4)審計日誌檢查

在Web伺服器中如果啟用了審計日誌功能，則Web Service審計日誌會記錄訪問者的IP地址、訪問時間、訪問文件等信息，SQL注入漏洞攻擊往往會大量訪問某一個頁面文件(存在SQL注入點的動態網頁)，審計日誌文件會急劇增加，通過查看審計日誌文件的大小以及審計日誌文件中的內容，可以判斷是否發生過SQL注入漏洞攻擊事件;另外還可以通過查看資料庫審計日誌，查詢某個時間段是否有非法的插入、修改、刪除操作。

(5)其他

SQL注入漏洞攻擊成功後，入侵者往往會添加特權用戶(如：administrator、root、sa等)、開放非法的遠程服務以及安裝木馬後門程序等，可以通過查看用戶帳戶列表、遠程服務開啟情況、系統最近日期產生的一些文件等信息來判斷是否發生過入侵。

3. SQL注入漏洞防範措施

SQL注入漏洞攻擊的防範方法有很多種，現階段總結起來有以下方法：

(1)數據有效性校驗。如果一個輸入框只可能包括數字，那麼要通過校驗確保用戶輸入的都是數字。如果可以接受字母，那就要檢查是不是存在不可接受的字元，最好的方法是增加字元復雜度自動驗證功能。確保應用程序要檢查以下字元：分號、等號、破折號、括弧以及SQL關鍵字。另外限製表單數據輸入和查詢字元串輸入的長度也是一個好方法。如果用戶的登錄名最多隻有10個字元，那麼不要認可表單中輸入10個以上的字元，這將大大增加攻擊者在SQL命令中插入有害代碼的難度。

(2)封裝數據信息。對客戶端提交的數據進行封裝，不要將數據直接存入cookie中，方法就是在編程的代碼中，插入session、if、try、else，這樣可以有效地防止攻擊者獲取cookie中的重要信息。

(3)去除代碼中的敏感信息。將在代碼中存在的用戶名、口令信息等敏感欄位刪除，替換成輸入框。

SQL=" select from users where username = ’admin’and password= ’1234567’ "

如：這樣顯然會暴露管理員的用戶名、口令信息。可以將其修改成：

SQL= " select * from users where username='" +Txtuser.Text + "' and userpwd='" + Textpwd.Text + "'"

這樣就安全了很多，入侵者也是不會輕易的就獲取到用戶名、口令信息。

(4)替換或刪除單引號。使用雙引號替換掉所有用戶輸入的單引號，這個簡單的預防措施將在很大程度上預防SQL注入漏洞攻擊，單引號時常會無法約束插入數據的Value，可能給予輸入者不必要的許可權。用雙引號替換掉單引號可以使大部分SQL注入漏洞攻擊失敗。 如：

“select* from users where username='" + admin + "' and userpwd='" + 1234567+ "'”

顯然會得到與

“select * from users where username='admin' and password= '1234567'”

相同的結果。

(5)指定錯誤返回頁面。攻擊者有時從客戶端嘗試提交有害代碼和攻擊字元串，根據Web Service給出的錯誤提示信息來收集程序及伺服器的信息，從而獲取想得到的資料。應在Web Service中指定一個不包含任何信息的錯誤提示頁面。

(6)限制SQL字元串連接的配置文件。使用SQL變數，因為變數不是可以執行的腳本，即在Web頁面中將連接資料庫的SQL字元串替換成指定的Value，然後將Web.config文件進行加密，拒絕訪問。

(7)設置Web目錄的訪問許可權。將虛擬站點的文件目錄禁止遊客用戶(如：Guest用戶等)訪問，將User用戶許可權修改成只讀許可權，切勿將管理許可權的用戶添加到訪問列表。

(8)最小服務原則。Web伺服器應以最小許可權進行配置，只提供Web服務，這樣可以有效地阻止系統的危險命令，如ftp、cmd、vbscript等。

(9)鑒別信息加密存儲。將保存在資料庫users表中的用戶名、口令信息以密文形式保存，也可以對users表進行加密處理，這樣可以大大增加對鑒別信息訪問的安全級別。

(10)用戶許可權分離。應盡可能的禁止或刪除資料庫中sa許可權用戶的訪問，對不同的資料庫劃分不同的用戶許可權，這樣不同的用戶只能對授權給自己的資料庫執行查詢、插入、更新、刪除操作，就可以防止不同用戶對非授權的資料庫進行訪問。

4. 結束語

SQL注入漏洞攻擊在網上非常普遍，許多ASP、PHP論壇和文章管理系統、下載系統以及新聞系統都存在這個漏洞。造成SQL注入漏洞攻擊的主要原因是開發人員在系統開發的過程中編程不規范，沒有形成良好的編程習慣，問題的解決只有依賴於規范編程。此外，也可以使用現有的SQL注入漏洞掃描器對整個網站中的關鍵代碼進行掃描，查找網站頁面中存在的SQL注入點。對於有問題的頁面，可以及時刪除或更新。本文通過對SQL注入漏洞攻擊的方法、原理以及攻擊實施過程進行了闡述和總結，並給出了一些常見的SQL注入漏洞攻擊防範的方法。

⑩ php使用預編譯語句，怎樣查看綁定後執行的語句

你使用的是PDO嗎？如果是只能查看mysql操作日誌了，因為PDO預處理，傳遞過去的是參數，不是sql語句。你可以直接列印變更的參數進行跟蹤。