SECURITY VULNERABILITY - Logins

106 views
Skip to first unread message

Jared Scheel

unread,
Feb 11, 2012, 12:03:27 PM2/11/12
to 8tracks-p...@googlegroups.com
Logins on both the main site and mobile site occur over http, instead of https. This results in usernames and passwords being transmitted in plaintext.

Remi - 8tracks

unread,
Feb 11, 2012, 4:41:04 PM2/11/12
to 8tracks-p...@googlegroups.com
Jared, you're absolutely correct and this does open a vulnerability.
Unfortunately this is a case where user experience and security are
colliding.

The issue is that the page is loaded with http, and on the website we
open up a lightbox for login, the login form is then submitted through
XMLHttpRequest and I'm pretty sure that we cannot submit the form in
HTTPS if the page was loaded through HTTP.

Now, I'm not the first person to deal with this and I found a good
thread about it here:
http://stackoverflow.com/questions/1105934/ajax-http-https-problem

Anyone knows the best way forward?

Remi

--
Rémi Gabillet
8tracks CTO & co-founder

Daniel Drozdzewski

unread,
Feb 11, 2012, 6:06:06 PM2/11/12
to 8tracks-p...@googlegroups.com
Remi,

There are few things you guys could look into:

1) why can't you point the lightbox to call the login through https.
I.e. pass to your lightbox https://8tracks.com/login instead of
http://8tracks.com/login.

This way the form submission using https:// would happen from a page
loaded via https:// (this is my thinking anyway). It will not make
the user happy anyway, as they will see http:// (no padlock) in the
address box of their browser.

2) try forcing nginx to rewrite all http requests to 8tracks.com/login
to use https://
Have a look here:
http://www.ruby-forum.com/topic/179377

3) In case you get HTTP 411 (Length required) response from your
server to your ajax call, simply add empty data (Length:0) to your
https:// post request:

$.ajax({
url: url,
type: 'POST',
data: {}, // <- set empty data
success: function(data, textStatus) {
// do something
}
});


hope some of this helps.


make sure that http://8tracks.com and https://8tracks.com resolve to the same

You should be able to submit forms or ajax calls through https no problem.

--
Daniel Drozdzewski

Daniel Drozdzewski

unread,
Feb 11, 2012, 6:10:06 PM2/11/12
to 8tracks-p...@googlegroups.com
please ignore the lines at the bottom of my last post. They meant to
disappear in the editing process. process fail!


On 11 February 2012 23:06, Daniel Drozdzewski

--
Daniel Drozdzewski

Jared Scheel

unread,
Feb 11, 2012, 10:42:44 PM2/11/12
to 8tracks-p...@googlegroups.com
Hi Remi,
I definitely understand the need for a good user experience, I'm doing the same at our own company! Daniel has a few good suggestions below. To build on his first suggestion, you should replace your current lightbox's html content with an iframe that points to a secure login route which contains the login html content. It looks like what you are doing now is loading the login html directly into the lightbox's content element. Replacing it with a properly styled iframe will mean that the user experience remains the same. The lightboxed iframe can tell the parent page that the login has completed successfully in a number of ways. With modern browsers, you can get fancy with postMessage, but for a cross-browser solutions, you man need to do something creative like modifying the iframe url and polling it in the parent.

Remi - 8tracks

unread,
Feb 28, 2012, 6:27:22 PM2/28/12
to 8tracks-p...@googlegroups.com
Sorry for the late reply.

I've been working on this actually and we're going the CORS
(http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing) way since
it's the easier for us to integrate. The only downside is that it
won't work on Opera so Opera users (all 0.6% of 8tracks users lol)
wont get https login unless they load the full login page.

I'll let you know when it's up.

Remi

--

Ray Slakinski

unread,
Feb 28, 2012, 8:38:03 PM2/28/12
to 8tracks-p...@googlegroups.com, 8tracks-p...@googlegroups.com
cool, you'll have to give us the deets when your ready with that so we can have a smoother switchover ;)

----
Ray Slakinski

Jared Scheel

unread,
Feb 29, 2012, 10:22:53 AM2/29/12
to 8tracks-p...@googlegroups.com
Awesome! Keep in mind, CORS is only partially supported in IE8-9 as well (http://caniuse.com/cors). Good luck and thanks for working on this!

-Jared


On Tuesday, February 28, 2012 5:27:22 PM UTC-6, Remi Gabillet wrote:
Sorry for the late reply.

I've been working on this actually and we're going the CORS
(http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing) way since
it's the easier for us to integrate. The only downside is that it
won't work on Opera so Opera users (all 0.6% of 8tracks users lol)
wont get https login unless they load the full login page.

I'll let you know when it's up.

Remi

Jared Scheel

unread,
Aug 8, 2012, 12:43:59 PM8/8/12
to 8tracks-p...@googlegroups.com
Remi,
I was watching my network traffic on login, and I noticed that you are still using javascript to make the create session request. Even though it is https, the request url still contains all of the login credentials, transmitted in plaintext. You can maintain the exact same login experience by using an iframe and javascript to notify the parent when to redirect. I've recorded a video for you to show you how my startup is able to maintain the same modal experience you want while using an iframe: http://www.screencast.com/t/So9i3ZHwydC2

Thanks!
-Jared

Remi - 8tracks

unread,
Aug 8, 2012, 2:44:35 PM8/8/12
to 8tracks-p...@googlegroups.com
Hey Jared, I was going to follow up on this actually. We just got this
secure login working last week but I was waiting to see how well it
works.

I just checked out your screencast, thanks for taking the time to put
it together. I actually thought of doing it the iframe way (we do this
in other places) but I really wanted to get Cross-Origin XHR requests
working. They worked okay but not that consistently across browsers so
I ended up going with JSONP since we had the API in place already.

As I went along, I did worry exactly about this question of url
encryption on https requests and found this on stack overflow:
http://stackoverflow.com/questions/499591/are-https-urls-encrypted

So I think we're good right? What's your take?

Remi

PS: Oh and I signed up for populr.me, it looks real nice.

Jared Scheel

unread,
Aug 8, 2012, 4:22:12 PM8/8/12
to 8tracks-p...@googlegroups.com
Interesting, I didn't realize that at all! Still, some of the comments
in that answer are important too, like the server logs caching the
request (which is, I'm sure, solvable). Thanks for clarifying this for
me. BTW, thanks for signing up. We are planning on sending out beta
invitations in October. In the meantime, here's a quick pop I made a
little while ago that embeds an 8tracks player. It's pretty sparse
(just some text, and 8tracks embed, and a soundcloud embed), but the
page only took 2 minutes to make :)
http://jscheel.populr.me/the-bass-i-dropped-it?ba

-Jared
Reply all
Reply to author
Forward
0 new messages