PHP is the king of SQL injections, they are often not too hard to come by on a lot of deployments. Sure, if you use modern PHP with modern toolkits/frameworks/libraries and you follow OWASP and are a competent developer, you might never introduce such vulnerabilities in your codebase. But PHP didn't gain popularity because it had frameworks that were concerned about security or that it had a trove of security conscious developers - it thrived because any 13 year old could string together a website that was as minimum of a viable product as possible.
If you have a sql injection vulnerability they literally already have the keys to the castle. This in addition gets you nothing you didn’t already have simply by setting the hash to a known value.
How would you persistently log into another user’s account, without them knowing anything was wrong and without knowing their password, with just sql injection?
Well i kind of agree with you that the covert persistence aspect makes this a borderline low severity bug, but pivoting from DB->access isn't exactly unheard of.
I would first of all, wonder why i would want that. Why access someone's account when i could just dump the DB. Obviously it depends on context, but most of the time, DB access is more valuable than account access.
I would check if the DB is misconfigured (e.g. In mysql, does the DB user have File or Super rights?)
I would dump all the passwords and see if anyone's is weak enough to suffer from a crack attempt
I would check if there is anything in the DB that looks like php serialized data (People are saying unfair things about PHP like it being the king of sql injection, but its probably fair to say that unsafe deserialization is pretty common in php).
As a last resort, i would check if there is anything that looks like HTML or JS in the database, and see if i could get an XSS to leverage into an account take over.
True, but in this case if you can write an invalid hash into a database, you can likewise write a valid one, and as such this doesn't really enable anything.
The one thing this does get you is that the original password would still work (technically any password would still work) so it may make it harder to detect since the user wouldn't "suddenly be locked out"...
