امنیت دیتابیس در ویژوال فاکس پرو

[rezakhj]

سوال 1
آیا میتوان برای دیتابیس رمز گذاشت طوری که دیگر کسی نتواند آنرا ویرایش کند ؟ چگونه ؟

[rezaTavak]

فعلا نه.

می تونید از mdb و odbc استفاده کنید یا از mysql

[kia1349]

Code Injection
Let me make some legal remarks. Decompilation and modification of executable files is prohibited by the license agreement of most products. Additionally, most countries have laws that make decompilation illegal even if such a clause is missing from the license agreement. In Europe there are only few legal exceptions for decompilation without the permission of the intellectual property owner. Should you need to decompile or modify (patch) an application, you should, in any case, contact the owner of the rights of this application and, eventually, a lawyer specialized in this subject. 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.

Code injection means that external code is executed inside the application. That doesn't have to be a negative thing, though. A Debugger in Windows, for example, loads one of its own DLLs into the debugged application to control the flow of execution in that process. How the external code gets into the application differs.

If a FoxPro application uses a FLL to encrypt data, it's quite easy to bypass this. The FLL has to exist physically on the disk for FoxPro being able to load it. In contrast to their counterparts in DOS, the PLB libraries, FLLs cannot be included into the application and loaded from their. In most cases the FLL remains on disk and is therefore easy to manipulate. The same applies to DLL in all Windows applications. In a Windows application you could write your own DLL that provides the same functions as the original DLL. Then you could capture all function calls and forward them to the actual DLL. Creating such a DLL can be automated if the interface definition is available. Now you are in the position to capture passwords passed on to that DLL, save them and use them later as needed. To protect against such a manipulation, you should create a checksum of FLL and DLL files, for instance, using the MD5 hash algorithm. Before loading a library verify the current checksum against one embedded in your application.

In Visual FoxPro you don't have to work that hard. When calling a function Visual FoxPro searches in the current program, in procedure files, in FLLs, in API declarations, in stored procedures, as external EXEs or APPs, or external FXP's. The exact search order varies between different versions of FoxPro. In any case, though, Visual FoxPro executes a FXP in the current directory when it didn't find any other procedure of that name anywhere else. Hence, 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, then the FXP is loaded and executed.

You don't have to be that clever to get at secret data. Imagine you had encrypted all tables with a tool like Cryptor. With an external attack the user has virtually no chance of decrypting these data if you picked a good password. Inside the application, however, you give the password to Cryptor. Visual FoxPro can then read all registered files without limitation. Developers tend to use the same password for all tables which is, moreover, stored inside the application somewhere. Because of its support of file masks, usually all tables are registered at once. The only remaining protection is therefore that only approved user get into the application. You might remember from the first chapter what the probability of this is like. If all tables are registered and not those only to which the current user has access to, you only need minimal rights to have access to all data.

Sufficient is including the report designer. If a user can modify reports in an application, he can open the data environment of the report and add any arbitrary table. The report designer offers even more surprises. Not only can you open tables on the disk. In the file open dialog you may enter any name of an included table that will then be opened in read-only mode. That might be useless for regular tables.

Class libraries and forms are nothing but tables. If you know the name of a class library, you can open it in the report designer. You find that name typically in the error messages. That's another reason to encrypt error logs and to not to display more than absolutely necessary. Even if you encrypted your application with any of the available protection tools this still works. The VCX in the report designer is decrypted and unprotected (how else should VFP be able to execute it).

There are many possibilities to execute code in your Visual FoxPro application. For instance, a user could write FoxPro code into a text file and then enter the following expression in the report designer:

SCRIPTEXEC(FILETOSTR("Datei.TXT"))

In Visual FoxPro 6.0 and earlier this requires to create an FXP, but that's not really an issue. The report designer is really unreliable. Therefore either leave it out or isolate the designer into a separate application that is launched with RUN. If the report designer isn't available, what can you do to inject code into the application? The next easiest way is to run the application in the development environment. Put SET STEP ON onto an ON KEY LABEL to suspend the application at any time. 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. What we are looking for are ways to execute code that is not included into the EXE. If you can't imagine such a way here are some examples:

_STARTUP or COMMAND line in the config.FPW

Index expressions in tables

Stored procedures

Triggers

Field validation rules

Database events

Reports

External forms, classes, queries or programs

All kind of scripts that are executed by the application

Macro substitution, EXECSCRIPT(), EVALUATE() or name expressions that are not validated.

Some options are not available in all versions or the runtime libraries. For instance, the COMMAND line is ignored in the runtime version of the more recent Visual FoxPro versions. One trick, though, works almost every time. A free table used by the application is added to a database. Depending on the version of Visual FoxPro that you are using, you can now use trigger, validation rules and database events in that new database to add your own code. If you open a table in Visual FoxPro that is part of a database and you haven't opened the database yet, then Visual FoxPro kindly opens the database for you. If database events are enabled Visual FoxPro triggers the DBC_OpenData event before even the table is opened. This event can contain arbitrary code that, for instance, copies all tables into unencrypted files onto a huge removable disk.

