Hi,<br><br>Sorry, I'm having a hard time understanding what you wrote below. Do you have a specific attack vector you are concerned with or just a general concern to protect against cross site scripting? <div><br></div>
<div>Perhaps you could provide a specific example or link to an example we can review if it's something specific.</div><div><div>Maybe someone else can respond if you have a specific attack in question.</div><div><br>
</div></div><div>If it's a general concern then the answer is you make safe all user data that is reflected back to the user or any other users.</div><div><br></div><div>Other comments below:</div><div><br></div><div>
<br></div><div><div class="gmail_quote">On Fri, Mar 26, 2010 at 3:52 PM, Jon mailinglists <span dir="ltr"><<a href="mailto:jon.mlist@gmail.com" target="_blank">jon.mlist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><div></div>User data for instance, say I have an application which is password<br></div>
protected and I'm using the Authenticate/Authorize model coming with<br>
Catalyst. I then protect the user data with a session cookie making<br>
sure $c->user->address is shown and editable by the logged in user<br>
(based on the thought that only the user can send me the cookie).<br></blockquote><div><br>Untangling that, I think you are concerned that a user could modify their "address" and have it reflected (displayed) back to them. And if that "address" is not correctly sanitized (escaped) then there's risk of cross site scripting. Is that correct?<br>
<br>The general answer there is, again, never reflect user-entered data without escaping.<br></div><div> <br></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
How do I protect that from another site with another tab? YUI.Get<br>
allows cross site requests, I haven't looked in too deep into it but<br>
when I take the url I see the javascript requests in gmail does and<br>
put it in a small YUI snippet will I get all my mail:<br>
<a href="https://mail.google.com/mail/?ui=2&ik=a_secret_token_or_my_id&view=tl&start=0&num=70&rt=h&search=drafts&zx=a_secret_token_or_my_id" target="_blank">https://mail.google.com/mail/?ui=2&ik=a_secret_token_or_my_id&view=tl&start=0&num=70&rt=h&search=drafts&zx=a_secret_token_or_my_id</a></blockquote>
<div><br></div><div>Lost me there. What is your concern with another tab? Browser should not allow one tab to run script in the context of another tab.</div><div><br></div><div>From what I understand, YUI.Get simply allows dynamically fetching content from third-party sites (just like you can with markup in your page). That's not a security risk itself, unless you are fetching from an untrusted third-party site.</div>
<div><br></div><div>You would have to add the YUI.Get code in the first place to your own page so it's not really cross site scripting if it's your own script that is running.</div><div><br></div><div>Sorry, I don't understand your last half a sentence about gmail. (Although, I've often wondered about their auth mechanism.)</div>
<div><br></div><div> <...></div><div>
<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
And again, I'm no security expert and this with javascript/browser</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
lack of security is fairly new to me so I'm not at all betting my</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
dirty undies that I'm correct. I'd be a lot happier if I'm not since</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
this would add a lot of hassle.</blockquote><div><br></div><div>I'm not a security expert, either. This may be the wrong list for security experts.</div><div><br></div><div>But, in general, off the top of my head the standard recommendations include:</div>
<div><ul><li>Use cookies for your auth token. Avoid more complex schemes for passing tokens around.</li><li>Use SSL if your site needs to protect private data and user confidence.</li><li>Change session ids upon authorization or switch to SSL.</li>
<li>Use secure cookies (only returned over SSL).</li><li>Use HttpOnly cookies (prevents cookie access in most clients).</li><li>Escape all reflected user data.</li><li>Avoid creating pages that allow users to enter (and reflect) markup.</li>
</ul></div><div>I'm sure there's others that people here can recommend.</div><div><br></div><div><div><br></div></div></div></div>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a><br>
</div>