-2

I am having some trouble here. I am building a search engine for my social debating platform, where all the user content (except sensitive data) is encoded in base64, for security purposes. While building the search engine I stumbled upon an issue; I couldn't search the user content if it was all stored in base64, obviously. Then I stumbled upon an answer here that stated that using FROM_BASE64 on the SQL query would decode and then process it. As a person who is extremely paranoid about security, my first concern was: does that function protect against any SQL Injection attacks when processing the data? Or would I need to when posting the content real_escape and then do base64 to use the function securely?

Sergio E. Diaz
  • 396
  • 3
  • 15
  • If you are extremely paranoid about security then you do realize that BASE64 isn't an encryption mechanism at all... and should never be used to store sensitive stuff... – Matt Jul 09 '14 at 19:29
  • If you remove the (exception), you are saying the same thing... "where all the user content is encoded in base64, for security purposes". Meaning all the user content (for security purposes) is base64... – Matt Jul 09 '14 at 19:35
  • Why would you base64 encode the safe stuff? Your just making it harder on yourself. Base64 is best left to transport layer, not storage. – Matt Jul 09 '14 at 19:38
  • How is user input safe? – Sergio E. Diaz Jul 09 '14 at 19:39
  • So you are saying: Yeah, user input is safe, don't even sanitize it, or encrypt it. – Sergio E. Diaz Jul 09 '14 at 19:40
  • 2
    Sergio: we are here to help you, we don't ow you nothing, you are the one who is asking here for help from others. So if someone misreads your question or didn't get something that YOU stated, at least have the decency to answer i a polite way. You don't want your questions to be answered? Because that's how you don't get your questions answered. – Michal Jul 09 '14 at 19:40
  • Yes you should sanitize it, but that's not the job of the DB layer, that's the application layer. Unsafe/Unsanitized should never have a chance to make it to the DB. – Matt Jul 09 '14 at 19:40
  • Also again, base64 isn't encryption, its encoding. – Matt Jul 09 '14 at 19:41
  • Matt: you clearly stated: "Why would you base64 encode the safe stuff?". I am afraid that user input is not safe stuff. – Sergio E. Diaz Jul 09 '14 at 19:42
  • I have NEVER mentioned it is encryption. – Sergio E. Diaz Jul 09 '14 at 19:43
  • Different meaning of safe. Meaning it doesn't require encryption for security purposes (password, email, secret stuff). Safe to be stored in plain text is what I meant. Not safe to be "executed". – Matt Jul 09 '14 at 19:44

1 Answers1

0

short answer : as long as you dont put HTTP-data into the FROM_BASE64-query there is no need to use base64 AT ALL - but using it does no harm. If you want to put ESCAPED http-data into it you also want to check for SQL-patterns, ... many languages have certain DBM-escapement functions / libraries, you're advised to use them

NEVER feed http-data directly into DB-functions of ANY kind without escaping it.

specializt
  • 1,913
  • 15
  • 26
  • What exactly are you saying? – Sergio E. Diaz Jul 09 '14 at 19:46
  • disregard base64 except if you want to store binary data and focus on SQL-escapement http://www.php.net/manual/en/mysqli.real-escape-string.php – specializt Jul 09 '14 at 19:50
  • http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php don't store in Base64, store in plain text, use parameters to avoid SQL Injection – Matt Jul 09 '14 at 19:51