Admin cannot use own password to log in

[pranav_hivarekar]

This is relating from #27464.

Hello,

I was working on wordpress-3.9.2 and came across some problems. I would like you to consider this.

There is problem is 'user_pass' field. If I create a user on Install with password ---> "><iframe src=javascript:alert(1)/> . Then I am unable to login using this password. This should not happen. Error or something should be implemented.

1. In wordpress-3.9.2/wordpress/wp-admin/install.php

$admin_password = isset($_POST['admin_password']) ? trim( wp_unslash( $_POST['admin_password'] ) ) : '';

wp_unslash( $_POST['admin_password'] ) here slashed are removed.

So, it is stored some hash.

2. In wp-login.php

You have a login form. Where password is passed. Here I guess password is passed in plain text or some other filter is used.

So, user cannot login.

I wrote this to inform of differences.

Due to this, user is unable to login from login panel. As password is filtered at install.php and hash is stored but while login password is not filtered as same as install.php.

This should be fixed.
I hope you add same filter on both passwords. :)

Proof Of Concept :
==============

1. Install a new copy of wordpress-3.9.2
2. Now, set up database.
3. Then you are redirected to --> wordpress-3.9.2/wordpress/wp-admin/install.php
4. Here enter your password as ---> "><iframe src=javascript:alert(1)/>
5. Now, finish the set up.
6. Now, on login try to enter your password as "><iframe src=javascript:alert(1)/> .
7. You won't be able to login as there is difference.

I hope you patch this. :)
Questions are welcome.

Regards,
Pranav

[dd32]

This should be fixed in 3.9 already via #26573 (Fixes the handling of " and ' in passwords)

I can't reproduce this on trunk, the password "><iframe src=javascript:alert(1)/> works for me, however, it's worth noting that spaces after the password are trim()'d, so since you're probably copy-pasting it, that seems like a likely cause.

Can you reproduce this on 4.0 or trunk?

[pranav_hivarekar]

This looks to be fixed. As user can use any password. Good to see that in 4.0.

[dd32]

Duplicate of #26573.