9

I installed a wiki on my shared webhosting (using Apache) account. This wiki is set to private (no read/edit/create rights for unauthorized users) and I'm the only one with an account.

The wiki inserts the wiki page title in the URL path, e.g. a page titled "Foobar" would have the URL example.com/wiki/Foobar.

I want to make sure three things:

  1. no-one shall be able to see my wiki content
  2. no-one shall be able to see if I created a certain wiki page
  3. no-one shall be able to see which wiki URLs I visit

In other words: not only the pages contain sensitive content, also the URL path is sensitive.

When I logout and visit example.com/wiki/Foobar (existent) and example.com/wiki/FoobarNope (non-existent) I (1.) can't see any content and (2.) there is no difference in the error message for the existent and the non-existent page.

I use the Firefox add-on RefControl to block the Referer header when I click at links to external pages.

I use HTTPS to encrypt the content and the URL paths (so if I ever should visit my wiki from an untrusted network, no sniffer should be able to see which wiki pages I visit, right?).

Now the only thing I'm not sure about is: What can the other customers on the same shared host see?

Each customer has SSH access. Installation of software is allowed (as long as no root is required). Eveyone has access to /tmp. I can start top and see what processes the other customers use at the moment. And probably more … (I'm not that savvy with this).

May it be possible that other customers see GET requests for the whole server? (if it matters: every customer has an own subdomain, the HTTPS encryption is accomplished by the hosters' wildcard SSL certificate)

Maybe something gets saved to /tmp when I visit a page in my wiki? Cache?

Maybe there is a global (error) log?

Or anything else?

unor
  • 1,769
  • 1
  • 19
  • 38

2 Answers2

9

Since the potential attackers (the other customers on the share host) can see your processes (as well as you see theirs), your Wiki and what you do with it is protected from their inquisitive eyes by the Unix security model: roughly speaking, non-root users cannot impact each other, subject to the access rights on files, directories and devices. You thus should make sure that the directories containing your site have adequate access rights (use chmod to set them). Take care that the Web server itself must be able to access them.

I suppose that your Wiki software uses a database, probably MySQL. Such database system use their own authentication layer, and enforce their own separation of users. There again, see the database documentation to check whether user separation is properly applied.

Ultimately, your security model relies on the lack of local exploits allowing standard users (like you or other customers) to gain root access on the machine or pierce the user separation layer in the database. A look at this database will show that this postulate might be a bit ambitious. Local exploits happen quite a lot, mostly because it is quite harder to protect against them than against remote exploits (IT security practitioners like to say that "the attack surface for local users is very large") and also because many people just don't care about them (local exploits do not matter much when you do not have potentially hostile local users). As usual, this is a risk vs cost trade-off: if security is really important for you, you should rent a dedicated server, not a shared hosting.

A note on SSL and the URL: with HTTPS, the URL themselves go through the tunnel, hence are encrypted. However, external observer can see the length of the encrypted data records, and thus infer the length (in bytes) of the URL you visit on your Wiki. This slight leak may or may not be important to you; if it is, try to get these lengths identical for all pages.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • I would like to add here, that you should not use predictable urls. There are tools like uniscan and many others that try to locate via dictionary attacks the most propable urls your site has. From an inside job this would be even easier as the user might have much better access rights from the localhost or same C class network. – Athanasios Kataras Jan 09 '13 at 10:29
3

If the shared server is configured properly, no other user should be able to see anything regarding your account (access logs, files, etc). Unfortunately that isn't always the case.

If that wiki is so important that you need to worry about the other customers on the server, I'd suggest you to get a VPS.

Zzz
  • 756
  • 5
  • 9
  • 1
    I would concur on the VPS or a good cloud server, they don't typically cost much more, but provide far better isolation. Granted, I still prefer my dedicated server box, but that goes out of most people's price range for their hosting needs. – AJ Henderson Jan 09 '13 at 15:20