They'll NEVER hack this!



  • <script>document.write('<i' + 'nput ty' + 'pe="hi' + 'dde' + 'n" n' + 'ame=' + '"' + 'code"' + ' i' + 'd=' + '"sec' + 'urity_co' + 'de" va' + 'lue="c5aa7edfb4f10c169f279ecfebb55a22" />')</script>

    Background: this is a CSRF token: the MD5 output in the field changes upon page refresh.

    For a bonus WTF, the source for the MD5 is not extremely easy to guess, but not actually very hard either. In fact, the PHP manual specifically warns not to use the functions used for generating the MD5 for security purposes.



  • Now I'm really curious... I know the manual warns against md5 for such things anyway but what could they possibly doing to get an extra warning about it?



  • They are not getting warnings per se. It's just that the input for the md5 call is generated using one of the functions PHP's manual warns not to use in a security context.



  • Not sure if it’s a CSRF protection...
    It’s probably something to prevents spambots from submitting the form (Since according to Jeff bots can not execute JavaScript)
    Or maybe they really dislike NoScript users.



  • Oh, you mean something exciting like rand() that is absolutely terrible? Or something... worse?



  • That's it. I thought that those were the same thing?



  • Something like that.



  • Nope. CSRF means you prevent some outside manipulation of whatever form that might be. Spam bots, that's something else entirely.

    A great example is from an online game I used to play. One could send a boobytrapped PM to a player and through the magic of TinyURL force all their equipped items to be unequipped and sold back to the game for a fraction of their real value. Of course, putting those through POST rather than GET would seriously have impacted that, but if they'd had one-use tokens attached to each operation, I wouldn't have even been able to orchestrate a POST through some other means, because I'd have to get the one-use token first, which is really what CSRF strategy is about preventing.

    (Though going POST rather than GET is just good sense anyway since it automatically makes it slightly harder to exploit through, say, persistent XSS attacks)



  • So if that thing gets randomly generated on pageload and not persisted anywhere other than that hidden form element, how could it be useful in either a CSRF or bot-prevention context? There has to be some meaningful operation the server can do to validate it.
    It's a reasonable-enough CSRF measure to set that same value in a cookie AND in a hidden form variable, then check that the two match each other when the post comes in. The hacker who sends a loaded link doesn't have any mechanism to set your cookies. I'll give the original author benefit of the doubt and assume he's doing that in code that we haven't seen.



  • Presumably you'd push it into $_SESSION which would be the usual practice and I assumed this wasn't that much of a failure (because if that wasn't done, I'd assumed we'd hear of it)

    It's a bit of a WTF to output it like that, and it's a lot of a WTF to use a terribad seeding system to generate it in the first place.



  • Arantor is correct, the value gets stored in a session variable. Every visitor gets a session token that gets set in a cookie, so PHP knows which requests belong together. All of this is standard behavior for PHP.



  • I wouldn't go with "terribad". The number one reason using a poor random number generator in a low risk scenario like CSRF prevention, is that you'll get dinged by overzealous security auditors. It makes a good duck if you know the audit is coming up though.



  • That seems like such a poor explanation for code.



  • @mruhlin said:

    The number one reason for not using a poor random number generator in a low risk scenario like CSRF prevention, is that you'll get dinged by overzealous security auditors.

    I'm having difficulty parsing that sentence. Is the fixed quote what you meant?



  • No, what he's saying is that you can use a shitty algo in something as (relatively, theoretically) low risk as a CSRF token (assuming there's something else to make it not entirely predictable) so you can make it a sacrifice to the auditors when they inevitably trawl the code base, because auditors will always demand change, so it's low hanging fruit to give them.



  • That's what he said in the next sentence. That sentence seems to want to fit either the "The number one reason for $doing_or_not_doing $action is $result" or "The number one reason $action is $good_or_bad_idea, is $result" patterns, but it doesn't quite fit either. It needs an "is $good_or_bad_idea" or a "for $doing_or_not_doing" section.



  • I assumed he omitted the 'for' rather than implying a 'for not'.



  • Yeah, I intended the "for not" to be in there. My bad. Worked out by coincidence though, for the reasons Arantor says.



  • @Arantor said:

    I assumed he omitted the 'for' rather than implying a 'for not'.

    The "though" at the end of the next sentence indicates a contrast with the previous thought, so that is why I inferred "for not" rather than "for," plus being dinged in an audit would normally be construed as something to be avoided. Not until the next, contrasting sentence does he give a reason this might be desirable.


Log in to reply