I see so many people criticizing it with no apparent experience or use of it, and this is the primary misconception I see. It is not block all scripts. Why would anyone need an extension for that? You just turn off Javascript in the preferences for that. What it is is a domain-by-domain whitelister.
I can't use Chrome because it doesn't have NoScript, and I end up routinely visiting domains that I didn't even realize have some foreign-loaded script that pops up some crappy survey over the page ("please give us your private info under the guise of providing site feedback we intend to ignore!"), or pops up a flash ad, or who knows what. The web is too irritating to use anymore without it. (And Flashblock.)
Also, NoScripts does have heuristics, but they can't catch already-in-the-page XSS without firing too many false positives. They do have some decent protection against hostile links that have XSS-inducing strings in a query string or something. You can in fact download NoScript and configure it just for that. Personally, I've never had anything but a false positive from that check, but I don't cruise fora where such links are common.
It isn't anywhere near as hard to use as the critics say it is. I know this because I use it on three systems and I don't even bother trying to synchronize the settings somehow; it's more work to synchronize the settings that just use it in all three places.
Mostly I browse to read, and NoScript eliminates a ton of pointless HTTP requests and CPU cycles.
Some bits of github don't work unless you enable JavaScript, but most of it does. So I only enable it when I'm using those bits.
I also make sure I log out of github before I start browsing other websites.
When I try to explain this to friends, they respond with, "No, it's only on that webpage I visit."
I don't think it is an exageration to say that an XSS flaw on something like github has the potential to be disasterous.
Even doing that as a prank would cause a Big Red Button security audit at some companies. As in, drop what you're doing, we need to go over every line of every commit in the git repo and verify nothing like a server password was committed. Recommendation #1 from that audit will be to stop using github.
Cute use of rickrolling btw. :-)
Quick work by the github guys, kudos.
For those who missed it, the title attribute inside commit messages in the file list wasn't HTML encoded.
They should then put up a notice on their website to describe what happened, describe how they confirmed that this flaw hasn't been exploited previously, and describe what measures they will take in future to prevent this sort of problem.
In my opinion, that is how a "good", company would react. Anything less would be a disappointment.
|In my opinion, that is how a "good", company would react.
Would you really want to be alerted every time a website you used closed a minor security hole, that had possibly never even affected anyone? They absolutely should, if any user information was leaked, or if there was downtime involved, but you honestly do not need to keep informing users about this sort of mundane security update. At best, I would suggest it go on their blog.
Not reporting "oh we found an xss hole that maybe one or two people had used before." is NOT a disappointment.
The injected script could for example submit a new SSH public key for your account (doesn't require your password again). Or just be funny and delete repos. Or just upgrading your account to a bigger, more expensive plan.
Or they could get a list of your private repositories. Combine that with the upload of a new private key and you'll get free access to proprietary code of any account.
Aside of fixing the XSS issue, they really should ask for the password again when uploading a public key.