防止sql注入app_什麼是sql注入怎麼防止注入

1. sql注入如何防止

1、使用參數化篩選語句

為了防止SQL注入，用戶輸入不能直接嵌入到SQL語句中。相反，用戶輸入必須被過濾或參數化。參數語句使用參數，而不是將用戶輸入嵌入語句中。在大多數情況下，SQL語句是正確的。然後，用戶輸入僅限於一個參數。

一般來說，有兩種方法可以確保應用程序不易受到SQL注入攻擊。一種是使用代碼審查，另一種是強制使用參數化語句。強制使用參數化語句意味著在運行時將拒絕嵌入用戶輸入中的SQL語句。但是，目前對此功能的支持不多。

2、避免使用解釋程序，這是黑客用來執行非法命令的手段。

3、防止SQL注入，但也避免一些詳細的錯誤消息，因為黑客可以使用這些消息。標準的輸入驗證機制用於驗證所有輸入數據的長度、類型、語句和企業規則。

4、使用漏洞掃描工具。

但是，防範SQL注入攻擊是不夠的。攻擊者現在自動搜索和攻擊目標。它的技術甚至可以很容易地應用於其他Web體系結構中的漏洞。企業應該投資於專業的漏洞掃描工具，如著名的Accunetix網路漏洞掃描程序。完美的漏洞掃描器不同於網路掃描器，它專門在網站上查找SQL注入漏洞。最新的漏洞掃描程序可以找到最新發現的漏洞。

5、最後，做好代碼審計和安全測試。

2. sql注入產生的原因以及如何防止

sql注入：是利用sql語句本身的語法規則，繞過前台提供的功能達到某種特殊目的手段。
防治措施：對輸入內容進行過濾。如果有服務端，還需要對伺服器端進行驗證。

3. Android中是怎樣防止SQL注入的

COPY過來有什麼意思。。。。。。。 ----------------------------- 要防止SQL注入其實不難，你知道原理就可以了。所有的SQL注入都是從用戶的輸入開始的。如果你對所有用戶輸入進行了判定和過濾，就可以防止SQL注入了。用戶輸入有好幾種，我就說說常見的吧。文本框、地址欄里***.asp?中？號後面的id=1之類的、單選框等等。一般SQL注入都用地址欄里的。。。。如果要說怎麼注入我想我就和上面的這位「仁兄」一樣的了。你只要知道解決對嗎？對於所有從上一頁傳遞過來的參數，包括request.form 、request.qurrystring等等進行過濾和修改。如最常的***.asp?id=123 ，我們的ID只是用來對應從select 里的ID，而這ID一般對應的是一個數據項的唯一值，而且是數字型的。這樣，我們只需把ID的值進行判定，就可以了...

4. j2ee怎麼防止sql注入

開發web的過程中，需要防範sql注入，或是javascript代碼注入，以下通過過濾器(filter)實現的，只實現了tomcat和weblogic下，其它應用伺服器可以參照實現即可。
非常簡單只需三個步驟：
第一步，在你的工程加入如下所示的過濾器代碼，一共兩個類：

CharFilter.java

[java] view plain
package com.hyjx.filter;

import java.io.IOException;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import java.util.Map.Entry;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.log4j.Logger;

