I learned something new today regarding MySQL.

The use of binary operator if used in a query or as collation type in DDL can make some significant difference in the results. Generally, when we create some table in MySQL, we don’t use binary collation. For example:

CREATE TABLE students (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255) NOT NULL
)ENGINE=MYISAM CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Now Lets insert some data

INSERT INTO stduents set name = 'Prajwal Tuladhar';
INSERT INTO stduents set name = 'PrAJwal TUladhar';

If a query is run in the above table:

mysql> SELECT *
    -> FROM students
    -> WHERE name = 'Prajwal Tuladhar';
+----+------------------+
| id | name             |
+----+------------------+
|  1 | Prajwal Tuladhar |
|  2 | PrAJwal TUladhar |
+----+------------------+
2 rows in set (0.00 sec)

So, if we want case sensitive results from a case insensitive table as above:

mysql> SELECT *
    -> FROM students
    -&gt; WHERE <strong>binary</strong> name = 'Prajwal Tuladhar';
+----+------------------+
| id | name             |
+----+------------------+
|  1 | Prajwal Tuladhar |
+----+------------------+
1 row in set (0.00 sec)

Or we can just changed the collation of the table as:

ALTER TABLE `students`  DEFAULT CHARACTER SET utf8 COLLATE utf8_bin

More information about binary operator here.

Very good documentary series by BBC regarding history of gold.

• Part I
• Part II
• Part III

One of the greatest obsessions of human beings.

The recent Wordpress bug that could reset the admin password seems to have been updated in the new version of Wordpress 2.8.4. Or if you are lazy like me, you can patch that bug yourself (I’m using quite old Wordpress version).

What we need is filename called wp-login.php

Try to find the function called reset_password. If you are using version 2.8.3, then the line number should be 185. Here is the code for the function without any modification:

function reset_password($key) {
	global $wpdb;

	$key = preg_replace('/[^a-z0-9]/i', '', $key);

	if ( empty( $key ))
		return new WP_Error('invalid_key', __('Invalid key'));
	$user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE user_activation_key = %s", $key));
	if ( empty( $user ) )
		return new WP_Error('invalid_key', __('Invalid key'));

	// Generate something random for a password...
	$new_pass = wp_generate_password();

	do_action('password_reset', $user, $new_pass);

	wp_set_password($new_pass, $user->ID);
	update_usermeta($user->ID, 'default_password_nag', true); //Set up the Password change nag.
	$message  = sprintf(__('Username: %s'), $user->user_login) . "\r\n";
	$message .= sprintf(__('Password: %s'), $new_pass) . "\r\n";
	$message .= site_url('wp-login.php', 'login') . "\r\n";

	$title = sprintf(__('[%s] Your new password'), get_option('blogname'));

	$title = apply_filters('password_reset_title', $title);
	$message = apply_filters('password_reset_message', $message, $new_pass);

	if ( $message && !wp_mail($user->user_email, $title, $message) )
		die('<p>' . __('The e-mail could not be sent.') . "<br />\n" . __('Possible reason: your host may have disabled the mail()function...') . '</p>');

	wp_password_change_notification($user);

	return true;
}

Just update the 2nd line of the function with:

if ( empty( $key ) || is_array($key) )

for

if ( empty( $key ))

I know this is just a dead simple work around and upgrading to version 2.8.4 is the best option. One can expect more of these kinds of vulnerability in near future especially when using query string in default way (http://domain_name.tld/file.php?var1=value1&var2=value2).

Also have a look the way the above function is implemented in 2.8.4 and the bug is patched.

function reset_password($key, $login) {
	global $wpdb;

	$key = preg_replace('/[^a-z0-9]/i', '', $key);

	if ( empty( $key ) || !is_string( $key ) )
		return new WP_Error('invalid_key', __('Invalid key'));

	if ( empty($login) || !is_string($login) )
		return new WP_Error('invalid_key', __('Invalid key'));

	$user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE user_activation_key = %s AND user_login = %s", $key, $login));
	if ( empty( $user ) )
		return new WP_Error('invalid_key', __('Invalid key'));

	// Generate something random for a password...
	$new_pass = wp_generate_password();

	do_action('password_reset', $user, $new_pass);

	wp_set_password($new_pass, $user->ID);
	update_usermeta($user->ID, 'default_password_nag', true); //Set up the Password change nag.
	$message  = sprintf(__('Username: %s'), $user->user_login) . "\r\n";
	$message .= sprintf(__('Password: %s'), $new_pass) . "\r\n";
	$message .= site_url('wp-login.php', 'login') . "\r\n";

	$title = sprintf(__('[%s] Your new password'), get_option('blogname'));

	$title = apply_filters('password_reset_title', $title);
	$message = apply_filters('password_reset_message', $message, $new_pass);

	if ( $message && !wp_mail($user->user_email, $title, $message) )
  		die('<p>' . __('The e-mail could not be sent.') . "<br />\n" . __('Possible reason: your host may have disabled the mail() function...') . '</p>');

	wp_password_change_notification($user);

	return true;
}

The exploit is the typical example of HTTP Parameter Pollution. If you haven’t gone thru the slide, I recommed you to have a look. The problem is that HPP can not be defended by using anti-XSS functions like htmlentities() and htmlspecialchars(). The way query strings are handled by the respective web servers like Apache, IIS and so on also makes it difficult to present universal solution. In my opinion, the best way to defend againsts HPP is to enable mod_rewrite and restricting the way key/value pairs are routed in a URL.

• Your ‘Big Idea’ Sucks
• Detecting global variable leaks
• Security Religions and Risk Windows
• JavaScript based encryption using RSA - Really nice concept
• Authentication in RESTful Systems
• The notion of Stateless in REST Architecture
• How lucky is/will be President Obama
• How people over age 15 spent their time in 2008

When I try to log into Twitter and Facebook I get following messages in Chromium, but other sites seem to be working fine. I wonder there should have some link / button to add SSL exception.

My Chromium build is 3.0.198.0 (22729) running on Ubuntu 9.04.

No one’s to blame here because the application is still in alpha phase and I am quite enjoying it actually excluding some rare weird issues.

Update:

It seems like Chromium build 3.0.201.0 (23024) has solved the issue.