Hello all, newby from Amsterdam here with an ACCDE security quest (1 Viewer)

orny

New member
Joined
Oct 18, 2023
Messages
10
Hello All!
I have been programming in Access for over 20 years, have always found it an extremely useful tool. My "specialty" is using Access as a front end and using MySQL as a backend. This usually works quite well. I stumbled into this group because I have always been interested in the security aspects of Access, and have been toying with something new in the past days. I entered via the "Encrypted-Split-No-Strings-DB" - thread.

I have just done my first tests using Access in combination with PHP calls over SSL to a SSL encrypted MySQL backend and a non-encypted ACCDE front-end. Anyone interested in trying to crack it open and tell me how they did it? As far as I could tell, Wireshark seems to show that there is just a lot of garbled bytes over the internet line. I tried to copy a new autoexec macro into th ACCDE, pointing to a new form, allowing me to alter settings. But I could only inject the rogue autoexec macro, not the frmRogueForm I had planned.

Look forward to hearing from you!


Best regards,

Pep
 
Welcome to Access World! We're so happy to have you join us as a member of our community. As the most active Microsoft Access discussion forum on the internet, with posts dating back more than 20 years, we have a wealth of knowledge and experience to share with you.

We're a friendly and helpful community, so don't hesitate to ask any questions you have or share your own experiences with Access. We're here to support you and help you get the most out of this powerful database program.

To get started, we recommend reading the post linked below. It contains important information for all new users of the forum:

https://www.access-programmers.co.uk/forums/threads/new-member-read-me-first.223250/

We hope you have a great time participating in the discussion and learning from other Access enthusiasts. We look forward to having you around!
 
Hi and welcome.
I am the author of the encrypted split no strings example. You can find a newer version on my website at

You can also find detailed advice on security in Access in my article

Unfortunately I don't use MySQL and am therefore almost certainly unable to assist with your request in another thread for assistance testing the security measures you have put in place.
 
Hello Orny,

I am from Amsterdam to. Iam experimenting with php api requests to get data into Access. Your question is not really clear to me. You want to inject a form into an existing accde?
Daniel.
 
Hello Orny,

I am from Amsterdam to. Iam experimenting with php api requests to get data into Access. Your question is not really clear to me. You want to inject a form into an existing accde?
Daniel.
Hi Daniel, my question is really: how safe can I make my ACCDE? And I've bene testing this by trying to break into it. What I meant with that comment about injecting a form is that I tried to break into my own ACCDE by injecting a rogue autoexec from another application. That is easy enough to do. Fortunately, it is NOT possible to inject a new rogue form into an ACCDE. Groet! Orny
 
Normally the app is split and what you are trying to protect from theft or manipulation is the data which will be in the back end

usual reason for protecting the front end is to prevent modification to forms, reports and code. Also to prevent someone from being able to discover the password to the back end or use the front end to gain access to the data. And perhaps licence management

what is left ‘out in the open’ is queries, which for me is the weak point. But easy to overcome by not placing them in the front end - keep in the back end either as a querydef or in a table, or hard coded in the front end vba.

so ‘how safe’ depends on what you want to protect, from whom, from doing what, by what means
 
Normally the app is split and what you are trying to protect from theft or manipulation is the data which will be in the back end

usual reason for protecting the front end is to prevent modification to forms, reports and code. Also to prevent someone from being able to discover the password to the back end or use the front end to gain access to the data. And perhaps licence management

what is left ‘out in the open’ is queries, which for me is the weak point. But easy to overcome by not placing them in the front end - keep in the back end either as a querydef or in a table, or hard coded in the front end vba.

so ‘how safe’ depends on what you want to protect, from whom, from doing what, by what means
It’s not hard to retrieve the backend password from the linked table connection string (as you probably know). I think that the accde hack is useless without access to the vba code and the possibility to change the forms/reports.
 
It’s not hard to retrieve the backend password from the linked table connection string (as you probably know).
totally agree - which is why I don't use linked tables when data security is a specified requirement. Not prepared to go into what I do instead:)
 
Hi Daniel, my question is really: how safe can I make my ACCDE? And I've bene testing this by trying to break into it. What I meant with that comment about injecting a form is that I tried to break into my own ACCDE by injecting a rogue autoexec from another application. That is easy enough to do. Fortunately, it is NOT possible to inject a new rogue form into an ACCDE. Groet! Orny
The article in my second link in post #3 mentions how to prevent a rogue autoexec macro having any effect
 
Normally the app is split and what you are trying to protect from theft or manipulation is the data which will be in the back end

usual reason for protecting the front end is to prevent modification to forms, reports and code. Also to prevent someone from being able to discover the password to the back end or use the front end to gain access to the data. And perhaps licence management

what is left ‘out in the open’ is queries, which for me is the weak point. But easy to overcome by not placing them in the front end - keep in the back end either as a querydef or in a table, or hard coded in the front end vba.

so ‘how safe’ depends on what you want to protect, from whom, from doing what, by what means
My back-end is MySQL and I send very small cryptic instructions over SSL, the backend does all the querying and sends JSON back to the front end, again of course over SSL. No saved queries, no local tables at all.
 
My back-end is MySQL and I send very small cryptic instructions over SSL, the backend does all the querying and sends JSON back to the front end, again of course over SSL. No saved queries, no local tables at all.
I'm not sure what the benefit of using Access is in this situation.

BTW, have you investigated MySQL Rest Service API
 
The link points to the MySQL Router REST API, which is some sort of load balancer/ HA failover router.
Yup, it's part of MySQL Router, but will work with a single instance of MySQL as well as with a replicated setup
 

Users who are viewing this thread

Top Bottom