sql注入預防的幾種手段

2020-11-06 暗網視界

搜索公眾號:暗網黑客

可領全套網絡安全滲透教程、配套攻防靶場

參考來源:https://www.cnblogs.com/toutou/p/4428152.html

SQL Injection

關於sql注入的危害在這裡就不多做介紹了,相信大家也知道其中的厲害關係。這裡有一些sql注入的事件大家感興趣可以看一下

防範sql注入的方法無非有以下幾種:

1.使用類型安全的SQL參數
2.使用參數化輸入存儲過程
3.使用參數集合與動態SQL
4.輸入濾波
5.過濾LIKE條款的特殊字符

...如果有遺漏的也歡迎大大們指教。

Sample:

var Shipcity;ShipCity = Request.form ("ShipCity");var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

上面是一個簡單的sql注入示例

用戶將被提示輸入一個市縣名稱。如果用戶輸入 Redmond,則查詢將由與下面內容相似的腳本組成:


SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

但是,假定用戶輸入以下內容:


SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

此時,腳本將組成以下查詢:


SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

分號 (;) 表示一個查詢的結束和另一個查詢的開始。雙連字符 (--) 指示當前行餘下的部分是一個注釋,應該忽略。如果修改後的代碼語法正確,則伺服器將執行該代碼。

SQL Server 處理該語句時,SQL Server 將首先選擇 OrdersTable 中的所有記錄(其中 ShipCity 為 Redmond)。然後,SQL Server 將刪除 OrdersTable。

只要注入的 SQL 代碼語法正確,便無法採用編程方式來檢測篡改。因此,必須驗證所有用戶輸入,並仔細檢查在您所用的伺服器中執行構造 SQL 命令的代碼。本主題中的以下各部分說明了編寫代碼的最佳做法。

下面就介紹一下常用的幾種防止sql注入的方法:

1. 驗證所有輸入

始終通過測試類型、長度、格式和範圍來驗證用戶輸入。實現對惡意輸入的預防時,請注意應用程式的體系結構和部署方案。請注意,設計為在安全環境中運行的程序可能會被複製到不安全的環境中。以下建議應被視為最佳做法:

(1)對應用程式接收的數據不做任何有關大小、類型或內容的假設。例如,您應該進行以下評估:

  • 如果一個用戶在需要郵政編碼的位置無意中或惡意地輸入了一個 10 MB 的 MPEG 文件,應用程式會做出什麼反應?
  • 如果在文本欄位中嵌入了一個 DROP TABLE 語句,應用程式會做出什麼反應?

(2)測試輸入的大小和數據類型,強制執行適當的限制。這有助於防止有意造成的緩衝區溢出。

(3)測試字符串變量的內容,只接受所需的值。拒絕包含二進位數據、轉義序列和注釋字符的輸入內容。這有助於防止腳本注入,防止某些緩衝區溢出攻擊。

(4)使用 XML 文檔時,根據數據的架構對輸入的所有數據進行驗證。

(5)絕不直接使用用戶輸入內容來生成 Transact-SQL 語句。

(6)使用存儲過程來驗證用戶輸入。

(7)在多層環境中,所有數據都應該在驗證之後才允許進入可信區域。未通過驗證過程的數據應被拒絕,並向前一層返回一個錯誤。

(8)實現多層驗證。對無目的的惡意用戶採取的預防措施對堅定的攻擊者可能無效。更好的做法是在用戶界面和所有跨信任邊界的後續點上驗證輸入。

例如,在客戶端應用程式中驗證數據可以防止簡單的腳本注入。但是,如果下一層認為其輸入已通過驗證,則任何可以繞過客戶端的惡意用戶就可以不受限制地訪問系統。

(9)絕不串聯未驗證的用戶輸入。字符串串聯是腳本注入的主要輸入點。

(10)在可能據以構造文件名的欄位中,不接受下列字符串:AUX、CLOCK$、COM1 到 COM8、CON、CONFIG$、LPT1 到 LPT8、NUL 以及 PRN。

如果可能,拒絕包含以下字符的輸入。

註:驗證輸入是最被常用和聯想到的,但是個人感覺這種方式不但代碼顯得肥胖,而且效率不是很好

2.使用類型安全的 SQL 參數

SQL Server 中的 Parameters 集合提供了類型檢查和長度驗證。如果使用 Parameters 集合,則輸入將被視為文字值而不是可執行代碼。

使用 Parameters 集合的另一個好處是可以強制執行類型和長度檢查。範圍以外的值將觸發異常。以下代碼段顯示了如何使用 Parameters 集合:

SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn); myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); parm.Value = Login.Text;

在此示例中,@au_id 參數被視為文字值而不是可執行代碼。

將對此值進行類型和長度檢查。如果 @au_id 值不符合指定的類型和長度約束,則將引發異常。

存儲過程如果使用未篩選的輸入,則可能容易受 SQL Injection 攻擊。

例如,以下代碼容易受到攻擊:

SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure '" + Login.Text + "'", conn);

如果使用存儲過程,則應使用參數作為存儲過程的輸入。

