Re: [WEB SECURITY] Seeking feedback on proposed security restriction in the browsers

["pdp (architect)" <pdp.gnucitizen@xxxxxxxxxxxxxx>]

which effectively means that users should not trust their browsers at
all since they do what the websites they access tell them to do. not a
good idea. :)

On 8/12/07, anurag.agarwal@xxxxxxxxx <anurag.agarwal@xxxxxxxxx> wrote:
>
>
> pdp -
>
> As far as backward compatibility is concerned, that can be implemented by
> the browsers. As ivan pointed out in his paper, browser can simply check if
> there is a security policy exists then browser should implement it otherwise
> it will behave the same way as it is behaving now. This way those sites
> which wants to implement can use the new features provided by the browser.
>
>
>
> Cheers,
>
>
>
> Anurag Agarwal
>
>
>
> SEEC - An application security search engine
>
> Web: www.attacklabs.com , www.myappsecurity.com
>
> Email : anurag.agarwal@xxxxxxxxx
>
> Blog : http://myappsecurity.blogspot.com
>
>
>
>
>
> ----- Original Message ----
> From: pdp (architect) <pdp.gnucitizen@xxxxxxxxxxxxxx>
> To: Anurag Agarwal <anurag.agarwal@xxxxxxxxx>
> Cc: WASC Forum <websecurity@xxxxxxxxxxxxx>; "Webappsec @securityFocus"
> <webappsec@xxxxxxxxxxxxxxxxx>
> Sent: Saturday, August 11, 2007 1:36:10 AM
> Subject: Re: [WEB SECURITY] Seeking feedback on proposed security
> restriction in the browsers
>
>
> right, I am not sure whether this is a good idea but I know for a fact
> that probably it wont make it, unless there is some sort of a miracle.
> If you haven't noticed yet, the world is moving toward crossdomain.xml
> which is property of Adobe, the biggest Web technology player at the
> moment. Firefox is moving towards Tamarin, and yes, although Tamarin
> has nothing to do with crossdomain.xml security implementation, there
> is a high chance of influencing the way web technologies will go.
>
> IMHO, crossdomain.xml is probably the change that we all need.
> However, unfortunately, It won't solve any problem but only bring
> more. Not that long time ago, I had a little discussion with Ethan
> Malasky from Macromedia on Ajaxian's blog. Here is a snippet from what
> I said.
>
>
> http://ajaxian.com/archives/kevin-lynch-at-the-ajax-experience/
>
>     Ethan,
>
>     I understand what you are saying. However, what I am trying to say
> is that with or without crossdomain.xml, XMLHttpRequest objects and
> JavaScript remoting hacks work. Let me make it clearer. :)
>
>     Due to the Same Origin Policies JavaScript can access only the
> current origin. Even if you implement the crossdomain.xml file,
> JavaScript again will be able to access the current origin. Why?
> Compatibly issues. We cannot move to the new technology over the
> night. With or without crossdomain.xml JSON or JavaScript remoting, if
> you like, will still work. The only thing that will change is
> increased attack surface due to the trust relationship between apps.
> Let me explain.
>
>     Let's say that we have app on A.com and another one on B.com.
> B.com says that A.com can access its data. Effectively, this means
> that If I can get XSS on A.com, I will be able to read the data on
> that domain including the data on B.com due to the trust relationship.
> Today this is not possible. I need two XSS vulns rather the one.
>
>     Again, correct me if I am wrong :)
>
>
> I guess this is a bit off topic but it is something that we need to
> cover since we are talking about policies. Let's get back to the
> question about CSRF.
>
> You can't stop CSRF. This is it. The technology does what it is
> supposed to do. I see how some policies can be used for good, in
> situations where attackers are after your router through some sort of
> CSRF attack, but again, I seriously doubt that something like this
> will ever work. For sure it will improve the situation security wise
> in certain areas but at the same time will make Web technologies
> rather inflexible which is something that developers hate. I don't
> think that people like crossdomain.xml and this is the reason why most
> sites allow everyone to connect to their stuff, although they probably
> don't know about the dangers of doing that.
>
> Also keep in mind that this solution will stop only POST based CSRF
> attacks. Those based on GET cannot be stopped. Someone may say that
> developers should make critical requests to go over POST only, but
> this is not the case that I see in the real world. Today, GET and POST
> are substitutable. PHP doesn't do it by default but I see developers
> enforce it anyway. I won't be surprised if we start using $_PARAMS
> instead of $_GET and $_POST in the future.
>
> Furthermore, most Java applications does not differentiate between GET
> or POST so they are practically excluded from any CSRF prevention
> policies we are talking about.
>
> So yes, we can setup a policy but it will never take off. First of all
> standardization bodies needs to except it. Then browsers have to
> implement it and we have a browser war going on at the moment. No
> developer will implement a standard that is not widely adopted.
>
> IMHO we need to look at security personalization options within the
> browsers rather then inventing new standards that may crash and burn
> like they've done so far. For example, browsers should not allow
> external pages to connect to sites with private IP addresses. But I
> would like to have the option to disable this policy if I want to.
>
> cheers.
>
> On 8/10/07, Anurag Agarwal <anurag.agarwal@xxxxxxxxx> wrote:
> >
> >
> > I am looking to get views from people on the list about a proposed
> security
> > restriction in the browsers
> >
> > The browser should check with the webserver which domains it can interact
> > with (load files from or submit post data to, etc) for that website. How
> the
> > check is implemented is upto the browser.
> >
> > For example: If a page from mybank.com is trying to submit data to
> > attacker.com then before submitting the data, the browser should check
> with
> > the mybank.com if it is allowed to do so.
> >
> > Q1. is it reasonable?
> > Q2. What are the pros and cons of this approach?
> > Q3. Would it limit some types of browser attacks (like some xss vectors,
> > etc)?
> > Q4. Would it open any new types of attack vectors?
> >
> >
> > I know there are security researchers, browser vendors, corporate security
> > folks and various other smart webappsec people on this list. I would
> really
> > appreciate if they can chip in with their 2 cents on this topic.
> >
> >
> > Any feedback is highly appreciated
> >
> >
> > Cheers,
> >
> >
> >
> > Anurag Agarwal
> >
> >
> >
> > SEEC - An application security search engine
> >
> > Web: www.attacklabs.com , www.myappsecurity.com
> >
> > Email : anurag.agarwal@xxxxxxxxx
> >
> > Blog : http://myappsecurity.blogspot.com
> >
> >
> >
>
>
> --
> pdp (architect) | petko d. petkov
> http://www.gnucitizen.org
>


-- 
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]