Is there even a way to make a server unhackable? I am really not sure :-(
I would try to put the whole thing on Google App Engine, at least then the burden would be on Google for the most part :-/
I would try to put the whole thing on Google App Engine, at least then the burden would be on Google for the most part :-/
Its a pretty difficult thing, the simple answer it turn it off :-) however you're second comment is more relevant.
"I would try to put the whole thing on Google App Engine, at least then the burden would be on Google for the most part :-/"
Google does a good job of securing their servers, however the risk is not that the 'server' gets hacked, rather its the application running on the server. So for example someone can't log into your server but they can SQL inject a command to dump your web site's password list and they don't have to log in.
Good secure design would start with really really strong testing around the applications 'mutation' points (which is to say where it changes in response to user input). When I was at Google products had to go through a security audit before being released and those guys were pretty good at their jobs. This is one of those cases where seeing a lot of ways people try to attack services gives you a leg up on looking for common weak points.
Nothing can ever be fully secure, but you can make it secure for all practical considerations.
Securing a network/host/application is like getting (and staying) in shape. It's a process that requires an ongoing effort. There's nothing you can buy that will take care of it forever.
Most breaches aren't the result of "impossible to prevent" attacks, they're the result of basic due diligence not being followed. You're right though, that it seems some days like that's the rule and not the exception.
While you can't have an "unhackable" site (or an "uncrackable" safe), it's all a matter of risk vs. reward. You can certainly ensure that your site doesn't have any vulnerabilities listed in the OWASP Top 10 (and test it repeatedly over time to make sure it stays that way).
And that's not even getting into a more mature vulnerability management process that involves outside assessments, source code reviews, and threat modeling. All those things are also nice to haves (or may be required, depending on your industry and the type of data you have access to).
It's totally understandable to be a pessimist about the state of security in our industry, but preventing these types of issues is not a Sisyphean task.
An unhackable server is probably possible, but a non-trivial unhackable server probably isn't. But you can still create sites that are secure, even if hackable. If the hackers had accessed a database of bcrypted passwords and if the site would have locked down when it detected erroneous volume of transactions, there would be no headliner here.
GAE doesn't even use SQL, btw. At least last time I checked they didn't - they seem to be planning to support it in the future, though.
However, even if the server is secure, I suppose if it was known that I am the admin of a BitCoin bank, my home computer would become a target, too. If my home computer would be hacked and I logged into the server, I would be screwed, too. It just seems too risky...
While the latter can happen and is broadly easier for a script kiddie, believe me, the former is nontrivial and very rarely done correctly. Your average web app is full of vulnerabilities, and while scanning can't quite be fully automated it's definitely something you can use automation to help with, so don't think you're secure-through-obscurity.
You can still directly append unescaped user input to your query and execute that against your datastore, though the limited capabilities of GQL does limit the attack surface somewhat.