It's also trivial, using Javascript, to change the page's contents. Say, setting the URL to which the admin user/pass is submitted to one on the attacker's site. The site could then record the login information, and redirect the browser to the real login form, such that it isn't even apparent that it's happened.

And yes, it's easy to only send the "bad" javascript to people loading this page, not to the entire web. Just check the HTTP "Referer" header in the request for the script. Yes, that works with DNS exploits too.

All they did was stick the js file in the website's global header or footer, and so it shows up on admin pages too. I would imagine this is a pretty common situation across many websites - I know I've done it in the past.

We can agree that is not really needed (admin visits are surely going to be massively buried by user visits), and that the risk is pretty small, so yes, they should add a quick condition around that script tag...

As a long-term NoScript user, I have avoided giving Google scripts much play. Since I give *any*, I supposed I'm still screwed, but I do avoid giving Google-analytics any freedom to roam. The one exception: when I was trying to view the Obama web site. I could see *nothing* without enabling a whole host of crapola.

Sad. Perhaps when he gets the man who invented the internet - or perhaps Mr. Hat from xkcd - on his S&T team things will turn around.

Do no evil. Right. Now what's that loud "whump whump whump" noise I hear getting closer....

McCain was honest about his ignorance of all this new fangled intar-web stuffs. Now it seems Obama's '1337 h4x0rs don't know J4(|{! Who got $k0013d now? lolz

As soon as you allow JavaScript to be run on the domain it acts with the same privs as if it came from that domain, which sort of makes sense.

So, yes it can snoop.

You can set cookies to not be read by JavaScript (HTML only) and of course you can set them to be only transmitted via SSL.

At the end of the day, if you want security then you don't let third parties on and you house at your own location. That's pretty simple to get.

But, before we all go and get our collective knickers in a twist, if JavaScript is going to be locked en masse then it will become a backend server call, which is even worse, so hoorah for JavaScript it adds security.

Whenever domain A includes script or images from remote domain B (and without using an iframe), domain B can control the content - and in the case of javascript, take over - the control of domain A. It's a form of XSS, but is an unfortunate, accepted technique based on trust, and is used on the vast majority of sites. Practically all web tracking counters work this way.

The choice to include tracking javascript on a popular government-related site is probably not a wise one, but could have been avoided.

"What reason do we have to think anyone inside the company would do something as nefarious as this?"

You mentioned that exploits of the urchin.js file could prove especially effective when combined with network or browser attacks, yet come back to the attack relying on someone inside google. It doesn't.

Network attacks could include attacks on the DNS system, pointing google-analytics.com to the attackers machine from which they serve up their own urchin.js file. From what I can see at google-analytics.com, google like to redirect pretty much everything on that domain to a google.com/analytics/xxxxxx address. If they do the same thing for those viewing their own stats (I don't use it), chances are such an attack would go unnoticed for days or weeks as the only thing being pulled from that domain would be javascript files which nobody looks at.

Browser attacks could include attacks against the host machine as well as the browser, altering the DNS server settings or the hosts file to point to the attackers address for google-analytics. The result would be the same, in that the attacker has control over what your browser thinks is google code.

Such attacks are made much easier when there is no ssl in use to pull the js code, as there are no warnings about invalid certificates.

Even el Reg has a flaw where SSL is concerned with analytics. http://www.theregister.co.uk/Design/javascript/_.js contains this line:

var s='<script type="text/javascript"'; return s+' src="'+ (document.location.protocol == "https:"?"https://ssl" :"http://www") + '.google-analytics.com/ga.js"></script>'

What this line translates to is: if the visitor is at http://www.theregister.co.uk then pull ga.js from google over plain http. Only pull it over https if they are visiting https://www.theregister.co.uk As long as thereg doesn't actually have a https version, then this line is useless. All visitors will receive the script from google over plain http.

"Where the four disagree was how easy it would be for Obama insiders or others to identify a plot as sinister as a rogue urchin.js"

As AC already pointed out, it's possible to hide a rogue file with referer header checks, and other tricks. When I've done security demonstrations using XSS in the past, a favourite was to return the rogue file to an IP address only once. It's likely that anyone attempting to view the rogue file will have already visited the page at least once, so the only thing they see upon accessing it again is a perfectly innocent file.

Such tricks may cut down on the return you get from the exploit (blocked referer headers, machines behind a NAT IP etc), but they keep the thing hidden for longer. If you get every password on the site but it's noticed instantly and passwords are changed, it's done you no good. If you get 75% of the passwords over 3 weeks and those passwords are not changed, you can work on getting the other 25% at your leisure from the inside.

Whilst this isn't a security forum ... now the topic is aired ... it would be good (and benificial to noobs like me) ... to perhaps run a story on offsite scripts in general?

From my perspective ... maybe a little defensive ... any script called from a domain you don't control seems careless at the least ... never mind on an admin page ... but what is the risk?

Millions use analytics ... so is everyone at risk from a roge JS at the Googleplex? ... or just those running that script on admin pages? ... presumably everyone, and a malicious script could do what it likes with your server ... at least as far as whatever process the webserver runs in is allowed (e.g. IUSR on Windows world) ... is that true? ... for example replacing urchin.js with one to load content from a rogue server thats neither Googleplex or yours to infect pcs? ... or is it limited to (for example) session data?

This raises more questions about the use of any external scripts / content you don't host than the fact it's some specific website.

A followup noobs guide to the risks ... now the topic is aired ... would be welcome.

Keep up the good work fokes! :)

