Monday, February 13, 2012

NodeJS: Switch is EVIL

switch statement in JavaScript is known to have bad effects as in other programming languages. In this post we discuss it's potential impact in server side JavaScript context like NodeJS. For more history on switch please refer Douglas Crockford's YUI blog post.

Let's look at a sample code snippet as in the screenshot below. This is an over-simplistic example. It is a funny little take on an app that reveals it's users the discount code based on their tiers. The logic that will determine the tier of the user and it's category is omitted for benefit of stressing on the issue at hand.


What should have happened was, the basic tier user Valued Customer should have been shown only 10% discount code. Now since our programmer forgot to apply the brakes (i.e. break highlighted in red in the previous case - in hurry or just human error or insufficient knowledge of switch may be), the second case code under case (dis < 5000) triggered leading to giving higher discount to a basic tier customer and showing a not so good message, as in the screenshot below.


Still in this fun app nothing really nasty happened. And the idea was exactly that to take a simple code and demo what switch could lead to.

In real world a similar mistake could lead to serious vulnerabilities - those are hard to detect. More I think of JavaScript, more I believe, coding best practices usually translate to security best practices. To be safe, anti-patterns like implied globals, with, eval, should be avoided. 


15 comments:

  1. are u still work with yahoo..? It shows in the code... :) it is not node js security vulnerability. A bad programmer can bring any robust system to knees...

    ReplyDelete
  2. Absolutely, and "switch" was as evil in C, as it was in PHP and as it is in Node.

    It is more likely to be abused. Thanks for the comment

    ReplyDelete
  3. switch is not evil, sleepy-coding is. The advice is no different than saying "don't use a knife, you can cut yourself."

    Yeah, I can cut myself... but I don't. :)

    ReplyDelete
  4. @hasanyasin: +1
    I'm don't think "switch" statements are evil. Sure, I've already make some mistake as anyone with "switch" and statement, but I don't ever remember of a debugging nightmare. It was all pretty straightforward to fix.

    On the other hand, a complex "if" statement is much harder to debug.

    ReplyDelete
  5. You are such an idiot.
    Again, it's nothing to do with Node JS or JS or switch.

    Programming is not for an idiot like you.
    You forgot something and you blamed on the statement.

    What a loser!

    ReplyDelete
  6. I came here expecting to find articles about Node.js security problems. Instead I found the top 5 don't of JavaScript.

    Literally none of these things should ever be a problem for a competent JavaScript developer. Every language is going to have its best and worst practices. Not bothering to learn them and then acting like its the fault of (all of) the frameworks built on the language doesn't really match up with Node.js security problems.

    ReplyDelete
  7. It's not the switch statement, it's the implicit fallthough that the problem, using 'break' as the final destination in switch is just a terrible idea, it's ridiculously easy to overlook, even for a competent programmer, they only human just like us.

    The developer behind Go Programming Language got it right, they favoured explicit over implicit, the switch in Go will not fallthough unless you specify the keyword 'fallthough'. 'break' is only used for breaking loop and that how it should of been.

    ReplyDelete
  8. HI,

    I would like to invite you to be a IT Security webinars at Times Group. Please write to me at mohini.chaudhary@timesgroup.com.

    ReplyDelete
  9. Do you normally serve as an author solely for this website or you do that for some other Internet or offline resources?

    ReplyDelete
    Replies
    1. No, just here. Would love to write more often. Have a lot to. Right now this blog is quite neglected. I hope to start righting some very interesting stuff soon.

      Delete
  10. Google why u still bring me here? :P

    But yes I do avoiding switch myself.

    In the above example, you can simply use a big `if ... else if ... else if ... else ...` block, which is fewer lines of code.

    In other situations (when you would have used == in your case statements) you can avoid switch and if-then-else like this:

    var result = {
    case1: function(){ action1(); },
    case2: function(){ action2(); },
    case3: function(){ action3(); }
    }[switchVal]();

    You may sometimes want to break that apart to handle the case where none of the cases match `switchVal`.

    Alternatively, you could keep using switch, but follow Crockford's advice, and use a lint tool to check for any cases without breaks.

    ReplyDelete
  11. well I even intentionally not put break on some of my case for example

    case 1: //do something
    case 2: //do something
    break;
    case 3: //do something
    break;

    and this is not only a problem of nodejs but almost all languages that uses the switch statement. switch statement is really helpful and much more even easier to maintain than its if..else counterpart.

    ReplyDelete
  12. This is a funny example of the ugly side of NodeJS, because a PHP script behaves exactly the same way, when using switch that way. This is a general issue and not something special in Node. From my point of view a developer with some skills would use that feature, for his needs. At least I did it sometimes in the past and I don't know why I should not do it. Sorry but this post is just crap.

    ReplyDelete
  13. Crappie blog wasted time in reading.

    ReplyDelete
  14. Why are so many trolls here? this blog is a trap!!! hahaha

    ReplyDelete