3個步驟解決SQL注入隱患

許多網站程式在編寫時，沒有對使用者輸入資料的合法性進行判斷，使應用程式存在安全隱患。 　　SQL注入是什麼? 　　許多網站程式在編寫時，沒有對使用者輸入資料的合法性進行判斷，使應用程式存在安全隱患。 使用者可以提交一段資料庫查詢代碼(一般是在瀏覽器網址列進行,通過正常的www埠訪問)，根據程式返回的結果，獲得某些想得知的資料，這就是所謂的SQL Injection，即SQL注入。 　　網站的惡夢——SQL注入 　　SQL注入通過網頁對網站資料庫進行修改。 它能夠直接在資料庫中添加具有管理員許可權的使用者，從而最終獲得系統管理員許可權。 駭客可以利用獲得的管理員許可權任意獲得網站上的檔或者在網頁上加掛木馬和各種惡意程式，對網站和訪問該網站的網友都帶來巨大危害。 　　防禦SQL注入有妙法 　　第一步：很多新手從網上下載SQL通用防注入系統的程式，在需要防範注入的頁面頭部用來防止別人進行手動注入測試。 可是如果通過SQL注入分析器就可輕鬆跳過防注入系統並自動分析其注入點。 然後只需要幾分鐘，你的管理員帳號及密碼就會被分析出來。 　　第二步：對於注入分析器的防範，筆者通過實驗，發現了一種簡單有效的防範方法。 首先我們要知道SQL注入分析器是如何工作的。 在操作過程中，發現軟體並不是沖著「admin」管理員帳號去的，而是沖著許可權(如flag=1)去的。 這樣一來，無論你的管理員帳號怎麼變都無法逃過檢測。 　　第三步：既然無法逃過檢測，那我們就做兩個帳號，一個是普通的管理員帳號，一個是防止注入的帳號，為什麼這麼說呢?筆者想，如果找一個許可權最大的帳號製造假像，吸引軟體的檢測，而這個帳號裡的內容是大於千字以上的中文字元， 就會迫使軟體對這個帳號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。 下面我們就來修改資料庫吧。 　　1.對表結構進行修改。 將管理員的帳號欄位的資料類型進行修改，文本型改成最大欄位255(其實也夠了，如果還想做得再大點，可以選擇備註型)，密碼的欄位也進行相同設置。 　　2.對表進行修改。 設置管理員許可權的帳號放在ID1，並輸入大量中文字元(最好大於100個字)。 　　3.把真正的管理員密碼放在ID2後的任何一個位置(如放在ID549上)。 　　我們通過上面的三步完成了對資料庫的修改。 　　這時是不是修改結束了呢?其實不然，要明白你做的ID1帳號其實也是真正有許可權的帳號，現在電腦處理速度那麼快，要是遇上個一定要將它算出來的軟體，這也是不安全的。 我想這時大多數人已經想到了辦法，對，只要在管理員登錄的分頁檔中寫入字元限制就行了!就算對方使用這個有上千字元的帳號密碼也會被擋住的，而真正的密碼則可以不受限制。