I have been performing penetration testing on a stock WordPress install. A persistence concern I see is that WP stores cleartext passwords within the browser memory.
To reproduce:
Login to WordPress and then log back out. Close that particular tab,
but keep Chrome open.
Create a dump file of the browser memory.
Open the dump file and search for the password, you will then see it present in clear text.
How can I prevent this from happening?
Regardless of the context of someone actually viewing the password this way, the use of a cleartext password cannot be good practice?
Ref: https://cwe.mitre.org/data/definitions/316.html
"How can I prevent this from happening?"
This is not a WordPress issue, as WordPress doesn't control the client's garbage collection. The password would disappear in short time, when the JavaScript engine would be available for this task.
"the use of a cleartext password cannot be good practice?"
The browser is passing clear text password to WordPress, this is how username-password authentication (also called basic authentication) works.
Related
Please read the whole question before saying duplicate.There are similar but this is different.
I have a website that users can post ads. Its written by using ASP.NET. So
If a user post an ad it should go through a review path.( Involving an admin )
eg: User posting an ad. Then admin log to his admin page and review the ad and then give the approve.
I developed it within the same solution file. Currently I put this page in a folder. To access it user have to type
www.test.com/admin/review.aspx
manually. Because that page is not linked from the main website. And this admin user doesn't have a user account in user account table. Note that whole site is secured with SSL.
So admin has to enter a password to enter this page. This password is hard coded( Not getting from the DB ).
So am I using the right approach? Can a hacker attack to this page?
I dont want search engines to index this page. Also what about this hard coded password method? Is it a secure way?
Is it a good way to implement this page in this domain? I have different domains for this website end with .org and .info etc. Can I use such to access my admin page?
Tell me the best and secured approach to do this. Thank you very much.
A hardcoded password is never a good idea:
Developers of the website will know the admin password for all deployments of the application.
If the password is discovered by an attacker, it cannot be easily changed.
Pre-production versions of the app will carry the same admin password as live versions.
The security of the admin page should be be based on the fact the URL is hidden. URLs are hard to keep secret as they're stored in browser and proxy logs, they are emailed, and are leaked in the referer header if links are followed or resources are used from other domains (e.g. JQuery).
Hiding the page from search engines is a good idea, however do so via the use of meta tags, not robots.txt, as robots can be viewed by anybody to determine the location of your secret pages.
Use established security methods to make your admin functionality secure:
Implement TLS/SSL so all acces is over HTTPS to mitigate Man-In-The-Middle attacks.
Implement account/IP lockout after a number of incorrect password guesses.
Use two factor authentication (e.g. Google Authenticator) to mitigate phishing attacks.
Store passwords in a DB or outsource your authentication to e..g Open ID.
If storing passwords in your DB, hash and salt them and use a slow algorithm such as bcrypt, scrypt or PDKDF2 with the highest number of iterations you can get away with.
My friend asked me to help him with his site on wordpress, he lost the wp admin panel password.
But he didn't loose the mysql login information so sirst i thought about changing the password right through phpmyadmin. I get in phpmyadmin and saw that password looks a little bit strange, like this $P$BUKCBYLJ.MmLPqlzZTw4P/rLnR.omZ.
This article helped me to create password that looks the same as passwords that already existed in mysql db passwords, so i put it in my admin's user_pass field.
But i'm still unable to log in.
Actually, when i try to access /wp-admin/, i see no standard wordpress login page
I see this
And when i fail to log in it gives me 401 and shows this page
Is it ok? What the difference between situations when standard login page shows and when this authentication alert box shows ?
Anyway, all I can think of is:
1) Online password hasher gives me wrong password,
2) You see, this authentication box says "please use your control panel password", so i think the site uses some other passwords, not passwords that are in it's db. Is it possible?
Thanks in advance!
You are seeing a Basic HTTP Authentication prompt, which is not part of WordPress - it is being sent by your webserver (likely Apache or Nginx). This provides an additional layer of security against brute force attacks as you need to "log in" to the web server before you can authenticate against WordPress.
The passwords for Basic Authentication are typically stored in .htpasswd files, and defined either in an .htaccess file or your webserver's configuration. Refer to this guide for some more information on how this is set up.
You will need to reset the Basic Authentication password in the .htpasswd file, or remove it entirely, before you can log into WordPress. Once you access the WordPress login prompt you can use the password that you have set for the user you want to login as. Options for resetting your WordPress password via SQL, phpMyAdmin, FTP, and the WP CLI can be found in the article Resetting Your Password on the WordPress site.
I've been reading around and noticed that WordPress 4.0 has a CSRF vulnerability in the wp-login.php file (https://wpvulndb.com/vulnerabilities/7691). It allows users that make the authenticated user visit a HTML file change the password for the authenticated user. As I've been running WordPress 4.0 for a while myself, I have now upgraded it and put it on localhost to try and test this vulnerability as I wanted to see how hard it actually would be to get in.
Now I have struggled across two questions: There is always a key generated at the password reset, how is that even bypassed? Plus, wouldn't I receive an email to confirm the password change?
I've tried to 'exploit' or use this vulnerability to reset the password of my own account. I created a post form, but that didn't work - always getting "you must be authenticated" - no matter what I do.
Can someone direct me to the right direction? Or provide an example? That would be really appreciated, as I don't see a way to create that on my own. I just want this for testing purposes to know the impact and if it would work at all.
Am using ASP.NET membership authentication in a small website and i just noticed some thing funny during testing. Am trying to enable user to change their login password any time they wish, i dragged a change password control to the form, i changed the password for my test account, but now all passwords are still working.
I can login with the old password as well as the new password with this particular test account. If i try with any other random characters as the new password, i cant successfully login (which OK). But if type the old password, am able to login, if i type the new password, am still able to login, am finding this very strange.
Refresh your browser and/or clear your browsing history. I've had this problem before.
I've also had this problem before (its because you are testing locally) even when you think you have cleaned browsing history, make sure you clean the cache and cookies, a few times, and then try it out. (I even open different browsers to check)
If this doesn't work (which it will) try debugging your code, or better yet grabbing the sql call using SQL profiler, which will show what you are passing, and you can try the query in your sql database and see if it returns anything.
Mostly its because you are probably testing locally tho
If a user clicks on a button that does a post (lets say it has UserName and Password in the post) and those credentials get authenticated successfully. If I did a redirect to a completely different application (so I can't carry session, etc) and I use a GET with the Username and Password in the querystring (I could even use basic encryption if that helps but regardless) and then when it gets to the page, I check to make sure it came from the page I expected it to come from, pull the values from the querystring, put them in a session variable and then do a redirect back to the same page (removing the querystring values so they can't be viewed by user). This all happens over SSL on the same server.
Can someone point out the security holes of someone intercepting the UserName and Password in this scenario?
If you are using SSL, noone can intercept the request. The problem is actually with the client itself. It's not really a good idea to put username and passwords in a GET request (even encrypted), because:
URL can be easily copied and pasted to someone else.
If a user clicks an outside link, the URL will be sent as the referrer.
XSS attacks can be used to hijack the URL.
Mehrdad already gives some problems, here are some others:
When used in a get request the username and password will be plainly visible in the users browser's history / cache.
The username / password combination will probably show up in you server logs too.
Also: think about using 'salted' hashes for the passwords instead of just storing it plaintext (if that's not the case already). Added: As Mehrdad correctly comments: ...even in case of salted hash, it's still vulnerable to replay attacks...
Edit:
#EdenMachine: I think you should google for 'Cross Site Authentication' and the likes - this will be 'somewhat' harder to implement but will (when done correctly) be done more secure (and also seamless). Example link: http://aspalliance.com/1513_Cross_Site_Authentication_and_Data_Transfer.all