Re: Getting started with WebKit plugins
Re: Getting started with WebKit plugins
- Subject: Re: Getting started with WebKit plugins
- From: Greg Herlihy <email@hidden>
- Date: Mon, 16 Jan 2006 13:08:42 -0800
- Thread-topic: Getting started with WebKit plugins
I think it unlikely that a browser plug-in could be measurably more secure
than its browser. I certainly would not write a browser plug-in with that
expectation. But the browser already provides a lot of security-related
services; so the plug-in should avail itself of those in order to protect
private information and to prevent spoofing, for example.
More specifically, to eliminate the risk of connecting to a "decoy" web
site, the browser should connect to the server via SSL (https). SSL
authenticates the server while encrypting the message traffic to prevent
third-party eavesdropping.
On 1/14/06 10:36 AM, "Christopher Drum" <email@hidden> wrote:
> Great tip! Thank you.
>
> On a semi-related topic, I was wondering what kind of advice you (or
> the board in general) may have for establishing security on a WebKit
> plugin. Specifically, I need to ensure that my plugin is only usable
> by our corporate intranet. I've been working with our web developers
> toward a solution, and I believe they have some ideas that will help
> the plugin verify an authenticated condition exists for the plugin to
> check against. However, I would even like to go so far as to hardcode
> the plugin to ONLY work at a list of very specific intranet sites.
I would look at the inverse though: if this measure really would improve
security - than the conclusion to draw would be that unless the plug-in's
communications are tightly controlled, there is a real chance of a security
lapse - and I would find that conclusion more disturbing than the whatever
reassurance I would take from the proposed fix.
> To me it seems like the arguments passed to the plugin through
> plugInViewWithArguments: contain the requesting URL, which could be
> checked against a private NSArray (perhaps stored in a private
> instance of some custom Security class) of "safe" intranet addresses.
> However, I'm still concerned about protecting against spoofing.
Again any user should use SSL if spoofing is a concern. And presumably would
already be doing so since these issues are not plug-in specific. And in
fact, the farther one gets away from the plug-in: its code and the logic of
its data processing - and the more one tries to control external factors,
such as which web sites the plug-in works with or when, the less effective
such measures ultimately become. Such steps are in a way shielding
weaknesses rather than building security from the inside out.
> What kind of security would you recommend be built into a plugin to
> restrict it's use to a very specific set of conditions? It occurs to
> me that a plugin could provide essential business services to a
> corporate workflow, but that those same services accessible in the
> wilds of the intranet would be a huge, huge, gaping security risk.
> Should the plugin alone be responsible for this, or should the
> intranet site's authentication get involved as well... a sort of two-
> pronged approach.
Establishing the authenticity of the data should be require examining only
the data itself, and not have to rely on external factors, such as the means
by which the data was delivered (though obviously it could be a criterion).
In some ways restricting the plug-in to specific sites makes it less secure,
because it doesn't fix the core problem which is that the plug-in apparently
cannot tell good data from bad.
If there is such a security risk were the plug-in to "fall into the wrong
hands" so to speak, it would seem to me that the fix would not to do
everything to keep it out of those hands, but for the plug-in to be more
discerning about whose hands it is in and why. The difference between the
two approaches is that one can be accomplished in software, and the other
cannot.
> I'm having a little trouble figuring out how to gain the benefits of
> the potential inherent in building a custom plugin without exposing
> my users to any potential negatives. In my case, the plugin's
> availability is limited to a very select group of people, and it's
> interface is hidden to all but three people who must have intimate
> knowledge of my company's workflow and naming conventions to even
> make use of the plugin. I feel this establishes fairly robust
> security by default: hackers can't hack what they don't know about.
> Still though, I would feel a lot better if I could very firmly and
> definitively state to the project leader, "The plugin is secure
> because of A, B and C."
There is no security in obscurity. If the plug-in's security rests on the
assumption that no one will ever "find out about it", then its security is
tied to happenstance and not to anything in the code. Security begins and
ends with the software. And while other steps can be taken to supplement a
piece of software's intrinsic security, they can never compensate for a
security hole in the software. If a program is not inherently secure, it is
simply not secure.
Greg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden