Turning it off is not “just totally stupid”. For one thing, scripts are sometimes annoying, and most of the web can still be successfully navigated without bothering with them. Turning scripts off can greatly decrease site load times, browser overhead, and network traffic.
For another, you don’t know what sort of user agent the customer is using—there are a lot of browsers for particular accessibility issues or other purposes that do not evenly support Javascript.
Supporting lack of javascript is just plain best practice, based on the principle of progressive enhancement.
Are you aware that with JavaScript, I can get your browser to submit a form to another site you are logged in to, that foolishly only validates sessions by cookies, and the other site will think you wanted to do that, and you would never know it happened?
Knowing this, would you still consider those who don’t want JavaScript enabled when visiting sites they don’t explicitly trust to be stupid?
Cross Site Scripting is the main vulnerability caused by javascript hosted on trusted sites. The problem there is that a hacker has managed to inject javascript onto the page (perhaps by submitting a comment that the server fails to encode for HTML) allowing the script to gather information provided in the version of the page associated with my login, and send that information to the hacker’s server. NoScript does provide some protection against this, but this is by suppressing the methods the injected script uses to report back to the hostile server. It only helps by disabling JavaScript when the injected attack loads a script from a (non white listed) hostile domain.
Cross Site Forgery, on the other hand, is an attack by JavaScript hosted on a random untrusted site I visit, perhaps by Stumbling. NoScript provides excellent protection against this simply by turning of JavaScript.
You can still have XSRF attacks without javascript though… so they are not caused by javascript but facilitated. Harder but doable, and you might protect yourself from some in the wild by turning off javascript.
Reading up about this a bit more it does appear that noscript does help against XSRF even those that don’t use javascript, by changing post requests from untrusted sites to empty gets.
Reading up about this a bit more it does appear that noscript does help against XSRF even those that don’t use javascript, by changing post requests to untrusted sites to empty gets.
Neat. Though I think you meant “changing post requests from untrusted sites to trusted sites to empty gets”, as would be expected to protect against Cross Site Forgery.
I agree with Vladimir Nesov—this is not relevant, and you seem to be using a soldier-argument. Anyway, validating write requests with cookies without auth tokens is plainly wrong, and there are trivial ways to do it right (automatically add auth token to all write forms, read-only forms like search boxes are not affected in any way by CSRF).
And you can do CSRF with “Press button to see kittens” trick, without a single line of Javascript. You can also read browser history with CSS, without Javascript. There aren’t that terribly many security failures that you can do with Javascripts but cannot without, and in any case it’s like using dynamite to deal with mosquitoes—completely disproportional reaction.
Suppose Mallory has identified 100 websites that are vulnerable to high valued Cross Site Forgery attacks. (The administrators of these websites failed to use any of the trivial ways to prevent this. Some users, though they can’t fix the servers, still want to protect themselves.) Is Mallory going to make a site that attempts to entice a user to click a button that apparently won’t do anything, but will actually attempt an attack that will work if the user happens to have an account and be currently logged in to the one targeted site? Or is he going to create a site that has some interesting content that may even entice the user to come back later, that will silently run a script that attempts an attack on every vulnerable site Mallory knows, every time the user visits, without the user having to press any buttons?
You can also read browser history with CSS, without Javascript.
Good to know, though it would have been nice to actually provide a description or a link instead of making me search for it. Though, finding a weakness in my armor does not convince me to abandon my armor which still protects me against many threats. I will consider strengthening my armor. (Unfortunately, it appears the linked extension only supports Firefox 2, but I will see what else I can find.)
I agree with Vladimir Nesov—this is not relevant, and you seem to be using a soldier-argument.
Neither you nor Vladimir have even attempted to identify a single detail about Soldier-Arguments that describes my arguments. I really don’t care about your unsupported opinions that an argument that you happen to disagree with has committed some fallacy.
The weak arguments shouldn’t be used to defend a position. These arguments may lower the other side’s confidence, but they won’t sway the conclusion, and so asking to reconsider the conclusion by giving such arguments is fallacious. It’s also pretty much useless and maybe even misleading, as getting a better idea of the real state of things requires a much more systematic study than a few hand-picked arguments, which are likely to suffer from selection bias anyway.
You don’t defend the statement that a country is economically prosperous by mentioning one successful company.
The weak arguments shouldn’t be used to defend a position.
The argument is not weak. If you think it is, explain why it is weak, why it won’t sway the conclusion.
You don’t defend the statement that a country is economically prosperous by mentioning one successful company.
This is not a good analogy. Malicious hackers will systematically exploit the most dangerous vulnerabilities in a way that the people of a country can not systematically do business with the most successful company.
Keep in mind, I was refuting the assertion that using NoScript is stupid. As thomblake has already explained, any good reason one might have for using NoScript is evidence for my position.
It seems you are using this fact as a soldier-argument. The position under discussion is that all things considered, turning scripting off seems to be a wrong decision. Of course there are potential problems, but at the same time, there are working solutions to these problems, and benefits from actually using the technology.
Such as? The only working solutions I know of are server-side, or disallowing javascript and/or cookies.
The position under discussion is that all things considered, turning scripting off seems to be a wrong decision.
No, the position under discussion is that turning Javascript off is “just totally stupid”. If one can provide good pro tanto reasons for doing so, it is at least not “just totally stupid”.
Disallowing Javascript does NOT protect you against CSRF—“Press button to see kittens” form works without any Javascript. The right solution is server-side—auth tokens for all cookie-validated write forms.
I’m all for ignoring the NoScript demographic—JavaScript is one of the basic building blocks of the web, and turning it off is just totally stupid.
Turning it off is not “just totally stupid”. For one thing, scripts are sometimes annoying, and most of the web can still be successfully navigated without bothering with them. Turning scripts off can greatly decrease site load times, browser overhead, and network traffic.
For another, you don’t know what sort of user agent the customer is using—there are a lot of browsers for particular accessibility issues or other purposes that do not evenly support Javascript.
Supporting lack of javascript is just plain best practice, based on the principle of progressive enhancement.
Are you aware that with JavaScript, I can get your browser to submit a form to another site you are logged in to, that foolishly only validates sessions by cookies, and the other site will think you wanted to do that, and you would never know it happened?
Knowing this, would you still consider those who don’t want JavaScript enabled when visiting sites they don’t explicitly trust to be stupid?
Cross site scripting is the main vulnerability caused by javascript, not request forgery.
I use noscript. It helps disable annoying ads.
Cross Site Scripting is the main vulnerability caused by javascript hosted on trusted sites. The problem there is that a hacker has managed to inject javascript onto the page (perhaps by submitting a comment that the server fails to encode for HTML) allowing the script to gather information provided in the version of the page associated with my login, and send that information to the hacker’s server. NoScript does provide some protection against this, but this is by suppressing the methods the injected script uses to report back to the hostile server. It only helps by disabling JavaScript when the injected attack loads a script from a (non white listed) hostile domain.
Cross Site Forgery, on the other hand, is an attack by JavaScript hosted on a random untrusted site I visit, perhaps by Stumbling. NoScript provides excellent protection against this simply by turning of JavaScript.
You can still have XSRF attacks without javascript though… so they are not caused by javascript but facilitated. Harder but doable, and you might protect yourself from some in the wild by turning off javascript.
Reading up about this a bit more it does appear that noscript does help against XSRF even those that don’t use javascript, by changing post requests from untrusted sites to empty gets.
More details can be found on the noscript developers blog,
Editted: Made correction suggested by child post of JGWeismann,
Neat. Though I think you meant “changing post requests from untrusted sites to trusted sites to empty gets”, as would be expected to protect against Cross Site Forgery.
I agree with Vladimir Nesov—this is not relevant, and you seem to be using a soldier-argument. Anyway, validating write requests with cookies without auth tokens is plainly wrong, and there are trivial ways to do it right (automatically add auth token to all write forms, read-only forms like search boxes are not affected in any way by CSRF).
And you can do CSRF with “Press button to see kittens” trick, without a single line of Javascript. You can also read browser history with CSS, without Javascript. There aren’t that terribly many security failures that you can do with Javascripts but cannot without, and in any case it’s like using dynamite to deal with mosquitoes—completely disproportional reaction.
Yes, this is plain stupid.
Suppose Mallory has identified 100 websites that are vulnerable to high valued Cross Site Forgery attacks. (The administrators of these websites failed to use any of the trivial ways to prevent this. Some users, though they can’t fix the servers, still want to protect themselves.) Is Mallory going to make a site that attempts to entice a user to click a button that apparently won’t do anything, but will actually attempt an attack that will work if the user happens to have an account and be currently logged in to the one targeted site? Or is he going to create a site that has some interesting content that may even entice the user to come back later, that will silently run a script that attempts an attack on every vulnerable site Mallory knows, every time the user visits, without the user having to press any buttons?
Good to know, though it would have been nice to actually provide a description or a link instead of making me search for it. Though, finding a weakness in my armor does not convince me to abandon my armor which still protects me against many threats. I will consider strengthening my armor. (Unfortunately, it appears the linked extension only supports Firefox 2, but I will see what else I can find.)
Neither you nor Vladimir have even attempted to identify a single detail about Soldier-Arguments that describes my arguments. I really don’t care about your unsupported opinions that an argument that you happen to disagree with has committed some fallacy.
Why, I agree with the argument. It just isn’t a killer argument that determines the overall decision, and that is the problem with giving it.
Are you serious? We should only ever present arguments that are powerful enough to convince everyone and conclude the discussion?
The weak arguments shouldn’t be used to defend a position. These arguments may lower the other side’s confidence, but they won’t sway the conclusion, and so asking to reconsider the conclusion by giving such arguments is fallacious. It’s also pretty much useless and maybe even misleading, as getting a better idea of the real state of things requires a much more systematic study than a few hand-picked arguments, which are likely to suffer from selection bias anyway.
You don’t defend the statement that a country is economically prosperous by mentioning one successful company.
Think of this in the scientific evidence vs. rational evidence setting. The protocol is there to ensure more reliable performance.
The argument is not weak. If you think it is, explain why it is weak, why it won’t sway the conclusion.
This is not a good analogy. Malicious hackers will systematically exploit the most dangerous vulnerabilities in a way that the people of a country can not systematically do business with the most successful company.
Keep in mind, I was refuting the assertion that using NoScript is stupid. As thomblake has already explained, any good reason one might have for using NoScript is evidence for my position.
It seems you are using this fact as a soldier-argument. The position under discussion is that all things considered, turning scripting off seems to be a wrong decision. Of course there are potential problems, but at the same time, there are working solutions to these problems, and benefits from actually using the technology.
Such as? The only working solutions I know of are server-side, or disallowing javascript and/or cookies.
No, the position under discussion is that turning Javascript off is “just totally stupid”. If one can provide good pro tanto reasons for doing so, it is at least not “just totally stupid”.
Disallowing Javascript does NOT protect you against CSRF—“Press button to see kittens” form works without any Javascript. The right solution is server-side—auth tokens for all cookie-validated write forms.