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.
Related
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.
In a recent security advisory, Microsoft warns that "Vulnerabilities in Gadgets Could Allow Remote Code Execution":
An attacker who successfully exploited a Gadget vulnerability could run arbitrary code in the context of the current user.
(Microsoft Security Advisory 2719662)
I don't really understand the point. As far as I know, gadgets are (by design) HTML-based application running with full trust!
Full Trust
The choice to run a gadget is presented to the user in the same way that the choice to run any application downloaded from the Internet is presented. Information about the author of the gadget is displayed in a dialog box that indicates there is risk associated with this file. After the user accepts the warning, the gadget will run with all of the permissions associated with the user's login account.
(MSDN: Gadgets for Windows Sidebar Security)
For example, nothing prevents you from adding
<script language="VBScript">
Set shell = CreateObject("Wscript.Shell")
shell.Run "notepad.exe"
</script>
and executing arbitrary commands from your gadget. This works and it's by design.
Obviously, they can do everything that another application running in the local user's context can do. So, where is the vulnerability the MS Security Advisory is mentioning which "can be exploited"?
Well the "gadget vulnerability" is the problem that:
the risks that gadgets are exposed to are the same as those faced by any web-based
application, e.g. Man-In-The-Middle or code injection. Similar issues existed in earlier versions of most web browsers but modern browsers have specifically implemented controls to attempt to mitigate many of these issues. These controls have not been implemented in the Gadgets platform, leaving them vulnerable to well-known and thoroughly discussed attacks.
- We have you by the gadgets, black hat.
so you can see the main exploit is that there were no controls to limit the gadgets from running code with no restraint.
Another problem:
Microsoft has said that it has discovered that some Vista and Win7 gadgets don’t adhere to secure coding practices and should be regarded as causing
risk to the systems on which they’re run.
so indeed running arbitrary code is part of HTA's but because the sidebar and gadgets platform didn't mitigate it and were quite pessimistic, thinking that all gadget programmers would write safe code and wouldn't try to exploit or do things gadgets aren't suppose to do.
Hope it answered what you asked.
I still think the question is quite vague because you say: well they allow to run arbitrary code and it's part of the model and concept and they didn't mitigate it so what's the exploit? it's already exploited... - this is the whole idea :)
It can be asked about every flaw and attack and that's exactly the problem - it was by design a problem and wasn't secure it was discovered that since no mitigation and since you are really able to run and execute the malicious code with no problem these gadgets have a flaw.
Agreed, the Gadgets platform appears to be no more or less vulnerable than if the user executed an unsigned application.
Why the same system-level execution prevention, heuristic analysis & other methods applied to applications could not be applied to Gadgets is mystifying to me.
This smacks of laziness on the part of Microsoft: The Gadgets platform was not highly regarded or widely used (despite the potential of delivering an unprecedented level of capability and integration of web-features directly into the desktop), so rather than make any attempt whatsoever to safeguard the user from malicious Gadgets, they simply discontinued them.
With the direction the User Interfaces in Windows, Mac and Android are headed, the average user has less and less idea how an app (or plugin) actually does what it is doing, so the proliferation of needless, opportunistic or even malicious apps continues. I've been back and forth over the Gadgets specification, and as near as I can tell, it is no more insecure than the plugins system used by Chrome and FireFox.
Execution of ActiveX and Java within a Gadget is subject to the Security settings in Internet Explorer. If your security settings allow a Gadget to do something, most of those functions are exploitable within a plugin or Java app as well.
The analyst reports I've read indicate that these vulnerabilities have been patched in "most modern browsers" but that clearly isn't true of Internet Explorer, as every Gadget exploit I've seen can also be run within the IE browser.
In short it is the "toggle-switch" style handling of ActiveX, Java and other plugins which is at fault here. By trying to spare the user endless prompting and eliminating the requirement of making an informed decision, Microsoft continues to leave uninformed or careless users wide open to malicious web apps and plugins.
Trust certificates & security patches would have been vastly preferable to discontinuing the feature.
As I see it, I think the security issue is a smoke screen. These "security issues" exists across many vectors, and gadgets, if they were such a problem would have been addressed much sooner than the dawn of the release of Windows 8. My opinion is that gadgets were jettisoned because they are a power drain on a Windows 8 tablet. It reminds me of how the ribbon interface was "to expose deeply buried functionality" when I think in reality Microsoft was really planning for a touch interface. So, whatever "excuse" Microsoft gives for doing something, I tend to look for a deeper purpose. Hopefully this will change with the new management. Does anyone know if it is possible to install some sort of gadget platform on Windows 8.1? Thanks!
These attacks happen in this way:
An attacker would have to convince a user to install and enable a vulnerable Gadget
An attacker who successfully exploited a Gadget vulnerability could gain the same user rights as a logged-on user. If the user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
as you see it is simple if you install a vulnerable gadget, now tell me who authorize your gadgets? in the world wild web there are many many fake gadgets..be careful.
also microsoft has a hotfix to disable sidebar and gadgets that you can find in this link :
microsoft advisory
and they killed gadgets and sidebar in windows 8
I appreciate you to find the exact details, here is the article presented in blackhat which made Microsoft disable gadgets:
We have you by the gadgets - Black Hat (pdf file)
One of the more powerful features of modern day browsers is the ability for software developers to write browser extensions to enhance, modify and tweak the pages visited by the user. As more of our lives migrate onto the browser, aren't we potentially exposing ourselves to a massive privacy and security holes created by the installation of a browser extension that is malicious in nature?
I realize the source code of these extensions is extractable and readable if the author has not made attempts to obfuscate the behavior. But the effectiveness of this type of review is compromised by the browser encouraging users to keep their extensions up to date. While version 1.0 of an extension may be innocuous, a users browser may suggest an upgrade to version 1.1 which could contain malicious code which could be used to scrape information from the screen of the compromised browser.
As both a user and developer of browser extensions, is the developer's reputation the only thing in place to provide assurances to their users that their browsing activity will be secure? Are there any mechanisms in place to help protect users from a compromised browser extension?
Are there any best-practices to develop extensions in a manner that provides users with the assurance that the code they install and update is benign in nature?
Browser extensions can do almost anything user can do. They can send your bank passwords, read files on local disk, execute commands etc. Security of a browser depends not only on browser itself, but also on all installed extensions.
I've written a few extensions for Chrome recently, and I had no idea how much harm extensions could really do before that.
Extensions ask for permissions, but these are very broad. Any non-trivial extension would most likely end up asking for "Full Permission", and most users would just bang the "YES" button. Even a tech savvy user may shrug this off as legitimate, I know I have.
Most extensions are free. It costs time and money to code them up, so how are developers getting their investment back? Some do it for fun, but chrome web store specifically asks if you are planning to inject adds - I can only deduce that this is a common practice for extension developers. Extensions could also act as tracking cookies, and sell usage stats to whomever.
It's near trivial to write an extension that would glob up your passwords and send them on to a third party. Even if these passwords are 'saved'. One of my extensions had a legitimate use case to modify all input fields on all pages, and I found out that chrome would just happily paste-in stored passwords in plain text. Same goes for CC information.
Many extensions include analytics packages, to help developers identify who their users are, which parts of the app is used and so forth. I think that this is a legitimate use case, but you may not necessarily agree.
If you are a developer, be advised that Chrome extensions could significantly impact page load times. My own extension, which I tirelessly optimized to be as lightweight as possible, caused all pages to have an additional 50-200ms load time.
So after I've seen what's possible, I've disabled all extensions in Chrome except for my own. I really only miss AdBlock.
Internet Explorer Browser Helper Objects are extremely unsafe. They basically allow the browser to run native code, which could be anything. I'm not sure if they're still as pervasive now as they were in years past, but they're one of the reasons why Internet Explorer is so much less secure than Firefox and other browsers.
Mozilla style plug-ins using XUL and Microsoft's Silverlight plug-ins are sandboxed to try and prevent malicious behavior. Ultimately it rests on the developer's reputation for any kind of software to be deemed trustworthy by its users, however. Even in cases where the developer is not trying to write malware, bugs in the program may expose security exploits.
Which is why you have multiple machines, and if you can't afford a new one, use a virtual machine to run most of the stuff and monitor it's behavior. Its what i do atleast before I do anything.
RnVja3Mgd2l0aCBtZSBmYW0hIGhpdCBtZSB1cCBhdCB0aGVib3NzODkwN0B5YWhv
by5jb20gaWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucw==
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.
What is the best way to avoid that an application is copied and used without the owner’s knowing?
Is there any way to trace the usage? Meaning periodically the application communicates back, with enough information so that we can know where it is, and if it’s legal. Next thing, of course, shut it down, if it’s not legit.
Software that "phones home" will be quickly shunned by the vast majority of your users. Just license it appropriately and sell it.
People who use your software professionally will either pay for it or they won't use it. Corporations tend to frown on potential lawsuits.
People who want to use your software without paying for it will continue to do so despite your best efforts to counteract them. Once the software is in their hands, it is out of yours. Without pissing off your users, your only recourse is a legal one.
If your product is priced reasonably, some people will pay for it and some won't. That is just something you need to deal with upfront and it should be factored into your business plan.
Don't do this, don't attempt it, don't even think about it.
This is a battle you can't win. If people want to pirate your software they will. You'll be shamed by the fact that a smart reverse engineer can write a one byte binary patch to subvert all your protection schemes.
The people who are going to pirate your software will do so and all these "security features" you build in will likely end up only inconveniencing your true supporters: the people who have legitimately purchased your software. These draconian DRM / anti-piracy schemes only build resentment among software users.
Hardware dongles are the best way if you are really concerned about piracy IMO. Check out the big industrial CAD/CAM packages worth thousands or tens-of-thousands, or the AV/Music production software, they virtually all have dongle protection. Dongles can be emulated or reversed but not without a significant investment in time, a lot more than just changing a few JEs to JNEs in your assembly.
Phoning home is not the way to go unless you are providing a service that requires a subscription and constant updates (like antivirus products, for example) as part of your business model. You need to have a bit of respect for your users and their privacy. You might have perfectly innocent intentions but what if a court ordered your company to hand over that information (like the US government is doing with Google and its search terms) - would/could you fight it? What if you some time in the future sold your company and the new owners decided to sell all that historic information to a marketing company? Privacy is not just about trusting a company not to abuse your data, it is trusting that company to go out of their way to protect your data. Which is pretty far down the list of priorities for most companies. So basically, the monitoring users thing is not really a good path to go down.
The best (and pretty much only) way to reliably prevent piracy is to have a client/server application instead of a standalone one, where a non-trivial part of the work is done by the server and users need to register. Then you can at least detect and block simultaneous use of the same account.
There are several approaches you could take, but there are three that will be vastly more effective that any of the others.
A. Don't create it.
Software that doesn't exist never suffers from unauthorized use.
B. Don't release it.
If you have the only copy, and you keep it that way, then the chances are exceedingly good that there will be no unauthorized use.
C. Give everyone permission to use it.
If you don't want anyone to use it without permission, then you can give everyone permission and there will be no unauthorized users.
There is a possibility to trace the usage. You can accomplish this by letting phone your tool home and send the information you need. The problem with this is, that first nobody likes software that phones home for this purpose and second with a simple application-level gateway you can block the application to phone home! What you describe in your question is a common problem of software-distributors and it's not an easy one to solve!
There's another thing I haven't seen mentioned yet : You could add loads of settings to the applications' configuration file, and start with ridiculous defaults. Then do the installation & configuration personally, so no-one but you is able to figure out how everything should be set. This can be a mayor put-down for people that are just trying out if a copy is enough. (Be sure to add settings that depend on all sorts of system-settings, like OS-version related DLL-versions that should be loaded, etc). Not very user-friendly tho ;-)