The load balancer may fulfill a security function in addition to making sure the over‐
all application has good performance. A load balancer
may function like a reverse
proxy, meaning it handles requests as though it were the actual web server. This
means the client never knows the real web server. No data is stored on this system
because its only purpose is to pass through the request. This is the reverse of a proxy
an enterprise might use, where the clients are hidden behind the proxy.
In this case,
the web server is hidden by the proxy.
If you were using a reverse proxy, you may be able to have it function as a web appli‐
cation firewall. Requests passing through the web server are evaluated to see whether
the requests appear to be legitimate or malicious. Malicious requests may be blocked
or logged, depending on their severity. This spreads out
the burden of validation and
is especially useful if the web application being used has not been developed by the
enterprise where it is run. If the internal functioning of the application isn’t known, it
can be helpful to have something watching out for requests that look bad.
Web Server
The
web server
takes in HTTP requests and feeds HTTP back. In a real application
architecture, this server could fulfill several functions. There could be code running
on
the server, or it could simply be a place to determine whether the response is static
(in which case it would be served up by the web server), or dynamic (in which case it
would be passed to servers behind the web server). Validation code may be run here
to ensure nothing bad is fed into the backend systems.
In some cases, such as really
small implementations, there may be little more than this server.
Web servers that run some form of code may have that code written in web-based
programming languages like PHP or several other languages.
Several other languages
can be used to perform simple server-side code. Programs that perform validation or
generate pieces of dynamic pages will run on this server, rather than on the client.
This is not to say that no code runs on the client. However, it is important to keep in
mind all of the places where program code can execute.
Anywhere code can execute
is a potential point of attack. If code is run on the web server, the web server is vul‐
nerable to attack.
If the web server were to be compromised, any data stored on the server would be
exposed to theft or modification. Any credentials stored
on the web server to get
access to any additional systems could be used, and the web server itself could
become a launching point for additional attacks against other systems.