註:在鄙人現在的項目中,這種方法應用最為廣泛

3.在動態 SQL 中使用參數集合

如果不能使用存儲過程,您仍可使用參數,如以下代碼示例所示:

SqlDataAdapter myCommand = new SqlDataAdapter( "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn); SQLParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); Parm.Value = Login.Text;

註:和第二種雷同,這種方法是為了補充方法2存在,因為往往在很多時候業務簡單不需要用proc的時候,可以用這種方法

4.篩選輸入

篩選輸入可以刪除轉義符,這也可能有助於防止 SQL 注入。但由於可引起問題的字符數量很大,因此這並不是一種可靠的防護方法。以下示例可搜索字符串分隔符。

private string SafeSqlLiteral(string inputSQL) { return inputSQL.Replace("'", "''"); }

註:Filtering Input有種類似方法1

5.LIKE 子句

請注意,如果要使用 LIKE 子句,還必須對通配符字符進行轉義:

s = s.Replace("[", "[[]"); s = s.Replace("%", "[%]"); s = s.Replace("_", "[_]");

註:針對like子句,在使用時的效率這裡就不多說了,總之要慎用了。

相關焦點

  • 網站安全實踐:對預防SQL注入的幾點建議
    從上圖我們可以不難找出企業網站存在安全風險的幾個同共點:XSS跨站腳本攻擊、SQL注入漏洞、後臺弱口令、系統/服務運維配置不當以及系統/服務補丁不及時……下面我們就從這主要的幾點開始和大家一起探討:1、 XSS
  • Java最新SQL注入原因以及預防方案(易理解)
    前沿在現有的框架中sql防注入已經做得很好了,我們需要做的就是儘量不要使用sql拼接調用java sql注入原因以及預防方案(易理解)SQL注入1.1 原理SQL注入是通過客戶端的輸入把SQL命令注入到一個應用的資料庫中,從而執行惡意的SQL語句。1.2 演示1.2.1 案例1有一個登錄框,需要 輸入用戶名和密碼 ,然後我們的密碼輸入 'or '123' = '123 這樣的。
  • SQL注入漏洞靶場SQLi-Labs通關教程
    SQLi-LabsSQLi-Labs是一個專業的SQL注入練習平臺,該平臺包含了以下在測試場景中常見的注入類型;環境共有65個SQL注入漏洞。其中9個環境,可通過本教程,按步驟實驗,復現學習該sql注入漏洞;攻防實驗地址https://www.anquanlong.com/lab_introduce?
  • mybatis如何防止SQL注入?
    sql注入發生的時間,sql注入發生的階段在sql預編譯階段,當編譯完成的sql不會產生sql注入一、採用jdbc操作數據時候String sql = &34;+id; PreparedStatement prepareStatement
  • Myql SLEEP函數和SQL注入
    sqlmap是使用Python編寫的一款資料庫sql注入掃描工具,目前支持常見的mysql、oracel、postgresql、sql server,access,db2,sqlite等數據的安全漏洞(sql注入)。在sqlmap盲主掃描中,通常會Fuzzy各種sql語句,通常還會使用sleep命令。
  • 你知道幾種web注入攻擊?
    SQL注入(SQLi)和跨站(xss)是許多常用注入攻擊之一,下面列出常用攻擊類型第一種 代碼注入攻擊者通過網站類型注入相應的代碼,這個代碼以當前網站用戶的權限執行系統命令,在高級事件中,攻擊者可能溢出來提權導致真箇 web伺服器的淪喪.
  • 網絡安全之sql注入,簡單繞過注入,零基礎也能看懂,含源碼。
    前言:我們知道sql注入是容易就被過濾的了,現在網站存在sql注入的基本就沒有了,但是,有一些簡單的過濾我們是可以通過一些手段繞過的。那麼在注入的時候我們無法閉合,自然注入的sql語句就會失效。但是我們既然不能 替換成了空格。那麼在注入的時候我們無法閉合,自然注入的sql語句就會失效。但是我們既然不能 避開單引號,那我們能不能利用它呢? 所以這款裡就會想到,在多加一個單引號,從而和原有的單引號構成閉合。比如:?id=1&39;1&39;1 ?
  • 何為SQL注入?防護手段看這裡
    網際網路安全是一個老生常談的問題,而資料庫更是信息資源的命脈所在,縱然SQL Server使用已經足夠普遍,攻擊手段更是層出不窮,作為最尋常使用的SQL語句,也可能因為注入攻擊,而遭受惡意侵害,本文將簡述SQL注入的攻擊與防護手段。SQL注入是什麼?
  • SQL注入實驗學習筆記
    id=1』如果頁面返回錯誤,則存在 Sql 注入。 原因是無論字符型還是整型都會因為單引號個數不匹配而報錯。當然還有可能加了』,和沒加是一樣的,這也有可能是注入。因為當把錯誤提示關閉時,它是不會在頁面顯示的。
  • 白帽子:SQL注入之二次注入
    原理:用戶向資料庫裡存入惡意的數據,在數據被插入到資料庫之前,肯定會對資料庫進行轉義處理,但用戶輸入的數據的內容肯定是一點摸樣也不會變的存進資料庫裡,而一般都默認為資料庫裡的信息都是安全的,查詢的時候不會進行處理,所以當用戶的惡意數據被web程序調用的時候就有可能出發SQL注入。
  • 安全測試——SQL注入
    SQL注入是Web系統安全攻擊的常見手段,攻擊者通過構建特殊的輸入或非法的SQL命令插入表單或頁面請求的字符串中後提交,從而達到利用伺服器執行惡意SQL語句的目的。SQL注入攻擊成功後,可直接屏蔽伺服器驗證,獲取訪問權限,甚至獲取伺服器的最高權限,執行篡改記錄等惡意行為。
  • SQL注入、XSS以及CSRF分別是什麼?
    什麼是SQL注入、XSS和CSRF?本篇文章就來帶大家了解一下SQL注入、XSS和CSRF,有一定的參考價值,有需要的朋友可以參考一下,希望對你有所幫助。SQL注入SQL注入是屬於注入式攻擊,這種攻擊是因為在項目中沒有將代碼與數據(比如用戶敏感數據)隔離,在讀取數據的時候,錯誤的將數據作為代碼的一部分執行而導致的。典型的例子就是當對SQL語句進行字符串拼接的時候,直接使用未轉義的用戶輸入內容作為變量。這時,只要在sql語句的中間做修改,比如加上drop、delete等關鍵字,執行之後後果不堪設想。
  • SQL注入的那些事 如何實現SQL注入
    個人能力有限 如有錯誤 ,歡迎指出0x00 前言書接上篇文章,本文主要介紹SQL注入的位置,工具和常用語法。本文一共1153個字,預計閱讀時間:6分鐘。0x01 WHERE----在哪裡插入SQL注入語句SQL注入出現的位置有:HTTP包頭、搜索框、登錄框、目錄名、文件名中。
  • SQL注入
    SQL 注入頁也是一種常見的 Web 攻擊方式,主要是利用後端程序的漏洞,針對資料庫(主要是關係型資料庫)進行攻擊。攻擊者通常通過輸入精心構造的參數,繞過伺服器端的驗證,來執行惡意 SQL 語句,SQL注入會造成拖庫(原始數據表被攻擊者獲取),繞過權限驗證,或者串改、破壞、刪除數據。
  • 網站怎麼防止SQL注入
    一、SQL注入簡介SQL注入是比較常見的網絡攻擊方式之一,它不是利用作業系統的BUG來實現攻擊,而是針對程式設計師編程時的疏忽,通過SQL語句,實現無帳號登錄,甚至篡改資料庫。二、SQL注入攻擊的總體思路1.尋找到SQL注入的位置2.判斷伺服器類型和後臺資料庫類型3.針對不通的伺服器和資料庫特點進行SQL注入攻擊三、SQL注入攻擊實例比如在一個登錄界面,要求輸入用戶名和密碼:可以這樣輸入實現免帳號登錄:用戶名: 'or1
  • 特殊場景的sql注入思路
    上一篇介紹了sql注入的基礎知識以及手動注入方法,但是在實際的環境中往往不會像靶場中那樣簡單。今天我就來為大家介紹一種特殊場景的sql注入思路。用戶名與密碼分開驗證的情況第一個場景我們以We Chall平臺的Training: MySQL II 一題為例。
  • 「Burpsuite練兵場」SQL注入之帶外通信
    具體操作即為通過注入SQL語句,構造請求到伺服器中,以此將我們所需查詢的數據帶出來。那什麼時候我們需要使用帶外注入技術呢?當Web應用不產生任何錯誤響應,並且任何響應報文與SQL語句不存在邏輯關聯,基於時間延遲的盲注未產生明顯時延,此時就只能使用帶外通信技術了,同時此種方式也可以節省使用布爾盲注或時延盲注所要消耗的大量時間。
  • 利用sql注入對違法網站的滲透
    注入,最近又通過一個sql注入點,成功進入某個非法網站的後臺,拿到整個網站的後臺數據,廢話不多,進入主題。漏洞的版本,所以直接利用漏洞的想法行不動;3.通過Nmap發現開放了3389埠及結合sql注入的報錯,判斷使用的是MySQL資料庫以上就是收集的一些信息,比較簡單,主要時間是花在了就尋存在sql注入的地方。
  • 我來談談sql注入,根本解決
    經常看到一些文章介紹sql注入,但發現存在一些根本性問題:大家都是在防sql注入,而沒有考慮如何根本解決!sql注入的成因:sql條件拼接導致,如:String sql=&34;+name;當name是一個sql片段是,如:name=&39;admin&34;,這就產生了sql注入問題。
  • 如何有效解決噁心的 SQL 注入?
    簡介文章主要內容包括:Java 持久層技術/框架簡單介紹不同場景/框架下易導致 SQL 注入的寫法如何避免和修復 SQL 注入JDBC,如// concat sqlString sql = &39;&34;&34;;Statement stmt = connection.createStatement();ResultSet rs = stmt.executeQuery(sql);安全的寫法是使用 參數化查詢 ( parameterized queries