One point not really mentioned yet is that you might simply be overstepping what your client really wants from you in this case. Overachieving is great and can give you lots of job satisfaction. But if the client simply doesn't care, thinks current performance is "good enough" and just wants some minor updates, it may be impossible to persuade them to make a large investment in you to overhaul the codebase.
At that point you'll probably need to decide whether to stand on principles and refuse to take a job that would force you to attach your good name to a embarrassing code mess or whether you can hold your nose, get in, get the job done with some duct tape, and get out with your payment.
If you do decide to go ahead with the duct tape job though, make sure to document, document, document and be as transparent as possible. The last thing you want is to get blamed for something going wrong in the future that is a result of an application flaw you warned the client about but that the client decided wasn't important enough to deal with at the time.
As far as the SQL injection risks go, as others have said you should be able to demonstrate to dangers of that to them in a way that shows the risks without actually doing anything destructive in production. But again, if they see it and don't care enough to pay you to fix it, you've done your good faith diligence in this case.