How difficult/easy is it to break into Joomla backend & to access the pages which are only set to be accessible by selected Joomla users of the website? Is it safe enough to rely on Joomla's management system?
Yes, Joomla is quite secure system by itself. Although you have to be careful with third party extensions and always track update news for all components (including core) you have installed and use your judgement about updating them. Usually security issues spotted quite quickly and you have time before succeed attack.
Another thing keep in mind is proactive defense with all possible means you have in hands, this includes .htaccess and .htpasswd, also good idea to restrict ftp access to only local ips and use sftp instead.
Also check out the security extensions around JED, the ones which prevents high level DDoS and extend admin page access protection might be also helpful, usually they are simple modules or plugins.
And yes, do not forget change default username for superuser. And change all passwords ftp/superusers/mysql/htpasswd on regular basis.
Follow this simple rules and you will be fine, at least most of the time you will be fine.
While Joomla security is fairly good, you need to keep up with the patches and, as dmi3y mentioned, you need to watch the third party extensions.
When it comes to information security, nothing is ever perfect. This solution may or may not be appropriate depending on the type of information that you are looking to secure, the number of users accessing it and how you manage the user rights.
Related
I have been building quite a few MVC based websites locally and am finally ready to deploy the first, but, I am getting rather nervous.
During testing, I noticed several things that worried me - I am using the default forms authentication with a few tweaks (although nothing to the underlining security).
I noticed that if I created a user in one application and logged in, then launched another application... it would keep me logged in* as the user from the previous application. The user doesn't even exist in the new application!
* - I used [Authorize] on controllers, and was surprised I could just get straight in without any sort of authentication
I assume it is because the cookie is being set for localhost instead of the application/port (although, not too much I can do about this in development).
Based on this, how secure is the default authentication?
1. Is there anyway to check from the code that the user doesn't have a "faked" cookie? / Check the user has logged in from my application?
2. I was just wondering if there are any sort of check lists or anything I can go through before deploying?
Sort of - 3.As of writing this, For question 1. I am guessing I could add a column with a random number that is saved to the cookie, and then that number is checked every time any authentication is done... however, I did not want to start mucking around with the membership provider... but I think this could work. Is this a good idea?
Try using IIS on your machine instead of VS Dev Server. Solves your problem 1.
Other than that I don't think you will need any extra effort to make default membership mechanisms of asp.net to make more secure if of course you don't need a real custom things to do in your projects. These things are around for a while now and I think they have been well tested in terms of security.
You just need to remember to put [Authorize] attribute to right places. If not on your controllers put them to right methods.
Basic Web Authentication shouldn't be trusted for applications which contain truly sensitive information. That being said it's sufficient for most applications. Be sure to check your application as often as possible before and after release for XSS vulnerabilities.
Here is Microsoft's recommended "Secure yourself" list. http://msdn.microsoft.com/en-us/library/ff649310.aspx
No matter how strong your authentication is, one small XSS mistake and a malicious user can do as they wish to your site, and your users data!
I recently read a good book: Worx Professional ASP.NET, it talks about these steps in more detail on securing yourself as well as exposing examples of problems. After reading this I was able to "deface and steal" my own sites information with relative ease, was a good eye opener on the importance of securing for XSS.
I was thinking of the multiple ways which security could be implemented in a Plugin-based system. Now when I say 'Security', what I mean is this:
a) How developers of a Plugin system can ensure that plugins are secure and safe to use on the Core platform.
b) How developers of a plugin can ensure that the plugins being used on their Platform are 'trustable' i.e. some sort of way by which we know 'WHO' developed this plugin ( similar to what Facebook do with their API keys )
c) How can developers control what changes a plugin makes to the UI (if this is permitted at all)? For example, a plug in that is permitted to mainpulate the UI and redirect the plugin user to certain webpages takes the user to a Phishing site.
I have my initial thoughts on the issue:
On a) I am contemplating whether the use of a Sandbox would be suffecient. Would this protect the plugin from, say, making Direct DB calls to do some naughty things? Would one be able to restrict the plugin from accessing the Local system without effectively hampering the functionality of the system? What are your ideas on this?
On b), I believe Facebook-like authentication is the way to go. But would this not be overkill for a Small Application ( 'Small' in the sense that it is smaller than Facebook or Jira)? Are there any other possible options?
On c) I will be honest and say I have no idea how this can be implemented. Any opinions out there?
So, the question is... how does one implement Security on a Plugin Architecture?
a and c are, if I understand you correctly, the same question.
You want to limit what is possible in your plug-in system, the easy answer is to go and limit the environment. Build an environment where security, the GUI and whatever you think is sacred must be protected by design, call it a sandbox, call it a very strict API, call it forcing the plug-in developers to use something which isn't a real programming language.
If it is impossible to make something look like a log-in screen, or to redirect people to other places, that's something malicious developers will have to go without.
This however makes for a rigid plug-in system where the developers have little freedom to implement new features which may not be acceptable; and people have made wrong assumptions about what is a safe operation in the past.
b Knowing who developed something requires you to ask them for and confirm personally identifying information.
At that point you can simply use an user and password over SSL, or a signing system where you become a certificate authority if your system is to be used by anyone else and you don't want the extra load of people downloading plug-ins. They can always misplace their keys but there is little you can do about that.
Won't work for a small system, though, even if you were signing for free.
The next best option is a handle where a few checked plug-ins that were legitimate means you can get your plug-ins in with less checking or with none at all.
If developers can't be bothered with registering an account either, you could always check for IP with a bit of SSL traffic to avoid spoofing and use that as their internal user name. People with dynamic IPs or behind proxies and a lot of plug-ins to send would eventually register.
Of course, this requires people that can check the plug-ins.
a) How developers of a Plugin system can ensure that plugins are secure and safe to use on the Core platform.
How do developers know anything? They don't. They must trust the framework. For open source, that means the download it and check it themselves. For proprietary, who knows how developers grow to trust the framework?
b) How developers of a plugin can ensure that the plugins being used on their Platform are 'trustable' i.e. some sort of way by which we know 'WHO' developed this plugin ( similar to what Facebook do with their API keys )
If you build a plugin framework, you don't know anything about the plugins. A plug-in framework can have "good" plug-ins and "bad" plug-ins. But who decides good or bad? The users do. If a plug-in is "good", it's useful and works. If a plug-in is "bad" it's useless or doesn't work. Most viruses are just useless software.
Any software can fit into the plug-in framework and still be useless. It's a value judgement, not a technical question.
c) How can developers control what changes a plugin makes to the UI (if this is permitted at all)? For example, a plug in that is permitted to mainpulate the UI and redirect the plugin user to certain webpages takes the user to a Phishing site.
Yep. Happens all the time.
What is "Phishing"? Sometimes I don't want to give out my email even to a "real" company. Are they "phishing" when they ask? Not really. What about a news source behind a registration page? I must register to get news. Is that Phishing? What about a site that promises financial information? If I register, is that phishing from the financial source or is that legitimate user registration? What if the financial information is about Nigeria? What if it's about a dead relative of mine in Nigeria?
There's no technical means for determining "good" vs. "bad" here. It's all a value judgement on the part of the user.
The "plug-in" framework can't decide anything. Only users can decide.
For the sake of simplicity I want to use admin links like this for a site:
http://sitename.com/somegibberish.php?othergibberish=...
So the actual URL and the parameter would be some completely random string which only I would know.
I know security through obscurity is generally a bad idea, but is it a realistic threat someone can find out the URL? Don't take the employees of the hosting company and eavesdroppers on the line into account, because it is a toy site, not something important and the hosting company doesn't give me secure FTP anyway, so I'm only concerned about normal visitors.
Is there a way of someone finding this URL? It wouldn't be anywhere on the web, so Google won't now it about either. I hope, at least. :)
Any other hole in my scheme which I don't see?
Well, if you could guarantee only you would ever know it, it would work. Unfortunately, even ignoring malicious men in the middle, there are many ways it can leak out...
It will appear in the access logs of your provider, which might end up on Google (and are certainly read by the hosting admins)
It's in your browsing history. Plugins, extensions etc have access to this, and often use upload it elsewhere (i.e. StumbleUpon).
Any proxy servers along the line see it clearly
It could turn up as a Referer to another site
some completely random string
which only I would know.
Sounds like a password to me. :-)
If you're going to have to remember a secret string I would suggest doing usernames and passwords "properly" as HTTP servers will have been written to not leak password information; the same is not true of URLs.
This may only be a toy site but why not practice setting up security properly as it won't matter if you get it wrong. So hopefully, if you do have a site which you need to secure in future you'll have already made all your mistakes.
I know security through obscurity is
generally a very bad idea,
Fixed it for you.
The danger here is that you might get in the habit of "oh, it worked for Toy such-and-such site, so I won't bother implementing real security on this other site."
You would do a disservice to yourself (and any clients/users of your system) if you ignore Kerckhoff's Principle.
That being said, rolling your own security system is a bad idea. Smarter people have already created security libraries in the other major languages, and even smarter people have reviewed and tweaked those libraries. Use them.
It could appear on the web via a "Referer leak". Say your page links to my page at http://entrian.com/, and I publish my web server referer logs on the web. There'll be an entry saying that http://entrian.com/ was accessed from http://sitename.com/somegibberish.php?othergibberish=...
As long as the "login-URL" never posted anywhere, there shouldn't be any way for search engines to find it. And if it's just a small, personal toy-site with no personal or really important content, I see this as a fast and decent-working solution regarding security compared to implementing some form of proper login/authorization system.
If the site is getting a big number of users and lots of content, or simply becomes more than a "toy site", I'd advice you to do it the proper way
I don't know what your toy admin page would display, but keep in mind that when loading external images or linking to somewhere else, your referrer is going to publicize your URL.
If you change http into https, then at least the url will not be visible to anyone sniffing on the network.
(the caveat here is that you also need to consider that very obscure login system can leave interesting traces to be found in the network traces (MITM), somewhere on the site/target for enabling priv.elevation, or on the system you use to log in if that one is no longer secure and some prefer admin login looking no different from a standard user login to avoid that)
You could require that some action be taken # of times and with some number of seconds of delays between the times. After this action,delay,action,delay,action pattern was noticed, the admin interface would become available for login. And the urls used in the interface could be randomized each time with a single use url generated after that pattern. Further, you could only expose this interface through some tunnel and only for a minute on a port encoded by the delays.
If you could do all that in a manner that didn't stand out in the logs, that'd be "clever" but you could also open up new holes by writing all that code and it goes against "keep it simple stupid".
From a usability perspective, is it better to integrate admin section on the main website or have a separate section to manage content?
Any thoughts are greatly appreciated.
EDIT: the application is a CMS for very non-techno friendly staff.
It depends on the project and part you want to administer, imho.
For example comments on newsposts should be administered in the website itself by showing a "delete" linkbutton for each comment. Otherwise the mods would have to look up the comment in the admin section => not very user friendly.
But in general I think a seperate admin section will usually be more clear to your client. You'd want them to see the site as a normal user would see it.
At the very least I would recommend moving all your administration files to a separate folder. That way if you're using a platform like .NET you can very easily control folder access though role and user-based web.config permissions.
Having your administration files all segregated allows you to do other things easily too, like delete them if you decide to move them to another server later. Also you can exclude them in your robots.txt file (although by putting it in the robots.txt file you will be telling other people this section exists, and robots don't have to mind this file).
Edit:
I feel like my answer missed the mark a little considering your question. Of course in-line editing is easier than going to a separate page from a usability perspective, but whenever I hear of mixing admin users with regular users giant alarm bells go off in my head.
I think that it depends on the function of the site and how intrusive it will be to your staff. Does it make sense for them to make changes while browsing the site and will they eventually become discouraged with your system because it forces them to inject unnecessary steps into their process? How long will the edits take? Does it make sense to show a completely different interface to administrators? I think an answer to this question requires a lot more understanding of what specific function you're trying to accomplish and will vary on a case by case basis.
I have never liked adding administration pages into the main site. It seems like it is too much of a risk from someone accidently getting access to the administration portion of the site. Even if you review the security over and over, there is always that possibility that something unexpected will happen, and it is a huge mess to clean up (what was modified, who accessed what etc. etc.). In my opinion keeping it as a seperate site is the easiest way to go.
While there is a level of convenience in being able to login to the main part of a site as a privileged user, and then clicking on parts of a page to edit/alter it, there is also a measure of security in having it in a separate area.
I have found that having a separate section of the website that is devoted specifically to administrative tasks makes the tasks easier to organize and use. Just look at Wordpress (especially the new 2.7 release), Drupal (a very popular cms), and Joomla (another very popular cms). If you would like to test these feature out to see why I think the separate section is better, you can go to www.opensourcecms.com and test out both Drupal and Joomla.
From a usability, the more integrated the better but it tends to add severely to the complexity. Its always best if you can perform the action within the context in which it occurs - lock out a bad user, trim a log thats too big etc. however since these tend to have significant side effects the security aspect trumps this a lot of the time out of fear.
I think you need to look at doing a risk assessment with regards to integrating the administration capabilities right into the application.
What would be the implication for the system if someone were able to escalate privelages and gain access to the admin functions. if every user was locked out maliciously - damage to the site, the reputation, SLA etc?
What destructive functions can an admin perform from this section ? delete lots of data? crash the app? alter costs that have material impact on users/customers?
Are the admin functions integrated in the app or isolated into specific admin functions?
Does the application have a public face or is it an intranet that is assumed secure?
I personally have never felt at ease integrating the admin section with the site out of fear that a security breach caused by my ineptness or something beyond my control like bad defaults, unpatched exploit. However, when the client is writing the cheque I tend to do what they feel is best.
I come from the school of Usability that says "minimise guess work". So, what kind of information did you get from your user group sessions?
Remember, you're not (and we're not) typical users of your system. Anything we say is going to be a guess. What's worse is that any opinion shown here is likely to be ill informed for your situation (but probably awesome at what they do). The only way you'll have an informed opinion on what to do is by going out and asking your users in intelligent ways.
Because this is a security issue some of your user mix should be people who specialise in security. Just because it's easier to use doesn't mean it's the most appropriate.
I don't know much about poking at servers, etc, but in light of the (relatively) recent Wordpress security issues, I'm wondering if it's possible to obscure which CMS you might be using to the outside world.
Obviously you can rename the default login page, error messages, the favicon (I see the joomla one everywhere) and use a non-default template, but the sorts of things I'm wondering about are watching redirects somehow and things like that. Do most CMS leave traces?
This is not to replace other forms of security, but more of a curious question.
Thanks for any insight!
Yes, many CMS leave traces like the forming of identifiers and hierarchy of elements that are a plain giveaway.
This is however not the point. What is the point, is that there are only few very popular CMS. It is not necessary to determine which one you use. It will suffice to methodically try attack techniques for the 5 to 10 biggest CMS in use on your site to get a pretty good probability of success.
In the general case, security by obscurity doesn't work. If you rely on the fact that someone doesn't know something, this means you're vulnerable to certain attacks since you blind yourself to them.
Therefore, it is dangerous to follow this path. Chose a successful CMS and then install all the available security patches right away. By using a famous CMS, you make sure that you'll get security fixes quickly. Your biggest enemy is time; attackers can find thousands of vulnerable sites with Google and attack them simultaneously using bot nets. This is a completely automated process today. Trying to hide what software you're using won't stop the bots from hacking your site since they don't check which vulnerability they might expect; they just try the top 10 of the currently most successful exploits.
[EDIT] Bot nets with 10'000 bots are not uncommon today. As long as installing security patches is so hard, people won't protect their computers and that means criminals will have lots of resources to attack. On top of that, there are sites which sell exploits as ready-to-use plugins for bots (or bots or rent whole bot nets).
So as long as the vulnerability is still there, camouflaging your site won't help.
A lot of CMS's have id, classnames and structure patterns that can identify them (Wordpress for example). URLs have specific patterns too. You just need someone experienced with the plataform or with just some browsing to identify which CMS it's using.
IMHO, you can try to change all this structure in your CMS, but if you are into all this effort, I think you should just create your own CMS.
It's more important to keep everything up to date in your plataform and follow some security measures than try to change everything that could reveal the CMS you're using.
Since this question is tagged "wordpress:" you can hide your wordpress version by putting this in your theme's functions.php file:
add_action('init', 'removeWPVersionInfo');
function removeWPVersionInfo() {
remove_action('wp_head', 'wp_generator');
}
But, you're still going to have the usual paths, i.e., wp-content/themes/ etc... and wp-content/plugins/ etc... in page source, unless you figure out a way to rewrite those with .htaccess.