One potential client gave me access to his FTP last night to check a small web software to see if I can perform the changes he wants and I found the following line in the code
$query = mysql_query("SELECT * FROM request WHERE MD5(CONCAT(id, code)) = '{$_GET['r']}' LIMIT 1");
I read in this question that mysql_query doesn't support multi queries, so that's the reason why I wasn't able to erase one test-table I created myself.
I did manage to use the old trick ' or 1 = 1 -- but the software interface is designed to list only 1 result of the query, which means I can't get my hands on all the data. But on this subject, the application is a small web software that processes requests.
The application doesn't hold sensitivity data, doesn't matter if you can find and load other people's request because you're not willing to pay their bills and there's nothing else you can do. No password involved, no credit card involvement, nothing. Nothing you can steal from the database matters.
In this case, do I have anything to support the allegations that inputting your data directly into the SQL is unsafe? Is there any way around to delete or update (update in a matter of corrupting) the data using SQL Injection so I can prove that it's actually unsafe? Or otherwise we have to admit that under the circumstances the software is safe enough?
The question is design to help me decide whether I should report back explaining that the client should pay someone to fix all the SQL Injections vulnerabilities. But if it's not broken, he won't be paying to fix it and apparently I can't prove that it's broken.
In answering to @James on comments, the website doesn't handle all your bills, just your bills with the specific client. For the sake of argument we can safely assume that nobody is going to be paying to fix only select vulnerabilities because indeed you won't find any customer of theirs worried about their bills getting out.
You are able to alter the structure and meaning of the query; you are able to add or remove conditions etc. from it and generally make it behave in ways the author did not intend. This is a security issue no matter how you look at it. You may not be able to find an adhoc exploit for it, but it can give someone a leg up in some way or another that nobody anticipates right now. For example, it can be used to probe the database for the existence of data or tables and columns. That alone can give an attacker additional information to formulate a more specific attack elsewhere.
Yes this is a security risk.
For example,
$_GET['r'] = "1 AND code LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'";
And we have a wildcard attack.
SQL Wildcard Attacks are about forcing the underlying database to carry out CPU-intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of web applications. Successful exploitation of this attack will cause Denial of Service.
Beyond that, an attacker can manipulate $_GET['r'] to find out more on your database, such as other tables, columns, and even databases - which is a huge security vulnerability in itself.