[OpenAjaxSecurity] Push and cross-site (was GET vs HEAD vs OPTIONS)

Jon Ferraiolo jferrai at us.ibm.com
Fri Jan 4 07:17:39 PST 2008


Kris,
I agree we need new browser features, particularly server push and
cross-site communications.

Regarding server push, such a feature already exists at W3C within the SVG
Tiny 1.2 Candidate Recommendation and ships on various mobile phones today:
http://www.w3.org/TR/SVGMobile12/svgudom.html#global__Connection. HTML5
defines a different connection interface at:
http://www.whatwg.org/specs/web-apps/current-work/#the-connection. Both of
these features provide for server push within client side polling. IMO, the
WhatWG/HTML5 crowd should just adopt the connection interface from SVG and
start putting it into browsers, rather than waiting years for HTML5 to
produce a stable spec of the server push feature. (Unfortunately, the HTML5
guys pretty much reject anything associated with SVG Tiny 1.2.)

But back to cross-site communications, my opinion is that the Access
Control spec has noble goals but did not choose the best initial direction.
My opinion is that a better approach would be:

1) Define a new Processing Instruction or meta tag for (X)HTML that web
developers can use to tell the browser to make cross-site access even more
draconian by disallowing *all* communications with other domains. As a
result, various other tags, such as <img> and <script>, can only access
files from the original domain from which the main document was served. All
communications with other sites must be put into an IFRAME sandbox.

2) Provide a high-speed cross-frame messaging mechanism so that the main
window can receive messages from its various IFRAMEs. By using a message
passing scheme, the main HTML file can control which IFRAME can mediate all
attempts to access the main HTML file and any of the IFRAME sandboxes.

3) Each IFRAME can use XHR as it is designed today to their heart's
content.

This approach provides both more flexibility and more security for browsers
that support the proposed new features. APIs (similar to SMash's APIs) can
be architected to work with today's browsers in a secure (but slow) manner
which will take advantage of the above proposal when shipping within future
browsers.

Jon




                                                                           
             "Kris Zyp"                                                    
             <kriszyp at xucia.co                                             
             m>                                                         To 
             Sent by:                  "OpenAjax Alliance Security Task    
             security-bounces@         Force" <security at openajax.org>      
             openajax.org                                               cc 
                                                                           
                                                                   Subject 
             01/03/2008 06:37          Re: [OpenAjaxSecurity] Fw: GET vs   
             PM                        HEAD vs OPTIONS                     
                                                                           
                                                                           
             Please respond to                                             
             OpenAjax Alliance                                             
               Security Task                                               
                   Force                                                   
             <security at openaja                                             
                  x.org>                                                   
                                                                           
                                                                           




  for years to come, especially since there is already an option today to
  do the same thing today via a server proxy at www.example.com, and with
  OpenAjax Hub 1.1, you will be able to make it happen in a secure manner
  from the client.


I sure hope we are not planning on relying on FIM for the future of cross
site communication. Don't get me wrong, it provides a doable solution to
the problem, and I think OAH 1.1 is very valuable, but relying on a
polling-base hack is hardly something that will scale and provide a
foundation to build our future on. We do need something (or multiple
things) like this proposal.
Kris_______________________________________________
security mailing list
security at openajax.org
http://openajax.org/mailman/listinfo/security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080104/5d54c198/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080104/5d54c198/attachment-0003.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic08979.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080104/5d54c198/attachment-0004.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080104/5d54c198/attachment-0005.gif 


More information about the security mailing list