Security and spurl.net (and others)

[Razzbar]

I found an interesting JS technique being used by spurl.net and a few
other sites, and implemented my own version of it. I like using it, but
I'm rather surprised it works at all.

One of my old backburner projects has been an online bookmark archive.
The obvious advantage of keeping bookmarks on a remote host is that
they are available from anywhere, not just the computer they were
bookmarked from.

My original approach was to use a page that would open a child window.
You'd surf in the child window and when you wanted to bookmark a site,
you'd switch to the parent window and hit a button. Worked great until
I tried to bookmark a site that was not in the same domain. That's how
I learned about the 'same domain' security policy 8-0

Spurl uses a small piece of JS code as a pseudo-url in a link, which
the user bookmarks, putting it on the browser's toolbar. When the user
clicks on the link on the toolbar, the JS code executes, opening a
window and calling a url, passing the current page's url and title in
the query string.

It's pretty slick really. But doesn't it seem to violate the 'same
domain' policy that keeps me from reading the title and url of a child
window?

I've implemented my own clone which asks for comments and keywords, and
doesn't save or submit until the user tells it to. But actually by the
time the user sees the popup contents, the server has already seen the
information. I also know it's possible to write one of these pseudo-url
popups to open and close a window without user intervention.

I really haven't taken the time to see just what other information one
of these popups can gather from the "current page" (never thought
about it until now) but the issue is that a little piece of code can
access the document object of a page across domains.

Any comments?

 

[VK]

But doesn't it seem to violate the 'same

domain' policy that keeps me from reading the title and url of a child
window?

As I see it there is not a JavaScript sandbox violation here, because
the actuall process goes on the server side. By clicking
javascript:void(someDomain/some.php) you're effectively calling a php
script on the server from your current page. Naturally php page has the
caller's URL right away as it's a part of CGI (OK, PHP uses CGI as a
transport for it's own protocol, but it doesn't change the picture too
much). "To fully satisfy customers", one could create server-side
virtual browser to get own copy of that page and study it on the spot
(title, language, links, number of paragraphs etc.)
Nothing to do with JavaScript security. Just the old as WWW dilemma:
convenience / privacy = const
More convenience - lesser privacy
Lesser privacy - more convenience

 

[Richard Cornford]

Razzbar wrote:

... a pseudo-url in a link, which the user bookmarks,
putting it on the browser's toolbar. When the user
clicks on the link on the toolbar, the JS code executes,
opening a window and calling a url, passing the current
page's url and title in the query string.

<snip>
Any comments?

A javascript pseudo protocol URL typed into the location/address bar of
the browser is executed as part of the current page, inside its script
environment. As a result it has exactly the same rights to access the
contents of the contained document as any other script on that page.

Javascript pseudo protocol URLs may also be set up as
favourites/bookmarks in the browser, as buttons on the toolbar, links on
the desktop (dragged onto the browser window to execute), and in many
other ways. Rendering a running document form any location wide open to
examination and manipulation.

They are used extensively in development to examine/modify the current
state of scripted document for testing and debugging. And they are used
"maliciously" to negate all notions of client-side security.

They provide the user of a web browser with absolute control over the
software that is executing on their computer. Just as it should be, as
there are no security implications for the user in having that power
over remotely originating code.

Richard.