關於防止SQL注入的問題

爲了避免出現這個漏洞，現在基本上的後臺驗證都不會使用這類方式，而是取得用戶輸入的賬號和密碼，在SQL中先將用戶名與數據庫中的記錄做對比，若數據庫中某條記錄的用戶名等於用戶輸入的用戶名，則取出該條記錄中的密碼，然後再與用戶輸入的密碼對比，正確就通過，不正確就返回。例如一下代碼：
 
<%
pwd = request.form("pwd") 獲取用戶輸入的密碼,再把值賦給pwd
name = request.form("name") 獲取用戶輸入的用戶名再把值賦給name
都沒有進行任何過濾
Set rs = Server.CreateObject("ADODB.Connection")
sql = "select * from Manage_User where UserName=" & name & "" 將用戶名和密碼放入查詢語句中查詢數據庫，
Set rs = conn.Execute(sql) 執行SQL語句，執行後並得到rs對象結果，“真”或“假”
If Not rs.EOF = True Then 如果是真則執行以下代碼
password=rs("password") 取得密碼數據
if password=md5(pwd) then
Session("Name") = rs("UserName") 將UserName的屬性賦給Name的Session自定義變量
Session("pwd") = rs("PassWord") 將PassWord的屬性賦給pwd的Session自定義變量
Response.Redirect("Manage.asp")了 利用Response對象的Redirect方法重定向Manage.asp
else
response.write "密碼錯誤！！！！"
end if
Else 否則執行以下代碼
Response.Redirect "Loginsb.asp?msg=您輸入了錯誤的帳號或口令，請再次輸入！"
End If
%>
 
通過以上例子可知道，密碼的驗證不再是直接在SQL語句中做驗證了，而是根據用戶名，取出對應的密碼，然後再與用戶輸入的做對比。這樣一來就造成了我們不能使用or=or繞過了。有的朋友在這裏可能有疑問了，若我們提交or=or那麼SQL語句就變成：select * from Manage_User where UserName=or=or，這樣一來得到的結果也應該是真啊，爲什麼就不能繞過呢？
 
其實就算SQL查詢的地方得到的值是真，可別忘了後面還有密碼的驗證，若我們提交以上SQL，得到賬號是真的，那麼後面根據賬號去數據庫中取出來的密碼與用戶提交的密碼是絕對通不過的。