[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] Seeking feedback on proposed security restriction in the browsers
- From: anurag.agarwal@xxxxxxxxx
- Subject: Re: [WEB SECURITY] Seeking feedback on proposed security restriction in the browsers
- Date: Sun, 12 Aug 2007 00:35:24 -0700 (PDT)
--0-321452400-1186904124=:73167
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
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. =0A =0ACheers,=0A =0AAnurag Agarwal=0A =0ASEEC - An =
application security search engine=0AWeb: www.attacklabs.com , www.myappsec=
urity.com=0AEmail : anurag.agarwal@yahoo.com=0ABlog : http://myappsecurity.=
blogspot.com=0A =0A=0A=0A=0A----- Original Message ----=0AFrom: pdp (archit=
ect) <pdp.gnucitizen@googlemail.com>=0ATo: "anurag.agarwal@yahoo.com" <anur=
ag.agarwal@yahoo.com>=0ACc: WASC Forum <websecurity@webappsec.org>; "Webapp=
sec @securityFocus" <webappsec@securityfocus.com>=0ASent: Sunday, August 12=
, 2007 12:28:48 AM=0ASubject: Re: [WEB SECURITY] Seeking feedback on propos=
ed security restriction in the browsers=0A=0A=0Awhich effectively means tha=
t users should not trust their browsers at=0Aall since they do what the web=
sites they access tell them to do. not a=0Agood idea. :)=0A=0AOn 8/12/07, a=
nurag.agarwal@yahoo.com <anurag.agarwal@yahoo.com> wrote:=0A>=0A>=0A> pdp -=
=0A>=0A> As far as backward compatibility is concerned, that can be impleme=
nted by=0A> the browsers. As ivan pointed out in his paper, browser can sim=
ply check if=0A> there is a security policy exists then browser should impl=
ement it otherwise=0A> it will behave the same way as it is behaving now. T=
his way those sites=0A> which wants to implement can use the new features p=
rovided by the browser.=0A>=0A>=0A>=0A> Cheers,=0A>=0A>=0A>=0A> Anurag Agar=
wal=0A>=0A>=0A>=0A> SEEC - An application security search engine=0A>=0A> We=
b: www.attacklabs.com , www.myappsecurity.com=0A>=0A> Email : anurag.agarwa=
l@yahoo.com=0A>=0A> Blog : http://myappsecurity.blogspot.com=0A>=0A>=0A>=0A=
>=0A>=0A> ----- Original Message ----=0A> From: pdp (architect) <pdp.gnucit=
izen@googlemail.com>=0A> To: Anurag Agarwal <anurag.agarwal@yahoo.com>=0A> =
Cc: WASC Forum <websecurity@webappsec.org>; "Webappsec @securityFocus"=0A> =
<webappsec@securityfocus.com>=0A> Sent: Saturday, August 11, 2007 1:36:10 A=
M=0A> Subject: Re: [WEB SECURITY] Seeking feedback on proposed security=0A>=
restriction in the browsers=0A>=0A>=0A> right, I am not sure whether this =
is a good idea but I know for a fact=0A> that probably it wont make it, unl=
ess there is some sort of a miracle.=0A> If you haven't noticed yet, the wo=
rld is moving toward crossdomain.xml=0A> which is property of Adobe, the bi=
ggest Web technology player at the=0A> moment. Firefox is moving towards Ta=
marin, and yes, although Tamarin=0A> has nothing to do with crossdomain.xml=
security implementation, there=0A> is a high chance of influencing the way=
web technologies will go.=0A>=0A> IMHO, crossdomain.xml is probably the ch=
ange that we all need.=0A> However, unfortunately, It won't solve any probl=
em but only bring=0A> more. Not that long time ago, I had a little discussi=
on with Ethan=0A> Malasky from Macromedia on Ajaxian's blog. Here is a snip=
pet from what=0A> I said.=0A>=0A>=0A> http://ajaxian.com/archives/kevin-lyn=
ch-at-the-ajax-experience/=0A>=0A> Ethan,=0A>=0A> I understand what=
you are saying. However, what I am trying to say=0A> is that with or witho=
ut crossdomain.xml, XMLHttpRequest objects and=0A> JavaScript remoting hack=
s work. Let me make it clearer. :)=0A>=0A> Due to the Same Origin Polic=
ies JavaScript can access only the=0A> current origin. Even if you implemen=
t the crossdomain.xml file,=0A> JavaScript again will be able to access the=
current origin. Why?=0A> Compatibly issues. We cannot move to the new tech=
nology over the=0A> night. With or without crossdomain.xml JSON or JavaScri=
pt remoting, if=0A> you like, will still work. The only thing that will cha=
nge is=0A> increased attack surface due to the trust relationship between a=
pps.=0A> Let me explain.=0A>=0A> Let's say that we have app on A.com an=
d another one on B.com.=0A> B.com says that A.com can access its data. Effe=
ctively, this means=0A> that If I can get XSS on A.com, I will be able to r=
ead the data on=0A> that domain including the data on B.com due to the trus=
t relationship.=0A> Today this is not possible. I need two XSS vulns rather=
the one.=0A>=0A> Again, correct me if I am wrong :)=0A>=0A>=0A> I gues=
s this is a bit off topic but it is something that we need to=0A> cover sin=
ce we are talking about policies. Let's get back to the=0A> question about =
CSRF.=0A>=0A> You can't stop CSRF. This is it. The technology does what it =
is=0A> supposed to do. I see how some policies can be used for good, in=0A>=
situations where attackers are after your router through some sort of=0A> =
CSRF attack, but again, I seriously doubt that something like this=0A> will=
ever work. For sure it will improve the situation security wise=0A> in cer=
tain areas but at the same time will make Web technologies=0A> rather infle=
xible which is something that developers hate. I don't=0A> think that peopl=
e like crossdomain.xml and this is the reason why most=0A> sites allow ever=
yone to connect to their stuff, although they probably=0A> don't know about=
the dangers of doing that.=0A>=0A> Also keep in mind that this solution wi=
ll stop only POST based CSRF=0A> attacks. Those based on GET cannot be stop=
ped. Someone may say that=0A> developers should make critical requests to g=
o over POST only, but=0A> this is not the case that I see in the real world=
. Today, GET and POST=0A> are substitutable. PHP doesn't do it by default b=
ut I see developers=0A> enforce it anyway. I won't be surprised if we start=
using $_PARAMS=0A> instead of $_GET and $_POST in the future.=0A>=0A> Furt=
hermore, most Java applications does not differentiate between GET=0A> or P=
OST so they are practically excluded from any CSRF prevention=0A> policies =
we are talking about.=0A>=0A> So yes, we can setup a policy but it will nev=
er take off. First of all=0A> standardization bodies needs to except it. Th=
en browsers have to=0A> implement it and we have a browser war going on at =
the moment. No=0A> developer will implement a standard that is not widely a=
dopted.=0A>=0A> IMHO we need to look at security personalization options wi=
thin the=0A> browsers rather then inventing new standards that may crash an=
d burn=0A> like they've done so far. For example, browsers should not allow=
=0A> external pages to connect to sites with private IP addresses. But I=0A=
> would like to have the option to disable this policy if I want to.=0A>=0A=
> cheers.=0A>=0A> On 8/10/07, Anurag Agarwal <anurag.agarwal@yahoo.com> wro=
te:=0A> >=0A> >=0A> > I am looking to get views from people on the list abo=
ut a proposed=0A> security=0A> > restriction in the browsers=0A> >=0A> > Th=
e browser should check with the webserver which domains it can interact=0A>=
> with (load files from or submit post data to, etc) for that website. How=
=0A> the=0A> > check is implemented is upto the browser.=0A> >=0A> > For ex=
ample: If a page from mybank.com is trying to submit data to=0A> > attacker=
.com then before submitting the data, the browser should check=0A> with=0A>=
> the mybank.com if it is allowed to do so.=0A> >=0A> > Q1. is it reasonab=
le?=0A> > Q2. What are the pros and cons of this approach?=0A> > Q3. Would =
it limit some types of browser attacks (like some xss vectors,=0A> > etc)?=
=0A> > Q4. Would it open any new types of attack vectors?=0A> >=0A> >=0A> >=
I know there are security researchers, browser vendors, corporate security=
=0A> > folks and various other smart webappsec people on this list. I would=
=0A> really=0A> > appreciate if they can chip in with their 2 cents on this=
topic.=0A> >=0A> >=0A> > Any feedback is highly appreciated=0A> >=0A> >=0A=
> > Cheers,=0A> >=0A> >=0A> >=0A> > Anurag Agarwal=0A> >=0A> >=0A> >=0A> > =
SEEC - An application security search engine=0A> >=0A> > Web: www.attacklab=
s.com , www.myappsecurity.com=0A> >=0A> > Email : anurag.agarwal@yahoo.com=
=0A> >=0A> > Blog : http://myappsecurity.blogspot.com=0A> >=0A> >=0A> >=0A>=
=0A>=0A> --=0A> pdp (architect) | petko d. petkov=0A> http://www.gnucitizen=
.org=0A>=0A=0A=0A-- =0Apdp (architect) | petko d. petkov=0Ahttp://www.gnuci=
tizen.org
--0-321452400-1186904124=:73167
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1=
0pt"><DIV></DIV>=0A<DIV>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. <BR> </DIV>=0A<P>C=
heers,</P>=0A<P> </P>=0A<P>Anurag Agarwal</P>=0A<P> </P>=0A<P><A =
href=3D"http://www.myappsecurity.com/"; target=3D_blank rel=3Dnofollow>SEEC =
- An application security search engine</A></P>=0A<P>Web: <A href=3D"h=
ttp://www.attacklabs.com/" target=3D_blank rel=3Dnofollow>www.attacklabs.co=
m</A> , <A href=3D"http://www.myappsecurity.com/"; target=3D_blank rel=
=3Dnofollow>www.myappsecurity.com</A></P>=0A<P>Email : <A href=3D"mailto:an=
urag.agarwal@yahoo.com" target=3D_blank rel=3Dnofollow>anurag.agarwal@yahoo=
.com</A></P>=0A<P>Blog : <A href=3D"http://myappsecurity.blogspot.com/"; tar=
get=3D_blank rel=3Dnofollow>http://myappsecurity.blogspot.com</A></P>=0A<P>=
</P>=0A<DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: arial, helvetica, =
sans-serif"><BR><BR>=0A<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times ne=
w roman, new york, times, serif">----- Original Message ----<BR>From: pdp (=
architect) <pdp.gnucitizen@googlemail.com><BR>To: "anurag.agarwal@yah=
oo.com" <anurag.agarwal@yahoo.com><BR>Cc: WASC Forum <websecurity@=
webappsec.org>; "Webappsec @securityFocus" <webappsec@securityfocus.c=
om><BR>Sent: Sunday, August 12, 2007 12:28:48 AM<BR>Subject: Re: [WEB SE=
CURITY] Seeking feedback on proposed security restriction in the browsers<B=
R><BR>=0A<DIV>which effectively means that users should not trust their bro=
wsers at<BR>all since they do what the websites they access tell them to do=
. not a<BR>good idea. :)<BR><BR>On 8/12/07, anurag.agarwal@yahoo.com <an=
urag.agarwal@yahoo.com> wrote:<BR>><BR>><BR>> pdp -<BR>><BR>=
> As far as backward compatibility is concerned, that can be implemented=
by<BR>> the browsers. As ivan pointed out in his paper, browser can sim=
ply check if<BR>> there is a security policy exists then browser should =
implement it otherwise<BR>> it will behave the same way as it is behavin=
g now. This way those sites<BR>> which wants to implement can use the ne=
w features provided by the browser.<BR>><BR>><BR>><BR>> Cheers,=
<BR>><BR>><BR>><BR>> Anurag Agarwal<BR>><BR>><BR>><BR>=
> SEEC - An application security search engine<BR>><BR>> Web: <A h=
ref=3D"http://www.attacklabs.com/"; target=3D_blank>www.attacklabs.com</A> ,=
<A
href=3D"http://www.myappsecurity.com/"; target=3D_blank>www.myappsecurity.c=
om</A><BR>><BR>> Email : anurag.agarwal@yahoo.com<BR>><BR>> Blo=
g : <A href=3D"http://myappsecurity.blogspot.com/"; target=3D_blank>http://m=
yappsecurity.blogspot.com</A><BR>><BR>><BR>><BR>><BR>><BR>&g=
t; ----- Original Message ----<BR>> From: pdp (architect) <pdp.gnucit=
izen@googlemail.com><BR>> To: Anurag Agarwal <anurag.agarwal@yahoo=
.com><BR>> Cc: WASC Forum <websecurity@webappsec.org>; "Webapps=
ec @securityFocus"<BR>> <webappsec@securityfocus.com><BR>> Sent=
: Saturday, August 11, 2007 1:36:10 AM<BR>> Subject: Re: [WEB SECURITY] =
Seeking feedback on proposed security<BR>> restriction in the browsers<B=
R>><BR>><BR>> right, I am not sure whether this is a good idea but=
I know for a fact<BR>> that probably it wont make it, unless there is s=
ome sort of a miracle.<BR>> If you haven't noticed yet, the world is
moving toward crossdomain.xml<BR>> which is property of Adobe, the bigg=
est Web technology player at the<BR>> moment. Firefox is moving towards =
Tamarin, and yes, although Tamarin<BR>> has nothing to do with crossdoma=
in.xml security implementation, there<BR>> is a high chance of influenci=
ng the way web technologies will go.<BR>><BR>> IMHO, crossdomain.xml =
is probably the change that we all need.<BR>> However, unfortunately, It=
won't solve any problem but only bring<BR>> more. Not that long time ag=
o, I had a little discussion with Ethan<BR>> Malasky from Macromedia on =
Ajaxian's blog. Here is a snippet from what<BR>> I said.<BR>><BR>>=
<BR>> <A href=3D"http://ajaxian.com/archives/kevin-lynch-at-the-ajax-exp=
erience/" target=3D_blank>http://ajaxian.com/archives/kevin-lynch-at-the-aj=
ax-experience/</A><BR>><BR>> Ethan,<BR>><B=
R>> I understand what you are saying.
However, what I am trying to say<BR>> is that with or without crossdoma=
in.xml, XMLHttpRequest objects and<BR>> JavaScript remoting hacks work. =
Let me make it clearer. :)<BR>><BR>> Due to t=
he Same Origin Policies JavaScript can access only the<BR>> current orig=
in. Even if you implement the crossdomain.xml file,<BR>> JavaScript agai=
n will be able to access the current origin. Why?<BR>> Compatibly issues=
. We cannot move to the new technology over the<BR>> night. With or with=
out crossdomain.xml JSON or JavaScript remoting, if<BR>> you like, will =
still work. The only thing that will change is<BR>> increased attack sur=
face due to the trust relationship between apps.<BR>> Let me explain.<BR=
>><BR>> Let's say that we have app on A.com a=
nd another one on B.com.<BR>> B.com says that A.com can access its data.=
Effectively, this means<BR>> that If I can get XSS on A.com, I
will be able to read the data on<BR>> that domain including the data on=
B.com due to the trust relationship.<BR>> Today this is not possible. I=
need two XSS vulns rather the one.<BR>><BR>> =
Again, correct me if I am wrong :)<BR>><BR>><BR>> I guess this is=
a bit off topic but it is something that we need to<BR>> cover since we=
are talking about policies. Let's get back to the<BR>> question about C=
SRF.<BR>><BR>> You can't stop CSRF. This is it. The technology does w=
hat it is<BR>> supposed to do. I see how some policies can be used for g=
ood, in<BR>> situations where attackers are after your router through so=
me sort of<BR>> CSRF attack, but again, I seriously doubt that something=
like this<BR>> will ever work. For sure it will improve the situation s=
ecurity wise<BR>> in certain areas but at the same time will make Web te=
chnologies<BR>> rather inflexible which is something that
developers hate. I don't<BR>> think that people like crossdomain.xml an=
d this is the reason why most<BR>> sites allow everyone to connect to th=
eir stuff, although they probably<BR>> don't know about the dangers of d=
oing that.<BR>><BR>> Also keep in mind that this solution will stop o=
nly POST based CSRF<BR>> attacks. Those based on GET cannot be stopped. =
Someone may say that<BR>> developers should make critical requests to go=
over POST only, but<BR>> this is not the case that I see in the real wo=
rld. Today, GET and POST<BR>> are substitutable. PHP doesn't do it by de=
fault but I see developers<BR>> enforce it anyway. I won't be surprised =
if we start using $_PARAMS<BR>> instead of $_GET and $_POST in the futur=
e.<BR>><BR>> Furthermore, most Java applications does not differentia=
te between GET<BR>> or POST so they are practically excluded from any CS=
RF prevention<BR>> policies we are talking about.<BR>><BR>>
So yes, we can setup a policy but it will never take off. First of all<BR>=
> standardization bodies needs to except it. Then browsers have to<BR>&g=
t; implement it and we have a browser war going on at the moment. No<BR>>=
; developer will implement a standard that is not widely adopted.<BR>><B=
R>> IMHO we need to look at security personalization options within the<=
BR>> browsers rather then inventing new standards that may crash and bur=
n<BR>> like they've done so far. For example, browsers should not allow<=
BR>> external pages to connect to sites with private IP addresses. But I=
<BR>> would like to have the option to disable this policy if I want to.=
<BR>><BR>> cheers.<BR>><BR>> On 8/10/07, Anurag Agarwal <anu=
rag.agarwal@yahoo.com> wrote:<BR>> ><BR>> ><BR>> > I a=
m looking to get views from people on the list about a proposed<BR>> sec=
urity<BR>> > restriction in the browsers<BR>> ><BR>>
> The browser should check with the webserver which domains it can inte=
ract<BR>> > with (load files from or submit post data to, etc) for th=
at website. How<BR>> the<BR>> > check is implemented is upto the b=
rowser.<BR>> ><BR>> > For example: If a page from mybank.com is=
trying to submit data to<BR>> > attacker.com then before submitting =
the data, the browser should check<BR>> with<BR>> > the mybank.com=
if it is allowed to do so.<BR>> ><BR>> > Q1. is it reasonable?=
<BR>> > Q2. What are the pros and cons of this approach?<BR>> >=
Q3. Would it limit some types of browser attacks (like some xss vectors,<B=
R>> > etc)?<BR>> > Q4. Would it open any new types of attack ve=
ctors?<BR>> ><BR>> ><BR>> > I know there are security res=
earchers, browser vendors, corporate security<BR>> > folks and variou=
s other smart webappsec people on this list. I would<BR>>
really<BR>> > appreciate if they can chip in with their 2 cents on t=
his topic.<BR>> ><BR>> ><BR>> > Any feedback is highly ap=
preciated<BR>> ><BR>> ><BR>> > Cheers,<BR>> ><BR>&g=
t; ><BR>> ><BR>> > Anurag Agarwal<BR>> ><BR>> ><=
BR>> ><BR>> > SEEC - An application security search engine<BR>&=
gt; ><BR>> > Web: <A href=3D"http://www.attacklabs.com/"; target=3D=
_blank>www.attacklabs.com</A> , <A href=3D"http://www.myappsecurity.com/"; t=
arget=3D_blank>www.myappsecurity.com</A><BR>> ><BR>> > Email : =
anurag.agarwal@yahoo.com<BR>> ><BR>> > Blog : <A href=3D"http:/=
/myappsecurity.blogspot.com/" target=3D_blank>http://myappsecurity.blogspot=
.com</A><BR>> ><BR>> ><BR>> ><BR>><BR>><BR>> --<=
BR>> pdp (architect) | petko d. petkov<BR>> <A href=3D"http://www.gnu=
citizen.org/" target=3D_blank>http://www.gnucitizen.org</A><BR>><BR><BR>=
<BR>--
<BR>pdp (architect) | petko d. petkov<BR><A href=3D"http://www.gnucitizen.=
org/" target=3D_blank>http://www.gnucitizen.org</A></DIV></DIV><BR></DIV></=
div></body></html>
--0-321452400-1186904124=:73167--
Brought to you by http://www.webappsec.org
Search this site
|