enhancement: add union-based SQLi tests with php://filter payload

[hansmach1ne]

Hey, thank you very much for taking interest in LFImap, even more to contribute for improvements. Currently, LFImap doesn't support testing for SQL injection per se (as there are other better tools such as SQLmap for that specific vulnerability).

With that said, could you just comment, what is the vulnerability scenario here? The app is vulnerable to SQLi, however with union based query, SQL backend wouldn't be able to parse our UNION-injected query 'php://filter...'

Aditionally, LFImap currently supports the file inclusion testing, even in this scenario. You can define the testing parameter like -U http://site.com/?id=1' UNION SELECT PWN and you can utilize all modalities to test for inclusion with parameter prefix/postfix.

[katanta]

Hi, thank you for considering the code.

The test exploits a vulnerability where a user-defined parameter is not sanitized before being used in an SQL statement, and the result of that query is used in a php include expression. Here is an example:

$foo=substr($_POST['foo'],0,100);
$sql = "SELECT bar FROM foos WHERE foo LIKE '%".$foo."%'";
$result = $conn->query($sql);

while($row = $result->fetch_assoc()) {
    include($row["bar"]);
    print("<br>");
}

In this case the code is vulnerable to SQLi because the POST parameter foo is unsanitized. An atttacker can exploit this using UNION-based SQLi to add a new row to the result of the query. Since the column bar is directly used in an include statement, this leads to an LFI vulnerability, especially combined with wrappers like php://filter.

While this vulnerability initially relies on SQLi to insert a payload into an exploitable position, it think it primarily an LFI. Therefore, I thought it would be a useful addition to LFImap. I have tried to use SQLmap against this kind of vulnerability, but the test phase did not deem the parameter as vulnerable to UNION-based SQLi.

I also tried using the method you suggested, but I just get an error message saying the URL is invalid. Also, I do not think the method you suggested would work if the vulnerable parameter were to be a POST parameter.

[hansmach1ne]

I'll look into this, might implement support for this scenario also.

Btw, you can write the switches you used, that yielded in URL is invalid, we might fix that too.