Secure single page in a site if site is hacked?

Question

I've been tasked with trying to find a way to secure a single page in our site if somehow, a hacker gets access to our files. This "single page" will be run on a different server.

Requirements:

• Show the user something that lets them know they are definitely viewing the right page

That's about it actually.

The idea being that during a process in our site, the user would navigate to this page, see something that lets them know "you are really at the page you want". That "something" could even be a url that points to a specific server running SSL.

However, I can't really think of any full-proof system to handle this. If somehow a hacker has access to what our website is serving, I feel like they could change anything, even going to an https: url in a new browser window for that page could be spoofed couldn't it? (edit: This is an important question. Could they somehow spoof the url "https://secure.ourwebsite.com" if they hack the main website at "http://main.ourwebsite.com"? Would the browser inform the user that they were actually going to the wrong url?)

Is this an impossible task?

edit
One potential idea would be something like this:
Client opens "http://main.ourwebsite.com". In an iframe, we load: "https://secure.ourwebsite.com". On that secure page, we have a key sent from the server. That page then uses Ajax to send that key BACK to the server, which verifies that the key was correct and shows a shiny image. This allows the user to visually see that they have a secure connection. Then when the user submits the form (on secure.ourwebsite.com) we encrypt the information and send it back over the SSL to secure.ourwebsite.com.
Is that a viable option?

Answer 1

The principle of SSL is that when the client browser displays https://secure.example.com/whatever.html then the URL bar in the browser shows that exact URL and the human user can be confident in the fact that what he sees is really what the server which genuinely owns the name secure.example.com decided to send at that time. This is completely unrelated to whatever happens with any other site, be it main.example.com.

And that's all.

This means that if you use an iframe then there is no URL bar, and therefore no guarantee. From the point of view of the user, when he connects to main.example.com then he sees what that server wishes him to view; if the server is under complete control of the attacker, then the user sees what the attacker wants the user to see. In particular, the attacker will not want the user to see the iframed version of https://secure.example.com/; instead, the attacker will server a picture which looks like the secure page, but is not the real thing. Since that's an iframe, the user cannot see the difference. The URL bar is the foundation of HTTPS security. Otherwise, it's just pictures, which are easily counterfeited.

There's really no salvation for a hacked site. No amount of SSL, Ajax or iframes will fix that.

Answer 2

SSL only protects the transmission and authenticity of the server/client connect. It doesn't help with protecting the content on the server in question.

To solve your problem, you need to create a hash of the content and sign it with your corporate private key. The user can now use your public key to verify that the content has not been tampered with.

As long as you keep your private key, well, private, then this approach is extremely safe.

You can use something like GnuPG to implement it.

Update: If someone hacks your "main" site, they can put up whatever content they like, including faking the content of your "secure" iframe. There is nothing you can do about that, except making sure your site is not compromised in the first place. Sorry. The approach signing content with gnupg still works, but it requires your user to check it themselves using your public key.

Answer 3

I don't think trying to hide a breach is the best approach, you should probably focus on doing a security review first, maybe hire a professional pentester if your company is really worried about security rather than in their public image.

Having said that, I see 3 different problems that you need to solve if you still want to take this route:

1. Figure out if the main page has been hacked.
2. How to fail over to the secondary server.
3. Not getting your secondary server hacked.

What I would do for 2 is probably a DNS approach, when you detect the page has been changed you modify your main domain name to point to the address of the secondary server, you will need some DNS provider that offers an API to do this programatically.

For problem 3 you need to have the secondary server on a complete different network/hosting provider, just to be on the safe side, and only have a single static page.

Problem 1 might be the hardest, since there is so many ways to modifiy a site, or the attacker might just not modify it at all.

Answer 4

I recall years ago there was a vendor that provided a hardware solution to the problem you describe.

It was an inline networking device. You would generate a checksum for the page you wanted to protect and the device would validate the checksum before it would allow the content to be served.

You could also create stop & go words. (most WAF's today will do this)

I don't know if the company is still around or not... I'll do some digging. I don't remember their name.

EDIT: I dug through some old business cards and the company was called Vericept. I hit the website and they appear to be Trustwave and are in the DLP space. They may still have a device that does what I mentioned above.