last day (15 days later) » 

13:59
4
Q: Protecting encrypted data in case of SQL injection

Mehdi BounyaLet's say there is a web application, with encrypted data. e.g. a website where patients leave notes to their doctors. A patient logs in, leave a note, that note is encrypted using symmetric encryption and inserted to the database, the user can still see his note if he ever comes back, the note ...

That makes no sense to me right now. So we say the patient types the note "hello" which will be encrypted to "axg875hv%21fh". That encrypted message is saved to the database. How would using SQL Injection to copy that message to a different user help in any way? The hacker would only see "axg875hv%21fh" because he can't decrypt it without the secret only the patient (and maybe the doctor) has. If you however are using the same secret for all messages of all patients that's a security issue itself.
@Nico the same key is used across all the application, the hacker copies "axg875hv%21fh" and goes to the database and update his note with "axg875hv%21fh" and goes back to the web application and visits the link to his own ticket, the application will then take his row (tampered) and decrypt it for him.
Surely the way you prevent this attack is to eliminate the SQL injection vector? If they can do that, they can cause more harm than just reading the notes.
So my question would be, why not encrypt it with a patient-doctor shared secret nobody else knows? Or even better a P2P like behaviour signal/Whatsapp etc are using. Private-Public key Combinations. But as @TripeHound already said first point would also be to eliminate SQL Injection possibilitys
@Nico That was just an example, let's say all the doctors can view all the notes, the note is not limited to a specific doctor.
@TripeHound I was wondering about ways other than that, this is just a hypothetical question.
13:59
When somebody is able to see the encrypted and the decrypted message, would that than not give him the possibility to derive the key from that - making your attack scenario even simpler: He can just download all the data and encrypt it himself.
@Daniel well that's a new fact, I'm fairly new to cryptography
@Mehdi Bounya: I am not an expert myself, but I understand that´s how the KRACK-WLan Hack works... Normally the only person that has both versions of a message should be the one having the key anyways!
@Daniel I just searched, it's called Known-plaintext attack and modern ciphers are not vulnerable to this attack
@Mehdi Bounya: In the System you described, Chosen-plaintext attack and Chosen-ciphertext attack would also be possible... bottom line: never use the same key for different users!
Say User A types "secret" and the database stores "X%*@". If an attacker steals "X%*@", and pastes it in the web interface, it gets stored in the database as a new ciphertext. Then when the hacker goes back to view their note, they will again see ""X%*@" (exactly what they typed). If they however, insert a new row, with the original ciphertext, then your scenario is valid. but not through the web front end.
13:59
@n00b that's my point... using SQLi with update permissions he can update his row
It's unclear what you are trying to protect against; do you want (1) the note to only be readable by doctors, (2) the note's author to be irrevocable, (x) anything else? Without clearly stated goals, the answers are all over the place...
Even with varying keys, the attack vector described in the OP seems to be such that it can at least be used to destroy data.
@MatthieuM. Users data can be read by website owners (all of them), each user can see his own data.
@HagenvonEitzen Yes, but destroying data is not the same as reading it.
@MehdiBounya You also need to prevent JavaScript injection attacks, just in case the framework you're using doesn't do that for you or if you could accidentally bypass the framework's prevention method.
 
4 hours later…
18:12
@AndrewMorton thanks but I already escape all my data properly, I'm more interested in this question about the right way of doing encryption, if I'm missing something

last day (15 days later) »