Secure error handling
2007-05May-18
Recently I reviewed a Visual FoxPro application for security issues. This application was using a popular file encryption DLL to transparently encrypt all tables. That's actually a good thing because unencrypted DBF files allow hackers to inject code into a VFP application. Breaking encryption algorithms is a futile exercise for all standard encryption algorithms.
The DLL that defined this function hasn't been loaded. When Visual FoxPro resolves a procedure name, at last it looks for an external PRG file in the current directory. Being equipped with the name of the procedure, I created a small PRG file that merely receives a number of parameters and displays each parameter in a message box. After copying the PRG to the program directory, I launched the application again. Sure enough, one of the parameters was the password.
The lesson to learn from this is that you should never allow the user to continue after an error occurred, unless you can guarantee that the program returns to a safe point. There usually is no such point until you reached READ EVENTS. If an error happens before you got to the READ EVENTS, terminate the application immediately.
The lesson to learn from this is that you should never allow the user to continue after an error occurred, unless you can guarantee that the program returns to a safe point. There usually is no such point until you reached READ EVENTS. If an error happens before you got to the READ EVENTS, terminate the application immediately.