① 對sql語句進行轉義能有效防止sql注入嗎
首先提及sql注入這個題目，也許大家會笑笑，覺得這是一件比較低級的攻擊方式，但事實上，正是這種不屑，就可能會導致我們網站資料庫伺服器被攻擊，甚至伺服器許可權都被提走，這種例子，以不鮮見。
$query = 'SELECT * from user where name =" '.$name.' "';
這樣的sql是我們經常有寫的，然後$name = ' ";delete from user where name="mini -- ";';
這里' 後面跟一個空格，其實沒有，是wile看的更清楚些。
② sql注入原理
SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令，說白了就是在表單中添加一些惡意的SQL命令，去騙取伺服器的一些許可權，或者查詢一些重要的數據。防止SQL注入的最初級的辦法就是在數據提交時屏蔽或轉義大多數的SQL關鍵字和一些符號，比如引號什麼的．
③ 什麼是sql注入如何防止sql注入
SQL注入是一種非常常見的資料庫攻擊手段，同時也是網路世界中最普遍的漏洞之一，簡單理解就是惡意用戶通過在表單中填寫包含SQL關鍵字的數據來使資料庫執行非常規代碼的過程。
問題來源是，SQL資料庫的操作是通過SQL語句來執行的，而無論是執行代碼還是數據項都必須寫在SQL語句中，也就導致如果我們在數據項中加入了某些SQL語句關鍵字，比如SELECT、DROP等，這些關鍵字就很有可能在資料庫寫入或讀取數據時得到執行。
解決方案
方案一：
採用預編譯技術
使用預編譯的SQL語句，SQL語句的語義不會是不會發生改變的。預編譯語句在創建的時候就已經將指定的SQL語句發送給了DBMS，完成了解析，檢查，編譯等工作，所以攻擊者無法改變SQL語句的結構，只是把值賦給?，然後將?這個變數傳給SQL語句。當然還有一些通過預編譯繞過某些安全防護的操作，大家感興趣可以去搜索一下。
方案二：
嚴格控制數據類型
在java、c等強類型語言中一般是不存在數字型注入的，因為在接受到用戶輸入id時，代碼一般會做一個int id 的數據類型轉換，假如我們輸入的是字元串的話，那麼這種情況下，程序就會報錯。但是在PHP、ASP這些沒有強調處理數據類型的語言，一般我們看到的接收id的代碼都是如下等代碼。
方案三：
對特殊的字元進行轉義
數字型注入可以通過檢查數據類型防止，但是字元型不可以，那麼怎麼辦呢，最好的辦法就是對特殊的字元進行轉義了。比如在MySQL中我們可以對" '
"進行轉義，這樣就防止了一些惡意攻擊者來閉合語句。當然我們也可以通過一些安全函數來轉義特殊字元。如addslashes()等，但是這些函數並非一勞永逸，攻擊者還可以通過一些特殊的方式繞過。
④ mybatis 怎麼解決 sql注入
通過對參數進行轉義：
比如如下的sql prdtNo這個參數如果包含可能會引起sql注入的字元時，mybatis會對其進行轉義
<selectid="queryCustomerDetail"resultMap="customerInfoMap">
select
<includerefid="Base_LinkColimn_list"/>
fromFSP_CUSTOMER_INFOiinnerjoinFSP_CUST_RELATIONr
oni.id=r.cust_idwherei.CIF_NO=#{cifNo,jdbcType=VARCHAR}
andr.PRODUCT_NO=#{prdtNo,jdbcType=VARCHAR}
</select>
⑤ sql注入問題
\ 是轉義的意思，其實還是 ' 如果不轉義，就不符合mysql 的語法，就會報錯。
⑥ 什麼是sql注入，怎麼防止sql注入
原理
SQL注入攻擊指的是通過構建特殊的輸入作為參數傳入Web應用程序，而這些輸入大都是SQL語法里的一些組合，通過執行SQL語句進而執行攻擊者所要的操作，其主要原因是程序沒有細致地過濾用戶輸入的數據，致使非法數據侵入系統。
根據相關技術原理，SQL注入可以分為平台層注入和代碼層注入。前者由不安全的資料庫配置或資料庫平台的漏洞所致；後者主要是由於程序員對輸入未進行細致地過濾，從而執行了非法的數據查詢。基於此，SQL注入的產生原因通常表現在以下幾方面：①不當的類型處理；②不安全的資料庫配置；③不合理的查詢集處理；④不當的錯誤處理；⑤轉義字元處理不合適；⑥多個提交處理不當。
攻擊
當應用程序使用輸入內容來構造動態sql語句以訪問資料庫時，會發生sql注入攻擊。如果代碼使用存儲過程，而這些存儲過程作為包含未篩選的用戶輸入的字元串來傳遞，也會發生sql注入。sql注入可能導致攻擊者使用應用程序登陸在資料庫中執行命令。相關的SQL注入可以通過測試工具pangolin進行。如果應用程序使用特權過高的帳戶連接到資料庫，這種問題會變得很嚴重。在某些表單中，用戶輸入的內容直接用來構造動態sql命令，或者作為存儲過程的輸入參數，這些表單特別容易受到sql注入的攻擊。而許多網站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中本身的變數處理不當，使應用程序存在安全隱患。這樣，用戶就可以提交一段資料庫查詢的代碼，根據程序返回的結果，獲得一些敏感的信息或者控制整個伺服器，於是sql注入就發生了。
防護
歸納一下，主要有以下幾點：
1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和
雙"-"進行轉換等。
2.永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員許可權的資料庫連接，為每個應用使用單獨的許可權有限的資料庫連接。
4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
6.sql注入的檢測方法一般採取輔助軟體或網站平台來檢測，軟體一般採用sql注入檢測工具jsky，網站平台就有億思網站安全平台檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS可以有效的防禦SQL注入，XSS攻擊等。
⑦ SQL注入攻擊與防範
關於SQL注入攻擊與防範
隨著網路的普及，關系資料庫的廣泛應用，網路安全越來越重要。下面是我為大家搜索整理了關於SQL注入攻擊與防範，歡迎參考閱讀，希望對大家有所幫助。想了解更多相關信息請持續關注我們應屆畢業生培訓網!
一、 SQL注入攻擊
簡言之，SQL注入是應用程序開發人員未預期地把SQL代碼傳入到應用程序的過程。它由於應用程序的糟糕設計而成為可能，並且只有那些直接使用用戶提供的值構建SQL語句的應用程序才會受影響。
例如：用戶輸入客戶ID後，GridView顯示客戶的全部行記錄。在一個更加真實的案例中，用戶還要輸入密碼之類的驗證信息，或者根據前面的登錄頁面得到用戶ID，可能還會有一些用戶輸入關鍵信息的文本框，如訂單的日期范圍或產品名稱。問題在於命令是如何被執行的。在這個示例中，SQL語句通過字元串構造技術動態創建。文本框txtID的值被直接復制到字元串中。下面是代碼：
在這個示例中，攻擊者可以篡改SQL語句。通常，攻擊的第一個目標是得到錯誤信息。如果錯誤沒有被恰當處理，底層的信息就會暴露給攻擊者。這些信息可用於進一步攻擊。
例如，想像一下在文本一下在文本框中輸入下面的字元串會發生什麼?
ALFKI'OR '1'='1
再看看因此生成的完整SQL語句：
這條語句將返回所有的訂單記錄，即便那些訂單不是由ALFDI創建，因為對每一行而言而有信1=1總是true。這樣產生的後果是沒有顯示當前用戶特定信息，卻向攻擊者顯示了全部資料，如果屏幕上顯示的是敏感信息，如社會保險號，生日或信用卡資料，就會帶來嚴重的問題。事實上，這些簡單的SQL注入往往是困擾那些大型電子商務公司的麻煩。一般而言，攻擊點不在於文本框而在於查詢字元串(可被用於向資料庫傳送值，如列表頁向詳細信息頁面傳送唯一標識符)。
還可以進行更復雜的攻擊。例如，攻擊者可以使用兩個連接號(--)注釋掉SQL語句的剩餘部分。這樣的攻擊只限於SQL Server，不過對於其他類型的資料庫也有等效的辦法，如MySql使用(#)號，Oracle使用(;)號。另外攻擊者還可以執行含有任意SQL語句的批處理命令。對於SQL Server提供程序，攻擊者只需在新命令前加上分號(;)。攻擊者可以採用這樣的方式刪除其他表的內容，甚至調用SQL Server的系統存儲過程xp_cmdshell在命令執行任意的程序。
下面是攻擊者在文本框中輸入的，它的攻擊目標是刪除Customers表的全部行。
LUNCHUN』;DELETE*FROM Customers--
二、防範
如何預防SQL注入攻擊呢?需要記住幾點。首先，使用TextBox.MaxLength屬性防止用戶輸入過長的字元是一個好辦法。因為它們不夠長，也就減少了貼入大量腳本的可能性。其次，要使用ASP.NET驗證控制項鎖定錯誤的數據(如文本、空格、數值中的特殊字元)。另外，要限制錯誤信息給出的提示。捕獲到資料庫異常時，只顯示一些通用的信息(如「數據源錯誤」)而不是顯示Exception.Message屬性中的信息，它可能暴露了系統攻擊點。
更為重要的是，一定要小心去除特殊字元。比如，可以將單引號替換為兩個單引號，這樣它們就不會和SQL語句的分隔符混淆：
string ID=txtID.Text().Replace(「』」，」』』」);
當然，如果文本確實需要包含單引號，這樣做就引入了其他麻煩。另外，某些SQL注入攻擊還是可行的。替換單引號可以防止用戶提前結束一個字元串，然而，如果動態構建含有數值的SQL語句，SQL注入攻擊又有發揮的空間了。這個漏洞常被(這是很危險的)忽視。更好的解決辦法是使用參數化的命令或使用存儲過程執行轉義以防止SQL注入攻擊。
另一個好建議是限制用於訪問資料庫的賬號的許可權。這樣該賬號將沒有許可權訪問其他資料庫或執行擴展的存儲過程。不過這樣並不能解決SQL腳本注入的問題，因為用於連接資料庫的進程幾乎總是需要比任意單個用戶更大的許可權。通過限制許可權，可以預防刪除表的攻擊，但不能阻止攻擊者偷看別人的.信息
三、POST注入攻擊
精明的用戶可能會知道還有另外一個Web控制項攻擊的潛在途徑。雖然參數化的命令防止了SQL注入攻擊，但它們不能阻止攻擊者向回發到伺服器的數據添加惡意的值。如果不檢查這些值，就使得攻擊者可以提交本來不可能存在的控制項值。
例如，假設你有一個顯示當前用戶訂單的列表。狡詐的攻擊者可能保存該頁面的一個本地副本，修改HTML內容向列表添加更多的項目，然後選擇某個「假」的項目。如果攻擊成功，攻擊者就能夠看到其他用戶訂單，這顯然是一個問題。幸好，ASP.NET使用一個很少被提及的叫做「事件驗證」的特性來防止這種攻擊。事件驗證檢查回發到伺服器的數據並驗證其中值的合法性。例如，如果回發的數據表明用戶選擇了一個沒有意義的數據(因為它在控制項中並不存在)，ASP.NET就產生一個錯誤並停止處理。可以在Page指令中設置EnableEventValidation特性為false來禁用事件驗證。創建使用客戶端腳本動態改變內容的頁面時，需要執行這一步。不過，此時在使用這些值之前要注意檢查潛在的POST注入攻擊。
;⑧ sql注入與轉義的php函數代碼
sql注入:
正常情況下:
delete.php?id=3;
$sql
=
'delete
from
news
where
id
=
'.$_GET['id'];
惡意情況:
delete.php?id=3
or
1;
$sql
=
'delete
from
news
where
id
=
3
or
1';
-------如此執行後，所有的記錄將都被刪除
應該採取相關措施。。。比如用之前先判斷是否是數字等等。
要使自己相信，從客戶端傳來的信息永遠是不可靠的！！
轉義:
有時候從客戶端傳來的數據，可能惡意包含些特殊的字元，比如單引號、斜杠等，所以需要轉義，轉義成普通的字元，此時就要用到string
addslashes
(
string
$str
)，這個函數可以對某個變數進行轉義。但是，如果對數組里的元素進行轉義，就用foreach循環數組，如下：
復制代碼
代碼如下:
foreach($_POST
as
$k=>$v)
{
if(is_string($v))
{
$_POST[$k]
=
addslashes($v);
}
}
但是如果數組中還包含數組，那就要遞歸進行轉義了，此時用到
array_walk_recursive(array
&$input
,
callback
$funcname
[,
mixed
$userdata
])
將用戶自定義函數
funcname
應用到
array
數組中的每個單元。本函數會遞歸到更深層的數組中去。典型情況下
funcname
接受兩個參數。input
參數的值作為第一個，鍵名作為第二個。如果提供了可選參數
userdata，將被作為第三個參數傳遞給
callback
funcname。成功時返回
TRUE，
或者在失敗時返回
FALSE
也就是說：用自定義的函數，至少要能接收兩個參數，而addslashes（）只能接收一個參數所以自定義一個函數如下:
復制代碼
代碼如下:
function
a(&$v,$k){
$v=addslashes($v);
}
array_walk_recursive(&$arr,'a');
系統自動轉義:
PHP中,有一個魔術引號的概念,如何打開?答:在PHP.ini中,magic_quotes_gpc=On;重啟apache即可
魔術引號被打開後，系統會自動對$_GET,$_POST,$_COOKIE數據進行轉義，在不知情的情況下，再次進行手動轉義的話，就轉多了，要想合理的進行轉義，就要首先判斷，魔術符號是否已經打開了，用magic_quotes_gpc()進行判斷，不需要傳值，關閉返回0，關閉返回1
復制代碼
代碼如下:
if(!get_magic_quotes_gpc())
{
//
如果魔術引號沒開
function
_addslashes(&$v,$k)
{
$v
=
addslashes($v);
}
array_walk_recursive(&$_GET,'_addslashes');
array_walk_recursive(&$_POST,'_addslashes');
array_walk_recursive(&$_COOKIE,'_addslashes');
}
⑨ Node.js中用escape解決sql注入
這時正常情況下能查詢到一條數據，如果將param修改成
let param = 'ns"-- ';
sql語句就會變成
select * from tb_nature where nature = "ns"-- " and del_status=1
後面的del_status就會被參數中的 -- 注釋掉，失去作用，能查詢到多條數據。
如果對param使用escape包裝下，就能將參數中的特殊字元進行轉義，防止sql的注入。
let sql = 'select * from tb_nature where nature = ' + mysql.escape(param) + ' and del_status=1';
⑩ php中防止SQL注入，該如何解決
防sql注入的一個簡單方法就是使用框架，一般成熟框架中會集成各種安全措施。
當然也可以自己處理，如果用戶的輸入能直接插入到SQL語句中，那麼這個應用就易收到SQL注入的攻擊。我認為最重要的一點，就是要對數據類型進行檢查和轉義。
php.ini
------------
display_errors 選項，應該設為display_errors = off。這樣 php 腳本出錯之後，不會在 web 頁面輸出錯誤，以免讓攻擊者分析出有作的信息。
打開magic_quotes_gpc來防止SQL注入，magic_quotes_gpc= Off，這個默認是關閉的，如果它打開後將自動把用戶提交對sql的查詢進行轉換，比如把 ' 轉為 '等，對於防止sql注射有重大作用。如果magic_quotes_gpc=Off，則使用addslashes()函數。
mysql 函數
---------------
調用mysql_query 等mysql 函數時，前面應該加上 @，即 @mysql_query(...)，這樣 mysql 錯誤不會被輸出。同理以免讓攻擊者分析出有用的信息。另外，有些程序員在做開發時，當mysql_query出錯時，習慣輸出錯誤以及sql 語句。
mysql_real_escape_string -- 轉義 SQL 語句中使用的字元串中的特殊字元，並考慮到連接的當前字元集。
Sql語句
------------
對提交的 sql 語句，進行轉義和類型檢查。如果請求是數值型，那麼調用is_numeric() 判斷是否為數值。如果不是，則返回程序指定的默認值。簡單起見，對於文本串，我將用戶輸入的所有危險字元（包括HTML代碼），全部轉義。由於php 函數addslashes()存在漏洞，我用str_replace()直接替換。get_magic_quotes_gpc()函數是php 的函數，用來判斷magic_quotes_gpc 選項是否打開。
其它
---------
使用預處理語句和參數化查詢（PDO或mysqli）。預處理語句和參數分別發送到資料庫伺服器進行解析，參數將會被當作普通字元處理。這種方式使得攻擊者無法注入惡意的SQL。