WordPress.org

Ready to get started?Download WordPress

Forums

How secure is wordpress? (9 posts)

  1. coolsti
    Member
    Posted 9 years ago #

    Hi,
    due to the insistance of a colleague, I installed wordpress on our intranet for him to use for presentation of his results. I am considering also using wordpress since it has a lot of features that I haven't (yet) built into my own home-brew php code for database access.
    However, looking at the way WordPress is structured, it is very different from the way I would have coded things, and I have some concerns regarding security. Maybe someone can comment on this?
    Firstly, I write all my code such that only short files containing basically require directives only are located in the http document tree, so no accident on my part should result in my php code being dumped to a browser, and the chances of my php scripts being overwritten by a hacker without my noticing it remain small. My php code is located away from the doc tree with appropriate safe permissions set so it would be hard to overwrite or directly see them. To do this, I generally have only one URL that accesses an entire database-site, and use a hidden variable to determine which part of the code the user is going to on the next request. But WordPress does not appear to be developed with this in mind. I am wondering how difficult it would be to move most of the code off the document tree. Has anyone tried this?
    Another thing is that WordPress does not appear to be using SESSION variables, and carries all the session identification in a cookie, including the md5 encrypted password. In my case, we authenticate against a Windows server, and the function I use for that needs the password un-encrypted (but it sends it over to the server in its own encrypted form for verification) - I am using smb_validate. So in order to use WordPress, I need to remove the password check after log-in, because I cannot verify using the md5 encrypted password stored in the cookie, and it would be a big no-no to pass around an unencrypted password there. I'm concerned about the security of my modification - of course I left the cookie itself intact, but haven't looked into yet how much else is checked. I am also concerned about how secure this way of doing things are anyway - my colleague tells me that if he reopens a closed browser without logging out, he is still logged in (bad for shared computers!). In my code, my cookie is tied to that and only that browser window - close the window and you are effectively logged out.
    Any comments on this would be welcome!
    Steve, Denmark

  2. NuclearMoose
    Member
    Posted 9 years ago #

    I appreciate that you would have coded things differently, but your perspective is based on a limited internal user base with your intranet. WP wasn't created for intranets, but I have no reason to believe that it couldn't be readily adapted to work in that fashion. If your intranet users have their own profiles (assuming an XP-like environment) then you issue is with your users moreso than anything else. People are the weakest point...you know that you can make strong security measures, but if people don't use them, then all that effort is for nothing. In this case, if people don't lock their workstations when they leave them, or at least log out of their user account/profile, then none of the application they run are secure.
    Security has been and always will be a focus with WP. The devs just did some fast work after finding out about a recent vulnerability that effected all kinds of software, and they released a minor version with the security changes added in to the core.
    As I said, I would think that WP would have to be, and could be, adapted for your uses, but there are many non-WP factors to consider as well.
    Just my $0.02.

  3. coolsti
    Member
    Posted 9 years ago #

    Hi "Just my $0.02",
    first let me say that my post was not a critic of WordPress. What I have seen so far is a fantastic piece of work, and would be very useful in certainly many areas, and that is exactly why I am interested in using it. It has many features already available that I don't yet have in my own (in comparison rather simple) application.
    It is just that I am 1) curious why things have been done this way, 2) possible implications on security and 3) whether people out there have successfully modified WP in the ways that would address the points I mentioned in my post. For example, a discussion with my company's IT support concerning "what I need to do to allow my own PHP database applications to be placed on our corporate system" resulted in one very big demand: That basically ALL of the actual php code be placed AWAY from the documentation tree, and only minor stubs with require statements remain in the doc tree. So I really do need to know if and how WP can be modified to accommodate this, or I simply won't be allowed to use it in our company (making my colleague indeed very sad, and maybe me too).
    You say that WP was not created for intranets. What was it created for? Because certainly the level of security needed for an intranet is far less than the level needed for something that is accessible from anywhere on the internet.
    Regarding the comment starting with "People are the weakest point..." , I agree with this, but I believe it is necessary to anticipate the irresponsibility or negligence of the common user and try to develop the software to cover as many situations as possible - of course within reason. For example, I know that there is a time out of the session cookie with WP, so this is ok. But I don't think it is ok that a person can close his browser window without logging out, then have another user open a new browser window and find him/herself logged on as the previous user. This is a minor risk in a small company, more of a risk in a larger company, and even more in another environment where something might be accessed from an internet cafe while travelling. Because a person will forget to punch that logout button once in a while.
    Anyway, please don't take all this for criticism - it is merely professional curiosity: why did they do it that way instead of the other way?
    Steve, Denmark

  4. OperaManiac
    Member
    Posted 9 years ago #

    WP is being user by guys like me to ZDNet! :D Only 1 security bug was discovered in the last 1 year. I had take that as pretty good record. But still... wait for more opinions. :)

  5. charle97
    Member
    Posted 9 years ago #

    go with your home grown solution. i can't think of any php based blogging systems in the market that can fulfill your requirements.

  6. Anonymous
    Unregistered
    Posted 9 years ago #

    You don't want to use sessions if your application sits on a load balanced farm that has sticky sessions turned off at the load balancer. If it's on an intranet I'd think that security is a little tighter such that your coworkers won't steal each others cookies to find their passwords ;)

  7. coolsti
    Member
    Posted 9 years ago #

    To the last poster, I have only developed for our intranet so I am not sure about what you mean regarding the disadvantages of sessions in another environment. I agree that it would be unexpected for co-workers to go around sniffing cookies to get a hold of passwords. But in my opinion it would be a very irresponsible thing to do to allow a password to go around as free text in a cookie anyway. In our case, the reason I am faced with this problem is because I have set things up so that WordPress login occurs with the company user's main Windows server log in password. This is to ensure that the same password expiration policy is used throughout the company, so that the user needs remember only one password, and so that the authorization is centralized (block the user's password on the main server, and the user is blocked everywhere). For this reason, it would be extremely dangerous to have this password out in the clear, intranet or not. The way I have it now, stealing a cookie from user "Bill" will allow access to Bill's session, but at least the password is no longer included.

  8. abrazell
    Member
    Posted 9 years ago #

    I am chiming in late on this but what was said about WP not intended for an intranet is that it was built for the internet where, in your instance, passwords being transmitted in plaintext would not be acceptable. I understand what you want to do to make your WP install operate on the same level as your domain and authenticate against a domain controller. That is a good and valid question -- one that I might be interested in as well. Please share any changes you make to your code in this regard. Perhaps I can implement it with a client I have in mind who wants to use WP internally but doesn't like the additonal level of authentication.
    Aaron

  9. ghettofinger
    Member
    Posted 9 years ago #

    But is it possible to use sessions? I mean, any web site can request your cookies right? If they do they have the md5 of your password, correct? As for being within a high availability enviornment, I see our point but using sessions is still possible between servers. Is anyone else concerned about this?

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.