Re: [sqlmap-users] Optimizing LIMIT 1 UNIONable injections

[Brandon P. <bpe...@gm...>]

Looking at some later requests, it appears that dumping a row from a table is performed this way (each column is concated together). So it looks like this kind of strategy is just not used consistently when limited to a single row.

However, it could still chunk multiple rows into a single concat statement (selecting 10 rows per request for instance, instead just one).

Just thoughts.


> On Aug 15, 2017, at 4:04 PM, Brandon Perry <bpe...@gm...> wrote:
> 
> Currently, it seems that sqlmap will use a payload such as the following is a UNIONable parameter is found that can only return one row in order for data to be exfil’ed.
> 
> -16301 UNION ALL SELECT NULL,NULL,(SELECT CONCAT(0x71787a7871,IFNULL(CAST(schema_name AS CHAR),0x20),0x716a706271) FROM INFORMATION_SCHEMA.SCHEMATA LIMIT 4,1),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
> 
> When enumerating databases in an injection like this, sqlmap will make a single request per db name (note the LIMIT clause). This is a bit inefficient. I understand there may be length limitations to query string parameters, but I’m curious why sqlmap wouldn’t use a more efficient payload, such as the following.
> 
> -16301 UNION ALL SELECT NULL,NULL,CONCAT(0x41414141, (SELECT schema_name FROM INFORMATION_SCHEMA.SCHEMATA LIMIT 4,1), 0x41414141,(SELECT schema_name FROM INFORMATION_SCHEMA.SCHEMATA LIMIT 3,1), 0x41414141,(SELECT schema_name FROM INFORMATION_SCHEMA.SCHEMATA LIMIT 2,1)),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
> 
> Error-based payloads certainly have length limitations in the data they can get out per request, but is there something preventing sqlmap from implementing a more efficient single-row UNION strategy when exfiltrating data?
> 
> Let me know if this doesn’t make sense.