Comment by mikestew
5 days ago
Here’s my problem with reviving FoxPro in any form: there’s a huge security hole in the Database Container (DBC) design. For DBCs to be useful, they must be read/write to all users (there is no permissions scheme). DBCs have stored procedures that can run any FoxPro code, including Win32 calls made from the FoxPro runtime. The stored procedures are stored as plain text in a “memo” field. Do you see where this is going? With a little technical knowledge, one can modify that INSERT trigger to whatever you like. EDIT: as the DB is just files in the file system, modifications can be made using a text editor, bypassing any checks in the FoxPro runtime. FoxPro just executes what it finds in there.
My recommendation is to get rid of the DBF/DBC files and move to a SQL DB of some flavor ASAP. If you have the source code, use ODBC or OLE DB to point to a server.
Source: filed that bug over 20 years ago when I worked on the Fox team. No, it wasn’t going to get fixed without rewriting large parts of how the DB engine worked.
One of the Ohio Secretary of State's "certified" (wrong terminology, but you get the idea) voter registration databases used by various county Boards of Elections is written in VFP. The software maintains the list of voters, their addresses, and scans of signatures.
Recently it had TOTP 'MFA' added to comply with a Secretary of State mandate.
Anyone who uses the software can just open the database files directly. They're just DBF files in a shared folder on a file server. All the users have to have read/write access to the files or the application won't work.
I hang my head.
Sounds like it works as designed.
seen this exact pattern in small business FoxPro setups too, DBFs on a share are one dropped SMB connection away from a corrupted index. if you're stuck maintaining something like this the least bad move is nightly copies of the whole folder to a second box, and actually opening that copy in the app now and then instead of just checking that the file sizes match.
This is an _excellent_ example of what anyone who has been professionally responsible for backups means when they say "it's not a backup until you've restored from it, booted into it, opened the app, and accessed the data"
There's still so much software out there that is an absolute lynchpin to a business that will never have the kind of durability/compatability many take for granted. The only thing that has changed in the past 2 decades is the operating system running the VM. In 2026 they are still yelling across the office or exchanging phone calls when one has finished and signed out so that the other can sign in and pull the updates.
It often isn't taken seriously or is written off because it's a "small business", but those 2-8 people run a book of business that clears this comment thread's lifetime earnings annually.
there is no permissions scheme
If you already have full access by design, then there's no "huge security hole" either.
This is entirely how FP is supposed to work. Don't like that, don't use it.
It ships database files over the network and does that blazingly fast.
Exactly. It's not a security hole. It's just the architecture of the program.
It seems like many people have a hard time understanding this, including developers.
Any attempt to add any kind of permissions, security, etc, without addressing the nature of the architecture (that the database engine runs in the same address space / security context as the UI) misses the point.
Further along those lines, it was a different world when the code was created.
Trust was a thing back then. Spam was something that came out of a tin and was made of dead animal. And passwords were limited to eight ASCII characters.
And as such, bolting security onto something that was designed inherently to be security agnostic is going to be a recipe for failure.
2 replies →
You’re saying it’s not a 2 tier client/server app, it’s a one tier app with no intermediate API to define or enforce permissions. Fine.
But the filesystem access to read/write the db files creates a path to bypass half of that application.
Does the application checksum the db file and have any resistance to filesystem tampering? That'd be trivial to beat, I’m sure, but it’d be something.
6 replies →
Well, I had to call it something. File system DBs were a problem long before FoxPro’s DBCs, yes. Yes, it’s an architectural decision. Sharp cookies would just modify the files directly. But that would just trash data (or bump my hourly rate in the HR DB). Most of the time, “full access to data” doesn’t necessarily mean “run arbitrary code”. In this case, it does, which I don’t think folks expect, hence “hole”.
There's a category in the OWASP Top 6, called: Insecure Design.
It is top 6 in their vulnerabilities ranking.
This is definitely insecure design.
> Well, I had to call it something.
A significant weakness?
A serious limitation for modern uses / in modern environments?
2 replies →
Many of the complaints you make apply to SQLite as well?
I don't know if dBASE variants support bind variables. That isolation is really required to avoid the "Bobby Tables" effect.
https://bobby-tables.com/
I'd prefer to see the dBASE language adapted to run on SQLite files, as they are a far more profound standard.
OP never mentioned SQLite. Most SQL products support proper ACLs.
I feel good about you, and that you are a good person, through and through. We don't say that enough here.
The permissions exploits on SQLite and dBASE are identical, sad to say.
You're a good guy. I respect you.
1 reply →
The largest VFP project I worked on used MS SQL Server.
Foxpro's local DB handling was amazing at pulling down tables, doing complex bulk operations, and pushing the changes. Data transfer was fast, coding ergonomics were great. On top of the extremely low-cost UI creation, it was a no-brainer.
But expectations were changing, everybody wanted to run it everywhere. Citrix bought some time, but the writing was on the wall.
I have memories of supporting a Netware network with a custom Foxpro app used by a bunch of telemarketers in the mid 90's.
When there was application error the source code would pop up in dialog maybe a some sort of debugger and the end users would just type a bunch of crap in trying to get out of it and hit enter and save the changes and corrupt the app for everyone and it would have to be restored from backup.
Pretty sure it was Foxpro or maybe dbase, definitely wasn't MS Access as it was still a dos based client.
Very different idea about app security back then, was really nice to developed the db, GUI front end and printable reports all in single runtime though.
Actually you can use foxpro with mssql and ole, you could than even add row level security for even more security
Maybe someone can put the core FoxPro ideas on top of SQLite
If it isn't client / server architecture there's no privilege separation using SQLite either. The storage format isn't the concern. Rather, the concern is it all runs in the same OS security context.
But it is a feature... I mean Excel also runs there...
1 reply →
True. When someone on the internet sends me a vfp file... i just open it in my IE6.0 no cares given.
Could the security hole not be closed up?
Maybe there's a way to run them more securely with a wrapper.
It does make sense to try and move to a sql db of some type, and my immediate thought is if something like Postgres, with a plugin or extension or two couldn't simulate enough of Foxpro.
That, or rewriting large parts of the DB engine seem readily much more possible now with LLM driven development.
> Here’s my problem with reviving FoxPro in any form
And then it moves to the orthogonal problem:
> SQL DB
(that in fact means: An app made for end users that are not trusted by default but really are somehow that is a improper implementation of the relational model and more improper developer platform, more like wordpress, and because is mostly deployed "networked" suddenly need to worry about remote access, that is totally not the main point of old Fox/dbase apps!)
And the funny things: SQL injection is not a problem with a Fox app (use of a stringy api is a MAJOR issue that lack of a permission model)
---
As one that have long experience with FoxPro and try to revive the style, lets go to the core of the problem:
Imagine you say to a C developer:
"You can't use `fopen` and other filesystem APIs, because well you have access to to the whole filesystem"
Or even better, the user!:
"You should not own your own filesystem!"
The DB is like the filesystem, but not that dumb!
The permissions model is orthogonal. Maybe you (normal) filesystem is running on a networked deployment with access by spies with and other personal that should have top-notch security.
Or is just a embedded device.
WHAT DECIDE THE SECURITY MODEl?
The kind of storage?
Nope!
Is the deployment and use case.
Similarly, what decide the security of a database?, the fact is a "database"?
No!, that is ridiculous. If you need to layer some kind of access control or whatever, is outside of the kind of storage you choses.
In fact, see how Wonderfully could be all if the "filesystem" where an actual database and you can run relational queries on top: Millions of "cli utilities" suddenly are unnecessary, the user (and developers!) have more freedom and control, and your big corp with byzantine rules will be even more happy.
----
P.D: I'm very well aware of the limitations of Fox, is ancient software! but the style of programming? Is like have a taste of start trek
P.D.2: And note that the vector attack described here is a fault of the dumb filesystem, actually!
Thanks, this is the most useful comment here. FoxDev reads the DBC the same way VFP does, so today it inherits the hole exactly. The runtime is actually the one place it can be fixed. I would put in a hash of the stored procedure text into the built executable and refuse to run a container whose procs don't match. Adding it to the list. Would you mind if I quoted your comment in the issue?
Feel free to quote me, contact info in profile if needed.
EDIT: sorry, I originally just skimmed your comment. I was unclear in my original comment: the files can be accessed and “hacked” from the file system with a text editor. (And a bunch of deleted stuff because I misread your comment.)
> FoxPro just executes what it finds in there.
Perfect. I'm looking for a program that executes everything it reads. You've tracked a 20-year-old security bug for FoxPro? That's gnarly. What if, instead of reviving FoxPro, we summon a new type of DOS with no security model to begin with? FoxPro was always better that way.
Hear me out. So, you have your regular computer on your desk, right? I call that the REAL SECURITY computer for REAL WORK: You know, your typical choice of Windows 11, Apple, or Linux. The biggest names in security. The names we trust. Real work. Real computers. Real security.
Next to it sits FoxPro, running new DOS on a separate computer with no security model at all.
Here's the ergonomics. You press your hands against your desk and push your office chair off like a boat, gliding away from the SECURE COMPUTER in the REAL WORLD toward FoxPro. FoxPro reads everything and executes with religious zeal.
- written from my treadmill. edit: fix typos