Topic: SQL Injection Prevention

Hi to all,


we have had an internal audit and the question has come up if and how MyVisualDatabase supports SQL Injection Prevention.


Any Information about available? Anything included by design?


- Are Parameterized SQL Statements possible
- What happens when somebody enter, for example, as Password or search value items like      12345 or 1=1
- What happens when somebody enter, for example, as Username or search value items like     john; --


I haven't found in the forum or anywhere else at the webpage information about this which can be presented to the auditors.


Thank you for your help in advance.


teco049

2 (edited by brian.zaballa 2020-08-21 14:04:33)

Re: SQL Injection Prevention

I think there's no parameterized sql statements. you can do escape_special_characters instead.
I hope they incorporate TSQLQuery later on.

For the other 2 questions. they will both not do anything harmful in your database. when logging in or if you try to fill it on your forms. They will be considered as text or numbers by the system.

brian

Re: SQL Injection Prevention

Hi Brian,

we use a lot of scripts in MVD.


Without any information from Dmitry, I have nothing to present the auditors.


Additional, without parameterized SQL Statements the auditors estimating that MVD is not GDPR compilant.


Any information from other Forum Users in EEA if MVD is GDPR compilant?


Thank you.

Re: SQL Injection Prevention

GDPR is about personal privacy protection, so, as long as you cannot protect sufficiently personal data stored in SQLite, you should consider using MVDB with a MySQL database with all securities around the server as a solution to be GDPR compliant if you use it to store personal and private data. There is still the possibility to write parameterized statements using SQLite, look for prepared statement for SQLite, everything is in the method you use to code your application, you are the only one to be responsible for the safety of the data. MVDB is a framework to manipulate data, you should maybe read more about SQLite and MySQL to present something to auditors. If you use a lot of scripts, then you should read about Delphi to implement security in your SQL statements. Anyway, you can still try to inject the database to be sure!! Now, if the auditors are not able to read your script to detect possible SQL injection, then they should do another job, I don't know... blowing dust from server fans for example smile

Re: SQL Injection Prevention

When it comes to data protection, tcoton is right. Using sqlite as your database might compromise personal data if not stored or protected right. Encrypting your database is one way but might cost you a little bit. I'm not familiar with GPDR but doing some research, I run on some  issues.

Encryption is the best way to protect data during transfer and one way to secure stored personal data. It also reduces the risk of abuse within a company, as access is limited only to authorized people with the right key

. You can also encrypt fields (personal information) saved on your database (retrieving and storing might be tricky but attainable).

brian

Re: SQL Injection Prevention

tcoton wrote:

GDPR is about personal privacy protection, so, as long as you cannot protect sufficiently personal data stored in SQLite, you should consider using MVDB with a MySQL database with all securities around the server as a solution to be GDPR compliant if you use it to store personal and private data. There is still the possibility to write parameterized statements using SQLite, look for prepared statement for SQLite, everything is in the method you use to code your application, you are the only one to be responsible for the safety of the data. MVDB is a framework to manipulate data, you should maybe read more about SQLite and MySQL to present something to auditors. If you use a lot of scripts, then you should read about Delphi to implement security in your SQL statements. Anyway, you can still try to inject the database to be sure!! Now, if the auditors are not able to read your script to detect possible SQL injection, then they should do another job, I don't know... blowing dust from server fans for example smile

Funny (the last part about doing another job) but irrelevant to the auditors. It's not just about personal data, it's about a security check.


GDPR means also privacy by design, which includes the development environement in our case. MVD uses not a complete delphi environement but a delphi script environement with limited delphi functionallity. When we would use RAD Studio or Lazarus or CodeTyphoon the situation would be clear for the audit. The application developer must use the unrestricted functionality accordingly.


The Delphi script is seen very clearly by the auditors. The manufacturer determines which safety functions are included or not. What is not listed in the documentation is not included and not possible.


The internal audit was in preperation for an official audit. We can close here. Audit has been finished at Aug. 31.


As far as I can tell, the following was criticized during the audit:
- "Compiled" scripts can be reverse engineered relatively easily because they are not binary compiled or encrypted but as a compressed script.
- Passwords in the scipts for database encryption are stored openly and not encrypted. So worthless because easy to read.
- The included RC5 encryption is faulty (conversion Ansi / UTF problem) and therefore cannot be used.
- Delivery with SQLite library without encryption.
- MySQL with full encrypted data storage is only possible in the enterprise version, not in the community. The note in the selection of the database engine is missing here (We don't use MySQL often so I can't confirm. Our other database servers have encryption included).


Besides, the auditors can read the scripts and recommend a 1: 1 implementation in RAD Studio or CodeTyphoon.

Re: SQL Injection Prevention

As far as I can tell, the following was criticized during the audit:
- "Compiled" scripts can be reverse engineered relatively easily because they are not binary compiled or encrypted but as a compressed script.
- Passwords in the scipts for database encryption are stored openly and not encrypted. So worthless because easy to read.
- The included RC5 encryption is faulty (conversion Ansi / UTF problem) and therefore cannot be used.
- Delivery with SQLite library without encryption.
- MySQL with full encrypted data storage is only possible in the enterprise version, not in the community. The note in the selection of the database engine is missing here (We don't use MySQL often so I can't confirm. Our other database servers have encryption included).

I totally agree with this points and they have been a hot discussion for many years on this forum but it seems that the devs at MVDB are not really in a rush to provide a solution which is a shame since people would like to use it at work but hey... there are laws and regulations that IT services have to abide to!!