The following post could be taken in the wrong way which may discourage some people from using plugins developed by the APEX community. Please read the ENTIRE post before you make any conclusions.
They're some good comments for this post. I've summarized them and included my thoughts in the following post: Malicious Code in APEX Plugins - Feedback
One of the best features of APEX plugins is the ability to share them with the community. Some sites, such as apex-plugin.com, host over 70 plugins. Most of these plugins are open source and free to use in production applications. These plugins have saved organizations lots of time developing redundant code.
There is the possibility for someone to develop a malicious plugin which could compromise your entire database or access to your application. For example I could easily create a dynamic action plugin that could send me a list of all your tables each time the plug-in is run. That being said I would never do that, but someone with bad intentions could.
What does this mean for you? Before integrating a plugin into your application (even in a development environment) you should look at both the PL/SQL and JavaScript code to see what they do. In most cases this extra step will take a few minutes but can save you a lot of headaches (and potentially your job). This is one of the main reasons why I don't compress JavaScript files in plugins that I post on apex-plugin.com. I want to ensure that other developers can easily review my code.
I am not trying to fear monger (there's enough of that going on in society as is) developers about the threat of using plugins. I just want to make sure that developers know the risks involved and what they should do to protect their database and business when integrating 3rd party plugins.
I still think that the Oracle corp. should maintain the plugin repository so they can at least validate the plugin and hold it to some kind of standard. Sort of like Apple does. Not quite as rigid, but at least they back the plugins and will remove anything that is deemed bad.
ReplyDeleteGood post - I think too many blindly throw in a plugin with no understanding what it actually does.
And what do you think about wrapped PL/SQL code? Some plug-ins use this technique (so you need not only to install the plug-in itself, but also the - wrapped - PL/SQL package)...
ReplyDeleteGood post. On apex-plugin.com we have a approvement process. It's a good suggestion for us to scan the plugin and the code more accurate before publishing it.
ReplyDeleteOn the other hand APEX is (still) a small world. If someone is posting such a plugin he will be tracked down and publicly excommunicated :-)
Learco
I've been cautioning people about this for some time now.
ReplyDeleteI don't fear malicious code as much as I do "black box" code - code that someone else wrote that today, works just fine with a specific set of versions. But, when you upgrade any part of your stack, breaks, and since no one knew how it worked, takes an entire application with it.
Or, more realistically, plug-ins or anything online that is sub-optimal. Sure, that cool plugin may work well with 100 rows, but can it scale to 1000, 10,000 or even 1,000,000 rows? And if it doesn't, is there anyone who will support it?
I'm definitely not against plugins or sites that host & share them, but like everything else, you need to exercise a bit of caution before jumping in head first.
- Scott -
Dear Martin,
ReplyDeleteYou exactly describe here my concern.
And indeed we need to be aware of the risks when using a plug-in created by someone else than the Oracle company.
Iloon
Hi Martin
ReplyDeleteYou've raised a good point, but I think you've missed the fact that people should place some trust in plugins developed by professional APEX companies/consultants or from a reputable site like apex-plugin.com. People can review the authors online presence and make a measured judgement.
Also, not everyone will understand what happens within a plugin, and some can get very complex and the source can be over 10,000 lines of code. What do you suggest here? Personally I think it comes back to trust...
Lastly, companies/consultants (myself included) might want to license their plugins and provide support (i.e. commercial plugins). Trial versions may be provided with obfuscated source and minified javascript. The blog post sort of suggests that if the source is not readable that you shouldn't trust the plugin, which I would have to disagree with.
Your thoughts?
Cheers
Matt
Hi Martin
ReplyDeleteYou've raised a good point, but I think you've missed the fact that people should place some trust in plugins developed by professional APEX companies/consultants or from a reputable site like apex-plugin.com. People can review the authors online presence and make a measured judgement.
Also, not everyone will understand what happens within a plugin, and some can get very complex and the source can be over 10,000 lines of code. What do you suggest here? Personally I think it comes back to trust...
Lastly, companies/consultants (myself included) might want to license their plugins and provide support (i.e. commercial plugins). Trial versions may be provided with obfuscated source and minified javascript. The blog post sort of suggests that if the source is not readable that you shouldn't trust the plugin, which I would have to disagree with.
Your thoughts?
Cheers
Matt
Thank you for all the excellent feedback on this post. I've summarized these comments in the following post: http://www.talkapex.com/2011/04/malicious-code-in-apex-plugins-feedback.html
ReplyDelete