6

The shared hosting I am using had Memcached enabled, I searched some forums that using Memcached in a shared hosting environment, can cause security problems like view the cache of the other user, edit the cache, etc. But the date is way back 2013, so I am a bit anxious about it, is it still not secure/safe to use Memcached in shared hosting environment?

And also, I do not have an access in the php.ini so SASL authentication will not work on me. Is there a way to use Memcached safely/securely? If it doesn't, are there any other options for me to use cache the data results?

Da Heel
  • 81
  • 1
  • 2

2 Answers2

2

If you did not configure it, then you can't know if its secure. Doesn't matter if we're talking about memcached, an Oracle database, opensshd....

As grochmal says, there are no intrinsic access control mechanism in memcache. So there is very little scope for the service provider to implement the kind of partitioning you might desire.

Encrypting all the data you store in memcache would solve the disclosure problem (but creates a key management problem). It doesn't prevent damage to the data.

are there any other options for me to use cache the data results

We don't know what the hosting is nor what your requirements for security are. If "the data" is a mysql result set, then you use mysql's caching. If its JSON data fetched via HTTP then you may be able to use a forward proxy. If its caching the output of your own pages, then a reverse proxy.....

symcbean
  • 18,278
  • 39
  • 73
1

Well, memcached itself has no permission configuration whatsoever (just the permissions of the listening socket). You simply boot the daemon and all memory objects that are sent to it will be stored based on the key. There is no distinction between the user or machine that sends or retrieves the data, you can even get key collisions.

Memcached was designed to be simple a small, forcing the application layer to think about everything else. And originally designed to run on the same machine as the application. That design did not change since 2013.

All that said, if a hosting provider gives you a socket on a different machine to which you connect to memcached directly, then you should stop using that hosting provider straight away. That's just plain unwise. Hosting providers that use memcached will either run a different memcached daemon for each user (the entire daemon is just a couple of kilobytes), use a reverse proxy (with authentication), or build a memcached compatible cache that does not really run memcached.

If you look at what AWS does:

A Memcached layer is an AWS OpsWorks layer that provides a blueprint for instances that function as Memcached servers

i.e. their elastic cache can be used as a memcached cache, but it is not a memcached daemon listening on a socket. And (from the same article) you can see that there is authentication to your cache:

Custom security groups

This setting appears if you chose to not automatically associate a built-in AWS OpsWorks security group with your layers. You must specify which security group to associate with the layer. For more information, see Create a New Stack.

Therefore, using memcached as any networked solution notably in a hosting environment is simply unwise. But most hosting environments advertising memcached, aren't really using memcached, they place a layer in from to add permissions.

grochmal
  • 5,677
  • 2
  • 19
  • 30