View and vote on the article here: Project Spyder : Secure Data and Code Management
Project Spyder : Secure Data and Code Management| Category | | | Summary | | Information on Project Spyder. |
| | Body | What really makes Project Spyder unique is not only that it is the only project of its kind, but that unlike most PHP applications which are centered only on content management, Spyder provides a secure way to access data and manage code while leaving a lot of the actual implementation up to the user website's developers.
The core of Spyder consists of a small PHP file capable of dynamically loading modules and their metadata. Surrounding this, Spyder comes with four standard 'system' modules; the Data module, the Access module, the Secure Module Interface (SMI) module, and the Secure Data Layer (SDL) module.
The Data module is a simple data abstraction layer with the capability of caching information and running it through 'filter' networks to keep injection attacks out. It runs on the principle of plug-in 'data provider' modules, all of which need to be able to convert data from whatever their source is (e.g. SQL, a file system, or PHP Super Global Arrays) to data capable of being stored in a large 'caching tree'. Whenever data is sent to a provider for storage, or retrieved from a provider for buffering, it is passed through a network of filters customizable to each data provider. This therefore delegates data processing (such as adding and removing slashes) to the lowest level, protecting against injection attacks. It also allows for the possibility of all data going through a script being passed through encryption filters.
The role of the Access module is arguably the most important of Spyder's system modules, because it processes all of the custom designed access groups and privileges. These 'group' and 'privilege' array trees give the user the ability to create complex groups of privileges which can be set to either 'on' or 'off' through a plug-in system of access 'rules' (such as IP filters and password filters). With so many different ways to share the access between different groups, such as groups requesting other groups' access, groups giving access to other groups, and filtering access to specific privileges, the module has unlimited potential. All of this is controlled by a set of secure manipulator functions, which decide whether or not modules can modify the access trees by reading the access tree itself.
The Secure Module Interface (SMI) module is the latest addition to the system modules. It works by utilizing the access module and the module system's identification facilities to create an interface capable of giving modules control over which modules use their functions. It works on the principle of a lock and key - it defines a group of privileges for each registered module which can only be enabled by a key which a module gives to selected other modules. This is achieved by creating an access module rule that is only valid when the module's keys are defined in the 'lock' module. The lock module has been thoroughly tested to ensure that it is completely secure - that is, the only way for modules to fake other modules' keys is to guess an MD5 key. The SMI is the cornerstone behind the upcoming ?sandbox? technology.
Lastly, there is the Secure Data Layer module. This module limits access to certain files accessible by the data module with an access module group. It works through a layer on top of the standard system data module, maintaining a tree in the access module mirroring the data module. Access is then controlled through an access tree which can be created and maintained by the website admin, limiting privileges of different modules and users to accessing only certain files. Finally, through use of the SMI module, modules are forced to use the SDL instead of the system data module, while letting system modules and other trusted modules have unrestricted access through the system data module. This is the other key element behind the upcoming ?sandbox? technology.
All these modules will not only work together to provide the base of a state-of-the-art content and group management system, but also provide the basis of the innovative ?sandbox? technology. The system modules, combined with a code parser which filters out unwanted function calls from every new module when it is loaded, makes it possible to let any user run any code they want, provided that certain functions aren't called (i.e. file system and database access functions). Even then, the functionality of these functions will be enabled, albeit only selectively, to users and modules which are defined as trusted in the access database.
This gives the user the ultimate in customization! Any user will be able to load his or her own downloaded modules, or even their own home grown ones if they so choose, all in a secure framework. Some would argue that it could be done more easily by writing an entirely new scripting language in C++ (or an equivalent language), but this way, people can customize the way a website appears by writing their own code in a popular, easy to use, and useful language for which there is already a great amount of coverage for on the Internet.
So, that is Spyder. The current roadmap for Spyder dictates that the CMS system will be available by version 0.6, the groupware by 0.7, and the sandbox to be in a primitive but usable state by at least version 0.8. Version 0.4 is rapidly approaching release, and will more than likely be on the new CPC Surfsafe website upon its completion, including the first three system modules - the data module, access module and SMI. Stay tuned for updates on this!
Please direct any questions to zaydana, who will be happy to answer them. Also, don't forget to tell everyone you know who can code PHP that they can contribute to this project, and help to code a revolutionary concept that has the potential to turn the Web upside down! ;) |
|
This article was imported from zZine. (original author: Sorcer)
There are no replies to this post yet.
|