Ian.

Google analytics scripts to run? NoScript solved that problem a long time ago.

"it's disgraceful if whoever maintains his Internet presence is as clueless as this article portrays. I think I smell YetAnotherPaperEngineer[tm] born out of the Web boom who has absolutely zero Internet version of street smarts ..."

...runs on the client - not the server so how could change.gov be exploited using urchin.js?

Not only is this an initial fail but a complete followup fail too.

It does occur to me that this may not actually be the real admin page - particularly since, as others have pointed out here, there is no reason to put urchin.js on a genuine admin interface since you'd only be monitoring your own team's visits. If it's a decoy, on the other hand, you might well be interested in traffic to it.

Of course, given the number of newbie mistakes this team of clowns has made already, I wouldn't be surprised to find their CMS still has the default login enabled (or a username and password of 'change').

One serious flaw in the article, though: a DNS attack which replaced urchin.js with a copy from another server would work just as well for substituting the change.gov login page itself in the same way. It does open the door to attack from Google employees who have the right access to the Analytics service - but any external attacker wouldn't be able to do anything through urchin.js that he couldn't do as easily to change.gov itself.

"By referring to javascript that's hosted elsewhere, you're basically at the mercy of that other organization,"

Like the ISP? Like the network admin? You're always at mercy to some provider on the net.

I think the point of putting Urchin on the admin page is to make it easier for them to log the people hitting that page and trying to log in. They chose to trust Google's admin skills for that which isn't surprising since Google CEO was a campaign adviser.

Meh.

You get a complete fail for failing to understand the article and comments about dns injection and then insulting the Reg and followup posters.

This article conflates two issues. Firstly, the security issues related to including external client side scripting in a page. The problems associated with this are pretty well covered in the article.

Secondly, even if the external javascript is not used to execute malicious credential stealing code, it is a danger in itself. That this danger is poorly understood is clear from comments like this by "schill":

"Practically all web tracking counters work this way."

Tracking is the keyword here. Google Analytics (previously known as Urchin before the Larry and Sergei like the razor so much they bought the company) is all about tracking users as they travel the interweb and is a pretty hefty violation of most data protection laws. Idiots use it because they think they are getting some statistics for free when in fact they are selling valuable information to an advertising agency in return for some pretty graphics.

Thirdy, just because "everyone else is doing it" is never a justification for an action: siphyllis is a very popular sexually transmitted disease. Does that make it desirable?

