Google Firefox Extensions: Good or Bad? You Decide!


Nitesh Dhanjani points out some security issues with Google's new FireFox extensions that just don't smell right:

Every request is transmitted to Google over HTTP, i.e. in clear-text. This is not good. Here is why: Consider a web application that uses SSL to encrypt the session. If this web application were to submit private information about you via a GET request (i.e in the URL, such as a credit card number), this will now be transmitted to in clear-text, allowing someone on your network segment, or any router in between yourself and to sniff the information off the wire.

Do user privacy policies even matter when you do stuff like that?


Two things that bother me about that article...

I've met hundreds of 'security professionals' like him, that spout the usual '[X] is insecure' shite coupled with 'look at me, I know how to make a HTTP request without a browser' to make themselves sound like they know what they are talking about, and have absoltely 0 respect for those people. This one especially, as his 'article' is a bag of hype designed to impress stupid people by the looks of things.

1) What are the chances of someone being on your network segment running a packet dump? Small, but ok, i'll give him that one, it can happen.
2) Based on his example, the only thing that seems to be transmitted, is the URL of the website your visiting
3) Usually when you use an ecommerce site, you visit the non-HTTPS version first and only get directed onto the HTTPS version during checkout. Fair enough. With the exception of ecommerce, most other sites are in plain HTTP. So how the fuck does this tosser conclude that having the URL of the site you are visiting sent to G in plan text is insecure? You would be sending the same damn info when you made the first plain http request to the target site anyway.

The extension sends the entire GET request to Google. If a web application were to send private information via GET parameters, this will now be transmitted to Google.

a) that hardly makes sense, b) no shit sherlock. You make a get request and data get's sent, who would have thought!

The biggest security hole, if you wanted to find one, would be DNS cache poisioning at the ISP level whereby the IP address of a target URL is modified on the DNS server and the fake IP to the real domain is given out to any client accessing that site. That risk affects every non-SSL connection to every site in the world, and is not specific to google or that google FF extension in anyway whatsoever... and he doesnt even pick up on it.

I can't believe that is on an Oreilly website either, admittedly I don't read their sites that often but I associate the Oreilly brand with good, factual, accurate content (books specifically). That article brings the whole Oreilly brand into disrespect by being so factually way off the mark.

lastly, @title of TW thread: great, though somewhat misleading ;)

I associate the Oreilly

I associate the Oreilly brand with good, factual, accurate content

so do I, but I don't know tons about the security stuff, hence me thinking that article was legit.

nice post on you foo

@title of TW thread: great, though somewhat misleading

shall the thread title be changed to something like

Even O'Reilly Publishes Crap Sometimes


Foo: I don't think you know what you are talking about. I am going to ignore your name calling, and concentrate on your arguments. First and foremost, when HTTPS (SSL) is in use, the entire URL, ie GET parameters are NOT 'sniffable'. The GET parameters, ie for example, ?sessionid=xyz is sent to the web server AFTER the SSL connection is established. The author of this article is suggesting that in case of ecommerce websites, the value of these parameters will now be sent over HTTP. I'd advise you to RTFA, please.

Interesting title change.

Interesting title change. Aaron, I agree with mattdive.

The article, isn't necessarily bad. Where the article falls down is that it derives the conclusion that https urls are sent although within the article it makes no mention of tests to see if that is true.

For the PageRank queries, at least, some urls are not sent through to get PageRank values. For example, those local to the machine. Perhaps it is the case that this safebrowsing tool does something like that.

I have no idea if it does or not, perhaps I will get time to look/test later. It is a reasonable assertion to think that the system does send HTTPS requests. So, until someone shows it true or false one way or another perhaps we should refrain from calling it a bad article?

diplomatic title now? I wish

diplomatic title now?

I wish I knew more about the technical issues


If any legitimate service is sending secure and sensitive data via a GET instead of a POST they should be taken offline in the first place. Flogging whoever did it publicly would be nice as I would never use them and would loudly sound the alarms if I saw such shitty practices so I'll just skip past this bullshit assessment.

Having the data exposed plain text over the net is one thing, put passing so-called secure data via GET is just idiotic - it's probably stored in plain text on some web server log file just waiting to be hacked, crunched in all sorts of 3rd party log analysis programs, yada yada so the practice is very bad but for many other reasons than this asshat mentions.

Next, if it's anti-phishing the odds of phishers using SSL is pretty slim as all the phishers I've run across are shoe-horned into some hacked web hosting account somewhere and they don't give a shit about your privacy so that data is being exposed in plain text no matter what 99.9% of the time anyway making his argument even more idiotic.

Personally, if that data has to be sent in plain text I'd rather that data be sent to Google first than a phisher.

FYI, when I used to run a hosting service for a few years I caught some shithead customer using a form to send credit card data via unsecured email with a formmail script and I disabled his page, and his formmail script, set all related files so he couldn't edit them with the immutable bit to make sure they stayed off. Then I sent him a nice email about how bad what he did was and if I ever caught him again I'd be reporting him to the CC company. Apparently the idiot never read the email I sent him or ever checked his web site as it stayed that way for almost 2 years LOL

