--------------------------------------------------------
過濾URL中的一些特殊字符，動態SQL語句使用PrepareStatement..
------解決方案--------------------------------------------------------
注入的方式就是在查詢條件里加入SQL字符串. 可以檢查一下提交的查詢參數里是否包含SQL,但通常這樣無益.
最好的辦法是不要用拼接SQL字符串,可以用prepareStatement,參數用set方法進行填裝
------解決方案--------------------------------------------------------
sql注入形式：...where name="+name+",這樣的sql語句很容易sql注入，可以這樣：
jdbcTemplate.update("delete from userinfo where id=? and userId=?", new Object[]{userInfo.getId(),userInfo.getUserId()});
我的一些代碼，望有用！
------解決方案--------------------------------------------------------
Sql注入漏洞攻擊：如1'or'1'='1
使用參數化查詢避免
cmd.CommandText="select count(*) from 表名 where username=@a and password=@b";
cmd.parameters.Add(new SqlParameter("a",".."));
cmd.parameters.Add(new SqlParameter("b",".."));
------解決方案--------------------------------------------------------
恩，用框架，用jpa的pojo。。就沒這種事情了
SSH2架構中 怎么防止SQL注入呢？還有其他相關安全問題怎么設計呢？
目前的安全，只是對用戶密碼加密，前台jquery驗證。
如何實現防止注入攻擊還有我的頁面有些隱藏域保存這當前登錄用戶的信息等信息。
用戶查看頁面源代碼就可以查看到了。
有沒好的解決方案呢？還有其他哪些要注意的地方呢？
Struts2 hibernate3 spring 3.0
sql server 2000 sp4
------解決方案--------------------------------------------------------
1：向 CA 購買證書，使用 HTTPS 進行通信，以保證在網絡傳輸過程中是安全的
2：避免 XSS 注入（頁面回顯的 input text, input hidden 均過濾 <、>、"、' 等字符等）
3：使用隨機鍵盤或者安全控件防止鍵盤木馬記錄用戶的輸入
4：若要在 Cookie 中寫入數據，盡量使用 Cookie 的 HttpOnly 屬性
5：響應中設置一些諸如 X-Frame-Options、X-XSS-Protection 等高版本瀏覽器支持的 HTTP 頭
6: 不管客戶端是否做過數據校驗，在服務端必須要有數據校驗（長度、格式、是否必填等等）
7: SQL 語句采用 PreparedStatement 的填充參數方式，嚴禁使用字符串拼接 SQL 或者 HQL 語句
六個建議防止SQL注入式攻擊
2009-04-01 14:38
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語句的注入式攻擊。