Vous êtes sur la page 1sur 16

Security in FoxPro (protecting application and data

)
by Christof Wollenhaupt, Foxpert

Login, Logout, Knock out
Microsoft has a lot of experience and knowledge in developing secure applications and actually does so. What sounds like a failed attempt to be funny, is surprisingly true. Microsoft spent hundred of millions dollars in the research of security, has got worldwide recognized security experts and is permanently challenged by tens of thousands of security experts and its competition. This makes it even more surprising that most developers start from the ground with the security aspects of their own applications. Hence, it's obvious that security is not the primary focus of software developers. Without hesitation, they demand administrator privileges for their application and implement their own login dialog to restrict access. They write their own encryption routines to encrypt single field in a table. They spend a lot of effort to protect tables in case of power failures. For all these problems there are readily available solutions that are – almost with certainty - superior to the homemade solutions. Using the login dialog and password check I'd like to show how many security leaks a Visual FoxPro application could have. Technically, such a login dialog is very simple. The user enters user name and password. The application executes a query. Execution continues if user name and password are valid. Otherwise the application terminates, usually after a few unsuccessful attempts. That's the theory. In reality, though, there's a lot that can go wrong. Let's start with some particularities of Visual FoxPro. In the following samples I assume that the user name is stored in lcUser and the password in lcPassword. A typical password validation could look like this:
*A S S U M E :W el o c a t e dt h ec o r r e c tr e c o r di nU S E R . D B F I FN O TA L L T R I M ( U s e r . c P a s s w o r d )= =m . l c P a s s w o r d *i n v a l i dp a s s w o r d E L S E *p a s s w o r di sO K E N D I F

That looks pretty safe, doesn't it? However, what happens if lcPassword is NULL? Every expression that contains NULL is NULL itself. A condition that is NULL cannot be true, never. If an IF condition results in NULL, Visual FoxPro always executes the ELSE branch. In the sample above, the user can log on successfully, if he only knows a correct user name. In the password textbox all he needs to do is to hit CTRL+0, and Visual FoxPro assigns NULL to the Value property of the textbox. This way it's quite easy to log on as an Administrator. Check every IF command if the condition can be NULL The sample above is only dangerous if the attacker knows a valid user name. Otherwise, he wouldn't make it beyond the SEEK like that I omitted in the sample. Unfortunately, user names are often easy to guess. It's particular easy for a stranger to guess a user name if he doesn't have to enter them, but can comfortably pick one from a combobox. If then –

