3 ms·

The issue is rather that even though the situation isn't black and white, a very large majority of web developers aren't security knowledgable enough to make th

by LunaSea 11y ago

The issue is rather that even though the situation isn't black and white, a very large majority of web developers aren't security knowledgable enough to make the decision of if it is or isn't safe to use it in each specific case. This is why blanket black-listing (or white-listing in cases where it is possible) is a better option because, similar to Murphy's law, if something (like eval) can be misused it will be.

Klathmon 11y ago
But that kind of hand-holding doesn't ever work. if someone wants to do something "bad" in a language, it's better to teach them why it's bad than to blacklist certain parts of it. I've seen developers tell me that eval is bad, but they found a way to do what they want by using `new Function()` (which takes a string of code and makes it into a function that can be executed...) Teach why these things are a good idea to avoid, teach why it's dangerous, teach scenarios where it's tempting but there is a better way, but don't disallow their use entirely. We wouldn't be developers if we just gave up the first time someone told us that we couldn't do it that way.
- LunaSea 11y ago
  I disagree. Security is a job on it's own and although you can teach some security know how in the grand scheme of things a web developer will never be at the same level of understanding than an actual penetration tester or security researcher. To enforce rules like this, the best practice I would say is to add JSLint or ESLint with a strict rule set on a pre-commit hook and then refuse any commits / merges that don't pass the static analysis of those tools.
  - Klathmon 11y ago
    I agree that security stuff is best left to security researchers. However you need to draw the line somewhere. Allowing a while loop can be a security issue for some applications. I was more talking about issues like the `with` in JS or `goto` in other languages. Yeah, they are a really bad idea for the vast majority of situations, but every now and then they are incredibly useful or provide an insane speed improvement and they can be safely used. An eval example i've seen recently was about sending functions to web-workers. The only way to allow code to run in a web worker without a separate file is to convert a function to a string and eval the code in the web-worker side. So i could massively over complicate my build system, duplicate code in a bunch of places, and near-double the size of the downloaded code to get it working without eval, or i could setup a simple eval system and have it run a function passed in as a string. Yeah, you shouldn't be using eval to decide if the number entered was 5 or 6, but saying it's disallowed from the codebase entirely is silly. Even a policy like "any code that uses eval must be approved by X, Y, and Z before they will be allowed in the codebase" is much more sane.

by LunaSea 11y ago

Klathmon 11y ago

But that kind of hand-holding doesn't ever work. if someone wants to do something "bad" in a language, it's better to teach them why it's bad than to blacklist certain parts of it. I've seen developers tell me that eval is bad, but they found a way to do what they want by using `new Function()` (which takes a string of code and makes it into a function that can be executed...) Teach why these things are a good idea to avoid, teach why it's dangerous, teach scenarios where it's tempting but there is a better way, but don't disallow their use entirely. We wouldn't be developers if we just gave up the first time someone told us that we couldn't do it that way.

LunaSea 11y ago
I disagree. Security is a job on it's own and although you can teach some security know how in the grand scheme of things a web developer will never be at the same level of understanding than an actual penetration tester or security researcher. To enforce rules like this, the best practice I would say is to add JSLint or ESLint with a strict rule set on a pre-commit hook and then refuse any commits / merges that don't pass the static analysis of those tools.
- Klathmon 11y ago
  I agree that security stuff is best left to security researchers. However you need to draw the line somewhere. Allowing a while loop can be a security issue for some applications. I was more talking about issues like the `with` in JS or `goto` in other languages. Yeah, they are a really bad idea for the vast majority of situations, but every now and then they are incredibly useful or provide an insane speed improvement and they can be safely used. An eval example i've seen recently was about sending functions to web-workers. The only way to allow code to run in a web worker without a separate file is to convert a function to a string and eval the code in the web-worker side. So i could massively over complicate my build system, duplicate code in a bunch of places, and near-double the size of the downloaded code to get it working without eval, or i could setup a simple eval system and have it run a function passed in as a string. Yeah, you shouldn't be using eval to decide if the number entered was 5 or 6, but saying it's disallowed from the codebase entirely is silly. Even a policy like "any code that uses eval must be approved by X, Y, and Z before they will be allowed in the codebase" is much more sane.