12 ms·

There is something you can do about it, but it's expensive and different from what you are used to. Safer languages is a good place to start. Input validation

• LoSboccacc 11y ago
  > anit-patterns can be learned a spell checker didn't save you from a typo. not nitpicking, just using this example to illustrate a point: for an app to be secure, developers have to be 100% of the time on ball, while an attacker just has to be lucky once. the weight is so much in favor of attacker than only few of the biggest can afford to pay for a competitive level of security, it being a race: security is effective not when perfect, but when it costs more to attack a site than what you'd gain of it.
  • mdpopescu 11y ago
    Or even when the gain/cost ratio for attacking YOUR site is greater than the one for other sites. (You don't have to outrun the bear, you have to outrun the other people.)
  • ethbro 11y ago
    > a spell checker didn't save you from a typo Believe this is where parent's preference for high-quality, easy-to-use libraries handling common security operations comes from. It's a lot easier to make a typo (or logical mistake) in 250 lines of your own code than in (hopefully) <250 lines of a library invocation. Honestly, library functionality like this in any given language should be thought of as an analog to infrastructure spending. We're finally seeing reinvestment from end-users and value capturers (Facebook, Google, MS, etc) back down the chain to the OSS projects they depend on. Language guiders (and in some cases the support businesses who are attached to languages) should be equally serious about this. If your language doesn't have high-quality, easy-to-use libraries to mitigate attack surfaces, that's a fundamental weakness in your language eco-system... (Aka the "Perl+CPAN is better than a lot of more advanced languages, because code" argument)
• georgerobinson 11y ago
  > Safer languages is a good place to start. Could (and should) a safer language pre-empt that you should first check strlen(str) != 0 before doing strcmp? I know of no language which does this. > Input validation can be made to be machine-verified Likewise, can you elaborate on this? How does the machine know what type of input this is? If input is tagged by the developer, what's to stop the developer from forgetting to tag the input correctly?
  • icebraining 11y ago
    Could (and should) a safer language pre-empt that you should first check strlen(str) != 0 before doing strcmp? I know of no language which does this. In some languages, you can define a string type that only contains strings of one or more characters. And then you'd need to "convert" a regular string into one of those by using some function that forced you to handle the strlen(str) == 0 case. I believe you can define that in Idris, for example.
  • shkkmo 11y ago
    except for strlen(str) != 0 doesn't really do much to fix the issue. At best all it does is mean you have to guess the first character. If you are comparing byte by byte the correct code is: valid = true; for(i = 0; i < strlen(user_token); i++) { if(strlen(token) < i || user_token[i] != token[i]) valid = false; } if(strlen(token) != strlen(user_token)) valid = false; return valid;
    • delinka 11y ago
      Let's make it somewhat more readable: int token_length = strlen(token); int input_length = strlen(input); int match_count = 0; // for constant-time comparison... // Just get this out of the way now; no need to dawdle // (because the length of a token is generally known) if (token_length != input_length) { return false; } // No need to worry about mismatched buffer lengths at this point for(int i=0; i<token_length; i++) { if (token[i] == input[i]) { match_count++; } } // if the same number of characters match, voila! return (match_count == token_length); It takes far too long to understand the intent and verify the correctness of lines like: if(strlen(token) < i || user_token[i] != token[i]) valid = false;