jon.mlist at gmail
Mar 28, 2010, 7:12 AM
Post #12 of 22
(2929 views)
Permalink
|
Hi
Top posting, don't rip my head off.
I'll try explaining a bit better. English isn't my first language and
it can be a bit hard explaining too abstract things sometimes. So a
more hands on try coming up:
In my catalyst app I have this sub (not really, but this makes things
easier to follow):
sub get_info : Local {
my ($self, $c) = @_;
my $info = $c->user->member_info;
my $res = 'MyNamespace.callback({"ResultSet":{"totalResultsAvailable":"73399","firstResultPosition":"0","totalResultsReturned":"20","Result":[{"Title":"'.$info->get_column('first_name').'
'.$info->get_column('last_name').'","zip_code":"'.$info->get_column('areacode').'"}]}});';
$c->response->body($res);
}
One has to be logged in, and one obviously is seeing that $c->user is set.
If I now on another domain put this html/js:
<div id="container"><button id="siteExplorerData">Click
me</button><div id="results"></div></div>
function(Y) {
MyNamespace = YUI.namespace('example.SiteExplorer');
var elResults = Y.one("#results"),
tIds = {},
loading = false,
current = null;
var onSiteExplorerSuccess = function(o) {
// stop blocking requests
loading = false;
};
var onSiteExplorerFailure = function(o) {};
var onSiteExplorerTimeout = function(o) {};
var getSiteExplorerData = function() {
if (loading) {
return;
}
loading = true;
//prepare the URL for the Yahoo Site Explorer API:
var sURL = "http://MY-CATALYST-SERVER:3000/member/get_info";
var transactionObj = Y.Get.script(sURL, {
onSuccess: onSiteExplorerSuccess,
onFailure: onSiteExplorerFailure,
onTimeout: onSiteExplorerTimeout,
timeout: 20000,
context: Y
});
current = transactionObj.tId;
};
MyNamespace.callback = function(results) {
var aResults = results.ResultSet.Result;
tIds[current] = true;
var html = "<b>FAILED</b>"
if(aResults)
html ="<li><strong>" + aResults[0].full_name + " lives in "
+ aResults[0].zip_code + "</strong></li>";
//insert string into DOM:
elResults.set('innerHTML', html);
};
//suppress default form behavior
Y.get("#siteExplorerData").on("click", getSiteExplorerData);
});
(it's basically this YUI example:
http://developer.yahoo.com/yui/3/examples/get/get-script-basic.html)
I then login to my application in one tab, and in another tab access
this js/html. That will give back the data about me since I've got a
valid session which gets sent to my catalyst server. That means
evilempire.com has access to my logged in users data, and that's what
I want to protect them from. XSS from another site.
That's why I was talking auth tokens or some other means of protection.
I suppose more people have thought of that, and this isn't really
Catalyst specific but very general. What I wonder though is if there's
any built in mechanism to protect from that since if I haven't got it
all wrong are cookie based sessions pretty much useless as security.
Was this easier to follow?
/Jon
On Sat, Mar 27, 2010 at 5:09 PM, Bill Moseley <moseley [at] hank> wrote:
> Hi,
>
> 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?
> Perhaps you could provide a specific example or link to an example we can
> review if it's something specific.
> Maybe someone else can respond if you have a specific attack in question.
> 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.
> Other comments below:
>
> On Fri, Mar 26, 2010 at 3:52 PM, Jon mailinglists <jon.mlist [at] gmail>
> wrote:
>>
>> User data for instance, say I have an application which is password
>> protected and I'm using the Authenticate/Authorize model coming with
>> Catalyst. I then protect the user data with a session cookie making
>> sure $c->user->address is shown and editable by the logged in user
>> (based on the thought that only the user can send me the cookie).
>
> 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?
>
> The general answer there is, again, never reflect user-entered data without
> escaping.
>
>>
>> How do I protect that from another site with another tab? YUI.Get
>> allows cross site requests, I haven't looked in too deep into it but
>> when I take the url I see the javascript requests in gmail does and
>> put it in a small YUI snippet will I get all my mail:
>>
>> 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
>
> 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.
> 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.
> 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.
> Sorry, I don't understand your last half a sentence about gmail. (Although,
> I've often wondered about their auth mechanism.)
> <...>
>>
>> And again, I'm no security expert and this with javascript/browser
>>
>> lack of security is fairly new to me so I'm not at all betting my
>>
>> dirty undies that I'm correct. I'd be a lot happier if I'm not since
>>
>> this would add a lot of hassle.
>
> I'm not a security expert, either. This may be the wrong list for security
> experts.
> But, in general, off the top of my head the standard recommendations
> include:
>
> Use cookies for your auth token. Avoid more complex schemes for passing
> tokens around.
> Use SSL if your site needs to protect private data and user confidence.
> Change session ids upon authorization or switch to SSL.
> Use secure cookies (only returned over SSL).
> Use HttpOnly cookies (prevents cookie access in most clients).
> Escape all reflected user data.
> Avoid creating pages that allow users to enter (and reflect) markup.
>
> I'm sure there's others that people here can recommend.
>
> --
> Bill Moseley
> moseley [at] hank
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
>
_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/
|