too. an application typically uses an ODBC query to verify the password. But if you XOR the original string with the encrypted text. the password was correct. This operator respects the current SET EXACT setting. To get at them is often easier than necessary. the password is encrypted before it's stored in a table. Comparing strings in Visual FoxPro is everything but a simple topic. the password is XORed with a secret key. If the query returns a record. or the ASCII value each character in the password is incremented or decremented by a fixed or variable value. there's no match for the password and user name entered. Up to now we only focused on the actual string comparison. are easy to find. Mostly. the encrypted password is sent across the network without further protection. =>. you get an encrypted text. all possible login names are even clearly listed. only two algorithms cover most such encryptions. l c P a s s w o r d . Either. In Windows XP or MSN Messenger. Those don't even have to be valid. With local data the opposite approach might be possible. the password is encrypted and the assembled SELECT statement is sent to the server using SQLEXEC() or REQUERY(). Whoops. SET NEAR. If two strings are considered to be equal depends on a number of factors. All accesses go to the cursor . the code above uses the = operator. Take a look at the following sample and find out how to bypass the validation routine: *A S S U M E :W el o c a t e dt h ec o r r e c tr e c o r di nU S E R . An ODBC Trace Tool or a Network Monitor can easily reveal them. especially =. l c P a s s w o r d *i n v a l i dp a s s w o r d E L S E *p a s s w o r di sO K E N D I F And. as well. especially if the same differences are used for all passwords. The default is OFF which means that the left-hand string is only compared up to the length of the right-hand string. you don't need any further explanations. Surprisingly. . the password was wrong. SET ANSI. Since Microsoft's designs have always been copied in the past it's just a matter of time to see similar login dialogs in other applications. I FA L L T R I M ( U s e r . XOR is a very popular encryption mechanism. at all! Check all string operations for unwanted side effects. on the other hand. . The addition/subtraction tricks. SET COLLATE. If you XOR the encrypted text with the secret key.T. on the client side. != and <>. too. you get back the original string. If.DBF table itself? Maybe we can open the table outside the application. #. have you been successful? Instead of using the == operator. All you need is a pair of encrypted and plain passwords. Logging on successfully is just a matter of not entering any password. c P a s s w o r d )=m . <=. no one should be surprised if passwords or other information are quickly discovered and harm is done.as demonstrated in the VFP Tastrade sample – a picture of each employee is included. <. If you XOR a string with a secret key. But what about the User. as well as various codepage related settings. In other words. if the value on the right side is an empty string. If the password is stored in clear text. If user data is stored in a SQL server. To make it easier the application might copy the user table into a cursor and decrypt it. That means. D B F l c P a s s w o r d=N V L ( m . The expression always returns . These are SET EXACT. you get… the secret key. " " ) & &l i v ea n dl e a r n . >.

very long time. he can not conclude from those of other passwords. You cannot only get the line number and error code. We all know such functions for checksum calculations. Most hash algorithms are asymmetric. he would have to invert the algorithm. Visual FoxPro contains a class library named _CRYPTAPI. The Windows CryptAPI provides functions to obtain such hash values using very secure algorithms. Never store secret information. many applications pick a default value that is comfortable to the developer or user.VCX since version 7. Unencrypted system information do not belong into an error log. On the other hand. If that ceases to be the case. at all. Visual FoxPro makes it extremely easy to collect information about the current state and environment. but information about every aspect of Visual FoxPro using L I S TS T A T U S|M E M O R Y|O B J E C T|C O N N E C T I O N S|D L L S Such information are often stored in error logs. deleting of files is one possibility to gain access to a system. that's of no use. Such a place holder is called a hash. This method is called a brute force attack. Visual FoxPro starts swapping cursors to disk as . you need to calculate the hash value for any possible password to get the opposite. That's even true if you only store the password temporarily in a procedure. but often this is possible by deleting an index tag or a file. He only has to wade through the LIST MEMORY logs to find a considerable number of passwords with no effort at all. Even if an attacker has both values. That's not only true for data. To make it easier to use this API. That's secure as long as Visual FoxPro has enough memory. Better. The solution cannot be to encrypt the password even better. In general. there are much easier approaches for Visual FoxPro based data that are discussed later in this article. The problem is the same in all cases: The encrypted password is stored in the table. but hardly secure.TMP files. and is usually the last resort as it is takes a very. You can really make a hacker happy if you store the password of the user in a variable. For that.instead of the table. To validate the password you compare the hash value of the entered password against the stored hash value in the user table. Nonetheless. brute force attacks have a 100% chance of success… if you have enough time. Suppose. if you kill VFP in the task manager or turn off the computer abnormally. The content of the password doesn't matter. In cases of an error. A hash algorithm converts a string of arbitrary length into a single number that is most likely different for different input strings. you have the following function to obtain the return value of a modal VCX form: . You can analyze these files to your heart's content. All you want to know is if the entered password matches the stored value. a place holder is just as good. While it's easy to obtain a hash value. even if he knows the algorithm that was used to obtain the password. It's much harder to cause an error just in this moment. If there's an error in an application. For good algorithms on today's computers this can be millions of billion years. To obtain a password for a known hash. you don't need the password itself. The solution must be not to save the password in the first place! But how to validate a password if it's not stored somewhere? Think about what you actually want to accomplish. but also for the contents of the memory. just place holders. though.

what happens if there's an error while loading the form? If you. Visual FoxPro uses its default value: . If you have the possibility and need these data. More and more applications.T. Hence. Don't let the user continue program execution in case of an error. You should always cancel the current function. So far. To send a query to the SQL server. How long do you need to crack the following code? l c S Q L=" S E L E C T*F R O MU s e rW H E R Ec U s e r n a m e = ' " + . The hacker therefore doesn't have to know the name of the user. this is only true if the indexed field also allows NULL values. Since . either terminate the application immediately. we focused on comparing the value. " " ) + " 'A N Dn H a s h = " + T R A N S F O R M ( N V L ( l n H a s h . That means. better encrypt error logs. If that error is ignored. could cause security issues. One variation of causing an error is S E E Kl c U s e r While SEEK can search NULL values. Visual FoxPro doesn't create the form at all. if the password is correct. Error handling is always critical. If you don't provide Visual FoxPro with a value. too. for instance. but in a SQL server database.T. In case of an error you should always think carefully about which options a user may have. In the code above. the user can login by renaming a file. in the first line and cause errors in the next two lines. too. Otherwise.l o F o r m=C R E A T E O B J E C T ( t c F o r m ) l o F o r m . l c S Q L ) > 0a n dR E C C O U N T ( " S Q L R e s u l t " ) > 0 *O K E L S E *E r r o r E N D I F . Ignoring an error can be an option during development. there're good chances that this attack results in using a privileged account. loForm would be . Admittedly. the application assembles SQL statements and often sends them with SQL Pass-Through to the SQL server. S h o w ( ) u R e t V a l=l o F o r m . 0 ) ) I FS Q L E X E C ( l n H a n d l e . is also the return value for a successful login. If you log the error. m . Since typically the first record contains a test user for the developer or the administrator. but not at runtime. N V L ( m .F. But. causing an error to bypass a security check can be called an advanced technique. do not save data in FoxPro tables. l c U s e r . this function works flawlessly every time. SEEK cancels out with an error. the record pointer is still on the first record and the password validated. uRetVal would never be defined and the RETURN line would fail. But locating the record. you shouldn't store information that aren't absolutely necessary. The following code tries to determine. u R e t V a l R E T U R Nu R e t V a l And call this function from the main program like this l l L o g i n O K=C a l l M o d a l V C X ( " f r m L o g i n " ) In your tests. bind a textbox to a table and that table doesn't exist. or use RETURN TO or TRY…CATCH at the READ EVENTS to continue execution at a predetermined point. Visual FoxPro always returns a value from a function and a procedure. though.

As we will see later.or even the developer .The password query has been replaced through a hash value query. adding a stored procedure. you only need a single point in the application to execute code to turn off most conventional security mechanisms. For security reasons. for instance. This user often has got the rights that the administrator of the application . You can precisely define who can alter the database. though. If the user can control the SQL server right from the login dialog. these features are hardly used. Additionally. " A B C D E … Z 1 2 3 4 5 6 7 8 9 0 " . In Visual FoxPro. The correct verification would be to check if exactly one record is returned. and so forth. it might be the safest solution to drop that dialog completely. " " ) . developers even use the sysadmin account provided by the SQL server. when he enters the following user name: 'o r1 = 1o r1 = 1 The resulting query always returns records. a hacker has the entire arsenal of Visual FoxPro at his hands. A hacker could create new users. For each table and each column you can specify if a user can read or write to it. adding or deleteing users. and square brackets that are used as string delimiters. the code checks if the SQL server returns records at all. Depending on the backend you can send multiple commands in a single command string. In Visual FoxPro this is the quotation mark. The . like adding a new table. such a configuration doesn't seem to be a problem as the application controls access and only the developer and the system administrator know the password. Such a constellation should have been prevented by the database. Always validate user input before using it any further. With HTML these are mostly "<" and ">" which you should remove from the input stream. Use the security mechanisms that you server offers. C H R T R A N ( c S t r i n g . " " ) The inner CHRTRAN removes all valid characters. The possibilities are not limited to altering a simple query. The remaining characters are invalid. All input values have to be validated if they are in an acceptable form. too. You have seen on the last few pages how little security that could mean. Multiple records in the result set would mean that there are multiple records for the same user and the same password. Similar problems do not only exist with SQLEXEC().needs. Often. Sometimes. EVALUATE() and SCRIPTEXEC(). In reality. the single quotation mark. In FoxPro you can easily use the CHRTRAN() function for that. The most important rule is to strip off all terminating characters. If input values are used in conjunction with these features without further validation. change passwords and execute stored procedure in one pass from the login dialog. Typically all users of the application share a common user account that has been created for the application. Another tendency of developers plays an important role in security. You can specify if records can be deleted or added. there are many possibilities to shoot oneself into the foot: macro substitution. you should focus on valid characters and remove all others: C H R T R A N ( c S t r i n g . That allows the hacker to modify the query as he wishes. Let me rephrase this for you: The only protection of the database is the login dialog of the application. Most SQL servers have a very powerful user right management system. but the user name is still inserted into the query unchanged.

If the core of your application is the database that you provided. The reason is usually a strategic decision of the management. Such a field can only be indexed on the encrypted contents. or can be very expensive at max. the program encrypts the content before each write access. When using address databases for mail merge letters. The most common security mechanisms in Visual FoxPro applications try to protect against an external attack. Due to this restriction. evil former employees or prestige-addicted script kiddies. Upon saving you quickly end up with invalid values or memo fields that are truncated to 254 characters. and there is an attack. however. no body did anything. An automatic update via FTP or sending an email in case of an error doesn't sound like an unreasonable request of customers.outer CHRTRAN uses this string to remove invalid characters from the original string. this group of users tries to user alternative applications to modify data. wants to perform a data conversion for one of your former customers. App Attack! In the previous chapter you have learned how easy it is to bypass many security mechanisms in many Visual FoxPro applications. The worst group. you have a colleague who believes to be smarter than you and feels forced to prove that. though. anymore. This trend is not as far as many papers from Microsoft want to make us believe. there's a trend to distributed applications even in the FoxPro universe. purely. already. There are two fundamental approaches to data encryption in Visual FoxPro: file and field based encryption. With the field based encryption. but at least the integration of the internet is widely a fact. this at least weakens the own position. . Reading is done the opposite way: The content of the field is passed to a decryption function. even though technically such a solution might not make sense. Or. That could be a competitor who wants to learn about the inner workings of your application or. Searching on anything else involves the decryption function and disables Rushmore. In reality. the much smaller dimensions are those that are a risk to your application. is called the "power user". if you think of terrorist activities. More and more customers want to know how secure an application is and even let developers sign that somehow. you can only search for exact matches on encrypted fields. For internal applications used by bigger companies another common request is to access the application with a browser via the intranet. To secure data developers often use an encryption library. Creating an index on the decryption function would put the clear text of the protected fields into the CDX file where they can be recovered easily. SQL server is discovered and accepted as a more reliable data storage for Visual FoxPro applications. such a user could try to avoid the cost associated with every address he uses. Of course. When the possibilities of the application are not sufficient. The frequency with which developers ask in online forums for encryption tools for application and data proofs a steadily increasing need for security. If a developer signs such a paper believing in the security of tools like Refox or Cryptor. The increasing consciousness of security issues becomes an issue especially for independent consultants. Increasingly. Someone attacking my application? Impossible! You are right. typically using Excel or Access. More over. your client might want to use that data in a different way than he is allowed to.

the function at index #224 in NTDLL. rather an administrative decision and can be performed independently of the application.DLL is the NtReadFile() function that is used to read files. There are tools designed to prevent exactly this. When now Visual FoxPro calls the NtReadFile function. as well. In the list it changes the address at position 224 to point to its own version and saves the old address in some list. or because this behavior is typical for bad programs like viruses or worms. Cryptor has its own version of NtReadFile. Depending on the Windows version. 56 Bit DES. Activating EFS is not a developer. The Domain Controller manages the keys used for encryption. there's only one tool available for FoxPro: Cryptor from XiTech. the easiest solution is the Encryption File System (EFS). but . When Windows loads a DLL it creates a list of all functions and their addresses in memory. DESX or 3DES. Depending on your needs you have multiple possibilities. When protecting the application the goal is usually to prevent that someone can decompile the application and recover the sources. For each DLL there's such a jump list. Calling the function is therefore entirely transparently and works for all utilities that run in the VFP process including third-party libraries and ActiveX controls. Since 2003 there are tools available that use a brute force attack in a reasonable time frame if part of the password is known. The application only sees decrypted data. To enable it. To read data. Such a file system comes with Windows 2000 and Windows XP. The administrator. the keys only become available when the hacker knows the administrator password. on the hard disk there are only encrypted files. some encrypted contents. For instance. as of writing this. on the other hand. or similar low-level tools. Additionally. set the file attribute "encrypted" in the file properties dialog. Cryptor has to implement it. If more than the current user should access these files. You access the file like before. Cryptor does not work together with KonXise. When creating a DLL you have to live with potential restrictions. controls file access rights. though. Nothing is perfectly secure. Cryptor has to be loaded into its own process. this is 40 Bit DES. Otherwise. Decryption of these files therefore requires the computer with the desired data. Windows EFS uses the DES algorithm. Should that happen at a write access. Cryptor. If Microsoft implements a new file access function. All products that don't produce machine code. If you want to prevent unauthorized users from reading data. Those without access cannot read any data. it takes the function pointer at position 224 and calls Cryptor this way. On that machine. A further disadvantage of these tools is that Cryptor has to modify the jump list of DLLs. decrypts all data and returns them to Visual FoxPro. and not the developer. If you need to protect data in a peer-to-peer network or you want to encrypt files before sending them to your users.File based encryption doesn't suffer from this restriction. This is the case when you launch an EXE. because encryption works transparently. even though both are from the same company. the file would be lost for ever. EFS is a good solution for internal applications running on the company network. you need the keys that are stored on the Domain Controller. Cryptor works by altering these jump lists. across a network you must have a Domain Controller. the domain controller and access as an administrator. for instance. calls the original function. some functions would return decrypted. even if they steal the hard disk and use NTFS file systems for DOS. For instance. The disadvantage is that Cryptor has to be updated for each version of Windows. though. The last one is currently considered to be quite safe and is the same used in bank transactions and ATM machines across Europe. because they either use the same trick.

com If you use a different decompiler. you can de-compile an application without problems that has been branded by other tools. There's a difference if the restored code reads P R O C E D U R E_ 1 ( _ 2 . t n P r i c e ) l n S u m=t n A m o u n t*t n P r i c e R E T U R Nl n S u m*T a x .htm http://www. Here's a list of de-compilation tools for FoxPro: product ReFox AntiPro UnFox SecurityFox Web site http://www. In the sample above. R a t e Products like Visual FoxPro.com/tools. method names.frog. In addition it's therefore necessary to add a loader program that decrypts the application and then calls the Visual . the manufacturers.home. It's important to understand that it is the responsibility of the decompiler to respect this tag. Contemporary protection tools therefore encrypt the compiled EXE. too.xitech-europe. The first approach in FoxPro was branding. though. Obfuscators try specifically to reuse names as much as possible.htm http://asm001. "crack" or "hack". Additionally. Most pages are Russian or in various Asian languages.NET the mostly used technique is obfuscation. that was not a big issue. To find them simply search Google for "Refox" in combination with words like "warez". An application treated in this manner is not recognized by Visual FoxPro anymore. In FoxPro the most common approaches are branding and encryption. Via the internet these tools are now available to all developers worldwide. _ 1 Or P R O C E D U R EL i n e T o t a l ( t n A m o u n t . methods. etc. In . That means that a brander writes a specific tag into the compiled file. etc. Java and . because they are used to resolve dependencies. are stored in clear text. you can find patches on the internet that remove these tags. are renamed so that they don't make any sense. Visual FoxPro doesn't notice this modification and can execute the application as usual. Because the only thing changed in the program is this tag. In the past when only few of such tools existed. That means that all variables. there are usually very good chances to restore the sources completely.NET are especially vulnerable for this kind of decompilation.chinaren. this tag is checked and eventually the tool refuses to decompile the code.so-called P-code are especially vulnerable for de-compilation. "_1" was used in four different places: as a procedure name.co. obfuscators alter the code in a way that it does the same.html http://www. The approaches to protect applications are different in these products. For complete protection you would have to brand your application with all tools.com/source. Additionally.uk/ReFox. a variable. If names like class names.weihong.htm http://www. but doesn't look anymore like the code produced by the compiler. an alias and a field name. know now to save passwords). _ 3 ) _ 1=_ 2*_ 3 R E T U R N_ 1 * _ 1 .taketech. like a password hash. When the same tool is used to decompile a program.cz/prod02. for instance (yes. but today developers in many countries around the world have been created decompilers that ignore other tags.

FoxPro runtime. That doesn't have to be a negative thing. Now you are in the position to capture passwords passed on to that DLL. All these tools have one thing in common: they protect the application or data against external access. To protect against such a manipulation. contact the owner of the rights of this application and. in stored procedures. Differences among the tools are if decryption happens in memory or into a file. The basic principle doesn't change. or external FXP's. Then you could capture all function calls and forward them to the actual DLL. Before loading a library verify the current checksum against one embedded in your application. Additionally. In contrast to their counterparts in DOS. for example. Code injection means that external code is executed inside the application. The exact search order varies . The FLL has to exist physically on the disk for FoxPro being able to load it. though. Should you need to decompile or modify (patch) an application. though. In a Windows application you could write your own DLL that provides the same functions as the original DLL. The Visual FoxPro application typically doesn't notice it is protected. Decompilation and modification of executable files is prohibited by the license agreement of most products. The most successful strategy for internal attacks can be summarized as Code Injection meaning that code is executed inside the application. In most cases the FLL remains on disk and is therefore easy to manipulate. just because one part is working you shouldn't expect that your application is secure. for instance. All of these tools do not protect against attacks from the inside. all of these tools do their job quite well. Visual FoxPro is extremely vulnerable for this kind of manipulation Code Injection Let me make some legal remarks. The same applies to DLL in all Windows applications. However. FLLs cannot be included into the application and loaded from their. in FLLs. loads one of its own DLLs into the debugged application to control the flow of execution in that process. When calling a function Visual FoxPro searches in the current program. in API declarations. Creating such a DLL can be automated if the interface definition is available. it's quite easy to bypass this. If a FoxPro application uses a FLL to encrypt data. if the file is additionally compressed. as external EXEs or APPs. The following explanations are meant to give you an idea of what others could do with your code and to enable you to protect against that. a lawyer specialized in this subject. using the MD5 hash algorithm. in any case. Even though there are cracks for these tools and hacker constantly try to bypass their protection or to hack their encryption algorithm. Visual FoxPro can read files encrypted with Cryptor and execute application protected with KonXise. KonXise or Armadillo. This technique is used by tools like ReFox with Level II. in procedure files. How the external code gets into the application differs. most countries have laws that make decompilation illegal even if such a clause is missing from the license agreement. you should. save them and use them later as needed. and so on. In Europe there are only few legal exceptions for decompilation without the permission of the intellectual property owner. you should create a checksum of FLL and DLL files. the PLB libraries. A Debugger in Windows. In Visual FoxPro you don't have to work that hard. A lot of new tools are currently under development or just out in their first releases. eventually.

If all tables are registered and not those only to which the current user has access to. Class libraries and forms are nothing but tables. a user could write FoxPro code into a text file and then enter the following expression in the report designer: S C R I P T E X E C ( F I L E T O S T R ( " D a t e i .0 and earlier this requires to create an FXP. you give the password to Cryptor. There are many possibilities to execute code in your Visual FoxPro application. Because of its support of file masks. but that's not really an issue. you can open it in the report designer. If the application is encrypted this isn't an option as Visual FoxPro won't recognize the EXE as a Visual FoxPro application in the IDE. stored inside the application somewhere. moreover. Developers tend to use the same password for all tables which is. however. If a user can modify reports in an application. The only remaining protection is therefore that only approved user get into the application. if you change function names in a FLL and at the same time provide an FXP with that name in the current directory of the application.FPW Index expressions in tables Stored procedures . Put SET STEP ON onto an ON KEY LABEL to suspend the application at any time. Even if you encrypted your application with any of the available protection tools this still works. Inside the application. Not only can you open tables on the disk. Sufficient is including the report designer. then the FXP is loaded and executed. With an external attack the user has virtually no chance of decrypting these data if you picked a good password. usually all tables are registered at once. Visual FoxPro can then read all registered files without limitation. Visual FoxPro executes a FXP in the current directory when it didn't find any other procedure of that name anywhere else. you only need minimal rights to have access to all data.between different versions of FoxPro. The report designer offers even more surprises. he can open the data environment of the report and add any arbitrary table. what can you do to inject code into the application? The next easiest way is to run the application in the development environment. You might remember from the first chapter what the probability of this is like. In the file open dialog you may enter any name of an included table that will then be opened in readonly mode. You find that name typically in the error messages. If you can't imagine such a way here are some examples: _STARTUP or COMMAND line in the config. Hence. though. That's another reason to encrypt error logs and to not to display more than absolutely necessary. If the report designer isn't available. In any case. T X T " ) ) In Visual FoxPro 6. If you know the name of a class library. What we are looking for are ways to execute code that is not included into the EXE. The VCX in the report designer is decrypted and unprotected (how else should VFP be able to execute it). Imagine you had encrypted all tables with a tool like Cryptor. That might be useless for regular tables. Therefore either leave it out or isolate the designer into a separate application that is launched with RUN. The report designer is really unreliable. You don't have to be that clever to get at secret data. For instance.

Depending on the version of Visual FoxPro that you are using. that's wrong. One trick. it executes the trigger code in the system data session. let's use SQL server. The following program uses this trick to automatically copy all loaded VCX files onto the hard disk. They work as advertised. you might think. that is. anyway. for instance. If database events are enabled Visual FoxPro triggers the DBC_OpenData event before even the table is opened. are tables. All class libraries. If plain tables are insecure. The reason is simply that the code below exploits a design in Visual FoxPro against which those tools were never designed to protect. * = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = . Such a work area is always in a data session. works almost every time. All you need is a trigger in a table that Visual FoxPro opens in the system data session. queries or programs All kind of scripts that are executed by the application Macro substitution. Unfortunately. VCX files. If you compiled the application with debug information that is not even necessary as the entire source code is still contained in the VCX! That's true even if you used any available encryption tool that can't be cracked externally. While accessing the system data session (#0) sounds impossible at first. When loading a class Visual FoxPro opens them in the system data session. There's no way for them to distinguish good code from bad code as far as security is concerned. Some options are not available in all versions or the runtime libraries. a field validation rule or a trigger. copies all tables into unencrypted files onto a huge removable disk. That secures data and your code is safe. When evaluating an index expression. If you manage to execute code in the system data session. As soon as Visual FoxPro starts making changes to that table. the COMMAND line is ignored in the runtime version of the more recent Visual FoxPro versions. Therefore they can not be protected by branding tools. This event can contain arbitrary code that. Visual FoxPro always activates the correct work area. For instance. A free table used by the application is added to a database. In contrast to FXP files you cannot encrypt VCX files. there's nothing that stops you from copying all loaded VCX files. then Visual FoxPro kindly opens the database for you. you can now use trigger. If you open a table in Visual FoxPro that is part of a database and you haven't opened the database yet. For technical reasons they can't do anything against code injection. OK. These tools prevent decompilation from the outside. EXECSCRIPT(). validation rules and database events in that new database to add your own code. classes. EVALUATE() or name expressions that are not validated. VCXes extracted this way are entirely unprotected and can be decompiled by any decompiler available on the market. though. It's very important to notice that this is not a problem with these products.Triggers Field validation rules Database events Reports External forms. it's actually not a big issue.

l n S e l e c t ) *A d dat r i g g e rt ot h er e s o u r c ef i l e C r e a t eT r i g g e rO nE x t r a c t V C XF o rI n s e r ta sE x t r V C X ( ) C r e a t eT r i g g e rO nE x t r a c t V C XF o rU p d a t ea sE x t r V C X ( ) C r e a t eT r i g g e rO nE x t r a c t V C XF o rD e l e t ea sE x t r V C X ( ) S e tR e s o u r c et oE x t r a c t V C X P r o c e d u r eE x t r V C X I fS e t ( " D a t a S e s s i o n " )= =0 A c t i v a t eS c r e e n ?" . writes to the resource file. . The trigger gets called on any write access to the resource file. " L o c a ll a T a b l e s [ 1 ] . T . as the database might have been closed already. . If you can modify the database.*M o n i t o rt h es y s t e md a t a s e s s i o nf o rl o a d e dV C Xl i b r a r i e s *a n ds a v et h e mt od i s k . Terminating an application. though. 2 ] ) I fJ u s t E x t ( D b f ( ) )= =" V C X " I fn o tF i l e ( " _ _ " + J u s t F n a m e ( D b f ( ) ) ) A c t i v a t eS c r e e n ?" E x t r a c t i n g :" + J u s t F n a m e ( D b f ( ) ) C o p yT o( " _ _ " + J u s t F n a m e ( D b f ( ) ) ) E n d i f E n d i f E n d f o r S e l e c t( m . * = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = I fV e r s i o n ( 2 )= =2 R e t u r n E n d i f M e s s a g e B o x ( " S t a r t i n g . for instance. bets are good for you. " ) *C r e a t ea ne m p t yR e s o u r c ef i l ei nan e wd a t a b a s e L o c a ll n S e l e c t S e tS a f e t yo f f l n S e l e c t=S e l e c t ( ) S e l e c t0 C r e a t eD a t a b a s eE x t r a c t V C X U S ES y s ( 2 0 0 5 )A g a i n C o p yS t r u c t u r et oE x t r a c t V C XD a t a b a s eE x t r a c t V C X S e l e c t( m . when you close a report preview or a BROWSE window. too. . That happens. Proactive protective . you could put this code into the DBC_OpenData event.l n T a b l e . l n S e l e c t ) E n d i f R e t u r n. Since most applications use a report designer.l n S e l e c t l n S e l e c t=S e l e c t ( ) F o rl n T a b l e = 1t oA U s e d ( l a T a b l e s ) S e l e c t( l a T a b l e s [ m . You might have to move EXTRVCX to a different location in this case. l n T a b l e . The EXTRVCX function is called by a trigger. .

you should clarify how much security is needed. is: Avoid any access from the outside. The second question covers those that have (even a theoretically) possibility to do so. In most cases it's sufficient to protect the application against decompilation using ReFox or similar tools. security measurements often lead to inconveniences for the honest user. For security issues the same is true as for all design issues. take only minutes or less if you apply them right from the beginning. That makes it much less probable that there are tools for automated attacks that Script Kiddies might use. And security costs money. On the other hand. For the code this means to use branding and encryption tools. The big question is: how paranoid you should get? No matter what you do. Once you have figured out against whom you need to protect and how effort you want to spend on that. The most important questions for you to ask are: Who could be interested in getting at my code or data? Who has got the possibility to do that? What abilities and knowledge do these persons have? With the first question you find those that have an interest in attacking your application. On the other hand it means that each attack is most likely targeted at you specifically. A hacker needs to have a certain amount of knowledge about FoxPro to compromise your application. For data this means to control access. like the competitor. So even if ReFox might not protect against all types of attack. The early in the life cycle you start thinking about it.NET applications running on IIS. That protects against the curious persons who simply have to try if the application can be decompiled or files be modified in Excel. The most common reason for security risks in applications is not the stupidity of the developer. and maybe even your application. Before you start protecting your application in many months' of work. The rule. A professional hacker won't stop that. To attack a computer that is vulnerable to this attack you don't need to know how the attack works. to encrypt data files and to ensure that the LogIn dialog is really secure. it's wrong not to use ReFox or a similar tool. actually has an interest in specifically hacking into your application. It's only a matter of time and effort.Maybe the previous pages left you with a minor bad feeling. but without these measurements your application would be completely unprotected. If you have a web shop. the cheaper it is. On the one side this means that you less likely get into a broad attack in which you just happen to be the victim by chance. everyone with internet access could potentially break into your computer. This list is neither complete. Most solutions. Security leaks in that configuration spread quickly and tools are created that use them automatically. you could go through the following list of solutions. That's different for ASP. or lots of reasons to panic NOW! This analysis doesn't have to be a professional security risk analysis if you don't work in a security relevant area. This is an important difference. just where to get the programs to perform the attack. as most applications have at least one of these security leaks. . Try to achieve secure habits. They simply exist because nobody has thought about them. there's a way round it. As a starter it's often sufficient to think about the various aspects of security. nor are these solutions fail-safe. Don't panic! Analyze the situation of your application and you might find out that there's not much of a problem. but only a limited group. the most important rule. for instance. like removing invalid characters from a string. because FoxPro is more a niche product.

All security boundaries in your data should match those of the storage system. Hence. a user should either be allowed to access all or no data in a file. That's especially easy if you use PRG files for the class definitions. the application has to control access which makes it vulnerable for code injection attacks. The only way to protect against execution of machine code is the integrated user and security management of the operating system. this is usually not an issue no matter what the design looks like since you can control access down to the field level. Restrict access to the administrator table to the administrator group on the operating system level. the names of database objects and all names belonging to a table. put these fields into a second table. For instance. If such a name is used in a string. the error message also contains the long name. If your application encounters an error. As you probably have quickly noticed. If you store data on a SQL server. you need to use simpler names. After you prevented external access through encryption and replacing names (obfuscation). you have to exclude such names from the list of #DEFINEs.H file you could define. For programs. especially if some names are contained in other names. If certain fields can only be seen by administrators. Then a hacker can't even easily use search and replace features to replace variables with clear text. there's nothing you can do.Encrypt data if you cannot trust the administrator. If you give the program and the computer out of your hands. If therefore a user decompiles your application he doesn't see the easy names on the left side. . In this case. You only have to use these possibilities! Try to collaborate with the system administrator right from the beginning to find a design that not only makes data retrieval easy. This includes all property names of VCX based classes. This way you make decompilation even easier. for example: # D E F I N E # D E F I N E # D E F I N E # D E F I N E L i n e T o t a lk f j e w a o i r u j s o i d f j h o i a s d j 9 4 2 4 h r f j s k j g f h i u 9 4 3 8 9 4 s f d h k y c v n m c x b v x c j h l n C o u n tk f j e w a o i r u j s o i d f j h o i a s d j 9 4 2 4 h r f j s k j d g f h i u 9 4 3 8 9 4 s f d h k y c v n m c x b v x c j h l n P r i c ek f j e w a o i r u j s o i d f j h o i a s d j 9 4 2 4 h r f j s k j g f h i u 9 4 3 8 9 4 s f d h k y c q v n m c x b v x c j h l n S u mk f j e w a o i r u j s o i i d f j h o i a s d j 9 4 2 4 h r f j s k j g f h i u 9 4 3 8 9 4 s f d h k y c v n m c x b v x c j h If you include this file into all your programs. as well. Use the primary key to create a one-to-one relationship. Visual FoxPro replaces the names when compiling your code. If a user is only allowed to see certain fields. Work with the administrator to limit access to data. You have to follow some rules. Pay attention when using macro substitution as the name has been replaced upon compilation and you need to use the long name to access variables. Best start with _1 and count upwards. Since you can only replace generically. In a . But you have a certain level of control over the execution of VFP code. but the slightly more complex ones on the right side. there are simply techniques to make them more secure. those names have only minor difference which makes them hard to distinguish. If your users should be able to report errors on the phone. There are some things you can't redefine. though. you could use an include file to replace names in the program with other strings. you should work on preventing that unauthorized code is executed in your application. Especially Visual FoxPro code usually offers the easiest way to access data. use [] as string delimiter instead of "" or ''. but also allows for easy maintenance. you immediately have security issue. or at least raised the bar significantly. When using DBF files the smallest unit is a file.

just like any table. especially delimiting characters. These files can be empty or contain sample data. Instead of accessing encrypted. but also SCX. To extract those from an encrypted application is significantly more difficult. too. In the development environment quit the application immediately. this EXE accesses a second data directory with test data. . Parse all expressions. too. Important algorithms therefore belong into a PRG. you must check the header for manipulations. that no settings have been changed. Especially you can redirect system files to files that are modified and included index expressions.FPW into your application as this file has precedence over external files. Libraries (FLLs) should be included and copied to disk with a random name before it is loaded.FPW file is one possibility to execute code before your application run. check the report file for manipulation like an index. This all is quite a lot of work. and copy them out as needed. Alternatively use a hash code (MD5) to determine a finger print of the file and validate this hash value every time you load the DLL. before you open it with USE. Open a database as a table and validate stored procedures if there are added database events and validation rules have been added to tables. Executing code is limited to the report designer. to execute code before the report is opened. As this hinders debugging. You rather be sure that you need that level of security. Even if the code is not visible. If the user tries to access tables through the report designer.FPW and FoxUser. immediately quit the application. Before you access a file you should ensure that it hasn't been manipulated. real data. If your application happens to notice that the environment is different from what it should look like. Never release versions that include debug code. files are easy to extract. FoxPro specific files require special attention.DBF files. All saved reports need to be checked for manipulations before they are execute in the real application environment. he fails since the COM EXE server has never decrypted the original set of tables. otherwise you risk that the application runs in the debugger. For index check the expressions. triggers. If you have to use Visual FoxPro reports. Verify all inputs before you process them. Expressions that you can't uniquely identify indicate a potential manipulation. You can be assured that someone finds out how to activate that debug mode. First of all. Remember that you can add reports to a database. you should include a Config. For tables verify the table header and if a table has been added to a database. EXECSCRIPT(). To securely use the Visual FoxPro report designer. That means. The Config. Check all calls to SQLEXEC(). etc. that no FLLs are loaded that shouldn't be loaded and that no ON KEY LABEL are active.Preventing that execution is a huge step forward to securing the application. Remove them as they might call external FXP files that perform malicious actions. create special debug versions that do not have this limitation. create a COM EXE server. that no tables are open that shouldn't be open. a hacker can still step through the code line by line and check the contents and the changes of variables and properties. VCX. Remove invalid characters from a string. EVALUATE() and the usage of macro substitution. It's best to include FRX files into the application. When checking the environment pay attention to the Config.

or use web services to access tables. but all kind of applications. should use them to search for your password. either use a SQL server. too. If you need more security. Such passwords are often vulnerable to brute force attacks. FoxPro tables are inherently insecure as the entire content can be accessed. Security is a topic we all should think about more and we will be forced think about more in the future. A lot can be done with zero to nothing efforts if you consider security right from the beginning. Usually you can't avoid that. register it only after the user entered a password and deregister it once you have checked the password. but this method increases security significantly. Don't assume that such configuration files only contain valid date. If. If a user can take an encrypted file back home. you might want to sue the violator. Before you compete with Russian or Chinese lawyers. If you could offer your application as a web service on your own machine and your client only access the web service. If you encrypt files never decrypt them longer than necessary. Passwords are another critical part. Visual FoxPro makes it attackers very easy. Usually that is only possible in the country of residence of that user. If you need to create programs. you encrypt the user table. Not only web applications are affected. it can be used to compromise your application. Such lists are used by hackers. As soon as a password is known. too. This might result in each file having a different password. Consider that one can check between hundred thousand and several millions Windows passwords per minute if one has certain hash keys from the registry. If you encounter a violation of the license agreement. encrypt them or calculate a checksum using a relatively secure algorithm such as MD5. If you have expensive algorithms you should consider not giving the binary code out of your hands. but you. hard to remember passwords with digits and special characters. very careful with that. check with your own lawyer if you can restrict sales and re-sales to countries in which you can use legal actions. Then you always have full control about who access which data. others can make changes not in your interests.Even if it's quite tempting to store certain things as VFP programs. Short passwords or passwords that have a meaning as a word are taboo. if at all. he can use a program to try all possible passwords without being disturbed. be very. Just as easy as you can change these data driven programs. use this possibility. Especially for passwords used by applications there's absolutely no reason not to use difficult. at all. . There's no better protection against decompilation. or encapsulate data access into a DCOM/COM EXE server. Tables for which a user has no rights should not be registered. A very high degree of security in a Visual FoxPro application is only possible with extremely high efforts and additional tools. In the internet there are word lists with hundred of thousands of commonly used passwords (ever wondered how some dubious web sites make their money when there content is free… after you registered with a password?). for example. Consider non-technical aspects.