Add *.googleanalytics.com/* to your content blocker.

"If that urchin.js can be controlled by somebody with malicious intent (and with the latest DNS exploits they don't even need to control the google server), then the content of those Obama sites could be manipulated," he writes in an email to The Register.

If you can manipulate the dns, why not just point the change.gov and barackobama.com somewhere else ? that way you will get everything, even if they don't have javascript enabled, better ? no ?

I use Google Analytics on my websites but only on the public, non-https and non-admin sites. Logins to the hidden content are completely separate from the public sites, no links from the public sites, no non-https landing sites and no 3rd party site scripts. Still not 100% ideal but the data I get from GA is useful enough that I'll risk the consequences for my fairly unimportant sites.

Surely adding GA to a global header is lazy and counter-productive, isn't it? How difficult is it to simply have a little script that does an add-on to the HTML published to certain directories? Even the consumer-oriented iWeb has a third party Mac Automator script that allows users to selectively choose what I want to "infect" with GA.

...would also run on the admin's clients.

It runs on the client and so can hijack the authentication to the admin portal. It could easily rewrite the page to redirect login attempts to a rogue server, or just read and steal the cookies of authed users

Once you have an admin login the site can be altered any way they wish, no doubt there will be a ton of data that can be stolen, and we all know how people like using the same password for multiple accounts, so you'll also probably gain access to email accounts and the like.

The only fail here is people not understanding the risks of cross server scripting.

Because IN THEORY someone could change the analytics script to hand over the security credentials of the user working on the client. That is to say, that instead of sending usage info back to google, it could send the user's authentication token.

To all the NoScript/clientside commentators, there seems to be a misunderstanding here. NoScript will protect YOU, and YOU will not become an attack vector. However, anyone who isn't using NoScript CAN be an attack vector. (It is also highly likely that the ADMIN console will use JavaScript, since that kind of complex webapp will generally speaking slow to a crawl without it.)

So if someone is running JavaScript on the client, how can this affect the Server? Well when the call to urchin.js is made, if this call can be hijacked in any way (as mentioned, there are several ways this can happen) then the CREDENTIALS of the browser making this connection can be exposed back to the originator of the false urchin.js, wherever they are. They can then use these credentials to log in and do what they want to the site using the Admin console.

I hope this makes it all clearer.

BTW sorry about SHOUTING, but I can't use bold or italics and didn't fancy *this*.

Yes, in theory a remotely hosted javascript file can potentially be a security threat, in this specific case that threat is nonexistant.

Google, probably more than any other company in the world, has to be concerned with data security, and I doubt that hijacking urchin.js is as easy as modifying the code and uploading to an FTP server. I expect that any change to production code within google has to go through a rigourous QA procedure where and changes made have to be both justified and tested by people other than the initial programmer before getting anywhere near a live environment. Any changes made would also be logged against the programmer using whatever internal CVS system Google uses - so any attempt to hijack the code could be easily traced back to the original programmer.

Also, unlike most other remote scripts, there is AFAIK a contract between yourself and Google when you subscribe to the service so Google could be liable for any security breach through their software.

If you are going to go to this level of paranoia regarding a site, then the security risk doesn't even start at Analytics let alone end there. A maintenance engineer at the hosting provider with access to the physical machine, a support engineer at the hosting provider with administrative access to the box, your own programmers could writing a backdoor for themselves, anyone working for Obama who has access to the information - all of these are more likely than Google hijacking your Analytics.

There is a line where security and paranoia goes from reasonable precatuion to loopy loopy la la land - and this is well over the line, and still not news-worthy. If you can't trust any 3rd party products, then why are you relying on Verisign for your SSL certificate, Unix for your server, PHP for your programming language - they could all be compormised by a malicious programmer just as much as google to compromise your data security.

I'm no security expert, but even I know not to include a call to 3rd party Javascript on sensitive pages.

I'm interested to see what some of the commenters on the original story ("Utter utter turd", "Worst article ever", "What kind of failed computer geek wrote this article about nothing?") say in response.

This story seems to born from asking 'experts' known to over-hype things and scream that the sky is falling when it in fact, not.

Sure, an attacker who manages to hack Google, or a Google employee could potentially hack change.gov, but as the reporter noted, it's quite clear that the Obama campaign has more serious concerns than getting hacked by Google staffers or hackers who decide to change the contents or urchin.js.

Also, DNS poisoning google-analytics.com is kind of pointless, as they're probably not even using the SSL interface (which has a certificate that is only valid for donate.obamabidentransitionproject.org and www.donate.obamabidentransitionproject.org, btw).

And the fact that it was on administrative pages does not make much difference from it being on non-administrative pages, if it's on the same domain, it doesn't matter which pages it's on.

So how about we keep a lid on the FUD, eh?

Dear Sir, please read the article. It's quite plain english -- even I understood most of it. :-)

Alternatively, just trust the smart people when they say it's a real problem. And have a nice weekend!

Did you even read the article? Yes javascript runs on the client, but if you have control of the script source then it is trivial to change content. Want to change the title of the page from "Barack Obama" to "John Mcain"? Urchin JS executes on page load, so simple adding a function to do the following:

getElementsByTagName('title')[0].innerHTML = 'John McCain is the US President';

will do exactly that. Urchin.js is in every page, so every client which executes it will do the above change. That is a very basic example of course, but it shouldn't take much imagination to come up with a more malicious use. Each and every page element is changeable by DOM scripting - you could change form targets, cookie handling or submission content to name just three.

@Andrew Ness:

Simple: The JavaScript code runs on the client side and is granted, by the client's security model, the same privileges as a same-domain script. This means that it now has access to the global memory space reserved for the entire application (on the client side, of course), which in turn includes being able to perform requests to the server as if it was part of the original application served by the it.

The article gives the example of the script having access to the Session Cookies set by the server; this alone is a big threat, as it may give the third-party who controls the external script access to session information, or in a worse case scenario, same-privileges to execute requests on the server as the logged-in user.

You seem to misunderstand the threat. It is not that evil JavaScript is going to hack into the server; the threat is that an external party--one over which your organization has absolutely no control--may have access to the same functions, privileges, and features of the application at the server side available to a local user trusted by the server.

-dZ.

"...runs on the client - not the server so how could change.gov be exploited using urchin.js?"

1) Admin connects to login page of website administration over his browser.

2) Website pushes page with instruction to load to urchin.js from 3rd party.

3) Browser downloads urchin.js from 3rd party and executes it. As another poster said "web regrettably relies on XSS" but it' still not a 100% good idea.

4) urchin.js has access to the document presented in the browser, so can tune it. Not sure how much it can twiddle though, Javascript experts help out please!

5) Admin sees login page as normal, so logs in to website.

6) Twiddled document posts captured login credentials to website, but also to evil machine hidden underneath extinct volcano.

7) Admin's work can also be tracked from underneath extinct volcano from this point on.

Malicious script could trick the user into submitting unintended contents using an existing form. You would need to know details of the page you are compromising. But that would be rare and completely noticeable so the risk of getting caught doing this would be really high, SSL and IP access restrictions are a mute point in this case cause js is run on the client although should be active on any CMS.

Google employees could probably find lots of things, find Obama's home ip address and let's see his search history - this would be equally risky and likely more compromising. At the end of the day there is an implied trust relationship with the website you are using.

DNS being taken would be a real problem - if so all bets are off - even on SSL no one pays attention to cert errors anymore. But this is more of a "Sky could fall" type comment.

Yup, and it's a security risk giving anyone (including the admins) access to the admin area. Who knows what they might do!

That and the fact the hosting company probably has access to the files, should it want to.

Suggest the whole site is taken offline, and runs on a disconnected webserver. That way, nothing bad could happen.

Yes, javascript runs on the client, but it has access to everything on the page that the client does.

Cookies that are not set to httponly for instance. Or the ability to change where a form will be submitted to. Either of those can be used to steal login credentials.

If the client happens to be logged in as an admin, you can use the JS to do pretty much anything they could, like adding yourself as a user, deleting records, changing details etc.

It a trivial task for javascript to gather the contents of form fields and send them to an offsite collection point. Read: Trivial to scrape and gather administrative userid and passwords.

I'm surprised that that you classify this article as a "fail".

The only "fail" here is that your failure to grasp that handing a third party over whom you have no control

(1) a map of your website, including non-public administrative pages and

(2) simultaneously providing them a mechanism to gather administrative userids and passwords

is a recipe for insecurity.

And so does the googlesyndication ad server.

Maybe, if the Reg served up ads from inhouse, I'd be willing to look at them. But allowing "googlesyndication" creates tons of eye-hurt from everywhere, and I can't stand it.

Andrew Ness, it RUNS on the client box but the JS code is downloaded from the foreign server-- and so, pretty easily hacked DNS could actually be getting it from Russia, or Nigeria.

The big deal, though, is disclosing the fact that you've gone to talk at big government via the web, and Google now KNOWS this. Sooner or later, "evil gets done".

Latest DNS exploits argument is rubbish, if they'd subverted DNS they could just attack the site directly, no need to try a more heavily cached domain like Google. Furthermore, if you've had your DNS exploited then I really don't think that you're worrying about the .gov websites so much as your bank details.

So in fact the "security risk" is trusting Google. That's it. No other risk. No huge glaring hole apart from Google.

However we trust third party components all the time. The site was built by a third party, it probably used third party controls. So if you're going to trust a third party, one as big as Google is not actually such a risk.

Yes there is potential for an exploit, if an evil oompah loompah gets political, but I really think you've over egged this in the attempt to find a story.

If you really need lessons in how the internet works perhaps you should go on a course (probably not an OU one from what I hear). Your "security risks" are nonsense. If the site is to be visible to users outside the LAN then there are a legion of "risks" which must be taken which make the google analytics trivial.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Just who are these w3 people anyway and what are their connections with the taleban?!?!?!

Is that the Obama camp chose Blue State Digital purely as a political patronage choice, not based on quality of technical expertise choice. Had they made the selection based on quality of technical expertise, they would have gone with a tuely professional outfit.

Much though I hate to admit it, this is not BO's fault. Not only didn't he code the pages, I'm sure he had nothing to do with deciding who did. Still, it does give the impression that his team was more interested in influencing the voters than in getting the job done right. One can only hope that they will learn from this experience and be more careful when they set things up for the new administration. Quite frankly, however, my impression is that BO's main skill is running for office and that he will be more at the mercy of his staff for this kind of thing than many other presidents have been. Only time will tell, and I sincerely hope and pray that I'm wrong.

yes I did read the article and the claims are false. Claiming that the content is in jeopardy by running javascript is bogus.

The representation of the content may be modified on the client side but the real data is cannot be modified unless the attacked browser is adding / modifying content so this is extreme scaremongering.

As other comments have noted, GA is run from El Reg pages so this is just another case of glass houses. If the risk was worth running an article, surely the exposers of this "risk" wouldn't be a vector for the risk?

El Reg's comment page currently uses the following external code:

<script type="text/javascript" src="http://edge.quantserve.com/quant.js"></script>

hm.

"The representation of the content may be modified on the client side but the real data is cannot be modified unless the attacked browser is adding / modifying content"

To use a word you seem familiar with, that's a fail.

The attacked browser need not be doing anything for javascript within the page to launch any links the user has access to behind the scenes. If all you have access to is your own profile, the attacker can automatically change your password and email address for you and send a ping to their server to give them your new password (unless of course the coder had some brains and included a requirement for the original password to be entered before making those changes).

If the user has access to any admin functions (highly likely inside an admin panel), the javascript can do anything that admin panel can do. Add new users, delete users, edit content, run sql commands if the coder was dumb enough to include that "feature".

To others asking why someone would bother using a DNS attack against google-analytics rather than the site itself, a quick question for you. In every day browsing of the net, how many sites do you come across running GA? More than 32% of Alexas top 500 sites run it. The percentage is probably higher for other sites. Poison the DNS for change.gov, you've managed to attack one site. Poison the DNS for GA, you've managed to attack thousands.

http://royal.pingdom.com/2008/05/28/google-analytics-dominate-the-top-500-websites/

I'm with Ian.

Also: NoScript is very nice and I use it. Nevertheless IE still has more than half the market, and it has no such facility (AFIAK). Wishful thinking is just that.

> Comprende?

Some of us have street-smarts.

The person you are replying to apparently doesn't.

Nor do the other people who don't get it.

Hopefully, I can trade 3 decades of "internet knowledge" (whatever that is), for a more than lucrative retirement fixing these kids mistakes ...

Is this website hosted in a data-centre in Obama's basement, patrolled at night by only his most trusted henchmen; Is the content management system written by eunuchs who will only be releasd from their cages in 2015; is everyone with administrative rights vetted for their knowledge and application of network security?

One rogue employee at wherever it's hosted, or on the web app development team, or one slip-up on the security of the campaign team's personal PC security (or using a cyber-café PC with a keylogger on it, f'rexample) could do just as much damage as a rogue urchin file... yes it's a bad idea.. but it's unrealistic to call it a likely threat.

…serve up a local copy of urchin.js, neatly avoiding the whole problem.

Run NoScript, and have appropriate entries in your /etc/hosts file (or even in your router) to keep Google Analytics well away from your machine. There's probably also an extension that silently strips out cookies matching /^__utm/ in order to leave GA guessing.

My point exactly... this is just a little farfetched.

But then again, there's still no reason for putting goolge analytics on the admin side of things, so I suppose you may as well remove all unnecessary routes for attack.

I think the best way forward in this discussion is to observe that there is no such thing as a safe network (local or wide).

Security might be increased provided there are no third party stuffs at all.

Design your own operating system, commission your own hardware, make sure that you own all of the cables, ... even down to ensuring your own power supply that does not run close to other power supplies, ...

So, in the end: want it on the internet? Want it secure? Dream on?

Have had a lovely little "127.0.0.1 www.google-analytics.com" in my hosts file ever since I first noticed a number of websites trying to download this little urchin.js file. Apache logs on the same machine (dev webserver) filled up rather quickly with 404s until I put an empty urchin.js file in htdocs tho.

Solved my paranoia anyway - and speeds up website loading (first noticed when Google was being slow in delivering the urchin.js file and stalled some pages loading)

But I smell bullshit in the air.

With any news event, "experts", "consultants", etc will always go look for some spin to make some sort of ruckus to get themselves and their services/products in the news.

Oh dear, oh dear. Please, stop with this reporting already.

It's still bullshit. If somebody internally compromised urchin.js (now deprecated btw) then the majority of the internet has a big problem, let alone Obama's little blog.

If that little script got compromised then Google have a huge issue in that it would probably spell the end of Google Analytics. Who would trust them after that?

No. This is just scare mongering. You're creating a story out of almost nothing.

And no, just because you got access to the DOM, doesn't mean you had access to the database or "full admin rights".

I say once again. This is a really shitty non-story.

Sounds like your "experts" are as uninformed as 0.2% of your readership.

I just located and viewed it in under 30 seconds simply by Googling for "urchin.js".

Here's the link:

http://www.google-analytics.com/urchin.js

Simply fire that link up in Chrome and you get the full source code. Here's the first few lines for the doubters:

//-- Google Analytics Urchin Module

//-- Copyright 2007 Google, All Rights Reserved.

//-- Urchin On Demand Settings ONLY

var _uacct=""; // set up the Urchin Account

var _userv=1; // service mode (0=local,1=remote,2=both)

//-- UTM User Settings

var _ufsc=1; // set client info flag (1=on|0=off)

var _udn="auto"; // (auto|none|domain) set the domain name for cookies

var _uhash="on"; // (on|off) unique domain hash for cookies

var _utimeout="1800"; // set the inactive session timeout in seconds

var _ugifpath="/__utm.gif"; // set the web path to the __utm.gif file

var _utsp="|"; // transaction field separator

var _uflash=1; // set flash version detect option (1=on|0=off)

var _utitle=1; // set the document title detect option (1=on|0=off)

var _ulink=0; // enable linker functionality (1=on|0=off)

var _uanchor=0; // enable use of anchors for campaign (1=on|0=off)

var _utcp="/"; // the cookie path for tracking

var _usample=100; // The sampling % of visitors to track (1-100).

//-- UTM Campaign Tracking Settings

var _uctm=1; // set campaign tracking module (1=on|0=off)

var _ucto="15768000"; // set timeout in seconds (6 month default)

var _uccn="utm_campaign"; // name

var _ucmd="utm_medium"; // medium (cpc|cpm|link|email|organic)

var _ucsr="utm_source"; // source

var _uctr="utm_term"; // term/keyword

var _ucct="utm_content"; // content

var _ucid="utm_id"; // id number

var _ucno="utm_nooverride"; // don't override

Yes, if you can compromise urchin.js, you can potentially redirect the login form and steal credentials. But to achieve this you are relying on the following:

1. Being able to poison the DNS for long enough that Google doesn't detect it (I'm sure that google*.com finds itself to be a big target for DNS spoofing attacks on a regular basis anyway.)

2. Finding a corrupt Google employee who can modify urchin.js or insert rules that serve your malicious version to visitors of the target site, again for long enough that Google does not detect it.

3. Having an admin user of the target site actually visit it, load a fresh copy of urchin.js (and not the one cached in their browser), and log in to the control panel during the short window in which your exploit is live.

It could be done. But wait - if you're capable of steps 1 and 2 anyway, then why go via Google? It makes much more sense to simply poison the DNS records of the target site itself, or use social engineering on its developers/admins. You'll have a much better chance of succeeding.

It was a poor decision - probably just laziness - to globally include the Google tracking code on all site pages, but the chances of it being used as an attack vector are slim to none.

Am I the only person that on seeing the word 'fail' used in the context of the latest trendy meaning of it, simply ignores everyhing else the poster has to say?

Presumably these people use it in conversation in 'meat space' (another phrase that happily died out).

Or paid shills, defending Google? Perhaps fan boys.

Regardless, stop defending bad security practices.

Same vuln, but with much less "the world is doomed" fud. Good. It's a little tiny (almost unexploitable) vuln on a "private" PR website, FFS. Hardly the end of the world as we know it. Yes, usin JS (any JS) on this page (and any page) is probably a bad idea. No, nasty black hats cannot use it to take over the US or kill your dog.

Any time you stick third-party bits you don't have complete control over you are creating the exact same risk scenario.

This is simply a prominent, high-profile example.

* there should be a "meh", non-issue icon...

Can I just point out that while we all loved the horror and world ending devastation of Dan's DNS exploit, it is not really practical to code websites on the assumption that DNS is exploited. I mean, most people use DNS servers that have since been patched. The exploit was months ago, and to suggest that third party components are wrong because the end user might have a duff DNS provider is basically saying "but what if the end user is comprimised". If they are, then THEY are broken, not your site.

If someones DNS has been poisoned then the whole internet is wide open for risks. As was pointed out when the exploit was published - it broke the internet. You can't base security on the assumption that DNS might be poisoned, it's just too bad an exploit for a server to be able to protect a client from (SSL does help though).

More importantly, DNS is of course served to clients, so to attack the site you would need to directly attack the DNS server of someone you knew was going to visit that site. You would then need to hope their DNS server wasn't patched. You would then need to hope that their DNS server hadn't already cached "google" (fat chance).

The reference to the DNS exploit being required to expose this hole is just about proof that the hole isn't really there.

This is the exact same issue as it has always been ... neither more nor less critical and neither more nor less dangerous than it has ever been.

Sorry, Dan Goodin ... normally your stories are interesting and useful, but you've been trapped by writing this story as if it was a new security issue of some kind, and now you're trapped into trying to justify writing the article in the first place. The second article didn't expand on the first, so much as try a different, unsuccessful tack toward making it seem interesting.

Basically, if a Google employee were to mess with urchin.js, change.gov could be affected.

As could millions of other websites.

Also, if someone were to compromise various DNS services or the hosted files themselves, then there are additional security issues to contend with.

This also goes for potentially millions of other websites.

And if someone were to manage to route all of the Internet's cables through their bedroom, there is potential for disaster for change.gov.

Let's say I'm a rogue Google employee or a DNS cracker or whatever bad guy you prefer, and I have managed to execute any of the numerous attacks that might have an impact on change.gov.

This article and its predecessor both imply that, having done the hacks, I would be intent on changing change.gov to make Obama look bad, or maybe even use that domain for typical XSS purposes, like snagging change.gov admin login data or generating links to other nasty sites to try to trick visitors into doing something not in their favor.

I have control of the urchin.js script and the best thing I can think of to do is change "Obama" to "McCain"? Or maybe I can get the admin credentials for change.gov and, oh boy, look at the crazy fun we're gonna have now! Or maybe not.

Having gone to the trouble of hacking urchin.js (risking job and freedom) or having gone to the trouble of executing a DNS crack (risking fortune and freedom), I can tell you that there are far more tempting targets than change.gov at my disposal!

As before, this is a non-issue. Dan, you owe your readers an apology for going off the deep end on this ridiculous scenario. There is no safe harbor on the Internet ... if someone gains access to any of the thousands of critical bits that make it work, then it doesn't work ... but let's not claim that change.gov's use of Google Analytics code is some kind of special risk element, because it is just as risky as anything else online, which is to say that it is an extremely low risk shared by millions of other sites.

It would be far more useful to report on where the Obamas' new dog will be coming from, as this decision carries more dangerous implications for the world than the Google Analytics issue does. Which is to say ... not many implications for the world in either case.

"What reason do we have to think anyone inside the company would do something as nefarious as this?"

http://www.theregister.co.uk/2008/11/24/verizon_snoopers/

Of course the CMS company could totally screw them to, but risk is the price of sucess. Note to self, 3rd party .js on non SSL admin page = bad. Pretty bad. Not end of world bad, but bad enough to know Obama isn't some super president with programming or computer security experience. I'd say the non SSL is worse than the .js, but whatever. This election cycle has had more hacking than I'm comfortable with. Palin, Obama's phone, websites wtih basically obvious flaws.

If the admin login page is not actually a honeypot?

Does somebody really have to spell it out?

Obama's web page architect has made an error in judgement, security wise.

An error that a PROFESSIONAL in the field wouldn't make.

Is this WebBoomPaperEngineer[tm] going to the White House?

I really, really hope not ...