Table of Contents for
Mastering phpMyAdmin 3.4 for Effective MySQL Management

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Mastering phpMyAdmin 3.4 for Effective MySQL Management by Marc Delisle Published by Packt Publishing, 2012
  1. Cover
  2. Mastering phpMyAdmin 3.4 for Effective MySQL Management
  3. Mastering phpMyAdmin 3.4 for Effective MySQL Management
  4. Credits
  5. About the Author
  6. About the Reviewers
  7. www.PacktPub.com
  8. Preface
  9. What you need for this book
  10. Who this book is for
  11. Conventions
  12. Reader feedback
  13. Customer support
  14. 1. Getting Started with phpMyAdmin
  15. What is phpMyAdmin?
  16. Installing phpMyAdmin
  17. Configuring phpMyAdmin
  18. Installing phpMyAdmin configuration storage
  19. Upgrading phpMyAdmin
  20. Summary
  21. 2. Configuring Authentication and Security
  22. Securing phpMyAdmin
  23. Summary
  24. 3. Over Viewing the Interface
  25. Customizing general settings
  26. Character sets and collations
  27. Navigation panel
  28. Main panel
  29. User preferences
  30. Query window
  31. Summary
  32. 4. Creating and Browsing Tables
  33. Creating our first table
  34. Inserting data manually
  35. Browse mode
  36. Profiling queries
  37. Creating an additional table
  38. Summary
  39. 5. Changing Data and Structure
  40. Changing table structure
  41. Summary
  42. 6. Exporting Structure and Data (Backup)
  43. Exporting a database
  44. Exporting a table
  45. Exporting selectively
  46. Exporting multiple databases
  47. Saving the export file on the server
  48. Memory limits
  49. Summary
  50. 7. Importing Structure and Data
  51. Importing SQL files
  52. Importing CSV files
  53. Importing other formats
  54. Reading files from a web server upload directory
  55. Displaying an upload progress bar
  56. Summary
  57. 8. Searching Data
  58. Performing a complete database search
  59. Stopping an errant query
  60. Summary
  61. 9. Performing Table and Database Operations
  62. Changing table attributes
  63. Emptying or deleting a table
  64. Renaming, moving, and copying tables
  65. Performing other table operations
  66. Multi-table operations
  67. Database operations
  68. Summary
  69. 10. Benefiting from the Relational System
  70. Defining relations with the relation view
  71. Defining relations with the Designer
  72. Benefiting from the defined relations
  73. Column commenting
  74. Summary
  75. 11. Entering SQL Statements
  76. The Query window
  77. Multi-statement queries
  78. Pretty printing (syntax highlighting)
  79. The SQL Validator
  80. Summary
  81. 12. Generating Multi-table Queries
  82. Exploring column criteria
  83. Generating automatic joins (internal relations)
  84. Executing the query
  85. The visual builder
  86. Summary
  87. 13. Synchronizing Data and Supporting Replication
  88. Supporting MySQL replication
  89. Summary
  90. 14. Using Query Bookmarks
  91. Creating bookmarks
  92. Recalling bookmarks from the bookmarks list
  93. Passing a parameter to a bookmark
  94. Summary
  95. 15. Documenting the System
  96. Generating relational schemas
  97. Summary
  98. 16. Transforming Data using MIME
  99. Enabling transformations
  100. Examples of transformations
  101. Summary
  102. 17. Supporting Features Added in MySQL 5
  103. Supporting routines—stored procedures and functions
  104. Executing code with triggers
  105. Using information_schema
  106. Partitioning
  107. Exploring the event scheduler
  108. Summary
  109. 18. Tracking Changes
  110. Prerequisites
  111. Principles
  112. Initiating tracking for one table
  113. Testing the tracking mechanism
  114. Determining tracking status
  115. Structure snapshot
  116. Exporting a version
  117. Creating a new version
  118. Deleting tracking information
  119. Summary
  120. 19. Administrating the MySQL Server
  121. Database information
  122. Server information
  123. Summary
  124. A. Troubleshooting and Support
  125. Seeking support
  126. Contributing to the project

Securing phpMyAdmin

Security can be examined at the following various levels:

  • How we can protect the phpMyAdmin installation directory
  • Which workstations can access phpMyAdmin
  • The databases that a legitimate user can see

Protecting phpMyAdmin at directory level

Suppose an unauthorized person is trying to use our copy of phpMyAdmin. If we use the simple config authentication type, anyone knowing the URL of our phpMyAdmin will have the same effective rights to our data as we do. In this case, we should use the directory protection mechanism offered by our web server (for example, .htaccess, a file name with a leading dot) to add a level of protection. More details are available at http://en.wikipedia.org/wiki/Basic_access_authentication.

If we decide on using http or cookie authentication types, our data would be safe enough. However, we should take normal precautions with our password (including its periodic change).

