Use the Oracle 10g built-in security features for PHP

Most WEB applications today need to adopt at least some basic security policy. For example, a Web site that provides password-protected content, only Web sites with admin backend, blogs and personal magazines, E-commerce sites, intranet, and so on.

The most common design method for building these types of Web applications is to consolidate the security policy into the business logic of the Web application, whereby the application determines whether a user has access to a data in the database. In this case, the role of the database is only to store data and to provide data on request. In other words, if the WEB Application command database provides specific information, the database executes the command directly without checking the user's permissions.

In this article, you will learn how to implement application security rules at the database level with Oracle's built-in security features to improve the overall security of your application. As a spin-off benefit, implementing data access security directly in the database not only helps to improve the security of the application, but also helps reduce complexity.

Requirements for database-side security

What happens when you control data access from a WEB application? In most cases there is no problem; This is a good solution, especially when the data involved is not mission critical or top-secret. This approach is used in a number of books and online resources. In fact, a popular php/mysql book explicitly opposes the creation of more than one database user account per application because "additional users or complex permissions can reduce MySQL execution speed by checking for more information before an operation continues." That's true, but there are a few things you might consider before you give up the idea of consolidating security into database logic. Let's look at the following example.

Suppose you create a Content management system (CMS). It uses a database to store content published on a Web site. Most of the data is public, allowing anonymous Web users to read, but only editing change data. Use a single database account to access and modify records in the database and control security with PHP code by using password to protect access to pages that only administrators can access.

If the public side of the Web application suffers from an attack of SQL injection on a public search form (that is, a form that is not tightly coded), the intruder may be able to execute arbitrary SQL statements on the database objects that the public account can access. Of course, in this case, the execution of the SELECT statement does not cause any major problems, because the data is inherently public. However, because common permissions and administrative permissions use the same database account, intruders can also execute UPDATE and DELETE statements, or even delete tables from the database.

How can we prevent this from happening? The easiest way to do this is to completely limit the permissions on the public database account to modify data. Let's take a look at how Oracle solves this problem.

Basic overview of Oracle Security

Oracle databases provide WEB developers with many ways to control data access, from managing access to specific database objects, such as tables, views, and procedures, to data that controls individual rows or columns. Obviously, the discussion of each security feature or available option for Oracle is beyond the scope of this article. Here, we will not cover much detail, but only the most fundamental aspects of Oracle data Access security:

• Authentication and user accounts

• Permissions

• role

Authentication and user accounts. As with other databases, each user requesting access to Oracle (the database account) must pass validation. Validation work can be done by a database, an operating system, or a network service. In addition to Basic authentication (password validation), Oracle also supports strong validation mechanisms such as Kerberos, CyberSafe, RADIUS, and so on.

Role. An Oracle role is a well-known set of permissions. Although you can grant user account permissions directly, using roles can greatly simplify user management, especially when you need to manage a large number of users. It is highly efficient to create manageable small roles and then grant users one or more roles based on the user's security level. Not to mention how easy it is to modify permissions-simply modify the roles associated with the role, without modifying each user account.

To simplify the initial creation of a new user, Oracle has three predefined roles:

· Connect role-This role enables users to connect to the database and perform basic operations, such as creating their own tables. By default, this role cannot access other users ' tables.

· The RESOURCE role-resource role is similar to the CONNECT role, but it allows users to have more system privileges, such as creating triggers or stored procedures.

· DBA role-allows users to have all system permissions.