I generally prefer HTTPS browsing. When I tried to go to https://www.gamedev.net many resources on the website failed to load. This made me question GameDev's HTTPS support.
So then I decided to test the login form. To my surprise, it doesn't use HTTPS!
The login form does a POST to "http://www.gamedev.net/index.php?app=core&module=global&section=login&do=process" (not that it's NOT https). I wanted to see if I could capture my password using WireShark, and to my dismay it was incredibly easy:
[attachment=24127:Screen Shot 2014-10-08 at 10.59.17 AM.png]
This shows my username and password as part of the POST in clear text. I have redacted with black my password, the hex dump, and portions of the POST data that aren't immediately relevant.
Guys, this is a huge security vulnerability.
**Passwords are sent over clear-text on GameDev.net**
Yeah, it's been this way for ages. Definitely avoid reusing login credentials on any site that doesn't use good authentication.
You can use twitter or google to login, so logging in happens via Google's https login page.
Author
Certainly, but I'll bet lots of people have (even though they shouldn't). I think secure should be the default for this site, rather than insecure.Yeah, it's been this way for ages. Definitely avoid reusing login credentials on any site that doesn't use good authentication.
That's a good alternative, but given that GameDev.net already has a valid SSL/TLS cert, they might as well use it...You can use twitter or google to login, so logging in happens via Google's https login page.
All HTML forms seem to have http hard-coded. The backend doesn't seem to care whether or not you post in HTTP or HTTPS. Therefore, it should be safe to force HTTPS or even remove the protocol from the URL.
So, here's a quick greasemonkey script I wrote to drop the protocol from form actions:
Well, shame on me for making the assumption that IPS doesn't eat anything that looks like a regular expression and contains two forward slashes.
So, here's a quick greasemonkey script I wrote to drop the protocol from form actions:
// ==UserScript==
// @name Form Action Protocol Rewrite
// @namespace fastcall22.com
// @description Rewrites form actions to use the current protocol context
// @include /^https?:\/\/(www\.)?gamedev\.net\//
// @version 1
// @grant none
// ==/UserScript==
(function(){
Array.prototype.forEach.call(
document.querySelectorAll('form'),
function(f) {
f.setAttribute('action',n = (f.getAttribute('action')||'').replace(/^https?\:\/\//,'//'));
console.log(n);
});
})();
Well, shame on me for making the assumption that IPS doesn't eat anything that looks like a regular expression and contains two forward slashes.
lol I ran into that forum issue before a couple of days ago.
Anyway, I imagine the reason the URLs are hardcoded is because without the protocol browsers can decide that the address is relative and not absolute and thereby break the whole thing (in other words, the protocol is required, pretty much). Although hardcoding to http instead of https is a bad idea, yeah.
Author
The protocol is never really required. You can start with "/" and it's taken as the root of the current domain (for example, "/foobar" is <current-protocol>://<current-domain>/foobar, so here on this site it would be http://www.gamedev.net/foobar). Alternatively, you can use "//" to inherit the protocol of the current page (that is, "//foobar" is <current-protocol>://foobar, which would be http://foobar here on GameDev.net).Anyway, I imagine the reason the URLs are hardcoded is because without the protocol browsers can decide that the address is relative and not absolute and thereby break the whole thing (in other words, the protocol is required, pretty much).
Either way, HTTPS should be hard coded for a login POST with a password being sent.
(ugh, the editor ate my post, and I don't have time to retype it)
I turned off https logins a while ago because something wasn't working but at this point.. I forget what that something was and whether https was related so..
It's back on for now.
Obviously the NSA is behind all of this. You can't deceive us Michael.
I turned off https logins a while ago because something wasn't working but at this point.. I forget what that something was and whether https was related so..
Obviously the NSA is behind all of this. You can't deceive us Michael.
I turned off https logins a while ago because something wasn't working but at this point.. I forget what that something was and whether https was related so..
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
