Perhaps, but an employee in that position can steal credentials even without GET logs.
This entire discussion is predicated on a contradictory assumption, that an employee would be corrupt enough to steal credentials from web server logs, but not corrupt enough to steal the same credentials from any other source (inc. database access).
It is like letting a criminal into your home, then being concerned that they might see your security system's pin written on a sticky note on the fridge. Sure, it is a problem, but ultimately the criminal doesn't need that pin to steal your shit, you already let them walk right in.
GET logs end up in all sorts of places. I would not be at all surprised if anyone working at EBay could get access to them. Not to say they should have access to them, but access to the logs is different from access to the server. Log reading permissions have a rightfully lower standard than ssh/deployment permissions.
(But part of what makes it OK to have more people with access to the logs is you don't put things like username/passwords for all of your customers in the logs.)
With that logic it doesn't make sense to store passwords encrypted in the DB then either. If an outside attacker gains access to a system it would really suck to have a bunch of passwords sitting in logs unencrypted. Security in depth and all...
This entire discussion is predicated on a contradictory assumption, that an employee would be corrupt enough to steal credentials from web server logs, but not corrupt enough to steal the same credentials from any other source (inc. database access).
It is like letting a criminal into your home, then being concerned that they might see your security system's pin written on a sticky note on the fridge. Sure, it is a problem, but ultimately the criminal doesn't need that pin to steal your shit, you already let them walk right in.