Scripts change confirmation?

[guesswho]

Imagine that a site which I allowed to use javascript is attacked by hackers who put some dangerous code instead of original. My question is: can NoScript create some hash of all scripts on the page which I have enabled and ask me every time it founds some changes in JS? Obviously, I would need to confirm each regular site update, but that's a price for better security.

[Thrawn]

http://noscript.net/faq#qa1_11

[guesswho]

http://noscript.net/faq#qa1_11

https://addons.mozilla.org/de/firefox/addon/jsview/ shows "Dieses Add-on wurde durch seinen Autor entfernt." and the "When a respectable site gets compromised, 99.9% of the times malicious scripts are still hosted on a different domain" is BS due to Tor hosting incident ans my webmastering experience. So the answer is "No". Ok.
Please update your FAQ.

[barbaz]

JSView is still available here:
http://xsidebar.mozdev.org/modifiedmisc.html#jsview

Note that the extension "as is" is buggy and may display "http :// undefined /" instead of the actual source file, especially on Mac OS X. It's not hard to fix that though.

[Thrawn]

Thanks for spotting that JSView has been removed (updating the FAQ is for Giorgio, when he gets time; he's been busy with FlashGot lately).

Unfortunately NoScript is not able to compute a signature of JavaScript files, since the point where it blocks them is before they are downloaded. Intercepting them after download would mean a whole new infrastructure, assuming that it's even possible.

And how would this handle inline scripts?

And there are often dozens of scripts on a site, sometimes hundreds, so you'd potentially be drowning in alert spam.

[guesswho]

And how would this handle inline scripts? And there are often dozens of scripts on a site, sometimes hundreds, so you'd potentially be drowning in alert spam.

1. Well, sure, I would. But on the other hand it's a bad idea to put inline scripts onto the site and especially - to generate different quantity of elements containing inline scripts since we have DOM and Jquery and tons of other useful things. So it's up to site owner and the people who decide to visit and use such sites. If you decide to go to an african swamp at night, don't be surprised to be eaten by an evil crocodile.
2. We can hash scripts grouping it by a domain, so there would be only one alert about something is changed (but probably we'll need some text comparing functional to easily look what exactly changed).
3. Also, I was thinking on a way to somehow sign my scripts with PGP key or something and then put it on production server, being sure no other scripts will executed without my permission even if the site will be compromised. But there is no browser mechanisms that would allow this by now.
Anyway, thank you for your answers and support.

[Thrawn]

1. Well, sure, I would. But on the other hand it's a bad idea to put inline scripts onto the site and especially - to generate different quantity of elements containing inline scripts since we have DOM and Jquery and tons of other useful things. So it's up to site owner and the people who decide to visit and use such sites. If you decide to go to an african swamp at night, don't be surprised to be eaten by an evil crocodile.

But on the sites that are well written, this feature would be less needed, and for those that are accountable, as Giorgio suggests, it's needed even less. I don't need to trust that my bank's security will be perfect, only that they will be the ones who will wear the cost of something going wrong.

So the cost/benefit tradeoff of implementing this might not work out so well.

2. We can hash scripts grouping it by a domain, so there would be only one alert about something is changed (but probably we'll need some text comparing functional to easily look what exactly changed).

That sounds like an interesting idea for a whole new addon. If you'd like to write it, I expect I'd check it out, if only for educational reasons.

But it would need to be very non-intrusive, because of course 'scripts changed' is not normally an indication of something going wrong.

3. Also, I was thinking on a way to somehow sign my scripts with PGP key or something and then put it on production server, being sure no other scripts will executed without my permission even if the site will be compromised. But there is no browser mechanisms that would allow this by now.

If you're willing to go to that much trouble (and kudos on that), then may I recommend instead making your site work without JavaScript? You can do a whole lot with CSS. If visitors don't need JavaScript to make your site work, then they can just leave it blocked, and then they're safe no matter what.

Anyway, thank you for your answers and support.

You're welcome .

[guesswho]

I don't need to trust that my bank's security will be perfect, only that they will be the ones who will wear the cost of something going wrong.

As for me, it is wrong idea to think that somebody's will wear the cost. First, dangerous code is not something that alerts "hello, i'm a dangerous code, lol" so it could be silently doing its work, until site admins will silently remove it, and you will never know it ever existed. The second is, did you ever think it could be the bank iniative itself? I remember that story about ATM's that checkning for traces of cocaine on your credit card and altering your credit history using this info. Why couldn't they check what sites you are visiting by just putting the code once a time, collecting data, and then never put this code again, so you will never know about it? The third is - in soviet russia compromised banks sue you. Really, they have a bunch of lawyers, mafia support and corrupted government. And you have only yourself to confront them. I know a lot of stories when people's money got frozen and they sue by years to get it back. Moreover, once I fell in this story myself and it took month to prove that my own money is not a "fraud". The whole point about sueing is just freaking wrong.

[Thrawn]

I remember that story about ATM's that checkning for traces of cocaine on your credit card and altering your credit history using this info. Why couldn't they check what sites you are visiting by just putting the code once a time, collecting data, and then never put this code again, so you will never know about it?

To stop tracking, I recommend RequestPolicy.

The third is - in soviet russia compromised banks sue you. Really, they have a bunch of lawyers, mafia support and corrupted government. And you have only yourself to confront them. I know a lot of stories when people's money got frozen and they sue by years to get it back. Moreover, once I fell in this story myself and it took month to prove that my own money is not a "fraud". The whole point about sueing is just freaking wrong.

Then it doesn't sound like they are really 'trusted' in the sense that NoScript uses that word.

I realise that there might not be any trustworthy choices, and you're stuck with banks you don't trust. But if that's the case, then you're in deeper trouble than NoScript can fix.

[guesswho]

Then it doesn't sound like they are really 'trusted' in the sense that NoScript uses that word.

Then I conclude that NoScript is based on a false concepts, because there is no such things as absolutely trustworthy organisations as there is no an "absolute security" thing. NoScript, as a tool, can only increase level of user security. And it is bad to mantain an illusion about existence of trustworthy sites. It's better to honestly tell that when you enable javascript on some site, you are become unsecured on it (so if you want to stay secured at this point, you'd recommended to use A,B,C addons along with NoScript). There is no shame about this, NoScript not intended to be a security panacea.

[Thrawn]

Then it doesn't sound like they are really 'trusted' in the sense that NoScript uses that word.

Then I conclude that NoScript is based on a false concepts, because there is no such things as absolutely trustworthy organisations as there is no an "absolute security" thing.

In the country where I live, I can hold my bank accountable if they have a security breach and someone is able to compromise my account. If that is not possible in your country, then you are unfortunate.

NoScript, as a tool, can only increase level of user security. And it is bad to mantain an illusion about existence of trustworthy sites. It's better to honestly tell that when you enable javascript on some site, you are become unsecured on it (so if you want to stay secured at this point, you'd recommended to use A,B,C addons along with NoScript). There is no shame about this, NoScript not intended to be a security panacea.

Giorgio never claimed that NoScript is perfect, but if the sites you allow really are trustworthy, then it keeps you very safe - usually safe even if an attacker compromises those sites.

If all the sites you do business with are not actually trustworthy, then you have bigger problems, which NoScript cannot solve and was never designed to solve. Perhaps you need to browse like Richard Stallman.

[guesswho]

If all the sites you do business with are not actually trustworthy, then you have bigger problems.

It is fun, how we cannot understand each other, because of different life experience, I guess. Imagine, your (g)mail account was hacked using javascript exploit, and all your mail, containing valuable data, was transferred to some somalia server to unknown person. You can sue (g)mail company, you can get some money compensation. But you cannot return your data back. Shit happens and the site, you thought, was trustworthy, and that was truthworthy for 20 years, can become dangerous in about a second. And if your security software detects malicious code - your data is saved. If not - you lose. Absolutely trustworthy site or company is an abstraction which physically impossible.

[Thrawn]

Imagine, your (g)mail account was hacked using javascript exploit, and all your mail, containing valuable data, was transferred to some somalia server to unknown person.

As Giorgio points out in the FAQ, this is difficult to do. NoScript has XSS filtering to prevent reflected attacks, and persistent attacks usually don't have much space to work with, so they work by importing scripts from another site. Which NoScript will block. RequestPolicy helps too.

With NoScript, I'm not very worried about my account being hacked. However, if I thought that Google itself was a threat and might attack my machine, then I would have to shut down my Gmail account and take my business elsewhere. If you can't do that - eg if all the banks are actually likely to be dangerous to you - then you have bigger problems than your web browser security.