The directory where phpMyAdmin is installed contains sensitive data. Not only the configuration file but also all scripts stored there must be protected from alteration. We should ensure that apart from us, only the web server effective user has read access to the files contained in this directory, and that only we can write to them.

Note

phpMyAdmin's scripts never have to modify anything inside this directory, except when we use the Save export file to server feature (explained in Chapter 6).

Another recommendation is to rename the default phpMyAdmin directory to something less obvious; this discourages probing of our server. This is called security by obscurity and can be very effective—but avoid choosing other obvious names such as admin.

Another possible attack is from other developers having an account on the same web server as we do. In this kind of attack, someone can try to open our config.inc.php file. As this file is readable by the web server, someone could try to include our file from their PHP scripts. This is why it is recommended to use PHP's open_basedir feature, possibly applying it to all directories from which such attacks could originate. More details can be found at http://php.net/manual/en/ini.core.php#ini.open-basedir.

Displaying error messages

phpMyAdmin uses the PHP's custom error-handler mechanism. One of the benefits of this error handler is to avoid path disclosure, which is considered a security weakness. The default settings related to this are:

$cfg['Error_Handler'] = array();
$cfg['Error_Handler']['display'] = false;

You should let the default value for display be false, unless you are developing a new phpMyAdmin feature and want to see all PHP errors and warnings.

Protecting with IP-based access control

An additional level of protection can be implemented, this time verifying the Internet Protocol (IP) address of the machine from which the request is received. To achieve this level of protection, we construct rules allowing or denying access, and specify the order in which these rules will be applied.

Defining rules

The format of a rule is:

<'allow' | 'deny'> <username> [from] <source>

The from keyword being optional; here are some examples:

Rule

Description

allow Bob from 1.2.3/24

User Bob is allowed from any address matching the network 1.2.3 (this is CIDR IP matching, more details at http://en.wikipedia.org/wiki/CIDR_notation).

deny Alice from 4.5/16

User Alice cannot access when located on network 4.5.

allow Melanie from all

User Melanie can log in from anywhere.

deny % from all

all can be used as an equivalent to 0.0.0.0/0, meaning any host. Here, the % sign means any user.

Usually we will have several rules. Let us say we wish to have the following two rules:

allow Marc from 45.34.23.12
allow Melanie from all

We have to put them in config.inc.php (in the related server-specific section) as follows:

$cfg['Servers'][$i]['AllowDeny']['rules'] =
array('allow Marc from 45.34.23.12', 'allow Melanie from all');

When defining a single rule or multiple rules, a PHP array is used. We must follow its syntax, enclosing each complete rule within single quotes and separating each rule from the next with a comma. Thus, if we have only one rule, we must still use an array to specify it. The next parameter explains the order in which rules are interpreted.

Order of interpretation for rules

By default, this parameter is empty:

$cfg['Servers'][$i]['AllowDeny']['order'] = '';

This means that no IP-based verification is made.

Suppose we want to allow access by default, denying access only to some username/IP pairs, we should use:

$cfg['Servers'][$i]['AllowDeny']['order'] = 'deny,allow';

In this case, all deny rules will be applied first, followed by allow rules. If a case is not mentioned in the rules, access is granted. Being more restrictive, we would want to deny by default. We can use:

$cfg['Servers'][$i]['AllowDeny']['order'] = 'allow,deny';

This time, all allow rules are applied first, followed by deny rules. If a case is not mentioned in the rules, access is denied. The third (and most restrictive) way of specifying rules order is:

$cfg['Servers'][$i]['AllowDeny']['order'] = 'explicit';

Now, deny rules are applied before allow rules. A username/IP address pair must be listed in the allow rules and must not be listed in the deny rules, for access to be granted.

Blocking root access

As the root user is present in almost all MySQL installations, it's often the target of attacks. A parameter permits us to easily block all phpMyAdmin logins of the MySQL's root account, using the following:

$cfg['Servers'][$i]['AllowRoot'] = FALSE;

Some system administrators prefer to disable the root account at the MySQL server level, creating another less obvious account possessing the same privileges. This has the advantage of blocking root access from all sources, not just from phpMyAdmin.

Protecting in-transit data

HTTP is not inherently immune to network sniffing (grabbing sensitive data off the wire). So, if we want to protect not only our username and password but all the data that travels between our web server and browser, then we have to use HTTPS.

To do so, assuming that our web server supports HTTPS, we just have to start phpMyAdmin by putting https instead of http in the URL as follows:

https://www.mydomain.com/phpMyAdmin/

If we are using PmaAbsoluteUri auto-detection, shown as follows:

$cfg['PmaAbsoluteUri'] = '';

phpMyAdmin will see that we are using HTTPS in the URL and react accordingly.

If not, we must put the https part in this parameter as follows:

$cfg['PmaAbsoluteUri'] = 'https://www.mydomain.com/phpMyAdmin';

We can automatically switch users to an HTTPS connection with the following setting:

$cfg['ForceSSL'] = TRUE;