I am sending some data through as a GET parameter using urlencode(base64_encode()) in PHP. Is there any way I can check the data isn't malicious before using it on the other side? I am concerned that if the user sends eval(malicious_code) in the string, it will automatically run when I decode it. Any thoughts?

Maybe I could send a token in the URL and check it on the other side - if so any ideas for that - my mind has gone blank on that front.

  • decoding alone will execute code? – schroeder Jan 19 '17 at 15:42
  • That is part of my question - will it? OR rather - can we say 100% it definitely never will – Liam Bailey Jan 19 '17 at 16:01
  • 1. What are the two "sides" as you put it? JS/HTML in a browser on the client-side, PHP on the server-side? When you say "as a GET parameter" do you then mean that the JS is sending to the PHP, therefore when you say "using it on the other side" you mean on the PHP side? 2. We cannot tell you whether data is malicious without knowing what you use it for. No data is intrinsically malicious. If this data gets stored in a database, then shown as a user comment on a web site, then there are many ways to maliciously exploit the system: SQL injection maybe, script injection in the comment section. – CR Drost Jan 19 '17 at 16:01

If you run urldecode(base64_decode($input)), it will not be executed, just decoded. In your example if an input is eval(...), then you get the string eval(...) after decoding. Unless you explicitly run it, it will not execute.

By the way if the only point of applying base64 encoding is to increase security, as for any other encoding, it will not.

| improve this answer | |
  • Thanks for this. The point is not security, the data is a sizeable chunk of text which is in no way sensitive, encoding is simply a way of making it sendable via the url query parameter. So as long as I don't run eval() or exec or some such on the string it won't run, even if it contains eval itself? Just want to be 100% clear – Liam Bailey Jan 20 '17 at 13:05
  • It wont execute. But if you are sceptical, you can try it! Urlencoding is enough for the data to be transferred correctly, you don't neccessarily need base64. – Rápli András Jan 20 '17 at 13:08

As Rapli says, the recieving end will only execute the code if it has been explicitly configured to do so.

While I see no reason to exchange executable code in this way (unless we are talking about code deployment to a remote system which is a very different conversation) there may well be good reasons for ensuring the integrity of data in such a manner.

As per usual, TLS makes ensuring CIA much simpler but, in the absence of a client certificate, it does not solve all the problems.

A complementary approach would be (for example) to use a simple signing mechanism creating a secure hash using a salt known by both ends and sending that with the message. But this does not protect against replay attacks. For that you need one-time passwords or sequentially numbered transactions. An alternative which merely reduces the window of opportunity would be to agree a TTL and include a timestamp in the (signed) payload.

But note that if you are going down the road of a shared secret, particularly if this is not using TLS, then you would get the added benefit of confidentiality by using that secret as an encryption key rather than just a salt for the hash.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.