Can attacker steal data from AES encrypted table without knowing the key?

Question

I think of a situation that attacker can steal data from AES encrypted table without knowing the key. I tried to search on internet but found nothing about this(may be I were not using the correct keyword), really appreciate if any one can shed some light on it.

Assuming that the table is encrypted with same key but different IV:

1. Attacker signs up for a new account in an application normally.
2. Application creates the account and inserts a new row (2nd row in table below)
3. Somehow attacker found a vulnerability in application to run SQL injection
4. By SQL injection, attacker replaces cipher of his row with Victim's value e.g. aes_cipher_2 -> aes_cipher_1 and iv_2 -> iv_1
5. Attacker signs in his own account
6. Attacker goes to the profile page, then application decrypts Victim's data (aes_cipher_1) and shows the plaintext to him.

ID	Username	Address	IV
1	Victim	aes_cipher_1	iv_1
2	Attacker	aes_cipher_2	iv_2

Answer 1

Yes the attack in the question could work, under the stated assumptions. AES-CTR encryption of database fields is ill-advised, for this reason, and others.

One possible partial mitigation is using authenticated encryption, for example AES-GCM, and including the ID and Username field in the authenticated data. The net effect is that encrypted data (in an Address field) altered in any way, including dissociated from the original ID or Username or IV, will fail decryption with cryptographic certainty.

Authentication will increase the size of the cryptogram (the data in an Address field) by the like of 12 bytes (that's a parameter), regardless of the size of the ID and Username field. The slight size increase can be mitigated by making the IV part of the cryptogram, which is advisable anyway if only because it makes it less likely that the link between cryptogram and it's IV gets lost. Putting the IV at the beginning of data encrypted by a block cipher is the standard practice anyway.

Authenticated encryption gives much better protection than deriving the AES-CTR key from a master key and Id or/and Username: if adversaries can manage to change CTR-encrypted data and observe the behavior of some IT system on the deciphered data, then it's to fear they can learn something about the data. For example, if the byte '<' in the deciphered data causes some recognizable behavior, then it takes like 30 attempts per characters to decipher; just like in movies. Authenticated encryption protects against this, derived keys do not.

I'm far from stating authenticated encryption of confidential database entries is foolproof. It does not give protection from many insiders. It does not even provide good protection for backups, because all too often the key will be in the backup (for this reason I advocate encrypting database backups with public key and hybrid encryption). And authenticated encryption can often be circumvented. For example, with read access to a database that includes a hashed password, attackers would often be able to mount a password search that would find the passwords of some users, then log in as one of these users. And with write access, attackers could change password hashes to that of a password they know, and log in as any user of their choice.

Again: cryptography should not be the first line of defense for a database. It should not be read-accessible, much less write-accessible by attackers. And it the database uses a text language for queries (a design mistake entrenched in current IT practices, that allowed and still allows countless attacks, and causes huge wastes of computing resources in query generation and parsing), then at least a carefully designed and reviewed query-generation software layer must enforce separation of data from the query language.