/**
* @author jfish
* @since 2006.1.12
*/
public class CharFilter implements Filter {

public FilterConfig config;
public void setFilterConfig(FilterConfig config) {
this.config = config;
}
public FilterConfig getFilterConfig() {
return config;
}

public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {

HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse res = (HttpServletResponse) response;

boolean filter = true;// 是否過濾；
String excludeURL;// 不過濾的url地址
excludeURL = config.getInitParameter("excludeURL");
if (excludeURL == null || "".equals(excludeURL)) {
filter = true;
} else {
String url = req.getRequestURI();// url地址
String[] excludeURLA = excludeURL.split(",");
for (int i = 0; i < excludeURLA.length; i++) {
if (url.indexOf(excludeURLA[i]) > 0) {// 如果含有不讓過濾的url地址則不過濾。
filter = false;
}
}
}
//得到應用伺服器類型
String appServer = config.getInitParameter("appServer");

if(filter)//需要過濾
{
if("tomcat".equals(appServer))//應用伺服器為tomcat時則：
{
if(checkTomcat(req,res))
{
String webapp = req.getContextPath();
res.sendRedirect(webapp + "/charError/charError.html");
}
else
{
chain.doFilter(request, response);
}
}
else//應用伺服器為weblogic時則：
{
Map m = req.getParameterMap();
if(req instanceof ParameterRequestWrapper) {
m = ((ParameterRequestWrapper)req).getSuperRequest().getParameterMap();
req = ((ParameterRequestWrapper)req).getSuperRequest();
}
//System.out.println(((String[])m.get("op"))[0] + "-----------" + req.getParameter("op"));
ParameterRequestWrapper wrapRequest=new ParameterRequestWrapper(req, m);
if(checkWeblogic(wrapRequest, res))
{
String webapp = req.getContextPath();
res.sendRedirect(webapp + "/charError/charError.html");
}
else
{
chain.doFilter(wrapRequest, response);
}
}

}
else//不需要過濾
{
chain.doFilter(request, response);
}
}

public boolean checkWeblogic(HttpServletRequest req, HttpServletResponse response) {

Map map = req.getParameterMap();

Set set = map.entrySet();
//request中的參數設置
boolean bl = false;
if (map != null) {
for (Iterator it = set.iterator(); it.hasNext();) {
Map.Entry entry = (Entry) it.next();
if (entry.getValue() instanceof String[]) {
String[] values = (String[]) entry.getValue();
for (int i = 0; i < values.length; i++) {
//替換成全形字元。
values[i] = getQjString(values[i]);
//是否包含有特殊字元
if (getCheckString(values[i])) {
return true;
}

}
}
}
}

//cookie過濾：除了JSESSIONID以外的cookie進行過濾
Cookie[] cookies = req.getCookies();
String cookieName = "";
String cookieValue="";
if(cookies!=null)
{
for (int i = 0; i < cookies.length; i++)
{
Cookie c = cookies[i];
cookieName = c.getName();
//System.out.println("=======cookie:"+cookieName);
if(cookieName!= null && !"JSESSIONID".equals(cookieName.toUpperCase()))
{
cookieValue = c.getValue();
if (getCheckString(cookieValue)) {
return true;
}
//進行特殊字元替換
cookieValue = getQjString(cookieValue);
c.setValue(cookieValue);
response.addCookie(c) ;

}

}
}

return bl;

}

public boolean checkTomcat(HttpServletRequest req, HttpServletResponse response) {

Map map = req.getParameterMap();
//運用反射機制，讓其可修改。
try
{
Method method=map.getClass().getMethod("setLocked",new Class[]{boolean.class});
method.invoke(map,new Object[]{new Boolean(false)});
}
catch(Exception e)
{
e.printStackTrace();
}

Set set = map.entrySet();

boolean bl = false;
if (map != null) {
for (Iterator it = set.iterator(); it.hasNext();) {
Map.Entry entry = (Entry) it.next();
if (entry.getValue() instanceof String[]) {
String[] values = (String[]) entry.getValue();
for (int i = 0; i < values.length; i++) {
//替換成全形字元。
values[i] = getQjString(values[i]);
//是否包含有特殊字元
if (getCheckString(values[i])) {
return true;
}

}
}
}
}

//cookie過濾：除了JSESSIONID以外的cookie進行過濾
Cookie[] cookies = req.getCookies();
String cookieName = "";
String cookieValue="";
if(cookies!=null)
{
for (int i = 0; i < cookies.length; i++)
{
Cookie c = cookies[i];
cookieName = c.getName();
//System.out.println("=======cookie:"+cookieName);
if(!"JSESSIONID".equals(cookieName))
{
cookieValue = c.getValue();
if (getCheckString(cookieValue)) {
return true;
}
//進行特殊字元替換
cookieValue = getQjString(cookieValue);
c.setValue(cookieValue);
response.addCookie(c) ;

}

}
}
return bl;
}
//特殊符號替換成全形.
/*
單引號'
雙引號"
小於號<
大於號>
分號;
等號=
注釋符--

5. 如何從根本上防止 SQL 注入

也許可以這樣回答你，如果能保證應用不使用「用戶輸入的字元串」來拼接成為「向SQL 伺服器發送的SQL執行字元串」的話，就可以從根本上防止SQL注入。

一、SQL語言的機理：
1、當前主流的幾大資料庫伺服器的數據存、取、匯總控制，都使用一種文本語句「SQL」語句。
2、當客戶端需要數據，或需要發送數據，或需要匯總數據時，都可以向資料庫發送這種標準的描述性文本，比如向資料庫發送「select * from bas1.dbo.tab1」就是告訴資料庫，我要取「資料庫bas1」中的「tab1」表中的所有欄位（用「*」通配來代表）的所有記錄（因為沒有加限制條件）。

二、產生SQL注入的基礎：
1、如果客戶端設計者沒有關注SQL注入方面的問題，就有可能在將用戶輸入進行拼接成SQL語句，並發送到伺服器端時，產生惡意的SQL可執行語句。
2、舉例說明：某個網頁上有個修改用戶密碼口令的功能，正常情況下下，用戶輸入原口令，與將要改成的口令，然後對用戶進行修改。用戶正常情況下輸入簡單的字串作為口令，比如「abcdef」，最終，合成向伺服器發送的語句可能為：
update UserTab set password = 'abcdef' where id=222

3、然而，有個人很淘氣，它輸入的字串為

abcdef' --
那麼，合成的發送給伺服器的語句就成了：
update UserTab set password = 'abcdef' --『 where id=222
這條句語一但發向伺服器，其結果是，所有的人的密碼都將變成 abcdef。
4、當然了，上面只是舉了一個例子，以便於你理解什麼是SQL注入。
（絕大多數應用的口令字串都是要進行加密的，所以，這個例子起僅在：
初級用戶寫的，明文存密碼，沒有注意SQL注入。這些條件合適時才起作用。）
5、同理，你可以想出很多的相關的東西，比如在修改用戶姓名的地方……

三、防止SQL注入的一些辦法：
1、客戶端接收到用戶輸入後，進行一次核查，不讓用戶輸入能產生SQL歧義的字元。比如禁止使用任何英文符號作為密碼、姓名等等。
2、盡可能減少用戶的直接字元的輸入，通配查詢，等。

6. 如何防範SQL注入式攻擊

SQL注入攻擊的危害很大，而且防火牆很難對攻擊行為進行攔截，主要的SQL注入攻擊防範方法，具體有以下幾個方面。
1、分級管理
對用戶進行分級管理，嚴格控制用戶的許可權，對於普通用戶，禁止給予資料庫建立、刪除、修改等相關許可權，只有系統管理員才具有增、刪、改、查的許可權。
2、參數傳值
程序員在書寫SQL語言時，禁止將變數直接寫入到SQL語句，必須通過設置相應的參數來傳遞相關的變數。從而抑制SQL注入。數據輸入不能直接嵌入到查詢語句中。同時要過濾輸入的內容，過濾掉不安全的輸入數據。或者採用參數傳值的方式傳遞輸入變數，這樣可以最大程度防範SQL注入攻擊。
3、基礎過濾與二次過濾
SQL注入攻擊前，入侵者通過修改參數提交and等特殊字元，判斷是否存在漏洞，然後通過select、update等各種字元編寫SQL注入語句。因此防範SQL注入要對用戶輸入進行檢查，確保數據輸入的安全性，在具體檢查輸入或提交的變數時，對於單引號、雙引號、冒號等字元進行轉換或者過濾，從而有效防止SQL注入。
當然危險字元有很多，在獲取用戶輸入提交參數時，首先要進行基礎過濾，然後根據程序的功能及用戶輸入的可能性進行二次過濾，以確保系統的安全性。
4、使用安全參數
SQL資料庫為了有效抑制SQL注入攻擊的影響。在進行SQLServer資料庫設計時設置了專門的SQL安全參數。在程序編寫時應盡量使用安全參數來杜絕注入式攻擊，從而確保系統的安全性。
5、漏洞掃描
為了更有效地防範SQL注入攻擊，作為系統管理除了設置有效的防範措施，更應該及時發現系統存在SQL攻擊安全漏洞。系統管理員可以采購一些SQL漏洞掃描工具，通過專業的掃描工具，可以及時的掃描到系統存在的相應漏洞。
6、多層驗證
現在的網站系統功能越來越龐大復雜。為確保系統的安全，訪問者的數據輸入必須經過嚴格的驗證才能進入系統，驗證沒通過的輸入直接被拒絕訪問資料庫，並且向上層系統發出錯誤提示信息。同時在客戶端訪問程序中驗證訪問者的相關輸入信息，從而更有效的防止簡單的SQL注入。但是如果多層驗證中的下層如果驗證數據通過，那麼繞過客戶端的攻擊者就能夠隨意訪問系統。因此在進行多層驗證時，要每個層次相互配合，只有在客戶端和系統端都進行有效的驗證防護，才能更好地防範SQL注入攻擊。
7、資料庫信息加密
傳統的加解密方法大致分為三種：對稱加密、非對稱加密、不可逆加密。

7. 什麼是sql注入，怎麼防止注入

sql注入其實就是在這些不安全控制項內輸入sql或其他資料庫的一些語句，從而達到欺騙伺服器執行惡意到嗎影響到資料庫的數據。防止sql注入，可以在接受不安全空間的內容時過濾掉接受字元串內的「'」，那麼他不再是一條sql語句，而是一個類似sql語句的zifuc，執行後也不會對資料庫有破壞。

如：

username = request("username") //獲取用戶名這里是通過URL傳值獲取的。

password = request("password") //獲取密碼也是通過URL傳值獲取的。

sql="select * from userlist where username = '" & username & "' and password = '" & password & "'"--------如果某個人知道某個用戶名是admin,常常有人網站的管理員用戶名就是admin,這是密碼可以選用'or 1 or ',

那麼sql="select * from userlist where username = 'admin' and password = '' or 1 or ''"，顯然1是恆真的，那麼驗證密碼就通過了。

防止的方式比較多，比如可以限制username,password中出現"'"這些字元，一般網站都是只允許數字，字元，下劃線的組合，這可以通過javascript驗證。也可以採取用存儲過程代替sql拼接，等等。

8. 什麼是SQL注入式攻擊如何防範

一、 SQL注入攻擊的簡單示例。
statement := "SELECT * FROM Users WHERE Value= " + a_variable + "
上面這條語句是很普通的一條SQL語句，他主要實現的功能就是讓用戶輸入一個員工編號然後查詢處這個員工的信息。但是若這條語句被不法攻擊者改裝過後，就可能成為破壞數據的黑手。如攻擊者在輸入變數的時候，輸入以下內容SA001』;drop table c_order--。那麼以上這條SQL語句在執行的時候就變為了SELECT * FROM Users WHERE Value= 『SA001』;drop table c_order--。
這條語句是什麼意思呢?『SA001』後面的分號表示一個查詢的結束和另一條語句的開始。c_order後面的雙連字元指示當前行餘下的部分只是一個注釋，應該忽略。如果修改後的代碼語法正確，則伺服器將執行該代碼。系統在處理這條語句時，將首先執行查詢語句，查到用戶編號為SA001 的用戶信息。然後，數據將刪除表C_ORDER(如果沒有其他主鍵等相關約束，則刪除操作就會成功)。只要注入的SQL代碼語法正確，便無法採用編程方式來檢測篡改。因此，必須驗證所有用戶輸入，並仔細檢查在您所用的伺服器中執行構造 SQL命令的代碼。

二、 SQL注入攻擊原理。
可見SQL注入攻擊的危害性很大。在講解其防止辦法之前，資料庫管理員有必要先了解一下其攻擊的原理。這有利於管理員採取有針對性的防治措施。
SQL注入是目前比較常見的針對資料庫的一種攻擊方式。在這種攻擊方式中，攻擊者會將一些惡意代碼插入到字元串中。然後會通過各種手段將該字元串傳遞到SQLServer資料庫的實例中進行分析和執行。只要這個惡意代碼符合SQL語句的規則，則在代碼編譯與執行的時候，就不會被系統所發現。
SQL注入式攻擊的主要形式有兩種。一是直接將代碼插入到與SQL命令串聯在一起並使得其以執行的用戶輸入變數。上面筆者舉的例子就是採用了這種方法。由於其直接與SQL語句捆綁，故也被稱為直接注入式攻擊法。二是一種間接的攻擊方法，它將惡意代碼注入要在表中存儲或者作為原書據存儲的字元串。在存儲的字元串中會連接到一個動態的SQL命令中，以執行一些惡意的SQL代碼。
注入過程的工作方式是提前終止文本字元串，然後追加一個新的命令。如以直接注入式攻擊為例。就是在用戶輸入變數的時候，先用一個分號結束當前的語句。然後再插入一個惡意SQL語句即可。由於插入的命令可能在執行前追加其他字元串，因此攻擊者常常用注釋標記「—」來終止注入的字元串。執行時，系統會認為此後語句位注釋，故後續的文本將被忽略，不背編譯與執行。

三、 SQL注入式攻擊的防治。
既然SQL注入式攻擊的危害這么大，那麼該如何來防治呢?下面這些建議或許對資料庫管理員防治SQL注入式攻擊有一定的幫助。
1、普通用戶與系統管理員用戶的許可權要有嚴格的區分。
如果一個普通用戶在使用查詢語句中嵌入另一個Drop Table語句，那麼是否允許執行呢?由於Drop語句關繫到資料庫的基本對象，故要操作這個語句用戶必須有相關的許可權。在許可權設計中，對於終端用戶，即應用軟體的使用者，沒有必要給他們資料庫對象的建立、刪除等許可權。那麼即使在他們使用SQL語句中帶有嵌入式的惡意代碼，由於其用戶許可權的限制，這些代碼也將無法被執行。故應用程序在設計的時候，最好把系統管理員的用戶與普通用戶區分開來。如此可以最大限度的減少注入式攻擊對資料庫帶來的危害。

2、強迫使用參數化語句。
如果在編寫SQL語句的時候，用戶輸入的變數不是直接嵌入到SQL語句。而是通過參數來傳遞這個變數的話，那麼就可以有效的防治SQL注入式攻擊。也就是說，用戶的輸入絕對不能夠直接被嵌入到SQL語句中。與此相反，用戶的輸入的內容必須進行過濾，或者使用參數化的語句來傳遞用戶輸入的變數。參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。採用這種措施，可以杜絕大部分的SQL注入式攻擊。不過可惜的是，現在支持參數化語句的資料庫引擎並不多。不過資料庫工程師在開發產品的時候要盡量採用參數化語句。

3、加強對用戶輸入的驗證。
總體來說，防治SQL注入式攻擊可以採用兩種方法，一是加強對用戶輸入內容的檢查與驗證;二是強迫使用參數化語句來傳遞用戶輸入的內容。在SQLServer資料庫中，有比較多的用戶輸入內容驗證工具，可以幫助管理員來對付SQL注入式攻擊。測試字元串變數的內容，只接受所需的值。拒絕包含二進制數據、轉義序列和注釋字元的輸入內容。這有助於防止腳本注入，防止某些緩沖區溢出攻擊。測試用戶輸入內容的大小和數據類型，強制執行適當的限制與轉換。這即有助於防止有意造成的緩沖區溢出，對於防治注入式攻擊有比較明顯的效果。
如可以使用存儲過程來驗證用戶的輸入。利用存儲過程可以實現對用戶輸入變數的過濾，如拒絕一些特殊的符號。如以上那個惡意代碼中，只要存儲過程把那個分號過濾掉，那麼這個惡意代碼也就沒有用武之地了。在執行SQL語句之前，可以通過資料庫的存儲過程，來拒絕接納一些特殊的符號。在不影響資料庫應用的前提下，應該讓資料庫拒絕包含以下字元的輸入。如分號分隔符，它是SQL注入式攻擊的主要幫凶。如注釋分隔符。注釋只有在數據設計的時候用的到。一般用戶的查詢語句中沒有必要注釋的內容，故可以直接把他拒絕掉，通常情況下這么做不會發生意外損失。把以上這些特殊符號拒絕掉，那麼即使在SQL語句中嵌入了惡意代碼，他們也將毫無作為。
故始終通過測試類型、長度、格式和范圍來驗證用戶輸入，過濾用戶輸入的內容。這是防止SQL注入式攻擊的常見並且行之有效的措施。

4、多多使用SQL Server資料庫自帶的安全參數。
為了減少注入式攻擊對於SQL Server資料庫的不良影響，在SQLServer資料庫專門設計了相對安全的SQL參數。在資料庫設計過程中，工程師要盡量採用這些參數來杜絕惡意的SQL注入式攻擊。
如在SQL Server資料庫中提供了Parameters集合。這個集合提供了類型檢查和長度驗證的功能。如果管理員採用了Parameters這個集合的話，則用戶輸入的內容將被視為字元值而不是可執行代碼。即使用戶輸入的內容中含有可執行代碼，則資料庫也會過濾掉。因為此時資料庫只把它當作普通的字元來處理。使用Parameters集合的另外一個優點是可以強制執行類型和長度檢查，范圍以外的值將觸發異常。如果用戶輸入的值不符合指定的類型與長度約束，就會發生異常，並報告給管理員。如上面這個案例中，如果員工編號定義的數據類型為字元串型，長度為10個字元。而用戶輸入的內容雖然也是字元類型的數據，但是其長度達到了20個字元。則此時就會引發異常，因為用戶輸入的內容長度超過了資料庫欄位長度的限制。

5、多層環境如何防治SQL注入式攻擊?
在多層應用環境中，用戶輸入的所有數據都應該在驗證之後才能被允許進入到可信區域。未通過驗證過程的數據應被資料庫拒絕，並向上一層返回一個錯誤信息。實現多層驗證。對無目的的惡意用戶採取的預防措施，對堅定的攻擊者可能無效。更好的做法是在用戶界面和所有跨信任邊界的後續點上驗證輸入。如在客戶端應用程序中驗證數據可以防止簡單的腳本注入。但是，如果下一層認為其輸入已通過驗證，則任何可以繞過客戶端的惡意用戶就可以不受限制地訪問系統。故對於多層應用環境，在防止注入式攻擊的時候，需要各層一起努力，在客戶端與資料庫端都要採用相應的措施來防治SQL語句的注入式攻擊。

6、必要的情況下使用專業的漏洞掃描工具來尋找可能被攻擊的點。
使用專業的漏洞掃描工具，可以幫助管理員來尋找可能被SQL注入式攻擊的點。不過漏洞掃描工具只能發現攻擊點，而不能夠主動起到防禦SQL注入攻擊的作用。當然這個工具也經常被攻擊者拿來使用。如攻擊者可以利用這個工具自動搜索攻擊目標並實施攻擊。為此在必要的情況下，企業應當投資於一些專業的漏洞掃描工具。一個完善的漏洞掃描程序不同於網路掃描程序，它專門查找資料庫中的SQL注入式漏洞。最新的漏洞掃描程序可以查找最新發現的漏洞。所以憑借專業的工具，可以幫助管理員發現SQL注入式漏洞，並提醒管理員採取積極的措施來預防SQL注入式攻擊。如果攻擊者能夠發現的SQL注入式漏洞資料庫管理員都發現了並採取了積極的措施堵住漏洞，那麼攻擊者也就無從下手了。

9. 針對sql注入攻擊，有哪些防範措施

防止sql注入app

與防止sql注入app相關的內容