If any legitimate service is

If any legitimate service is sending secure and sensitive data via a GET instead of a POST they should be taken offline in the first place.

I agree, however companies do do it and they're not all small ones.

I tested the article's assertions and it is true. HTTPS GET requests are sent plaintext to Google seemingly from whatever site.

Next, if it's anti-phishing the odds of phishers using SSL is pretty slim as all the phishers I've run across are

With respect, this misses the point. The argument is not that the phishers are using SSL but that by installing the extension you create a different security risk whilst visiting OTHER sites that was not originally present.

Now, it is arguable that the antiphishing extension does more good than it does bad. i.e. on the whole it is more likely a user is going to be victim to phishing than they are to be a victim to somebody sniffing (or listening with a naughty proxy server).

However, it is equally arguable that the url sent to Google does not need to be and should not be in plaintext. i.e. Google themselves should encrypt the information that thier own pages explain could contain personal information.

In my view, the only failings of the article are that it fails to explain what I have mentioned in the last two paragraphs. i.e. it slightly sensationalizes the situation and it does not explain that the tradeoff is avoidable.


first, the choice of using GET vs POST as the value of the method attribute in a form tag is immaterial in terms of security. it is the choice of protocol that is material. that is, as long as the protocol is https a GET is just as good as a POST. if http is used, then all of the information sent is available in the packet for examination as plain text, you just have to look in a different part of the packet.

where this has gone wrong is that the tool should detect the protocol of the base page and use the same protocol in transmiting the additional query. that is if the base page is https then use https, if not, then use either http or https.

normally, if a https page has additional callouts to http elements, all major browsers will, at least optionally, warn the user that there are unsecure elements being loaded by the secure page. however, this warning is bypassed by the tool because it is not a page element, but rather, a browser addon.

overall, the failing is that the tool breaks the security model designed into the browser by the vendor. more bluntly, the tool does not implement at least as strong security as the url it is being applied to, even though it is inherently possible to do so. in corp speak, they have failed to implement "best practices", even though it was perfectly possible to do so.

this has nothing to do with whether sniffing is practical or likely. it is simply bad and thoughtless design. if any thought was put into it, it would seem to be that they did not wish to support the overhead of using ssl at the expected volume levels. or, that the ssl protocol handshaking overhead would make their tool seem slow and encourage users to disable the function. user security just does not seem to have been a priority.


Bullshit - passing CC's by GET exposes them unencrypted in log files and is against the CC company rules and I report everyone I catch doing it. If they used a POST in the first place, just like VISA/MC require this would be mostly a moot point.

Rationalize it anyway you want but passing user form data via GET is just bad and most secure all around method is POST, period, regardless of SSL, as SSL isn't the end-all-be-all of security as what happens on the server side gets factored into the equation as well.

If these bad practices weren't in existence this would be a moot discussion.


Presuming that the requirements alluded to would be those enumerated in: "Payment Card Industry Data Security Standard" aka "Card Industry Security Standard"

That document contains:

Requirement 3: Protect Stored Data ...

This requirement can be met by either using encryption *or* restricting network and physical media access. Using either approach, it is immaterial that a GET might be logged because either the logs are also encrypted *or* under controlled access. The earlier stated criticism presumes that the logs are enabled and in plain text form. Neither are necessarily true. However, if the base requirements are met, the logging is permissible, and is certainly not prohibited.


Requirement 4: Encrypt transmission of cardholder and sensitive information across public networks.

Sensitive information must be encrypted during transmission over the Internet, because it is easy and common for a hacker to intercept and/or divert data while in transit.

4.1 Use strong cryptography and encryption techniques (at least 128 bit) such as Secure Sockets Layer (SSL), Point-to-Point Tunneling Protocol (PPTP), Internet Protocol Security (IPSEC) to safeguard sensitive cardholder data during transmission over public networks

4.1.1 For wireless networks transmitting cardholder data, encrypt the transmissions by using Wi-Fi Protected Access (WPA) technology if WPA capable, or VPN or SSL at 128-bit. Never rely exclusively on WEP to protect confidentiality and access to a wireless LAN. Use one of the above methodologies in conjunction with WEP at 128 bit, and rotate shared WEP keys quarterly and whenever there are personnel changes.

4.2 Never send cardholder information via unencrypted e-mail.

There is no mention of GET or POST in the document at all. Taken together, this means GET or POST is acceptable and only SSL or a like equivalent is acceptable in the eyes of VISA/MC. I stand by my earlier statement that as far as network interception is concerned, the only difference between GET and POST is the location of the data in the data stream. It is the use of SSL that is critical.


Requirement 7: Restrict access to data by business need-to-know.This ensures critical data can only be accessed in an authorized manner.

7.1 Limit access to computing resources and cardholder information to only those individuals whose job requires such access.

Taken with the required security policy of requirements 8 and 12, this would imply that third party admins and hosting employees should at least be aware that they should not be snooping around. This is regardless of intent.

In any event, this discussion was originally about the perverting of the site/client interaction where the data stream was intended to be protected by SSL and is then subsquently circumvented/sabotaged by Google.


version 1.0, December 15/2004

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.