具有自攻擊性的代碼
發表時間:2024-06-20 來源:明輝站整理相關軟件相關文章人氣:
[摘要]具有自攻擊性的代碼 寫出這類代碼的程序員如果被點破那么一定會被認為是大腦進水,但是這類的代碼已經漫天飛舞甚至成為葉子認為攻擊網站的最好手段之一,現看下面的一段代碼:<%set dbr = server.createobject("adodb.recordset")dbr....
具有自攻擊性的代碼 寫出這類代碼的程序員如果被點破那么一定會被認為是大腦進水,但是這類的代碼已經漫天飛舞甚至成為葉子認為攻擊網站的最好手段之一,現看下面的一段代碼:
<%set dbr = server.createobject("adodb.recordset")
dbr.open "SELECT * from testapp where id="& request("id") ,session("DS"),1,1
for i = 1 to dbr.recordcount %>
<%=dbr("id")%>-<%=dbr("title")%><br>
dbr.movenext
next
dbr.close
set dbr=nothing %>
這段代碼是根據輸入ID返回ID相關的標題名稱,相應的數據庫構造腳本為
CREATE TABLE [dbo].[testapp] (
[id] [int] NOT NULL , [title] [char] (10) COLLATE Chinese_PRC_CI_AS NOT NULL
) ON [PRIMARY]
但是這個腳本并沒有任何的安全檢查功能,這樣的腳本就是一個系統漏洞,先看一下正常腳本的執行情況:在瀏覽器中正常的敲入地址http://127.0.0.1/testapp/index.asp?id=5
將看到正常的顯示結果

圖-2 但如果輸入特殊的請求,如http://127.0.0.1/testapp/index.asp?id=5;update%20testapp%20set%20id=id%2b%201
這時候這段代碼中瀏覽器并沒有任何顯示

圖-3
好象什么都沒有執行,實際上在內部數據就已經變化了,看下面的SQL SERVER的屏幕執行前的數據如圖

圖-4 執行后的數據,
如圖

圖-5 可見表中數據ID列全部增加了1,正符合在連接地址欄中巧入的連接http://127.0.0.1/testapp/index.asp?id=5;update%20testapp%20set%20id=id%2b%201
其實對這個連接解碼再結合程序可以得到SQL語句 SELECT * from testapp where id=5;update testapp set id=id + 1 連接中的%20是空格的16進制代碼%2b是“+”的十六進制代碼
因此組成了以上語句。由于其中分號的作用SQL SERVER將一行SQL語句分解成若干行語句執行因此在執行過SELECT * from testapp where id=5語句后再次執行update testapp set id=id + 1語句使ID列增加1 這個后部的update testapp set id=id + 1也可以根據攻擊的需要替換成delete 以及 insert甚至在權限允許的條件下可以使用xp_cmdshell執行CMD命令。