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

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

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

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