incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Flores <>
Subject Re: API function: Open url in system web browser
Date Mon, 21 May 2012 01:59:20 GMT
Hi all,

This is my first post and a newbie to this topic.
IMHO this appears to be a logic issue best clarified with a row column table spelling out
all conditions and desired behavior:
Webview, Safari browser, Android browser, iFrame, parent, child, target, security, etc.

In the relational database world adding a new column successfully normalized
database to the third level.  Master Detail tables ( Parent Child tables ),
ie. order id, item id guarantees selecting a unique correct row each having 
1 to N quantity of an item.

Not sure if target parm alone can handle all combinations and if any major change
violates some specification.  The 'whitelist' appears unwieldy.

If this patch to fix problem becomes a kludge perhaps waiting for eventual bug fix is prudent.

Sent from my iPad

On May 20, 2012, at 11:38 AM, Shazron <> wrote:

> Ah I just had a realization that you might think that the whitelist
> occurs in shouldStartLoadWithRequest only.
> There is also CDVURLProtocol
> , 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 <> 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
>> <> 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 <> wrote:
>>>> e.g.
>>>> <script src=""></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 <> wrote:
>>>>> On Sun, May 20, 2012 at 12:43 AM, Brian LeRoux <> wrote:
>>>>>> How is opening a URL in a web browser a security risk to the Cordova
>>>>>> 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" <> wrote:
>>>>>>> Jesse, I understand the problem, I know what Brian is asking,
>>>>>>> afraid no one does understand with regards to the two request
>>>>>>> I was afraid someone would "go there" and suggest to compromise
>>>>>>> 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 <>
>>>>>>>> Shaz: I believe Brian is proposing you look for urls
>>>>>>>> containing _cordova-target= before rejecting them via the
>>>>>>>> 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="" target="_blank">asdf<a>
>>>>>>>> Providing a new API means the link becomes (or something
>>>>>>>> gap://app/openExtUrl/
>>>>>>>> Brian's proposal means the link becomes :
>>>>>>>> So either native code has to watch for links with '_cordova-target='
>>>>>>>> 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 <>
>>>>>>>>> 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 <>
>>>>>>>>>> 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].
>>>>>>>>>> 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=
>>>>>>> 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 <>
>>>>>>>>>>> When JIRA is back up (it's under maintenance
right now), see my
>>>>>>>>>>> first/second comment on this issue:
>>>>>>>>>>> It's a bit too long to rehash :)
>>>>>>>>>>> On Sat, May 19, 2012 at 8:17 AM, Brian LeRoux
<> wrote:
>>>>>>>>>>>> Sorry shaz, I must be dense but I missed
the technical reasons?
>>>>>>>>>>>> On May 19, 2012 11:48 AM, "Shazron" <>
>>>>>>>>>>>>>> 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

View raw message