Ok, so I figured out (one of the reasons) for my long-held assertion that “MySpace.com doesn’t work in any browser”. Short story: On first visit, the site records your browser version and other information. If any of this information changes while you’re surfing, they kick your ass out! Naturally, due to some fun toys on my browser, this info changes constantly ;-)
(Read on for a long and entertaining MySpace rant…)
For the last seven years or so, I’ve run a sweet Internet crapfilter program known as The Proxomitron. This is a powerful pattern-matching engine that intercepts and rewrites HTML before it gets to the browser, allowing such things as:
- Stop windows that pop-up, pop-under, or pop-over
- Stop those un-closable endless banner chains
- Stop pop-up JavaScript message boxes
- Remove web-branding and other scripts tacked on by “free” web providers.
- Convert most ads and banner pictures into simple text links
- Freeze all animated gifs
- Strip out background MIDI songs (or stop them playing automatically)
- Disguise your browser’s identity and version from JavaScripts
- (and much, much more!…)
I was enjoiying the Web without blinking things, popups, float-over ads and unkillable Flash animations long before browsers added their own pop-up blockers… I was also fed up with sites pulling this “this site requires Nutscrape v4.1 or higher!!” crap, so I added a filter rule that always reported my browser version as “Mozilla/8.0” (a very capable, futuristic browser, especially 7 years ago ;) . And as long as I was faking my browser version, I also had it add on a random quote to the version info with each request. This way, when vain webmasters generated statistics for their web sites (how many hits per day, what browsers, OSes, etc.), all the quotes* would show up in it. E.g.:
Mozilla/8.0 (compatible; MatrixViewer 1.0; There is no spoon.)
Mozilla/8.0 (compatible; Oh, and the next .com I catch referring to a personal website as ‘Content’ gets a boot up their ass.)
Mozilla/8.0 (Aww fuck. Now they want my license and registration.)
Mozilla/8.0 (compatible; but we can fix that… ; The BASTARD GEOCITIES SYSADMIN FROM HELL LIVES!!)
Mozilla/8.0 (compatible; If you’re searching for the meaning of life; this isn’t where to find it.)
Mozilla/8.0 (compatible; Quit looking here and get back to spanking your monkey.)
Mozilla/8.0 (compatible; Woo-hoo, I’m in a famous site’s Web log. HI MOM!)
Now all Web sites just magically worked (no matter what old-ass browser I was running on my old-ass computer back then), and I kind of forgot about it.
Fast-forward to the not as distant past, and I come across a couple sites that act just plain broken, notably MySpace. I had some friends on it begging and hounding me to create an account, so I did… and I tried to like it, I really did. And I tried to use it, I really did. But not only was the site guilty of breaking every rule in the HTML book and being impossible to navigate, but I’d log in, click on a link, and…
“Sorry… You Must Be Logged-In To Do That!”
So, grumble, re-log-in, click a link…
“You Must Be Logged-In To Do That!”
Okay, this site’s fuckin’ broken. Maybe it works in IE. Load up Microsoft Idiot Exploiter, login, click a link…
“You Must Be Logged-In To Do That!”
A few iterations of this and I wrote this site off as unusably defective. “Meh, maybe I’ll try back in a year or so and see if you’ve got it fixed.” I might have been tempted to email them to report this defectitude, but never did, most likely because I had to be Logged In To Do That.
Recently, someone linked me to a video hosted on Myspcae. Page loaded, video started playing, and after about the first three frames I got auto-redirected to a page to the effect of “An unknown error occurred.” Ah yeah, I remember those. Reload, and same thing. Now, the page had already downloaded completely, rendered, loaded the flash video player, and started playing. At that point, there’s no possible error that can occur – everything that needs to happen in the HTTP stream has already happened. It would be like getting up in the morning, doing your morning routine, driving to work, sitting down at your desk and then being told apologetically that your car didn’t start. This “error” can only mean that some scripted monkey-business is afoot.
So, why would a noisy, flashing ad-laden site like Myspace try to intentionally kick me out after the fact? A handful of commercial sites, paranoid that somehow, somewhere, a user is not making them money, try to detect these “sour users” according to some conditions, redirecting viewers to an error page if they detect one. Not accepting our cookies? Bamf, go away. Blocking ads? Yerrouttahere. No JavaScript? Piss off, mac.
As a quick experiment, I disabled the Proxomitron and tried again. No error redirect; everything worked fine. Re-enable, error message. Further investigation reveals that the difference was not even in the ads that were blocked, but the random quote in the User-Agent field. It turns out that the site, in some paranoid effort to catch (unspecified riff-raff), saves your browser version and similar info, checking it on every subsequent request to kick you out if it changes!
Officially, your browser version or similar information (IP, etc.) should rarely change during a session. Maybe Firefox installed an automatic update while you were browsing, etc., but that doesn’t happen often, right? Not quite… there are several legitimate reasons why this info could change frequently, and why it’s Bad Practice to try and validate sessions on it. Not just wiseasses like me having fun – anonymizers will constantly fake which browser gets reported (oh, you don’t want anonymous users?), various proxy servers will load-balance requests out from different IPs, and various toolbars and other junk users install (knowingly or not) will insert their own crap in these fields, sometimes on a per-request basis. Finally, users may use tools like User-Agent Switcher to fake MSIE because your site, or another just like it, really is broken.
Using the User-Agent field as part of session validation in this manner will do absolutely nothing** to impede actual riff-raff (spammers, etc.). They’ll just pick the most generic browser name and version, and then NOT CHANGE IT, just like a normal user. Spammers try as hard as possible to disguise themselves as normal user traffic, not do things to intentionally stick out like a sore thumb. Yet, I still see shite like this on production web sites. I’ve found that the Simple Machines Forum software also does this by default. Taken from the source code (/sources/security.php):
// Verify that they aren't changing user agents on us - that could be bad.
if (... $_SESSION['USER_AGENT'] != $_SERVER['HTTP_USER_AGENT'] ...)
$error = 'smf305';
is the cause of mysterious “Session verification failed!” errors for logged-in users who have something diddling their User-Agent string. (A hidden setting called ‘disableCheckUA’, accessible only by hand-editing the SMF database, disables this misfeature.)
Thus ends another long and winding ex-web-developer rant. Tune in next week for “Thou Shalt Not Advertise On 404 Pages, Fucking Eyeball Theives”.
* and my personal favorite (used only briefly), for having fun with overly vain webmasters looking at their site statistics:
Mozilla/8.0 (compatible; <script>alert(“You are the 10064th victim of the Browser String Virus! \n\n Now, to tackle that darned hard drive…”);</script>) . Most stats packages of the time didn’t expect these fields to contain stuff like HTML and Javascript, and so didn’t filter it.
** Technically, if the site has uncorrected, wide-open security holes and can’t find them, re-validating the IP address / User-Agent / etc. on every hit is a stopgap measure that can catch most session-hijacking attempts (at the expense of also locking out many legitimate users, of course). If a user’s authenticated session ID is stored in a cookie, and a vulnerability allows a malicious user to remotely steal the authenticated user’s cookie (e.g. via cross-site scripting exploit), the malicious user could spoof the logged-in user by presenting the hijacked cookie (until the authenticated user logs out or session expires). But if you check the UAgent too, the spoofer also has to know the user’s exact browser version. (Of course, if the spoofer can steal cookies via XSS, he already has this information, so it’s down to checking the IP address.) So, validating sessions on UAgent and IP can mask some gaping security holes and let you get rid of most of your bathwater… just depends how many expendable babies you have.
Leave a Reply