back to article Google Analytics — Yes, it is a security risk

Judging from some of the comments responding to our story about security sloppiness on Barack Obama’s website, it’s clear a discussion about the risks of third-party javascript is in order. Contrary to what many commentators believe, widgets used by Google Analytics and similar services do represent a threat, especially if you’ …

COMMENTS

This topic is closed for new posts.

Page:

Anonymous Coward

Javascript attack options

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.

0
0
Ed

It simply lazyness...

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...

0
0
Black Helicopters

NoScript remains your friend

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....

1
0
Alert

At least

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

0
0
Anonymous Coward

Like yeah

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.

0
0
Stop

Non-story; the web regrettably relies on XSS.

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.

0
0

no title

"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.

0
0
Paris Hilton

Offsite scripts in general

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.

0
0
Thumb Down

What? People actually allow

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

0
0
Silver badge

As I said ...

"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 ..."

0
0
Dead Vulture

Javascript

...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.

0
0
cjk
Boffin

Indeed Javascript...

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

0
0
Thumb Down

RE: Andrew Ness

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.

0
0
Syd

@Andrew Ness

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.

0
0
Boffin

NoScript and JavaScript ony runs on the client...

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*.

0
0
Stop

A delightfull mix of bullshit and backpeddling

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.

0
0
Thumb Up

Interesting

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.

0
0
Black Helicopters

We don't need no FUD

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?

0
0
Happy

@Javascript 2008-11-22 08:27 GMT

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!

0
0
Stop

@Andrew Ness

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.

0
0

Re: Javascript

@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.

0
0
Silver badge
Pirate

@Andrew Ness

"...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.

0
0
Coat

re: Javascript

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.

0
0
Thumb Down

Security risk

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.

0
0

RE: Javascript by Andrew

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.

0
0
Boffin

@Andrew Ness

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.

0
0
Dead Vulture

google-analytics tries to run from THIS page...

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".

0
0
Anonymous Coward

sensationalist

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.

0
0

Next time take your schooling

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?!?!?!

0
0
Boffin

The Real Problem

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.

0
0
Black Helicopters

I hate to be the one to break the news

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.

0
0
Bronze badge

Tracking "admin page" visits

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.

0
0
Anonymous Coward

Post article justification

"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.

0
0
Thumb Down

@Andrew Ness

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

0
0
Silver badge
Thumb Down

Confusing the issue

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.

0
0
Paris Hilton

Seems pretty dumb

"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 ?

0
0

Admin/hidden pages and Google Analytics

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.

0
0
Dead Vulture

@DaveT

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?

0
0
(Written by Reg staff)

@Andrew Ness

If you read the article, you clearly didn't comprehend it. Yes, The Reg uses Google Analytics, just like so many other web sites. But I assure you we don't link it to the admin section of our website for the reasons laid out above.

This point has been repeated umpteen times. Please finally take it in: It would be trivial for anyone with control to urchin.js to add scripts that steal session cookies, siphon the username and password entered and send them to any server of the attacker's choosing. With either of these two pieces of data, Change.gov has now been compromised. This is a risk that The Reg isn't willing to take, and it should be a risk that Change.gov isn't willing to take either.

Comprende?

0
0
Silver badge
Thumb Down

This page

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

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

hm.

0
0

Andrew

"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/

0
0
E

@Ian Bradshaw

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.

0
0
Silver badge

@Dan Goodin

> 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 ...

0
0
Flame

Least likely attack vector.

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.

0
0
Mo

Or, you could just…

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

0
0
Silver badge
Coat

Non-story

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.

0
0
Anonymous Coward

@ Jeff

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.

0
0
IT Angle

Net? Security?

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?

0
0
Silver badge
Thumb Up

Cut out Google

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)

0
0
Silver badge

I know bugger all about XSS

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.

0
0

Page:

This topic is closed for new posts.

Forums