Skip to main content
replaced http://stackoverflow.com/ with https://stackoverflow.com/
Source Link

This answer to a stackoverflow questionanswer to a stackoverflow question does a great job at explaining the attack that can get around mysqli_real_escape_string() using multi-byte character sets.

I've concluded that when running Drupal 6, we do not have to set the charset at the server level in order to be safe from the attack.

Drupal always sets the client to UTF8 (and not the GBK or BIG-5 charsets that are required for the exploit). Newer versions MySQL (> 5.1) are also not vulnerable.

HOWEVER, although Drupal is safe from this exploit, we should still follow the installation documentation which states, "The database should be created with UTF-8 (Unicode) encoding, for example utf8_general_ci.".

One helpful comment on the installation docs outlines how to create your database with UTF8 encoding, and how to ensure that UTF8 is used when performing a backup/restore:

To achieve this by the mysql command line interface use the following commands:
$ mysql -u root -p # Login
mysql> CREATE DATABASE databasename CHARACTER SET utf8; # Create with utf-8

When using mysqldump/mysql for backup/restore also force both server and client to utf8 by inserting into /etc/mysql/my.cnf:
default-character-set = utf8 # Server
skip-character-set-client-handshake # Force client

This answer to a stackoverflow question does a great job at explaining the attack that can get around mysqli_real_escape_string() using multi-byte character sets.

I've concluded that when running Drupal 6, we do not have to set the charset at the server level in order to be safe from the attack.

Drupal always sets the client to UTF8 (and not the GBK or BIG-5 charsets that are required for the exploit). Newer versions MySQL (> 5.1) are also not vulnerable.

HOWEVER, although Drupal is safe from this exploit, we should still follow the installation documentation which states, "The database should be created with UTF-8 (Unicode) encoding, for example utf8_general_ci.".

One helpful comment on the installation docs outlines how to create your database with UTF8 encoding, and how to ensure that UTF8 is used when performing a backup/restore:

To achieve this by the mysql command line interface use the following commands:
$ mysql -u root -p # Login
mysql> CREATE DATABASE databasename CHARACTER SET utf8; # Create with utf-8

When using mysqldump/mysql for backup/restore also force both server and client to utf8 by inserting into /etc/mysql/my.cnf:
default-character-set = utf8 # Server
skip-character-set-client-handshake # Force client

This answer to a stackoverflow question does a great job at explaining the attack that can get around mysqli_real_escape_string() using multi-byte character sets.

I've concluded that when running Drupal 6, we do not have to set the charset at the server level in order to be safe from the attack.

Drupal always sets the client to UTF8 (and not the GBK or BIG-5 charsets that are required for the exploit). Newer versions MySQL (> 5.1) are also not vulnerable.

HOWEVER, although Drupal is safe from this exploit, we should still follow the installation documentation which states, "The database should be created with UTF-8 (Unicode) encoding, for example utf8_general_ci.".

One helpful comment on the installation docs outlines how to create your database with UTF8 encoding, and how to ensure that UTF8 is used when performing a backup/restore:

To achieve this by the mysql command line interface use the following commands:
$ mysql -u root -p # Login
mysql> CREATE DATABASE databasename CHARACTER SET utf8; # Create with utf-8

When using mysqldump/mysql for backup/restore also force both server and client to utf8 by inserting into /etc/mysql/my.cnf:
default-character-set = utf8 # Server
skip-character-set-client-handshake # Force client

Source Link
rcourtna
  • 905
  • 6
  • 16

This answer to a stackoverflow question does a great job at explaining the attack that can get around mysqli_real_escape_string() using multi-byte character sets.

I've concluded that when running Drupal 6, we do not have to set the charset at the server level in order to be safe from the attack.

Drupal always sets the client to UTF8 (and not the GBK or BIG-5 charsets that are required for the exploit). Newer versions MySQL (> 5.1) are also not vulnerable.

HOWEVER, although Drupal is safe from this exploit, we should still follow the installation documentation which states, "The database should be created with UTF-8 (Unicode) encoding, for example utf8_general_ci.".

One helpful comment on the installation docs outlines how to create your database with UTF8 encoding, and how to ensure that UTF8 is used when performing a backup/restore:

To achieve this by the mysql command line interface use the following commands:
$ mysql -u root -p # Login
mysql> CREATE DATABASE databasename CHARACTER SET utf8; # Create with utf-8

When using mysqldump/mysql for backup/restore also force both server and client to utf8 by inserting into /etc/mysql/my.cnf:
default-character-set = utf8 # Server
skip-character-set-client-handshake # Force client