If I have an MS Access frontend that connects to an MS Access backend, is there a way to hide/permission block the pathway to the backend's folder such that they cannot access the backend database without severing the frontend/backend connection?
Right now I can't dedicate a server to a more "secure" form of DB or anything like that so I'm stuck with MS Access for now. I just don't want someone looking at, say, a link table path and then navigating to that folder and getting access to backend information. What might be some solutions to this?
With MS Access 2003 you can get some protection from user-level security Be very careful, the forums are full of people who have permanently lost access to their files. You should also create your own menus and compile. It is possible to disable the shiftkey open and all built-in menus, once again, this can lock you out of your file.
I know you have mentioned it, but I highly recommend that you migrate the backend to SQLExpress. The security model is much better and safer to use. SQL Express does not require a dedicated server and performs well on the desktop.
I think you can password protect your backend file.
Related
Basically there are some shared Excel files on my corporation's Sharepoint and I need local copies of It for data analysis. I am able to manually download all I need, but I need to automate this work somehow.
I'm writing this post because of issues regarding two aspects of this problem:
Microsoft Licenses: as I'm using a personal account on a corporation domain (for my work), so Microsoft won't let me setup gateways on Power Automate. I was able to create a Power Automate Flow that does exactly what I need, but my end point is messed up (can't connect to my local machine so I can create the file I need with the data from Sharepoint). I cannot acess these files with other account.
Two-factor authentication: I'm unable to use APIs with Sharepoint apparently because of this, and the authentication is something that I cannot disable due to my corporation's policies.
Any workaround is viable? I need some new ideas.
You could use PnP.PowerShell to automate this task.
For authentication issue just register an app on the target site collection and grant is access. Then use this app credentials to connect to the SharePoint site and download the files.
Reference -
To create a new app - https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/register-sharepoint-add-ins#to-register-by-using-appregnewaspx
Grant access to this app - https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs#setting-up-an-app-only-principal-with-tenant-permissions
Use this app to authenticate - https://pnp.github.io/powershell/cmdlets/Connect-PnPOnline.html#example-3
I'm fairly new at building Electron apps and I've seen a lot of examples where Electron app connects directly to a remote database (MySQL in my case) so I started wondering what the problems might be with doing it that way. My first thought was to have a remote API (built on top of Express) which would communicate with the database and Electron app (React) would just utilize that API.
Any advice? Thoughts?
Thanks.
A problem with directly connecting to the database is you have to embed the database credentials in the electron app which makes them available to anyone who wants to snoop through the code. In addition, once the credentials are exposed, you lose control over what anyone can do to your database.
This is why you would usually give the user their own credentials, have the user authenticate to a web server and then have the web server be the only one who can directly talk to the remote database. You can then completely control what happens to the database since your web server is the intermediary and the only one that actually talks to the database.
This doesn't mean that there aren't some circumstances where you might want the client to talk directly to the database as it really depends upon what you're doing, what the data is and what the risk exposure is for allowing untrusted code to directly manipulate the data in the database.
Remember, you cannot protect credentials embedded in a client. They can be discovered by the client and used for other things.
My client has asked me if it is possible to integrate his existing Microsoft Access database with his Linux shared host website. He has been keeping records of his customers' data on his local computer using Microsoft Access, but now wants to enable them to view their data online. Before I get back to him with the best approach, I wanted to ask a few questions here.
Currently it seems like I have two viable options:
a) Convert his database(s) to MySQL or similar and allow him to continue updating the databases with a web-based interface rather than the Microsoft Access desktop client.
b) Allow him to continue using Microsoft Access, and allow him to upload the updated files to a script that will parse them and then update a MySQL database.
I did some research regarding using the Microsoft Access database directly on Linux, but it seems ill-supported and not the best option.
Obviously option b would take a lot more work, but I am afraid he will resist changing from Microsoft Access to a web based alternative for updating the data. I just wanted to get some feedback before getting back to him.
So, what is the best way to integrate my client's existing MS Access database with his Linux-hosted site?
You can query a Microsoft Access database with PHP using PDO, but it probably isn't the most robust option for the web. Access is designed to be a single user database, and you will probably run into moderate to severe performance issues.
A guide on how it can be done can be found here: http://phpmaster.com/using-an-access-database-with-php/
About 7 years ago I had a similar problem, and we ended up converting the database to MySQL and let some users interact with the data via Access, which gave us a database that could be used on the web, and a familiar interface for users who refused to change to using the web, though your mileage may vary: http://dev.mysql.com/doc/refman/5.1/en/connector-odbc-examples-tools-with-access.html
Why not consider moving the tables out to something like SQL server, or use MySQL and then continue to use the Access front end on the users' desktops?
It seems to me that there is some wide spread confusion about the difference between what we call an application. An application has what we call a UI (user interface). This means you have user code, the user interface such as forms, and things like reports.
This part of the application is built using a development tool such as MS Access.
When building an application with MS, Access, or Delphi, or C++ or VB, you THEN ALSO have to choose the database system to store that data. So if you write an Application in C++, Delphi, VB or in this case MS Access you are THEN FREE to choose an appropriate database system for use with that development tool. Often people one developing application software with MS access will choose to use the default and file share based data engine called JET (or now ACE, since there is a new version that has 64 bit support and also store procedures).
In other words, you can continue to use this application, but simply link the tables to SQL server or in this case an instance of MySQL running on the web server.
So I'm not sure why there's such confusing here and people failing to distinguish between a database system you choose to work with? And that of using a tool like MS Access to build and develop software with.
I mean what's up next here? We going to call VB or c++ a database? It just seems spectacularly silly for people to not grasp and understand in our industry the difference between a database system, and that of the software development system.
I'm not sure where or why such mass confusing occurs here, but I certainly hope people are not being paid by someone or doing consulting or actually receiving billable hours on work in which the basic understanding and difference between a database and an application system is not understood! I am tempted to go off on a rant about the horrifying state of affairs and lack of education in our IT industry, but I shall refrain from doing so.
Anyway, I been using cheap low cost web hosting and deploying the MS Access applications to people's desktops for more than 10 years now. And I simply link the application to the instance of the database running on the web server. I started out doing this using MySQL, but for the last good many years I've been using SQL server (and I've only been using SQL server due to me being more comfortable with it).
So there's nothing stopping you from moving the data and tables to an instance of some type of SQL server or MySQL running on that Linux server. You can thus continue to use the Access application "as is". In this way fully 99% of the code and forms and application should continue to function without modifications. There might be a few small bits and pieces and a couple of lines of code in the application that don't work, but that shouldn't take more than a few hours of time for any experience application developer was familiar with Access as a development tool.
The beauty of such a setup is that any type of web interface you build will now instantly be seen in any of the access forms on the user's desktops. And any updates by users in Access forms and by Access VBA code will thus instantly appear on the web site because they're sharing the same database system.
So I think the best approach here is the first thing is to grasp the difference between an application built in using Access, and that of the database system you choose to use with Access.
Last but not least, Access does now have web publishing, and you can see how I change to running this Application in Access to 100% browser based in the following video:
http://www.youtube.com/watch?v=AU4mH0jPntI
However, the above does require what is called Access Web Services. And in fact it is based on a set of Web Services and a new interface that been added to Access – as such this setup would not be appropriate in this case unless one is running office 365 or SharePoint.
Commercially there are a few options. Here are a couple from Easysoft that may help when connecting from PHP-ODBC or PDO :-
The Easysoft ODBC-Access Driver, this can connect on Linux to a local access database or using Samba to an Access database on a remote Windows machine. If you were to use Samba you could access the MS Access database at the same time as other users.
The Easysoft ODBC-ODBC Bridge, this is a client server install where you put the client ODBC driver on Linux and the ODBC-ODBC Bridge ( OOB ) server on Windows. You then end up with PHP program -> OOB client -> OOB Server -> MS Access ODBC driver -> MS Access database.
Both solutions have there advantages and disadvantages but they should both fit your requirements. You can get a trial of the software from the Easysoft web site.
There is a new software tool, the CNS Media GateWay, you can use.
You can connect from any custom application or platform like Linux to MS Access, Exchange (2000 - 2013), MS SharePoint, Dynamics CRM, Dynamics NAV and many more via the CNS ODBC and JDBC driver, thus accessing, for example, the entire Exchange mailbox from your custom application.
I hope that this post helped you to answer your question.
for more info visit:
http://www.connecting-software.com
I just did something similar for a project that could not move the database out of Access and did not have the budget for a third party driver. And it was a big headache so documenting my solution here for anyone else who runs into this:
On the Linux server we can mount the Windows network drive that contains the access database and then load a table into memory using the Meza package. This was needed to know what changes we wanted to make to that table.
meza.io.read_mdb(path, table='TABLENAME')
To actually make updates in the access database, we moved the set of changes we wanted to make into a .txt file on a shared network drive (that we mounted above). Then on the Windows server we can read that file in with a Powershell script, generate the appropriate SQL in that script and execute that SQL on the Access database.
$conn = New-Object System.Data.OleDb.OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=$YOURACCESSDATABASE;Persist Security Info=False")
$conn.Open()
$transaction = $conn.BeginTransaction()
$command = $conn.CreateCommand()
$command.Transaction = $transaction
$command.CommandText = "UPDATE [table] SET [col]=#PARAMNAME"
$PARAMVAR = "Set a parameter value"
$command.Parameters.AddWithValue("#PARAMNAME",$PARAMVAR)
$command.ExecuteNonQuery()
$transaction.Commit()
In my workflow, I have the Linux python script loop and sleep waiting for the changes to be made and then the Windows Powershell script truncates the .txt file when it done making the changes which is what Linux python can check for to know when it's ready to continue.
A few notes:
Requires Microsoft Access Database Engine 2010 on the Windows server which you can download here: http://www.microsoft.com/en-us/download/details.aspx?id=13255
Powershell has to be running x86 architecture so I added this to my Powershell script:
if ($env:Processor_Architecture -ne "x86")
{ write-warning 'Launching x86 PowerShell'
&"$env:windir\syswow64\windowspowershell\v1.0\powershell.exe" -noninteractive -noprofile -file $PATHTOTHEPOWERSHELLSCRIPTYOUARECURRENTLYRUNNING' -executionpolicy bypass
exit
}
Three weeks ago, I found a list of my website's users and info on Paste Bin giving away all privacy. I ran updates and protected against SQL Injections. I also added a pre-request to save the SQL in text format in a LOG table whenever user input is required to be able to analyse any injection if my protection wasn't enough.
Then today the same post was on Paste Bin again with recent entries so I checked the LOG table to find only clean entries. Is there anything else than injections I should worry about? The web seems to give info about Injections only!
Could they have had access to the dbpassword in a php file on the server and could they have connected from and external server?
Should I change the dbpassword frequently?
Are there any solution non-script wise like hosting security plan or something like that which should be efficient enough?
I am receiving physical threats from hacked users and would really like to close this quickly...
If you're implementing your own protection against user input, you're probably doing it wrong. Most standard database libraries will give you a way of passing in parameters to queries where it will be sanitised properly, and these will have been coded with more things in mind than you're probably aware of. Reinventing the wheel in anything security-related is a bad idea!
Other things to worry about:
Password policy (strong passwords)
Access to your database server (is it firewalled?)
SSH access to your server (again, firewalled?)
Keeping all of your software up-to-date
Just to add to the other answers that you've had so far. If someone is posting the contents of your database online then you need to assume that the server(s) running the application and database have been compromised, as once they've gained initial access, it's likely that they'll have placed root-kits or similar tools onto the server to keep access to it.
As to how they got in there's a number of potential options, depending on the architecture of your solution, and it's imposssible to say which is the case without more details. Some of the more likely options options would be
SSH passwords
Administrative web apps (e.g. PHPMyAdmin) with common passwords or vulnerabilities
Access via hosting service (e.g. weak passwords on administrative login panels)
If the site is PHP based Remote File Inclusion issues are a distinct possibility
If you can I'd recommend engaging a forensics or incident response company to help you recover the data and rebuild, but failing that I'd recommend getting a backup from before the compromise and using that to rebuild the server, then ensure that all software is updated and patched and passwords are not the same as the compromised system, before bringing it online.
The best protection for this is to allow connections to the mysql database only from the machine where your application runs.
First of all, make sure, network access to the MySQL database is "need to know" - in most cases this is a simplye bind-address 127.0.0.1.
Next change the DB password, just because yes, you can (C)
Now think of this: If somebody got your DB passwd from your PHP files, you already are in deep s***t: Nothing stops him or her from just repeating that stunt! You need to audit your application for backdoors (after the fact problem) and how the guys got in there (before the fact problem). Check your apache logs for requests with unusual GET parameters - a filename in there mostly is a dead givaway.
I agree with Razvan. Also if you're running any CMS or prepackaged web pages, make sure they're the latest version. They most likely access as localhost from the web server. Hackers follow the change logs of those and every time a security patch is released, they attack published vulnerabilities on servers running the older version. It's often performed in bulk by crawlers. Odds are they have a database with your server listed as running old versions of things.
First you need to ensure that this "php file" containing the DB password(s) is not within the web root directory, otherwise they could simply access it like: http://mydomain.com/dbpassword.php.
Second, immediately change the passwords used to access your database.
Third, ensure that mysql will only accept connections from 'localhost', vs allowing connections from anywhere; '%'. And if it is a dedicated server, then you should "harden" the box and add an IP rule to IPTables where mysql access is only allowed from the server's IP. These changes would ensure that if they did get your db username/password creds, they can not access the database from a remote computer, instead they would have to exploit your application, or ssh into your server to gain access to your database.
Next, you should disable all user accounts to your site, and force them to update their passwords using a closed loop verification process. This will ensure no ongoing malicious activity is occurring with your users or their accounts.
These are just a few steps to take, there are others such as tracking local users login activity. It is possible that one of your system's user accounts has been compromised (rooted). The point is, you need to consider all points of access to your system and services therein, if you are unable to do it, it may be time to hire or contract a seasoned sysadmin to help you.
If this is shared web hosting, and another user is logged in with shell access and is able to guess the path to your web root, and the password configuration (PHP or other script) file is world readable, then the user can read it.
This is one of the most common vulnerabilities and is very easy to exploit.
If this is the case:
To correct the issue, you need to move the configuration file out of your web root folder and/or change the permissions on it so that it's not world readable, and then change your database password.
Most likely, the user would not be able to inject anything into your application.
Changing the database server so that it's only accessible locally or to your web server would do no good, since the malicious user would be on the same web server and still be able to access it.
If you did not see any malicious queries, then they are probably accessing your db via the MySQL command line (or PHPMyAdmin or other tool), and not through your application.
Enabling the general query log would allow you to see all queries in plain text in the log, but if this is shared web (and MySQL server) hosting, you probably won't be able to enable this.
This is something you may wish to report to your web host. They may be able to find the attacker and suspend their account or provide you with evidence.
i am making a project in visual basic 6 and ms-access. Its about college management system
and is a server based application. Clients can access the system in the server. But the main problem is how can i make my client use the access file located in the server computer.?? if my database file is already opened in the server computer then my clients cannot access the file in the server. Is there any another way to resolve the problem?
How can i make a database file in access so that all my clients can use it simultaneously?
Please help...
I believe you'll find your answer here.
Quoting from the MSDN article:
To prevent this behavior, you must
make sure that all users who open the
database have read, write, and create
rights for the folder in which the
database is located.
Additionally, if you are using a
security-enhanced Access database, you
must make sure that the users who open
the database also have Read permission
and Write permission on the folder
that contains the workgroup
information (.mdw) file.
I can't see any reason why clients on other computers can't open the same access database at the same time. What makes you think they can't? Can you provide more details on the problem?
That said are really sure you want be using MS Access as the DB? Why not simply use SQL Server 2008 Express? You can use either the SQL 2008 management tools to administer this DB or you can use MS Access connected to the SQL 2008 Express engine. This approach will definitely be considerable more stable and significantly faster.
Edit:
To answer your question more specifically it is possible to open an Access database exclusively which would result in your problem. Are you using ADO? What is your connection string?