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

["Prasad Shenoy" <prasad.shenoy@xxxxxxxxx>]

------=_Part_19658_3695747.1186796127517
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

If I understand what is being discussed here, this proposed solution won't
address XSS issue, correct? I can see how it can prevent or curtail CSRF up
to some extent. So thinking more about it, a thought that comes to my mind
is of a possible DoS on the server.

An attacker can exploit an XSS vulnerability, say, write a looping function
provoking the browser to confirm with the web server on ever iteration. How
many iterations can cause the server to go down is open to imagination I
guess.

Again, I ain't not expert on this "yet" so there is much chance that I might
be totally "off" the track here. If I am, please point it out :-)

P



On 8/10/07, Ryan Barnett <rcbarnett@gmail.com> wrote:
>
> Ivan Ristic wrote a proposal paper about a year ago called "Secure
> Browsing Mode" that you might want to look at -
> http://www.modsecurity.org/blog/archives/Secure_Browsing_Mode_Proposal.pdf
>
> It also references Gervase's paper.
>
>
> On 8/10/07, Anurag Agarwal <anurag.agarwal@yahoo.com> 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@yahoo.com
> > Blog : http://myappsecurity.blogspot.com
>
>
> --
> Ryan C. Barnett
> ModSecurity Community Manager
> Breach Security: Director of Application Security Training
> Web Application Security Consortium (WASC) Member
> CIS Apache Benchmark Project Lead
> SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> Author: Preventing Web Attacks with Apache
>
>
> ----------------------------------------------------------------------------
> 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]
>
>


-- 
Prasad

------=_Part_19658_3695747.1186796127517
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

If I understand what is being discussed here, this proposed solution won&#39;t address XSS issue, correct? I can see how it can prevent or curtail CSRF up to some extent. So thinking more about it, a thought that comes to my mind is of a possible DoS on the server. 
<br><br>An attacker can exploit an XSS vulnerability, say, write a looping function provoking the browser to confirm with the web server on ever iteration. How many iterations can cause the server to go down is open to imagination I guess.
<br><br>Again, I ain&#39;t not expert on this &quot;yet&quot; so there is much chance that I might be totally &quot;off&quot; the track here. If I am, please point it out :-)<br><br>P<br><br><br><br><div><span class="gmail_quote">
On 8/10/07, <b class="gmail_sendername">Ryan Barnett</b> &lt;<a href="mailto:rcbarnett@gmail.com";>rcbarnett@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ivan Ristic wrote a proposal paper about a year ago called &quot;Secure<br>Browsing Mode&quot; that you might want to look at -<br><a href="http://www.modsecurity.org/blog/archives/Secure_Browsing_Mode_Proposal.pdf";>http://www.modsecurity.org/blog/archives/Secure_Browsing_Mode_Proposal.pdf
</a><br><br>It also references Gervase&#39;s paper.<br><br><br>On 8/10/07, Anurag Agarwal &lt;<a href="mailto:anurag.agarwal@yahoo.com";>anurag.agarwal@yahoo.com</a>&gt; wrote:<br>&gt; I am looking to get views from people on the list about a proposed security
<br>&gt; restriction in the browsers<br>&gt;<br>&gt; The browser should check with the webserver which domains it can interact<br>&gt; with (load files from or submit post data to, etc) for that website. How the<br>&gt; check is implemented is upto the browser.
<br>&gt;<br>&gt; For example: If a page from <a href="http://mybank.com";>mybank.com</a> is trying to submit data to<br>&gt; <a href="http://attacker.com";>attacker.com</a> then before submitting the data, the browser should check with
<br>&gt; the <a href="http://mybank.com";>mybank.com</a> if it is allowed to do so.<br>&gt;<br>&gt; Q1. is it reasonable?<br>&gt; Q2. What are the pros and cons of this approach?<br>&gt; Q3. Would it limit some types of browser attacks (like some xss vectors,
<br>&gt; etc)?<br>&gt; Q4. Would it open any new types of attack vectors?<br>&gt;<br>&gt;<br>&gt; I know there are security researchers, browser vendors, corporate security<br>&gt; folks and various other smart webappsec people on this list. I would really
<br>&gt; appreciate if they can chip in with their 2 cents on this topic.<br>&gt;<br>&gt;<br>&gt; Any feedback is highly appreciated<br>&gt;<br>&gt; Cheers,<br>&gt;<br>&gt; Anurag Agarwal<br>&gt;<br>&gt; SEEC - An application security search engine
<br>&gt; Web: <a href="http://www.attacklabs.com";>www.attacklabs.com</a> , <a href="http://www.myappsecurity.com";>www.myappsecurity.com</a><br>&gt; Email : <a href="mailto:anurag.agarwal@yahoo.com";>anurag.agarwal@yahoo.com
</a><br>&gt; Blog : <a href="http://myappsecurity.blogspot.com";>http://myappsecurity.blogspot.com</a><br><br><br>--<br>Ryan C. Barnett<br>ModSecurity Community Manager<br>Breach Security: Director of Application Security Training
<br>Web Application Security Consortium (WASC) Member<br>CIS Apache Benchmark Project Lead<br>SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC<br>Author: Preventing Web Attacks with Apache<br><br>----------------------------------------------------------------------------
<br>Join us on IRC: <a href="http://irc.freenode.net";>irc.freenode.net</a> #webappsec<br><br>Have a question? Search The Web Security Mailing List Archives:<br><a href="http://www.webappsec.org/lists/websecurity/";>http://www.webappsec.org/lists/websecurity/
</a><br><br>Subscribe via RSS:<br><a href="http://www.webappsec.org/rss/websecurity.rss";>http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br><br></blockquote></div><br><br clear="all"><br>-- <br>Prasad<br>

------=_Part_19658_3695747.1186796127517--