[Catalyst] Picking template type based on input

[Jon mailinglists]

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.org> 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.com>
> 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.org
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>