Re: Getting started with WebKit plugins
Re: Getting started with WebKit plugins
- Subject: Re: Getting started with WebKit plugins
- From: Rudi Sherry <email@hidden>
- Date: Mon, 16 Jan 2006 09:51:43 -0800
On Jan 14, 2006, at 10:36 AM, Christopher Drum 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.
What would a user gain by spoofing to make your plug-in is talking to
a server that isn't one of the corporate servers? That is, is there
confidential information being passed from the client's machine to
the server, or only the other way around? The answer to that
question will greatly affect which security measures you want.
If this plug-in is only to access corporate information, then you
don't have to worry about spoofing the servers because the hackers
won't gain anything by having your plug-in talking to fake servers.
All they're get is fake information...
That said, whitelists are in general considered more secure than
blacklists. Unfortunately, a hacker could tamper with your plug-in
to add URLs to the whitelist.
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.
As well you should. A savvy and determined hacker that gets a copy
of your plug-in will fairly easily be able to find out the URLs it's
checking against, or spoof trusted sites.
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.
What exactly do you mean by "the wilds of the intranet"? Do outside
users have access to that intranet?
The other thing to worry about is whether the corporate servers need
to verify that they're talking to your plug-in: suppose someone wrote
another plug-in so the corporate server thought it was talking to
your plug-in when it was actually talking to a hacker's plug-in?
To have your plug-in verify that it was really talking to the right
server, you could also use a public/private key: there are any number
of encryption verification handshakes. Unfortunately that won't work
the other way around, since you would then have to have the private
key stored in the plug-in itself, and reverse-engineering would
reveal that.
The best you can do is have the server know it's talking to a
qualified user by having usernames and passwords. Force the user to
log in, and have the server not respond with any information unless
every request contains the resultant cookie (or whatever token the
server provides).
The user/password scheme is still vulnerable to man-in-the-middle
attacks; use https connections to the server (even on the intranet)
to mitigate that. Even those are hackable.... it depends on how
valuable this information is.
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.
I'm not a big fan of "security by obscurity"; a disgruntled ex-
employee would have and could share that knowledge. Usernames/
passwords are always good.
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."
Really what you're looking for is to show that anyone that gets by
the plug-in security already must have enough ability and knowledge
to hack the system without it; that is "the plug-in is not the
weakest point of attach because of A, B and C".
Hope this helps,
Rudi
Just curious to get other developers' thoughts on the matter.
Christopher Drum
On Jan 12, 2006, at 12:46 PM, Severin Kurpiers wrote:
Hi Christopher,
just for the case that you haven't discovered it yet: you can even
debug your plugin. Here the short description how to do this:
1. Put a link (or an alias) to the built debug version of your
plugin into ~/Library/Internet Plug-Ins.
2. Add Safari as a custom executable to your plugin project (menu
Project > New Custom Executable…)
3. Set some breakpoints.
4. Call the menu Debug > Debug Executable (or click the debug
button or use the keyboard shortcut).
It will launch Safari. You can now let Safari open a html page
that uses your plugin and the debugger will recognize the
breakpoints. It's pretty cool :)
Bye,
Severin Kurpiers
Verek Ltd.
On 11. Jan 2006, at 18:49, Christopher Drum wrote:
[...]
(10) This makes sense, and I feel silly for not thinking about
the console for the log file. For some reason it just didn't
occur to me that NSLog was sending it's text anywhere, in the
context of a plugin. Of course, it must and I thank you for
reminding me of the fact.
Christopher
_______________________________________________
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