If plain tables are insecure, OK, let's use SQL server. That secures data and your code is safe, anyway, you might think. Unfortunately, that's wrong. All class libraries, that is, VCX files, are tables. When loading a class Visual FoxPro opens them in the system data session. If you manage to execute code in the system data session, there's nothing that stops you from copying all loaded VCX files. While accessing the system data session (#0) sounds impossible at first, it's actually not a big issue. When evaluating an index expression, a field validation rule or a trigger, Visual FoxPro always activates the correct work area. Such a work area is always in a data session. All you need is a trigger in a table that Visual FoxPro opens in the system data session. As soon as Visual FoxPro starts making changes to that table, it executes the trigger code in the system data session.

The following program uses this trick to automatically copy all loaded VCX files onto the hard disk. In contrast to FXP files you cannot encrypt VCX files. Therefore they can not be protected by branding tools. VCXes extracted this way are entirely unprotected and can be decompiled by any decompiler available on the market. 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.

It's very important to notice that this is not a problem with these products. They work as advertised. The reason is simply that the code below exploits a design in Visual FoxPro against which those tools were never designed to protect. These tools prevent decompilation from the outside. For technical reasons they can't do anything against code injection. There's no way for them to distinguish good code from bad code as far as security is concerned.

*================================================= =======

* Monitor the system datasession for loaded VCX libraries

* and save them to disk.

*================================================= =======



If Version(2) == 2

Return

Endif

MessageBox("Starting...")



* Create an empty Resource file in a new database

Local lnSelect

Set Safety off

lnSelect = Select()

Select 0

Create Database ExtractVCX

USE Sys(2005) Again

Copy Structure to ExtractVCX Database ExtractVCX

Select (m.lnSelect)



* Add a trigger to the resource file

Create Trigger On ExtractVCX For Insert as ExtrVCX()

Create Trigger On ExtractVCX For Update as ExtrVCX()

Create Trigger On ExtractVCX For Delete as ExtrVCX()



Set Resource to ExtractVCX





Procedure ExtrVCX

If Set("DataSession") == 0

Activate Screen

? "..."

Local laTables[1], lnTable, lnSelect

lnSelect = Select()

For lnTable=1 to AUsed(laTables)

Select (laTables[m.lnTable,2])

If JustExt(Dbf()) == "VCX"

If not File("__"+JustFname(Dbf()))

Activate Screen

? "Extracting: "+JustFname(Dbf())

Copy To ("__"+JustFname(Dbf()))

Endif

Endif

Endfor

Select (m.lnSelect)

Endif

Return .T.

If you can modify the database, you could put this code into the DBC_OpenData event. The EXTRVCX function is called by a trigger. The trigger gets called on any write access to the resource file. That happens, for instance, when you close a report preview or a BROWSE window. Since most applications use a report designer, bets are good for you. Terminating an application, too, writes to the resource file. You might have to move EXTRVCX to a different location in this case, though, as the database might have been closed already.

[kia1349]

http://www.netlib.com/index.html

[kia1349]

و اما پیشنهاد من:
با یه برنامه باید جداول را کد کرد.اگر هدر فایل تغییر کند و خطری جدی برای جدولها نداشته باشد بهتر است تا اینکه کل جدول را بخواهیم کد کنیم
سپس جداول را به یک دیتابیس اضافه میکنیم
در یکی از ایونتهای دیتابیس که در زمان باز کردن دیتابیس اتفاق می افتد از کاربر یک کلمه رمز سوال میشود و چنانچه درست بود هدر جداول به حالت اول برگردانده شود
البته خودم امتحان نکردم فقط یک ایده بود
نظر شما چیست؟؟؟؟؟؟

[rezakhj]

ممنون آقای کیا
آیا بعد از اجرائی کردن برنامه و تحویل به مشتری دیتابیس مثل همان دیتابیس داخل خود پروژه است و قابل ویرایش است یا نه ؟
آیا شما تا حالا پروژه ای تحویل مشتری دادی و اگر دادی آیا برای امنیت دیتابیس فکری کردید؟

[rezaTavak]

دیتا بیس بعد از تحویل به صورت کد نویسی قابل تغییر است. با دستورات Alter table و...

برای امنیت عوض کردن هدر زیاد جالب نیست. چون اولا بانک فقط توسط یک نفر میتونه باز بشه و ثانیا خیلی مشکلات دیگه ای بر خواهید خورد مثلا در دستور select که باید جداول باز بشه. از سویی دیگر اگر جدولی هدر اولیه فقط عوض بشه با برنامه ای مثل winnc یا دستورات سطح پایین باز کردن فایل محتویات قابل نمایش خواهد شد.

[kia1349]

دقیقا همینطوره.مشکلات اجرائیش هم آدمو کلافه میکنه