The ability to bypass application security using UniObjects has really got me thinking. In the absence of any suitable remedies and perhaps as a stop gap solution whilst a better solution is written, I would recommend the following:
1. As Martin said, make sure that you do not let UniObjects traffic through your firewall. This cuts down the threat from outside but many hacks come from employees who are disgruntled or just plain nosey. 2. If you don't require UniObjects on all PCs then don't install it. If you do require it, don't install the documentation that gives the user a sample application to copy. Change the standard port used by UniObjects and don't advertise it. 3. Consider an architecture where the UniObjects client is a separate server (e.g. web server or Citrix server) and users don't require the UniObjects DLLs on their own client. This is also easier to maintain when you upgrade. 4. In addition to application security, make use of OS security. For example, if your HR system is only used by a handful of people, don't give all your users access to the data files and rely on the application security to keep them away. If they have to steal a password as well as write a VBA program, it is harder than just writing a VBA program. 5. Don't hard code usernames and passwords into your source code! They can be seen in the object code of any application. 6. Keep an eye on logs and look out for unusual behaviour. Can anyone help me with this? What logs are written to when someone logs in and can you distinguish between a telnet login and a UniObjects login? The reason it got me thinking was because I am guilty on a number of these points :-> so thanks for the question! Regards, Rob Wills (rob dot wills at tigerinfotech dot com) ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
