2 cissp ® Official Study Guide Eighth Edition

Dynamic Web Applications
In the early days of the web, all web pages were 
static
, or unchanging. Webmasters created 
web pages containing information and placed them on a web server, where users could 
retrieve them using their web browsers. The web quickly outgrew this model because users 
wanted the ability to access customized information based on their individual needs. For 
example, visitors to a bank website aren’t interested only in static pages containing infor-
mation about the bank’s locations, hours, and services. They also want to retrieve 
dynamic
content containing information about their personal accounts. Obviously, the webmaster 
can’t possibly create pages on the web server for each individual user with that user’s per-
sonal account information. At a large bank, that would require maintaining millions of 
pages with up-to-the-minute information. That’s where dynamic web applications come 
into play.
Web applications take advantage of a database to create content on demand when the 
user makes a request. In the banking example, the user logs into the web application, 
providing an account number and password. The web application then retrieves current 
account information from the bank’s database and uses it to instantly create a web page 
containing the user’s current account information. If that user returns an hour later, the 
web server would repeat the process, obtaining updated account information from the 
database. Figure 21.2 illustrates this model.

---

938
Chapter 21 
■
Malicious Code and Application Attacks
F I g u r e 21. 2
Typical database-driven website architecture
Web server
Firewall
User
Database server
What does this mean to you as a security professional? Web applications add complex-
ity to our traditional security model. As shown in Figure 21.2 , the web server, as a pub-
licly accessible server, belongs in a separate network zone from other servers, commonly 
referred to as a demilitarized zone (DMZ). The database server, on the other hand, is 
not meant for public access, so it belongs on the internal network. The web application 
needs access to the database, so the fi rewall administrator must create a rule allowing 
access from the web server to the database server. This rule creates a potential path for 
internet users to gain access to the database server. (For more on fi rewalls and DMZs, 
see Chapter 11, “Secure Network Architecture and Securing Network Components.”) 
If the web application functions properly, it will allow only authorized requests to the 
database. However, if there is a fl aw in the web application, it may allow individuals to 
tamper with the database in an unexpected and unauthorized fashion through the use of 
SQL injection attacks.