SQL Injections, Again…

Last Friday the Dutch TV program Zembla aired part two of the "verzuimpolitie" series. The first part was mainly about how employers could access medical information about employees. There is a news article about the second part here (with google translate).

The second part is about the security of the IT system which is used to record medical information about employees. They give this information to the company to which the company they're working for is outsourcing everything related to workplace absenteeism.

After the first part of the series some viewer reported that the website contained SQL injections. The creators of the program verified this and tried to report it to VCD (The company which offers the software as a service). Then VCD called to police to remove them from the VCD office.


Then Zembla contacted the Radboud University and asked them to assist with this issue. The University verified the SQL Injection and confirmed that this was a serious security flaw. Then a VCD executive told Zembla that there wasn't a SQL Injection, someone just stole the passwords. This is strange because VCD reported to the University that they recorded a SQL Injection attack by the University.


The users of the VCD Humannet software were not informed. And when some of the companies using this SaaS service became aware of the security incident it took a lot of effort before the service was temporarily shutdown to prevent further harm.


This whole story reminded me of the situation around Comodo and DigiNotar. Comodo was hacked, stopped the issuing process, reported the issue and fixed it. Then DigiNotar was hacked, did not stop the issuing process. It also didn't report the issue. Then they became bankrupt.


The lessons learned for SQL Injections for DBA's and Application Developers:
1. Input validation. This is obvious.

2. Use prepared statements if possible.

3. Prepare for a security incident: make it easy to disable applications or parts of applications.
If all client companies are in the same database then it's very hard to shutdown the application for just one company. Using one database instance per client company might be a solution.


4. Use isolation
If there are 10 client companies and they all use different databases  as separation, then you should also use 10 application users with the correct permissions. Then a SQL injection for one customer won't affect other customers.


5. Use a database firewall.
This is not very common yet. You could use GreenSQL or McAfee (partly opensource). There are more solutions available, but these are at least partly opensource.

6. Use two factor authentication if dealing with sensitive data.
You don't have to buy expensive tokens. There are enough free or almost free solutions available. Yubikey is a possible solution.

7. Do not store passwords, store hashes.



8. Use encryption an function like AES_ENCRYPT() to encrypt sensitive data.
This could guard your data from 'curious' DBA's and other administrative users.
 Do not use a hardcoded password for this! Make sure that the AES_ENCRYPT doesn't end up in your binlogs, use a variable! And only use TLS secured connections. It might be better to encrypt the data in the application instead of in the database. It could even be possible to use client side encryption to encrypt the data in the browser.

9. Remove old authentication methods, login screens, etc.


The lessons learned for SQL Injections for management:
1. Security scans are mandatory. Companies like Madison Gurkha and Fox IT can offer this.

2. Don't only inclue your own services in security scans, but also the external services you use.

3. Make sure that there is a security breach notification requirement in the contracts for security sensitive services.

4. Make it easy to report security incidents.

5. Do shutdown the service if needed for security.

6. Do inform your customers about the security incident.