3 ms·

yep, and doesn't use prepared statements for DB queries..

• PlzSnow 11y ago
  There's nothing wrong nor insecure about choosing not to use prepared statements. There does seem to be a very conservative/cargo cult streak amongst some tech people that there are only pure ways to do things. For example there is nothing wrong with building a SQL statement as a string and passing it to a database. If it's programmed correctly then it is exactly as secure as a prepared statement.
  • kevan 11y ago
    > If it's programmed correctly then it is exactly as secure as a prepared statement. It's really easy to program them incorrectly, and as a result the approach is less secure than just using prepared statements.
  • mweibel 11y ago
    of course it was a bit of a generalization. However I don't think it's harder to use prepared statements and I do think you should always use it, even if you're absolutely sure that the data you get in isn't an injection. Not using it rings an alarm bell IMO.
  • __david__ 11y ago
    > If it's programmed correctly then it is exactly as secure as a prepared statement. That's a very big "if" right there. The same could be said for nearly every security flaw ever—if it were programmed correctly, it wouldn't be a security flaw. The reason people harp on prepared statements is not because you can't be secure without them, but that it's much easier to be secure with them. One you have to think about all the time (do I need to escape, do I not need to escape), while the other is almost completely secure against SQL injections by default. Same thing with using system() vs execve()[1]. One is a minefield of quoting issues, the other has none. [1] Or multi-arg system(), like in Perl or Ruby.
  • kpcyrd 11y ago
    Have you had a look at the code? I found a remote code execution 15min after waking up: https://github.com/ipfspics/server/issues/10 https://github.com/ipfspics/server/issues/10