Design Database
The first step is typically to create a database, unless you are using a third-party database service. When a database is created, an owner is specified to execute and create a new statement. Typically, only the owner (or superuser) has permission to manipulate objects in the database. If you want to make it available to other users, you must give them permission.
The application never uses the database owner or Superuser account to connect to the database, because these accounts can perform arbitrary operations, such as modifying the database structure (for example, deleting a table) or emptying the contents of the entire database.
You should create different database accounts for each aspect of your program and give you very limited permissions on database objects. Assign only the permissions that are required to complete its functionality, and avoid the same user being able to complete another user's business. This way, even if an attacker exploits a program vulnerability to gain access to a database, it can only do the same extent as the program.
Users are encouraged not to use all of the transaction logic in the Web application (that is, the user's script). It is best to do this at the database level with views, triggers (trigger), or rules (rule). When the system upgrades, you need to open up a new interface for the database, then you have to redo all the database client. In addition, triggers can process fields transparently and automatically, and provide useful information when debugging programs and tracking facts.
Connecting to a database
The connection is built on the SSL encryption technology to increase the security of client and server-side communication, or SSH can be used to encrypt the connection between the client and the database. If these techniques are used, it is difficult for an attacker to monitor the server's communication or obtain information from the database.
Encrypting storage Model
Ssl/ssh can protect data exchanged between the client and the server, but Ssl/ssh does not protect the data that is already in the database. SSL is just a protocol for encrypting network traffic.
If an attacker obtains a license to access the database directly (bypassing the Web server), sensitive data can be exposed or abused, unless the database itself protects the information. Encrypting data within a database is an effective way to mitigate such risks, but only a small number of databases provide these encryption capabilities.
A simple solution to this problem is to create your own encryption mechanism and then use it in a PHP program. PHP has several extension libraries to do this work, such as Mcrypt and Mhash, which contain a number of cryptographic algorithms. The script encrypts the data before inserting it into the database and decrypts it later when it is extracted.
For some really hidden data, if you do not need to exist in clear text (that is, do not display), you can consider hashing algorithm. The most common example of using hashing algorithms is to store passwords after MD5 encrypted hashes in the database instead of the original plaintext password.
Example #1 hash encryption for password fields
<?php //Store password hash $query = sprintf ("INSERT into Users (name,pwd) VALUES ('%s ', '%s ');", pg_escape_string ($ username), MD5 ($password)); $result = Pg_query ($connection, $query); Send request to verify user password $query = sprintf ("Select 1 from Users WHERE name= '%s ' and pwd= '%s ';", pg_escape_string ($username) , MD5 ($password)); $result = Pg_query ($connection, $query); if (Pg_num_rows ($result) > 0) { echo ' Welcome, $username! '; } else { echo ' authentication failed for $use Rname. '; }? >