[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: Fri, 10 Aug 2007 15:55:46 -0700 (PDT)
--0-2093497591-1186786546=:42630
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Hi Amit=0A=0A>>For one, it doesn't fully handle situations in which the XSS=
payload can =0A>>write compromised data to another (publicly accessible, o=
r at least =0A>>attacker accessible) part of the site. For example, an XSS =
payload may =0A>>take the cookie value and "store" it in another part of th=
e site, such =0A>>as a page to where comments can be submitted. The attacke=
r then only =0A>>needs to frequently poll this section of the site and coll=
ect the data.=0A=0AI agree but the extent of damage could be limited. For o=
ne they wont be able to remotely control the victim browser. The other thin=
g is if the attacker stores the data on the server (like in the approach yo=
u mentioned) then from the forensics point of view at least it would be cle=
arer to find who the victims were...=0A=0Athoughts?=0A=0ACheers,=0A =0AAnur=
ag Agarwal=0A =0ASEEC - An application security search engine=0AWeb: www.at=
tacklabs.com , www.myappsecurity.com=0AEmail : anurag.agarwal@yahoo.com=0AB=
log : http://myappsecurity.blogspot.com=0A =0A=0A=0A=0A> *The browser shoul=
d check with the webserver which domains it can =0A> interact with (load fi=
les from or submit post data to, etc) for that =0A> website. How the check =
is implemented is upto the browser.*=0A>=0A> For example: If a page from my=
bank.com is trying to submit data to =0A> attacker.com then before submitti=
ng the data, the browser should check =0A> with the mybank.com if it is all=
owed to do so.=0A> =0A> Q1. is it reasonable?=0A> Q2. What are the pros an=
d cons of this approach?=0A> Q3. Would it limit some types of browser attac=
ks (like some xss =0A> vectors, etc)?=0A> Q4. Would it open any new types o=
f attack vectors?=0A> =0A=0AFor one, it doesn't fully handle situations in=
which the XSS payload can =0Awrite compromised data to another (publicly a=
ccessible, or at least =0Aattacker accessible) part of the site. For exampl=
e, an XSS payload may =0Atake the cookie value and "store" it in another pa=
rt of the site, such =0Aas a page to where comments can be submitted. The a=
ttacker then only =0Aneeds to frequently poll this section of the site and =
collect the data.=0A=0A-Amit
--0-2093497591-1186786546=:42630
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>Hi Amit</DIV>=0A<DIV> </DIV>=0A<DIV>>>Fo=
r one, it doesn't fully handle situations in which the XSS payload can <BR>=
>>write compromised data to another (publicly accessible, or at least=
<BR>>>attacker accessible) part of the site. For example, an XSS pay=
load may <BR>>>take the cookie value and "store" it in another part o=
f the site, such <BR>>>as a page to where comments can be submitted. =
The attacker then only <BR>>>needs to frequently poll this section of=
the site and collect the data.<BR></DIV>=0A<DIV>I agree but the exten=
t of damage could be limited. For one they wont be able to remotely control=
the victim browser. The other thing is if the attacker stores the data on =
the server (like in the approach you mentioned) then from the forensics poi=
nt of view at least it would be clearer to find who the victims were..=
.</DIV>=0A<DIV> </DIV>=0A<DIV>thoughts?</DIV>=0A<DIV> </DIV>=0A<P=
>Cheers,</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>SEE=
C - An application security search engine</A></P>=0A<P>Web: <A href=3D=
"http://www.attacklabs.com/"; target=3D_blank rel=3Dnofollow>www.attacklabs.=
com</A> , <A href=3D"http://www.myappsecurity.com/"; target=3D_blank re=
l=3Dnofollow>www.myappsecurity.com</A></P>=0A<P>Email : <A href=3D"mailto:a=
nurag.agarwal@yahoo.com" target=3D_blank rel=3Dnofollow>anurag.agarwal@yaho=
o.com</A></P>=0A<P>Blog : <A href=3D"http://myappsecurity.blogspot.com/"; ta=
rget=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 n=
ew roman, new york, times, serif">=0A<DIV>> *The browser should check wi=
th the webserver which domains it can <BR>> interact with (load files fr=
om or submit post data to, etc) for that <BR>> website. How the check is=
implemented is upto the browser.*<BR>><BR>> For example: If a page f=
rom mybank.com is trying to submit data to <BR>> attacker.com then befor=
e submitting the data, the browser should check <BR>> with the mybank.co=
m if it is allowed to do so.<BR>> <BR>> Q1. is it reasonab=
le?<BR>> Q2. What are the pros and cons of this approach?<BR>> Q3. Wo=
uld it limit some types of browser attacks (like some xss <BR>> vectors,=
etc)?<BR>> Q4. Would it open any new types of attack vectors?<BR>>&n=
bsp; <BR><BR>For one, it doesn't fully handle situations in which the =
XSS payload can <BR>write compromised data to another (publicly accessible,=
or at least <BR>attacker accessible) part of the site. For example, an XSS=
payload may <BR>take the
cookie value and "store" it in another part of the site, such <BR>as a pag=
e to where comments can be submitted. The attacker then only <BR>needs to f=
requently poll this section of the site and collect the data.<BR><BR>-Amit<=
/DIV></DIV><BR></DIV></div></body></html>
--0-2093497591-1186786546=:42630--
Brought to you by http://www.webappsec.org
Search this site
|