Securing the backend of your web application?

Question

We are grappling with how to architect are back end for security. Some of the recommendations I've seen look like this:

Some will have another firewall between the application server and the database (which would be on the internal network).

Question being with today's highly interactive pages where a lot of the logic is in javascript how would this work? Javascript generally needs to receive json. I would guess in this structure that the web server can't communicate directly with the database server. So you would have to go through the application server. That's all fine an dandy when your pages are static and the only code that will be communicating with the app server will be the web server but generally javascript will need to communicate with the app server (which in our case will be REST services). I'm also assuming in this structure the only thing that can communicate with the application server is the web server.

Answer 1

That's actually correct.

Typical web page request liftime:

• Javascript makes a request to the web server
• Web server validates the request
• • If the request is bad, reject it
• • If the request is good, send it to the app server
• App server receives the request for the data, retrieves it, send it back to the web server
• Web server formats the data into a JSON and sends it back to the client
• Client recieves data, validates it's what it is expecting, and does something

Of course this is something you've probably seen time and time again, but it doesn't really explain why the web server is there... or does it?

Let's look at the web server validating the request:

Here's there are three things that can happen:

• Request is malicious, this server instance goes down
  • Because of the way you formatted this web server, that malicious request doesn't affect the database or app server, so you jsut restart hte instance
• Someone intrudes onto the web server, and gets isolated in a netowrk of honeypots
• DDOS attack comes through to the web server, not database or app server

basically the advantage of this is that you can have your DNS point to the web server, and keep your app server and database secret and direct IP access only, meaning any other services(like data reporting) stay up if your website goes down.