They possibly felt that you were suggesting it was a lot of work to fix this, when in reality it would take a couple of hours to add sanitization checks to the inputs.
You're also overestimating the business impact of a security breach. This is an area where people's moral compass overrides their shrewdness. Notice that Anthem is still in business despite the worst possible breach, for example.
It's worth trying to improve security, if possible. But it takes one of two things: (a) leverage, or (b) patience. One of the main reasons that companies get a security audit is because a different company forces them to. They get an audit in order to obtain a CFD (client facing document) saying that they are secure. Without this, the other company will not do business with them, which is the sole reason why the security audit happens.
The other way -- patiently pointing out ways of improving the situation, and explaining the business merits of allocating time to this pursuit -- does not usually result in meaningful security improvements. This is an unfortunate fact of the industry, partly because security breaches do not usually put a company out of business. There are exceptions to this, but that is the common case.
To be fair, it would be a lot of work to fix the backend. The SQL is dynamically generated for every request, and the code that does so is thousands of lines long, with nested subroutines that construct sub-portions of the query, so there is no easy way to check where things need to be parameterized. Also there is some injection from unusual places (like a search options object separate from the search criteria object which includes the ASC/DESC which, you guessed it, is directly injected).
Realistically, to be safe, you'd have to gut the whole thing and replace it. You can be a "little safe" by doing something silly like replacing ' with '' but that doesn't protect in non-string cases, etc, and I wouldn't propose a solution like that because it could give a false sense of security.
I understand the push-back. The backend is maintained by others and it would add to their workload to secure it. That's a real and actual cost.
As for the business impact, you are right. I just wanted it to be "on the table" that I informed people of the situation, so that if there is an exploit in the future, I don't get the "why didn't you tell anyone this was vulnerable?" or something like that.
I came across an application that had SQL injection vulnerabilities everywhere (100s of ASP files). Query parameters were concatenated into strings over 1000s of lines. It would have been a year's project to properly parameterize every query across every system. Management wasn't too concerned until I showed them that I could drop the entire database (and the other databases on that DBMS) by putting a URL into IE6. Our eventual fix was to pass every query through a regex that would stop the worst queries (DROP, TRUNCATE), while making it a priority that everyone start writing safe queries and fixing bad query generation code when it is seen.
An attacker can't necessarily leverage ASC/DESC injection unless multiple queries can be issued by a single SQL statement (i.e. injecting "ASC; SELECT * FROM...") which isn't commonly enabled in most database deployments. But there are probably other insecurities here.
The solution is to run every input through a function that replaces each single quote with two single quotes. That is all that's required to prevent SQL injection, since it's not possible to construct a valid query regardless of the injection point. (EDIT: This refers to string inputs. Numeric inputs are handled in the obvious way, as is ASC/DESC. Injection into an ORDER BY clause is not usually exploitable. These are all of the cases.)
If you propose this solution to management, they may be somewhat more likely to take action, since it can be applied to the existing system.
I respectfully disagree with your claim that replacing ' with '' will complete the security. Reason: there are non-string cases, so there exists concatenations like:
"WHERE SomeNumber = " + inputValue + " ... "
but inputValue is a string (from untyped xml), but is put into SQL without quotes because SomeNumber is an int type in the database. Since the xml is constructed without validation, an attacker could put any value there, including strings to inject, and do so without using quotes.
You're also overestimating the business impact of a security breach. This is an area where people's moral compass overrides their shrewdness. Notice that Anthem is still in business despite the worst possible breach, for example.
It's worth trying to improve security, if possible. But it takes one of two things: (a) leverage, or (b) patience. One of the main reasons that companies get a security audit is because a different company forces them to. They get an audit in order to obtain a CFD (client facing document) saying that they are secure. Without this, the other company will not do business with them, which is the sole reason why the security audit happens.
The other way -- patiently pointing out ways of improving the situation, and explaining the business merits of allocating time to this pursuit -- does not usually result in meaningful security improvements. This is an unfortunate fact of the industry, partly because security breaches do not usually put a company out of business. There are exceptions to this, but that is the common case.