myfavoritebeer.org javascript login extremely naive
Simon Horton
example website code and then think that they are using the new
BrowserID best practice from the site, remember that browsers are
inherently insecure:
1) Open firefox
2) Install Firebug extension
3) Open firebug and open the console tab
4) Copy the following code into the console and then click run:
var data = {email:"bill....@microsoft.com"}
var l = $("#header .login").removeClass('clickable');;
l.empty();
l.css('opacity', '1');
l.append($("<span>").text("Yo, "))
.append($("<span>").text(data.email).addClass("username"))
.append($("<span>!</span>"));
l.append($('<div><a href="/" >(logout)</a></div>'));
l.unbind('click');
var iurl = 'http://www.gravatar.com/avatar/' +
Crypto.MD5($.trim(data.email).toLowerCase()) +
"?s=32";
$("<img>").attr('src', iurl).appendTo($("#header .picture"));
loggedIn(data.email);
Congratulations you are now an authenticated bill....@microsoft.com
on the myfavoritebeer.org site, done in all of 5 seconds.
At least if you do the verifiedEmail call from a server, open a
session and then check all calls from browsers have a session then you
have some form of barrier.
So this post is over the top, but remember there are lots of graphic
designers and others that do not understand the security side of
things, if they come to the example website they will assume it is a
best practice implementation, copy and paste and then think BrowserID
is bad when someone points out to them how insecure the example
website implementation is.
Otherwise I think the goal / design / idea of BrowserID is great, just
make the example better or explain up front it is very insecure.
Michiel de Jong
entirely. It does no ajax calls to anywhere. It stores your favourite beer
in the browser, and it never leaves from there.
In fact, do the following to test this:
I followed the steps you describe, and set Bill Gates' favourite beer to
"Sterni".
So if this is really a security flaw as you say, if you now log in as Bill
Gates, you should see Sterni as his favourite beer, right? Afaics, this will
not be the case. By changing the code of the app in my browser, I only
achieved that: changing the app in my browser.
In defense of the correctness of the demo app's implementation, it does
verify the assertion it receives:
https://github.com/lloyd/myfavoritebeer.org/blob/master/static/js/main.js (line
29).
So if you see this demo app, and consider using its code as a starting point
for doing something server-side, then it should be clear that you would want
to do the verification from your server and not from the browser. I don't
think anyone would do an ajax call for the verification, and then have the
client-side send {status: "ok"} up to the server, and have the server
believe that.
Now, I do agree with you that it's always better to put more warnings than
less warning in this sort of thing. So the code could contain a comment
saying 'warning: this is a client-side app. If you are writing a server-side
app, then please don't just follow this code literally and then send
{status: "ok"} up to the server, because a malicious user could forge that
from firebug, and thus fool your server. Instead, if you are opening up
server-side resources to logged-in users, make sure to do the verification
of the assertion from the server, and not (only) from the client.'
All the above IMHO and AFAICS, please correct where wrong.
Cheers!
Michiel
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>
Simon Horton
> IANASE, but i think you're confusing here. The demo app runs clients-side
> entirely. It does no ajax calls to anywhere. It stores your favourite beer
> in the browser, and it never leaves from there.
>
> In fact, do the following to test this:
>
> I followed the steps you describe, and set Bill Gates' favourite beer to
> "Sterni".
> So if this is really a security flaw as you say, if you now log in as Bill
> Gates, you should see Sterni as his favourite beer, right? Afaics, this will
> not be the case. By changing the code of the app in my browser, I only
> achieved that: changing the app in my browser.
>
> In defense of the correctness of the demo app's implementation, it does
> > var l = $("#header .login").removeClass('clickable');;
> > l.empty();
> > l.css('opacity', '1');
> > l.append($("<span>").text("Yo, "))
> > .append($("<span>").text(data.email).addClass("username"))
> > .append($("<span>!</span>"));
> > l.append($('<div><a href="/" >(logout)</a></div>'));
> > l.unbind('click');
> > var iurl = 'http://www.gravatar.com/avatar/'+
> > Crypto.MD5($.trim(data.email).toLowerCase()) +
> > "?s=32";
> > $("<img>").attr('src', iurl).appendTo($("#header .picture"));
> > loggedIn(data.email);
>
> > on the myfavoritebeer.org site, done in all of 5 seconds.
>
> > At least if you do the verifiedEmail call from a server, open a
> > session and then check all calls from browsers have a session then you
> > have some form of barrier.
>
> > So this post is over the top, but remember there are lots of graphic
> > designers and others that do not understand the security side of
> > things, if they come to the example website they will assume it is a
> > best practice implementation, copy and paste and then think BrowserID
> > is bad when someone points out to them how insecure the example
> > website implementation is.
>
> > Otherwise I think the goal / design / idea of BrowserID is great, just
> > make the example better or explain up front it is very insecure.
>
> > _______________________________________________
> > dev-identity mailing list
> >https://lists.mozilla.org/listinfo/dev-identity
Sure I can agree with that.
I guess the point is more that it is very confusing in terms of
understanding what BrowserID is and what it does for me. Basically I
was thinking that the idea is that instead of users needing to have to
create a new user account name and password for every site under the
sun they could sign in really quickly with BrowserID instead.
Great that would make life easier for everyone involved, then I look
at the example code but it is all in the browser, and it doesn't
matter that it is insecure since the app does not save or store
anything..... so why do you need to login, and I guess BrowserID is
not trying to solve the problem I thought it was trying to solve?
(i.e. having to create 100 different accounts all over the net and
having to remember passwords for them all)
Michiel de Jong
> the example code [is] all in the browser, and it doesn't
> matter that it is insecure since the app does not save or store
> anything..... so why do you need to login[?]
yeah, i agree it's a bit silly/useless to log in to a client-side only app,
and i also hadn't realised that fully at first! It's apparently really only
an example of the login flow, not an example of an app that actually uses
BrowserId in the way you would really use it. Which is fair enough. It just
wasn't as clear at first glance.
So yeah, i agree with you there should be a warning about this in the code,
so that all becomes a bit clearer. I would propose something like the
following:
https://github.com/lloyd/myfavoritebeer.org/pull/3/files
Cheers,
Michiel
Simon Horton
> On Jul 16, 12:09 pm, Michiel de Jong <mich...@unhosted.org> wrote:
>
>
>
>
>
>
>
>
>
> > IANASE, but i think you're confusing here. The demo app runs clients-side
> > entirely. It does no ajax calls to anywhere. It stores your favourite beer
> > in the browser, and it never leaves from there.
>
> > In fact, do the following to test this:
>
> > I followed the steps you describe, and set Bill Gates' favourite beer to
> > "Sterni".
> > So if this is really a security flaw as you say, if you now log in as Bill
> > Gates, you should see Sterni as his favourite beer, right? Afaics, this will
> > not be the case. By changing the code of the app in my browser, I only
> > achieved that: changing the app in my browser.
>
> > In defense of the correctness of the demo app's implementation, it does
> > verify the assertion it receives:https://github.com/lloyd/myfavoritebeer.org/blob/master/static/js/mai...
To try and clarify what I mean, I understand that firefox is helping
us out here and is using private / public keys and a protocol to
assert the identity of the user -- this is really useful -- the
question is then the last step of the process, the actual javascript
application / code is inherently insecure so how do we deal with that?
--> if the answer is that you have to do it on the server then why
build support for this into the browser?
I am guessing I am not understanding some step in this process.
Ben Adida
> Otherwise I think the goal / design / idea of BrowserID is great, just
> make the example better or explain up front it is very insecure.
I agree with you. We'll point out that myfavoritebeer.org is meant to
explain the user flow, but that secure implementations should do the
verification on the server.
Note that the developer instructions provide appropriate guidance, we
were hoping that's where people would start:
https://browserid.org/developers
Thanks for your feedback!
-Ben
Simon Horton
Thanks Ben, I was just a bit confused and trying to understand the new
technology :-)
I guess what you do is in the getVerifiedEmail function that receives
the assertion string you send that down to the server, it then calls
verify and checks that it worked ok and then responds to the client
with the email that logged in ok. In addition it opens a session or
similar to mark the user has logged in and give them access to their
server resources. I think it was this step that I missed in the
explanation at https://browserid.org/developers.
Of course the big gain you get is then people can "create an account"
at your server just by logging in with BrowserID.
/Simon