[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: Sat, 11 Aug 2007 22:44:30 -0700 (PDT)
--0-1394222402-1186897470=:30713
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
pdp -=0A=0AAs far as backward compatibility is concerned, that can be imple=
mented by the browsers. As ivan pointed out in his paper, browser can simpl=
y 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 th=
ose sites which wants to implement can use the new features provided by the=
browser. =0A=0A =0ACheers,=0A =0AAnurag Agarwal=0A =0ASEEC - An applicatio=
n security search engine=0AWeb: www.attacklabs.com , www.myappsecurity.com=
=0AEmail : anurag.agarwal@yahoo.com=0ABlog : http://myappsecurity.blogspot.=
com=0A =0A=0A=0A=0A----- Original Message ----=0AFrom: pdp (architect) <pdp=
.gnucitizen@googlemail.com>=0ATo: Anurag Agarwal <anurag.agarwal@yahoo.com>=
=0ACc: WASC Forum <websecurity@webappsec.org>; "Webappsec @securityFocus" <=
webappsec@securityfocus.com>=0ASent: Saturday, August 11, 2007 1:36:10 AM=
=0ASubject: Re: [WEB SECURITY] Seeking feedback on proposed security restri=
ction in the browsers=0A=0A=0Aright, I am not sure whether this is a good i=
dea but I know for a fact=0Athat probably it wont make it, unless there is =
some sort of a miracle.=0AIf you haven't noticed yet, the world is moving t=
oward crossdomain.xml=0Awhich is property of Adobe, the biggest Web technol=
ogy player at the=0Amoment. Firefox is moving towards Tamarin, and yes, alt=
hough Tamarin=0Ahas nothing to do with crossdomain.xml security implementat=
ion, there=0Ais a high chance of influencing the way web technologies will =
go.=0A=0AIMHO, crossdomain.xml is probably the change that we all need.=0AH=
owever, unfortunately, It won't solve any problem but only bring=0Amore. No=
t that long time ago, I had a little discussion with Ethan=0AMalasky from M=
acromedia on Ajaxian's blog. Here is a snippet from what=0AI said.=0A=0A =
http://ajaxian.com/archives/kevin-lynch-at-the-ajax-experience/=0A=0A Et=
han,=0A=0A I understand what you are saying. However, what I am trying t=
o say=0Ais that with or without crossdomain.xml, XMLHttpRequest objects and=
=0AJavaScript remoting hacks work. Let me make it clearer. :)=0A=0A Due =
to the Same Origin Policies JavaScript can access only the=0Acurrent origin=
. Even if you implement the crossdomain.xml file,=0AJavaScript again will b=
e able to access the current origin. Why?=0ACompatibly issues. We cannot mo=
ve to the new technology over the=0Anight. With or without crossdomain.xml =
JSON or JavaScript remoting, if=0Ayou like, will still work. The only thing=
that will change is=0Aincreased attack surface due to the trust relationsh=
ip between apps.=0ALet me explain.=0A=0A Let's say that we have app on A=
.com and another one on B.com.=0AB.com says that A.com can access its data.=
Effectively, this means=0Athat If I can get XSS on A.com, I will be able t=
o read the data on=0Athat domain including the data on B.com due to the tru=
st relationship.=0AToday this is not possible. I need two XSS vulns rather =
the one.=0A=0A Again, correct me if I am wrong :)=0A=0A=0AI guess this i=
s a bit off topic but it is something that we need to=0Acover since we are =
talking about policies. Let's get back to the=0Aquestion about CSRF.=0A=0AY=
ou can't stop CSRF. This is it. The technology does what it is=0Asupposed t=
o do. I see how some policies can be used for good, in=0Asituations where a=
ttackers are after your router through some sort of=0ACSRF attack, but agai=
n, I seriously doubt that something like this=0Awill ever work. For sure it=
will improve the situation security wise=0Ain certain areas but at the sam=
e time will make Web technologies=0Arather inflexible which is something th=
at developers hate. I don't=0Athink that people like crossdomain.xml and th=
is is the reason why most=0Asites allow everyone to connect to their stuff,=
although they probably=0Adon't know about the dangers of doing that.=0A=0A=
Also keep in mind that this solution will stop only POST based CSRF=0Aattac=
ks. Those based on GET cannot be stopped. Someone may say that=0Adevelopers=
should make critical requests to go over POST only, but=0Athis is not the =
case that I see in the real world. Today, GET and POST=0Aare substitutable.=
PHP doesn't do it by default but I see developers=0Aenforce it anyway. I w=
on't be surprised if we start using $_PARAMS=0Ainstead of $_GET and $_POST =
in the future.=0A=0AFurthermore, most Java applications does not differenti=
ate between GET=0Aor POST so they are practically excluded from any CSRF pr=
evention=0Apolicies we are talking about.=0A=0ASo yes, we can setup a polic=
y but it will never take off. First of all=0Astandardization bodies needs t=
o except it. Then browsers have to=0Aimplement it and we have a browser war=
going on at the moment. No=0Adeveloper will implement a standard that is n=
ot widely adopted.=0A=0AIMHO we need to look at security personalization op=
tions within the=0Abrowsers rather then inventing new standards that may cr=
ash and burn=0Alike they've done so far. For example, browsers should not a=
llow=0Aexternal pages to connect to sites with private IP addresses. But I=
=0Awould like to have the option to disable this policy if I want to.=0A=0A=
cheers.=0A=0AOn 8/10/07, Anurag Agarwal <anurag.agarwal@yahoo.com> wrote:=
=0A>=0A>=0A> I am looking to get views from people on the list about a prop=
osed security=0A> restriction in the browsers=0A>=0A> The browser should ch=
eck with the webserver which domains it can interact=0A> with (load files f=
rom or submit post data to, etc) for that website. How the=0A> check is imp=
lemented is upto the browser.=0A>=0A> For example: If a page from mybank.co=
m is trying to submit data to=0A> attacker.com then before submitting the d=
ata, the browser should check with=0A> the mybank.com if it is allowed to d=
o so.=0A>=0A> Q1. is it reasonable?=0A> Q2. What are the pros and cons of t=
his approach?=0A> Q3. Would it limit some types of browser attacks (like so=
me xss vectors,=0A> etc)?=0A> Q4. Would it open any new types of attack vec=
tors?=0A>=0A>=0A> I know there are security researchers, browser vendors, c=
orporate security=0A> folks and various other smart webappsec people on thi=
s list. I would really=0A> appreciate if they can chip in with their 2 cent=
s 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 applicati=
on security search engine=0A>=0A> Web: www.attacklabs.com , www.myappsecuri=
ty.com=0A>=0A> Email : anurag.agarwal@yahoo.com=0A>=0A> Blog : http://myapp=
security.blogspot.com=0A>=0A>=0A>=0A=0A=0A-- =0Apdp (architect) | petko d. =
petkov=0Ahttp://www.gnucitizen.org
--0-1394222402-1186897470=:30713
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>pdp -</DIV>=0A<DIV> </DIV>=0A<DIV>As far as ba=
ckward compatibility is concerned, that can be implemented by the brow=
sers. As ivan pointed out in his paper, browser can simply check if there i=
s a security policy exists then browser should implement it otherwise it wi=
ll behave the same way as it is behaving now. This way those sites which wa=
nts to implement can use the new features provided by the browser. </DIV>=
=0A<DIV><BR> </DIV>=0A<P>Cheers,</P>=0A<P> </P>=0A<P>Anurag Agarw=
al</P>=0A<P> </P>=0A<P><A href=3D"http://www.myappsecurity.com/"; targe=
t=3D_blank rel=3Dnofollow>SEEC - An application security search engine</A><=
/P>=0A<P>Web: <A href=3D"http://www.attacklabs.com/"; target=3D_blank r=
el=3Dnofollow>www.attacklabs.com</A> , <A href=3D"http://www.myappsecu=
rity.com/" target=3D_blank rel=3Dnofollow>www.myappsecurity.com</A></P>=0A<=
P>Email : <A href=3D"mailto:anurag.agarwal@yahoo.com"; target=3D_blank rel=
=3Dnofollow>anurag.agarwal@yahoo.com</A></P>=0A<P>Blog : <A href=3D"http://=
myappsecurity.blogspot.com/" target=3D_blank rel=3Dnofollow>http://myappsec=
urity.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-S=
IZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Orig=
inal Message ----<BR>From: pdp (architect) <pdp.gnucitizen@googlemail.co=
m><BR>To: Anurag Agarwal <anurag.agarwal@yahoo.com><BR>Cc: WASC Fo=
rum <websecurity@webappsec.org>; "Webappsec @securityFocus" <webap=
psec@securityfocus.com><BR>Sent: Saturday, August 11, 2007 1:36:10 AM<BR=
>Subject: Re: [WEB SECURITY] Seeking feedback on proposed security restrict=
ion in the browsers<BR><BR>=0A<DIV>right, I am not sure whether this is a g=
ood idea but I know for a fact<BR>that probably it wont make it, unless the=
re is some sort of a miracle.<BR>If you haven't noticed yet, the world is m=
oving toward crossdomain.xml<BR>which is property of Adobe, the biggest Web=
technology player at the<BR>moment. Firefox is moving towards Tamarin, and=
yes, although Tamarin<BR>has nothing to do with crossdomain.xml security i=
mplementation, there<BR>is a high chance of influencing the way web technol=
ogies 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 br=
ing<BR>more. Not that long time ago, I had a little discussion with Ethan<B=
R>Malasky from Macromedia on Ajaxian's blog. Here is a snippet from what<BR=
>I said.<BR><BR> <A href=3D"http://ajaxian.com/archives/kevin-l=
ynch-at-the-ajax-experience/"
target=3D_blank>http://ajaxian.com/archives/kevin-lynch-at-the-ajax-experi=
ence/</A><BR><BR> Ethan,<BR><BR> &n=
bsp;I understand what you are saying. However, what I am trying to say<BR>i=
s that with or without crossdomain.xml, XMLHttpRequest objects and<BR>JavaS=
cript remoting hacks work. Let me make it clearer. :)<BR><BR> &n=
bsp; Due to the Same Origin Policies JavaScript can access only the<BR=
>current origin. Even if you implement the crossdomain.xml file,<BR>JavaScr=
ipt again will be able to access the current origin. Why?<BR>Compatibly iss=
ues. We cannot move to the new technology over the<BR>night. With or withou=
t crossdomain.xml JSON or JavaScript remoting, if<BR>you like, will still w=
ork. The only thing that will change is<BR>increased attack surface due to =
the trust relationship between apps.<BR>Let me explain.<BR><BR> =
Let's say that we have app on A.com and another one on
B.com.<BR>B.com says that A.com can access its data. Effectively, this mea=
ns<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>&nb=
sp; 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 CSRF=
.<BR><BR>You can't stop CSRF. This is it. The technology does what it is<BR=
>supposed to do. I see how some policies can be used for good, in<BR>situat=
ions where attackers are after your router through some sort of<BR>CSRF att=
ack, but again, I seriously doubt that something like this<BR>will ever wor=
k. For sure it will improve the situation security wise<BR>in certain areas=
but at the same time will make Web technologies<BR>rather
inflexible which is something that developers hate. I don't<BR>think that =
people like crossdomain.xml and this is the reason why most<BR>sites allow =
everyone to connect to their stuff, although they probably<BR>don't know ab=
out the dangers of doing that.<BR><BR>Also keep in mind that this solution =
will stop only POST based CSRF<BR>attacks. Those based on GET cannot be sto=
pped. Someone may say that<BR>developers should make critical requests to g=
o over POST only, but<BR>this is not the case that I see in the real world.=
Today, GET and POST<BR>are substitutable. PHP doesn't do it by default but=
I see developers<BR>enforce it anyway. I won't be surprised if we start us=
ing $_PARAMS<BR>instead of $_GET and $_POST in the future.<BR><BR>Furthermo=
re, most Java applications does not differentiate between GET<BR>or POST so=
they are practically excluded from any CSRF 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>implement it and we have a browser war going on a=
t the moment. No<BR>developer will implement a standard that is not widely =
adopted.<BR><BR>IMHO we need to look at security personalization options wi=
thin the<BR>browsers rather then inventing new standards that may crash and=
burn<BR>like they've done so far. For example, browsers should not allow<B=
R>external pages to connect to sites with private IP addresses. But I<BR>wo=
uld like to have the option to disable this policy if I want to.<BR><BR>che=
ers.<BR><BR>On 8/10/07, Anurag Agarwal <anurag.agarwal@yahoo.com> wro=
te:<BR>><BR>><BR>> I am looking to get views from people on the li=
st about a proposed security<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
that website. How the<BR>> check is implemented is upto the browser.<BR=
>><BR>> For example: If a page from mybank.com is trying to submit da=
ta to<BR>> attacker.com then before submitting the data, the browser sho=
uld check 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 so=
me xss vectors,<BR>> etc)?<BR>> Q4. Would it open any new types of at=
tack vectors?<BR>><BR>><BR>> I know there are security researchers=
, browser vendors, corporate security<BR>> folks and various other smart=
webappsec people on this list. I would really<BR>> appreciate if they c=
an chip in with their 2 cents on this topic.<BR>><BR>><BR>> Any fe=
edback is highly appreciated<BR>><BR>><BR>> Cheers,<BR>><BR>>=
;<BR>><BR>> Anurag Agarwal<BR>><BR>><BR>><BR>>
SEEC - An application security search engine<BR>><BR>> Web: <A href=
=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>-- <BR>pdp=
(architect) | petko d. petkov<BR><A href=3D"http://www.gnucitizen.org/"; ta=
rget=3D_blank>http://www.gnucitizen.org</A></DIV></DIV><BR></DIV></div></bo=
dy></html>
--0-1394222402-1186897470=:30713--
Brought to you by http://www.webappsec.org
Search this site
|