安全測試后的調整-SQL注入解決方法
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
上周給別人做了個網站,無意間發現自己的作品有很多漏洞,在短短的20秒就被自己用sql注入法給干了。所以查了一點關于sql注入的資料,并且有點感悟,希望能與新手們分享一下。高手們見笑了!
SQL注入攻擊的總體思路: 發現SQL注入位置; 判斷服務器類型和后臺數據庫類型; 確定可執行情況 對于有些攻擊者而言,一般會采取sql注入法。下面我也談一下自己關于sql注入法的感悟。 注入法: 從理論上說,認證網頁中會有型如: select * from admin where username='XXX' and password='YYY' 的語句,若在正式運行此句之前,如果沒有進行必要的字符過濾,則很容易實施SQL注入。 如在用戶名文本框內輸入:abc’ or 1=1-- 在密碼框內輸入:123 則SQL語句變成: select * from admin where username='abc’ or 1=1 and password='123’ 不管用戶輸入任何用戶名與密碼,此語句永遠都能正確執行,用戶輕易騙過系統,獲取合法身份。 猜解法: 基本思路是:猜解所有數據庫名稱,猜出庫中的每張表名,分析可能是存放用戶名與密碼的表名,猜出表中的每個字段名,猜出表中的每條記錄內容。 還有一種方式可以獲得你的數據庫名和每張表的名。 就是通過在形如:http://www. .cn/news?id=10'的方式來通過報錯獲得你的數據庫名和表名! 對于jsp而言我們一般采取一下策略來應對: 1、PreparedStatement 如果你已經是稍有水平開發者,你就應該始終以PreparedStatement代替Statement. 以下是幾點原因 1、代碼的可讀性和可維護性. 2、PreparedStatement盡最大可能提高性能. 3、最重要的一點是極大地提高了安全性. 到目前為止,有一些人(包括本人)連基本的惡義SQL語法都不知道. String sql = "select * from tb_name where name= '"+varname+"' and passwd='"+varpasswd+"'"; 如果我們把[' or '1' = '1]作為name傳入進來.密碼隨意,看看會成為什么? 網管網bitsCN.com select * from tb_name = 'or '1' = '1' and passwd = '隨意' ; 因為'1'='1'肯定成立,所以可以任何通過驗證.更有甚者: 把['; drop table tb_name; ]作為varpasswd傳入進來,則: select * from tb_name = '隨意' and passwd = ''; drop table tb_name; 有些數據庫是不會讓你成功的,但也有很多數據庫就可以使這些語句得到執行. 而如果你使用預編譯語句.你傳入的任何內容就不會和原來的語句發生任何匹配的關系.(前提是數據庫本身支持預編譯,但上前可能沒有什么服務端數據庫不支持編譯了,只有少數的桌面數據庫,就是直接文件訪問的那些只要全使用預編譯語句,你就用不著對傳入的數據做任何過慮.而如果使用普通的 statement,有可能要對drop,; 等做費盡心機的判斷和過慮. 2、正則表達式 2.1、檢測SQL meta-characters的正則表達式 /(\%27)|(\')|(\-\-)|(\%23)|(#)/ix 2.2、修正檢測SQL meta-characters的正則表達式 /((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-) 54ne.com |(\%3B)|(:))/i 2.3、典型的 SQL 注入攻擊的正則表達式 /\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\ 中國網管聯盟www.bitscn.com %52))/ix 2.4、檢測SQL注入,UNION查詢關鍵字的正則表達式 /((\%27)|(\'))union/ix(\%27)|(\') - 單引號和它的hex等值 union - union關鍵字。 該文章在 2011/1/30 23:33:06 編輯過 |
關鍵字查詢
相關文章
正在查詢... |