-1

Can we use encryption (like base64 and...) instead of using real_escape_string for GET and POST data?

I know that it will slow the application down but how about the security?

webelizer
  • 316
  • 1
  • 11
  • 1
    Which security measures to you wish to perform? I'm struggling to see what base64 encoding a string will do for anything other than readability. – JimL Sep 13 '13 at 15:02
  • 1
    If you were using MySQLi/PDO prepared statements/bind variables, this wouldn't even be an issue – Mark Baker Sep 13 '13 at 15:03
  • 4
    Base 64 isn't *encryption*, it's *encoding*. – Bruno Sep 13 '13 at 15:04
  • the base64 is not important part! even AES! – webelizer Sep 13 '13 at 20:10
  • @webelizer "*the base64 is not important part! even AES!*": you seem to be confusing everything here (and no one talked about AES). Input sanitisation has nothing to do with encryption. Both are useful, but they are completely different aspects of security. – Bruno Sep 13 '13 at 20:18

4 Answers4

5

Neither.

Both options are equally useless and error-prone.

  • First, you have to distinguish an SQL query from a database. You need no data transformation for the latter at all.
  • Next, you have to format your data properly for the SQL query. not "escape" it.
  • Finally, as formatting rules are so complex to the point of being incomprehensible by average PHP user, he is supposed to use prepared statements instead, as the latter will format the data properly for him.
Community
  • 1
  • 1
Your Common Sense
  • 152,517
  • 33
  • 193
  • 313
  • 1
    I wish there was a feature like twitter "followers" because i love your snarky tone in your answers and comments. There should be more around here like these. – STT LCU Sep 13 '13 at 15:16
  • Thank U very much. how about this situation: imagine I have a blog system which user can save html post. we don't need searching the post or something else.... if I encrypt the post body (not other things) is it safe to save it directly to the database? I mean some times we just need to read and write the text to the database and nothing more! – webelizer Sep 13 '13 at 20:17
0

If your intention is performing client-side encryption as a means to protect communication client to application communication, you may find HTTPS / SSL encryption is a preferable alternative to doing it yourself. Hand-rolling encryption and decryption introduces another element of design complexity to your application's communication, which may be easy to circumvent depending on how it is designed.

EDIT: Encrypting data does not negate the risk of injection attacks as you will need to decode it on the application server. A clever assailant could simply piggyback your encryption method prior to transmission, injecting any payload they please.

plasmid87
  • 1,430
  • 1
  • 14
  • 20
  • thanks plasmid87, could you please explain more about injecting in this situation? – webelizer Sep 13 '13 at 20:19
  • No problem. Consider this scenario: the client software prepares information for transmission by using reversible encryption. Given that this action occurs in the client system environment, it is fair to assume that a knowledgeable agent could observe or reverse engineer the encryption being used from the client itself. With this knowledge, any message can be sent to the server using the same encryption. When the server decrypts the message, it is not safe for the server software to assume that the payload being sent is from a trusted source (it could be forged / altered, as mentioned above). – plasmid87 Sep 16 '13 at 17:30
0

Firstly, base 64 has nothing to do with encryption: it's an encoding mechanism, which allows for arbitrary binary data to be encoded as text, and decoded back when necessary.

Secondly, use prepared statements (or at least an API with bound parameters), not *_real_escape_string.

Community
  • 1
  • 1
Bruno
  • 110,518
  • 24
  • 258
  • 357
-1

Anyone can base64 encode their own bad injections with base64 so it's not at all a good idea. Also it's fairly easy to reverse engineer a custom salt for 6b4 encoded data so no.

Andy Gee
  • 2,728
  • 2
  • 21
  • 31