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

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

I would suggest that the trust should be put into the browser not the
website since you have not control over the website but you do have
control over the software installed on your PC. But again, the
security of the client depends on the security of the server and the
security of the server depends on the security of the client.

:) so we are walking on a rather thin surface here.

On 8/12/07, anurag.agarwal@xxxxxxxxx <anurag.agarwal@xxxxxxxxx> wrote:
>
>
> Interesting point. I dont know if thats how people see it though. I mean, I
> never thought in terms of trusting the browser, I always think in terms of
> trusting the website.
>
>
> 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@xxxxxxxxx" <anurag.agarwal@xxxxxxxxx>
> Cc: WASC Forum <websecurity@xxxxxxxxxxxxx>; "Webappsec @securityFocus"
> <webappsec@xxxxxxxxxxxxxxxxx>
> Sent: Sunday, August 12, 2007 12:28:48 AM
> Subject: Re: [WEB SECURITY] Seeking feedback on proposed security
> restriction in the browsers
>
>
> 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
>


-- 
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]