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.
Related
I think this is not the first time someone askes this question. But I couldn't get a clear answer.
Is it possible to "hack" a cookie? For example, If someone is logged in, I create an 'user id' cookie, with value 'usr01301', and this is a reference to that user. If this user is loading the webpage, the website will check for cookies. If a 'user id' is available, the user will login with the account connected to the user id.
But, is someone able to write this cookie manually? Or change it to another ID? To be able to login with this cookie.
YES
Session Hijacking is a very real thing, and it is easy to exploit on any website that does not have good security systems in place. Using a username in a cookie is a really, really bad idea.
There are browser plugins that make it easy to edit cookies, but you can even do it using the developer console that ships with many browsers.
For that matter, you don't need a browser at all. wget can perform http requests with cookies from the command line.
predictable cookies are a bad idea. with that, anyone can predict cookie for any user existed on that website. and manually edit also possible ad there are lot of tools available o internet to do it autometically.
https://bugarena.com/single/Y7A7WOZ1520
I've been trying to come up with a way for a web app to be able to make post requests etc. to multiple WordPress sites, but i'm struggling with the authentication, issue is, I don't want to use login details as such.
I've tried using Basic, JWT etc. but they all require you to enter the username and password at some stage.
In an ideal world, I would love to just be able to store a random string somewhere in the wp-config or something, and be able to attach that as a header in the requests and have it authenticate, but I haven't been able to find anything similar, has anyone ever done anything similar to this?
I'm building a Membership site using wordpress and Membership Plugin .
The site is still on my localhost. I did some trial sign ups and it worked perfectly well. But I noticed that, I can use even a fake email address such as xyz#gmail.com or something to sign up and create an account. So that's the problem. I don't know how this will work when I moved the site to my server.
But do you guys think this is a security hole ?
And what can I do for this as a solution ?
Here's what I suggest:
On the registration page, add a field where users need to enter a special code to complete registration and make the code as an image (or at least as something robots cannot process easy). This will prevent robots from constantly signing up to new accounts with bogus information.
Next, perform basic email validation to make sure the format is correct.
Next, strip the email address the user entered and verify the domain part is correct and if it is, have your server automatically send an email to the new account holder asking him/her to return to a special section of the site where he/she enters a special registration code assigned to him/her to complete registration.
Also, to save database space (I'm assuming registration info will be stored in one), ask users to complete registration within a limited time period or they will have to start over. If the time is up then relevant data from the database can be removed. I suggest setting the time period to at least one day.
If you are unable to do this, then you may need to find a better plugin that has the functionality I described.
And whatever you do, play with the website on localhost and make as few modifications on the live server as possible. This means make all changes at once on localhost if you can then upload everything at once to the live server.
I'm thinking of creating a diagnostics page for an ASP.NET app, which would be mostly intended for admin use to get more information about the application for diagnosing problems.
Examples of the info the page might have :
System.Environment.MachineName (might be useful in web farm scenarios)
System.Environment.Version
Environment.UserName
database name
current user's session ID
Some of the info on this page might be sensitive from a security perspective.
If you've done this sort of page before, what sort of security did you put on access to this page ? .
EDIT :
I should add - occasionally it might be useful to see this page whilst logged in as a specific (i.e. real) end user. e.g. say a problem can only be reproduced when logged in as a particular user. Being able to see the diagnostics page for that user might be useful. e.g. knowing the current session ID might be helpful for debugging.
EDIT 2 :
I'm starting to think that this diagnostics page should in fact be two different pages. One to display stuff which is the same for all users (e.g. database name, CLR version), and another for stuff which can vary by session (e.g. browser info, session ID).
Then you could lock down security more for the first page.
Yes, I've added this sort of page before (and found it useful). The security was pretty simple: the page contained a password form. The server-side code checked this password against a configured value and, if correct, displayed the real content and set a value in the user's session to say that they've been authenticated as a developer, so that they're not prompted again next time.
I suppose there was also a little security by obscurity, since the URL of the page wasn't published anywhere.
I was also careful not to reveal anything really sensitive on the page. For example, it allowed viewing our application config values, but masked out anything with "password" in it - hey, if we really want to see the password we can open a remote desktop session to the server.
There's also a couple of other ways you could do this:
If your web application has user authentication, restrict access to this page by checking that the user is flagged as an administrator or belongs to some kind of admin role.
Use a simple if (Request.IsLocal) ... type check, though the downside of this is that you still have to connect to the server and browse the website locally - which might not always be possible. However, this does still have the benefit of being able to easily view key system settings.
Personally, I've used a combination of both methods where a local request always allows access, and non-local requests require an admin user - eg. if (!Request.IsLocal && !IsAdminUser()) throw new SecurityException().
Also, I'm in agreement with Evgeny - be careful not to reveal anything really sensitive on this page (such as application connection strings or passwords).
use forms authentication and setup a user or two with access to that page. that way you can change passwords and revoke access once the site is deployed.
It sounds like you want a robust solution for your error page. I would take a look at open source projects like Elmah (http://code.google.com/p/elmah/) for a good example of a robust error page which includes configurable security. To give you an idea, here is a post on configuring Elmah which takes you through setting up the security. The security I have tested allows me to use my domain credentials to login.
I have a WordPress site. Like with many WordPress sites I see people (probably robots) trying their luck at the login page every once in a while. However, for the past 2 weeks it’s been non-stop at a rate of 400-500 tries a day…
So I went ahead and took the following security measures:
Changed the login URL to something different than the regular /wp-admin.
Limit the number of login attempts per URL and also automatically block any IP trying to login with an invalid username such as “test” or “admin”.
Set up two factor authentication to make sure that even though they tried they would not manage to get in, even if they guessed the username and password.
However that didn’t seem to do much and I’m still seeing a huge number of login attempts, so next thing I did was:
Password protect the login URL itself.
And still I’m seeing the same number of login attempts… now my questions are basically 2:
How are they managing to still try their luck at the login form even if that page is password protected?
Is there anything else I can do about it?
Cloudflare offers a free entry level plan that may help reduce some of this traffic before it gets to your site. Also, their $20/month plan (as of Aug 2017) can be paired with their WordPress plugin to use their built-in WordPress rulesets. CloudFlare also has a few more settings to allow you to put a few more filters and road blocks in front of specific types of traffic.
If you do choose to use CloudFlare with WordPress, be sure you understand exactly how/if you are choosing to push content into the CloudFlare CDN (content delivery network) and how that relates to the content cache on your site.
Standard disclaimer: I have no relationship with CloudFlare except as a customer.