In: Categories » Electronics and communication » Protocols » THE WEB APPLICATION ARCHITECTURE
| Web application architectures most closely approximate the centralized model of computing, with many distributed “thin” clients that typically perform little more than data presentation connecting to a central “thick” server that does the bulk of the processing. What sets Web architectures apart from traditional centralized computing models (such as mainframe computing) is that they rely substantially on the technology popularized by the World Wide Web, the Hypertext Markup Language (HTML), and its primary transport medium, Hypertext Transfer Protocol (HTTP). Although HTML and HTTP define a typical Web application architecture, there is a lot more to a Web app than these two technologies. A Brief Word about HTMLAlthough HTML is becoming a much less critical component of Web applications as we write this, it just wouldn’t seem appropriate to omit mention of it completely since it was so critical to the early evolution of the Web. We’ll give a very brief overview of the language here, since there are several voluminous primers available that cover its every aspect. Our focus will be on the security implications of HTML. As a markup language, HTML is defined by so-called tags that define the format or capabilities of document elements. Tags in HTML are delimited by angle brackets < and >, and can define a broad array of formats and functionalities as defined in the HTML specification. Here is a simple example of basic HTML document structure: <HTML> <H1>This is a First-Level Header</H1> <p>This is the first paragraph.</p> </HTML> When displayed in a Web browser, the tags are interpreted and the document elements are given the format or functionality defined by the tags, as shown in the next illustration (we’ll discuss Web browsers shortly). As we can see in this example, the text enclosed by the <H1> </H1> brackets is formatted with a large, boldfaced font, while the <p> </p> text takes on a format appropriate for the body of the document. Thus, HTML primarily serves as the data presentation engine of a Web application (both server- and client-side). As we’ve noted, a complete discussion of the numerous tags supported in the current HTMLspec would be inappropriate here, but we will note that there are a few tags that can be used to deleterious effect by malicious hackers. Most commonly abused tags are related to taking user input (which is done using the <INPUT> tag, wouldn’t you know). For example, one of the most commonly abused input types is called “hidden,” which specifies a value that is not displayed in the browser, but nevertheless gets submitted with any other data input to the same form. Hidden input can be trivially altered in a client-side text editor and then posted back to the server—if a Web application specifies merchandise pricing in hidden fields, you can see where this might lead. Another popular point of attack is HTML forms for taking user input where variables (such as password length) are again set on the client side. For this reason, most savvy Web application designers don’t set critical variables in HTML very much anymore. Most of the power of HTML derives from its confluence with HTTP. When combined with HTTP’s ability to send and receive HTML documents, a vibrant protocol for communications is possible. Indeed, HTML over HTTP is considered the lingua franca of the Web today. Transport: HTTPAs we’ve mentioned, Web applications are largely defined by their use of HTTP as the medium of communication between client and server. HTTP version 1.0 is a relatively simple, stateless, ASCII-based protocol defined in RFC 1945 (version 1.1 is covered in RFC 2616). It typically operates over TCP port 80, but can exist on any unused port. Each of its characteristics—its simplicity, statelessness, text base, TCP 80 operation—is worth examining briefly since each is so central to the (in)security of the protocol. The discussion below is a very broad overview; we advise readers to consult the RFCs for more exacting detail. HTTP’s simplicity derives from its limited set of basic capabilities, request and response. HTTP defines a mechanism to request a resource, and the server returns that resource if it is able. Resources are called Uniform Resource Identifiers (URIs) and they can range from static text pages to dynamic streaming video content. Here is a simple example of an HTTP GET request and a server’s HTTP 200 OK response, demonstrated using the netcat tool. First, the client (in this case, netcat) connects to the server on TCP 80. Then, a simple request for the URI “/test.html” is made, followed by two carriage returns. The server responds with a code indicating the resource was successfully retrieved, and forwards the resource’s data to the client. C:\>nc -vv www.test.com 80 www.test.com [10.124.72.30] 80 (http) open GET /test.html HTTP/1.0 HTTP/1.1 200 OK Date: Mon, 04 Feb 2002 01:33:20 GMT Server: Apache/1.3.22 (Unix) Connection: close Content-Type: text/html <HTML><HEAD><TITLE>TEST.COM</TITLE>etc. HTTP is thus like a hacker’s dream—there is no need to understand cryptic syntax in order to generate requests, and likewise decipher the context of responses. Practically anyone can become a fairly proficient HTTP hacker with very little effort. HTTPis also an ASCII text-based protocol. This works in conjunction with its simplicity to make it approachable to anyone who can read. There is no need to understand complex binary encoding schemes or use translators—everything a hacker needs to know is available within each request and response, in cleartext. Finally, HTTP operates over a well-known TCP port. Although it can be implemented on any other port, nearly all Web browsers automatically attempt to connect to TCP 80 first, so practically every Web server listens on that port as well (see our discussion of SSL/TLS in the next section for one big exception to this). This has great ramifications for the vast majority of networks that sit behind those magical devices called firewalls that are supposed to protect us from all of the evils of the outside world. Firewalls and other network security devices are rendered practically defenseless against Web hacking when configured to allow TCP 80 through to one or more servers. And what do you guess is the most common firewall configuration on the Internet today? Allowing TCP 80, of course—if you want a functional Web site, you’ve gotta make it accessible. Of course, we’re oversimplifying things a great deal here. There are several exceptions and qualifications that one could make about the previous discussion of HTTP. SSL /TLSOne of the most obvious exceptions is that many Web applications today tunnel HTTP over another protocol called Secure Sockets Layer (SSL). SSL can provide for transport-layer encryption, so that an intermediary between client and server can’t simply read cleartext HTTP right off the wire. Other than “wrapping” HTTP in a protective shell, however, SSL does not extend or substantially alter the basic HTTP request-response mechanism. SSL does nothing for the overall security of a Web application other than to make it more difficult to eavesdrop on the traffic between client and server. If an optional feature of the SSL protocol called client-side certificates is implemented, then the additional benefit of mutual authentication can be realized (the client’s certificate must be signed by an authority trusted by the server). However, few if any sites on the Internet do this today. The latest version of SSL is called Transport Layer Security (TLS). SSL/TLS typically operates via TCP port 443. State Management: Cookies We’ve dwelt a bit on the fact that HTTP itself is stateless, but a number of mechanisms have been conceived to make it behave like a stateful protocol. The most widely used mechanism today uses data called cookies that can be exchanged as part of the HTTP Authentication Close on the heels of statefulness comes the concept of authentication. What’s the use of keeping track of state if you don’t even know who’s using your application? HTTP can embed several different types of authentication protocols. They include Basic Cleartext username/password, Base-64 encoded (trivially decoded). - Digest Like Basic, but passwords are scrambled so that the cleartext version cannot be derived. - Form-based A custom form is used to input username/password (or other credentials) and is processed using custom logic on the back end. Typically uses a cookie to maintain “logged on” state. - NTLM Microsoft’s proprietary authentication protocol, implemented within HTTP request/response headers. - Negotiate A new protocol from Microsoft that allows any type of authentication specified above to be dynamically agreed upon by client and server, and additionally adds Kerberos for clients using Microsoft’s Internet Explorer browser version 5 or greater. - Client-side Certificates Although rarely used, SSL/TLS provides for an option that checks the authenticity of a digital certificate presented by the Web client, essentially making it an authentication token. - Microsoft Passport A single-sign-in (SSI) service run by Microsoft Corporation that allows Web sites (called “Passport Partners”) to authenticate users based on their membership in the Passport service. The mechanism uses a key shared between Microsoft and the Partner site to create a cookie that uniquely identifies the user. These authentication protocols operate right over HTTP (or SSL/TLS), with credentials embedded right in the request/response traffic. Clients authenticated to Microsoft’s IIS Web server using Basic authentication are impersonated as if they were logged on interactively. Other Protocols HTTP is deceptively simple—it’s amazing how much mileage creative people have gotten out of its basic request/response mechanisms. However, it’s not always the best solution to problems of application development, and thus still more creative people have wrapped the basic protocol in a diverse array of new dynamic functionality. Of course, Web applications can also call out to any of the other popular Internet protocols as well, such as e-mail (SMTP) and file transfer (FTP). Many Web applications rely on embedded e-mail links to communicate with clients. Finally, work is always afoot to add new protocols to the HTTP suite. One of the most significant new additions is Web Distributed Authoring and Versioning (WebDAV). WebDAV is defined in RFC 2518, which describes several mechanisms for authoring and managing content on remote Web servers. Personally, we don’t think this is a good idea, as protocol that involves writing data to a Web server is trouble in the making. Nevertheless, WebDAV is backed by Microsoft and already exists in their widely deployed products, so a discussion of its security merits is probably moot at this point. The Web ClientThe standard Web application client is the Web browser. It communicates via HTTP (among other protocols) and renders Hypertext Markup Language (HTML), among other markup languages. In combination, HTML and HTTP present the data processed by the Web server. Like HTTP, the Web browser is also deceptively simple. Because of the extensibility of HTML and its variants, it is possible to embed a great deal of functionality within seemingly static Web content. Some of those capabilities are based around active content technologies like Microsoft’s ActiveX and Sun Microsystem’s Java. Embedding an ActiveX object in HTML is this simple: <object id="scr" classid="clsid:06290BD5-48AA-11D2-8432-06008C3FBFC"> </object> Once again, in the world of the Web, everything is in ASCII. When rendered in a Web browser that understands what to do with ActiveX, the control specified by this object tag will either be downloaded from the remote Web site, or loaded directly from the local machine if it is already installed (many ActiveX controls come preinstalled with Windows and related products). Then it is checked for authenticity using Microsoft’s Authenticode technology, and by default a message is displayed explaining who digitally signed the control and offering the user a chance to decline to run it. If the user says yes, the code executes. Some exceptions to this behavior are controls marked “safe for scripting,” which run without any user intervention. Finally, the Web browser can speak in other protocols if it needs to. For example, it can talk to a Web server via SSL if that server uses a certificate that is signed by one of the many root authorities that ship certificates with popular commercial browsers. And it can request other resources such as FTP services. Truly, the Web browser is one of the greatest weapons available to attackers today. Despite all of the frosting available with current Web browsers, it’s still the raw HTTP/HTML functionality that is the hacker’s best friend. A great deal of information slips by underneath the pretty presentation of a Web browser, and in some cases, they surreptitiously reformat some requests that might be used to test Web server security (for example, Microsoft’s Internet Explorer strips out dot-dot-slashes before sending a request). Now, we can’t have that happening during a serious security review, can we? The Web ServerThe Web server is most simply described as an HTTP daemon (service) that receives client requests for resources, performs some basic parsing on the request to ensure the resource exists (among other things), and then hands it off to the Web application logic for processing. When the logic returns a response, the HTTP daemon returns it to the client. There are many popular Web server software packages available today. In our consulting work, we see a large amount of Microsoft IIS, the Apache Software Foundation’s Apache HTTP Server (commonly just called “Apache”), AOL/Netscape’s Enterprise Server, and Sun’s iPlanet. To get an idea of what the Web is running on its servers at any one time, check out the Netcraft survey at http://www.netcraft.net. Web Servers vs. Web Applications Which brings up the oft-blurred distinction between Web servers and Web applications. In fact, many people don’t distinguish between the Web server and the applications that run on it. This is a major oversight—we believe that vulnerabilities in either the server or elsewhere in the application are important. While we’re at it, let’s also make sure everyone understands the distinction between two other classes of vulnerabilities, network- and system-level vulnerabilities. Networkand system-level vulnerabilities operate below the Web server and Web application. They are problems with the operating system of the Web server, or insecure services running on a system sitting on the same network as the Web server. In either case, exploitation of vulnerabilities at the network or system level can also lead to compromise of a Web server and the application running on it. This is why firewalls were invented—to block access to everything but the Web service so that you don’t have to worry so much about intruders attacking these other points. We bring these distinctions up so that readers learn to approach security holistically. Anywhere a vulnerability exists—be it in the network, system, Web server, or application—there is the potential for compromise. For example, a typical attack must traverse the network, dealing with wire-level protocols such as Ethernet and TCP/IP, then pass the system layer with housekeeping issues such as packet reassembly, and on through what we call the services layer where servers like the HTTP daemon live, through to application logic, and finally to the actual data manipulated by the application. At any point during the path, a vulnerability existing in one of the layers could be exploited to cause system or network compromise. However, like the OSI model, the abstraction provided by lower layers gives the appearance of communicating logically over one contiguous medium. For example, a properly implemented attack against an HTTP server would simply ride unobtrusively through the network and system layers, then arrive at the services layer to do its damage. The application and data layers are none the wiser, although a successful exploit of the HTTP server may lead to total system compromise, in which case the data is owned by the attacker anyway. The Web ApplicationThe core of a modern Web site is its server-side logic (although client-side logic embedded in the Web browser still does some heavy lifting). This so-called “n-tier” architecture extends what would normally be a pretty unsophisticated thing like a HTTP server and turns it into a dynamic engine of functionality that almost passes for a seamless, stateful application that users can interact with in real time. The concept of “n-tier” is important to an understanding of a Web application. In contrast to the single layer the Web app layer can itself be comprised of many distinct layers. The stereotypical representation is three-layered architecture, comprised of presentation, logic, and data. To understand how this all works together, let’s illustrate with an example. Consider a simple Web application that searches the local Web server hard drive for filenames containing text supplied by the user and displays the results. The presentation layer would consist of a form with a field to allow input of the search string. The logic layer might be an executable program that takes the input string, ensures that it doesn’t contain any potentially malicious characters, and invokes the appropriate database connector to open a connection to the data layer, finally performing a query using the input string. The data layer might consist of a database that stores an index of all the filenames resident on the local machine, updated in real time. The database query returns a set of matching records, and spits them back to the logic layer executable. The logic layer parses out unnecessary data in the recordset, and then returns the matching records to the presentation layer, which embeds them in HTML so that they are formatted prettily for the end user on their trip back through the Web server to the client’s browser. Many of the technologies used to actually build applications integrate the functionality of one or more of these layers, so it’s often hard to distinguish one from the other in a real-world app, but they’re there. For example, Microsoft’s Active Server Pages (ASP) allow you to embed server-side logic within Web pages in the presentation layer, so that there is no need to have a distinct executable to perform the database queries. The key thing to understand about all of these technologies is that they work more like executables rather than static, text-based HTML pages. For example, a request for a http://www.somesite.net/article.php?id=425&format=html As you can see, the file article.php is run just like an executable, with the items to the left of the question mark treated like additional input, or arguments. If you envision article.php as a Windows executable (call it article.exe) run from a command line, the previous example might look like this: C:\>article.exe/id: 425/format: html Hackers the world over are probably still giving thanks for this crucial development in the Web’s evolution, as it provides remote users the ability to run code on the Web server with user-defined input. This places an extremely large burden on Web application developers to design their scripts and executables correctly. There are also a whole host of vendors who package so-called Web application platforms that combine a Web server with an integrated development environment (IDE) for Web application logic. Some of the more popular players in this space include BEA Systems, Broadvision, and others. Finally, multiple applications can run on one Web server. This contributes to the complexity of the overall Web architecture, which in turn increases the risk of security exposures. The DatabaseSometimes referred to as the “back end,” the data layer typically makes up the last tier in an n-tier architecture. Perhaps more than anything else, the database has been responsible for the evolution of the Web from a static, HTML-driven entity into a dynamic, fluid medium for information retrieval and e-commerce. The vendors and platforms within the data layer are fairly uniform across the Web today: SQL (of the Microsoft and non-Microsoft variety) and Oracle are the dominant players here. Logic components typically invoke a particular database connector interface to talk directly with databases, make queries, update records, and so on. The most common connector used today is Open Database Connectivity, or ODBC. ProxiesOne of the first usurpers of the clean one-client-to-one-server model was the Web proxy. Folks who administered large networks like America Online (AOL) decided one day that instead of allowing each of their umpteen million individual subscribers to connect to that newfangled Internet thing, they would implement a single gateway through which all connections had to pass. This gateway would terminate the initial browser request, and then request the original resource on behalf of the client. This allowed the gateway to do things like cache commonly requested Internet content, thus saving bandwidth, increasing performance, and so on. A gateway that makes requests on behalf of a client system has traditionally been called a proxy. Proxies largely behave as advertised, sparing bandwidth and decreasing server load, but they have at least one ugly side effect: state management or security mechanisms based on client source IP address tend to get all fouled up when traversing a proxy, since the source address of the client is always the proxy. How do you tell one client’s request from another? Even worse, when implemented in arrays as AOL does, one client request may come out of one proxy, and a second request may come out of another. Take home point: don’t rely on client-side information when designing Web application state management or security measures. Load BalancersAs you might imagine, someone soon came up with a similar idea for the server side of the Web equation. Load balancers perform somewhat like reverse proxies, managing the incoming load of client requests and distributing them across a farm of identically configured Web servers. The client neither knows nor cares if one server fulfills its request or another. This greatly improves the scalability of Web architectures, since a theoretically unlimited number of Web servers can be employed to respond to ever-increasing numbers of client requests. Load balancing algorithms can be categorized into static (where requests are routed in a predetermined fashion such as round-robin) or dynamic (in which requests are shunted to servers based on some variable load factor like least connections or fastest link). The load balancer itself typically takes on a canonical name like www.company.com, and then routes requests to virtual servers, which may or may not have Internet-accessible addresses. The New Model: Web ServicesThe Web is constantly evolving. What’s in store for Web application architectures in the near future? As we write this, the words on everybody’s lips are Web services. Web services are comparable to self-contained, modular Web applications. Web services are based on a set of much-hyped Internet standards-indevelopment. Those standards include the Web Services Definition Language (WSDL), an XMLformat for describing network services; the Universal Description, Discovery, and Integration (UDDI) specification, a set of XML protocols and an infrastructure for the description and discovery of Web services; and the Simple Object Access Protocol (SOAP), an XML-based protocol for messaging and RPC-style communication between Web services. (Is anyone not convinced XML will play an important role in the future of the Web?) Leveraging these three technologies, Web services can be mixed and matched to create innovative applications, processes, and value chains. Webservices alleviate a lot of this work because they can describe their own functionality and search out and dynamically interact with other Web services via WSDL, UDDI, and SOAP. Web services thus provide a means for different organizations to connect their applications with one another to conduct dynamic e-business across a network, no matter what their application, design, or run-time environment (ASP, ISAPI, COM, J2EE, CORBA, and so on). WDSL, UDDI, and SOAP grew out of collaborative efforts between Microsoft and various other vendors (including IBM, Ariba, DevelopMentor, and UserLand Software). Manyof the other large technology movers like Sun and Oracle are also on board the Web service bandwagon, so even though the current standards may not look the same in six months, it’s clear that Web services are here for the long haul. And of course, there will be a whole new crop of security woes as these new technologies move from crawling to walking.
|
legal disclaimer
1) Our website is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringements, please read the Terms of service and contact us to investigate the problem.
2) The E-articles directory team is not responsible for inaccuracies, falsehoods, or any other types of misinformation this tutorial may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here. Please read the Terms of service
Useful tools and features
If you like this article (tutorial), please link to it from your web page using the information above. Linking to this page, this is the only way to help us improve our service, the same time providing your visitors with a way to improve their online experience.
related articles
H.323 H.323 defines packet standards for terminal equipment and services for multimedia communications over local and wide area networks communicating with systems connected to telephony networks such as ISDN. The initial version of this standard came from the International Telecommunications Union (ITU) in June 1996. It defines communication over IP-based local area networks (LANs). A later version (v2), adopted in January 1998, extended it over wide are...
2. Wireless IN Services
The IN protocols and concepts can be used to implement enhanced wireless services rapidly and to have these services available across serving areas in an untethered wireless network. Some of these services are listed below: Voice-Based User Identification. This service employs a form of automatic speech recognition to validate the identity of the speaker. Access to services can then be restricted to the user whose voice (phrase) has been used to train the recognition device. Voice-Based Featur...
3. Wireless LAN and Personal Area Network
The Wireless Internet is not just wireless communications across town or the country. It is also local—sometimes in a home or office building. Wireless LANs are just becoming popular with economically priced wireless Ethernet equipment. Standards such as IEEE 802.11, HiperLAN2, and Home RF are leading the way to untethered communications in-building or outside over small areas. Another important development is the Personal Area Network, also known as Bluetooth. Let’s take a look at each of th...
4. The Domain Concept
The solution to all of these problems is the network domain. In a domain, you only have a single name and password, which gets you into every shared PC and printer on the network. Everyone's account information resides on a central computer called a domain controllera computer so important, it's usually locked away in a closet or a data-center room. A domain controller keeps track of who is allowed to log on, who is logged on, and what each person is allowed to do on the network. When you log onto the domain with your PC,...
5. Duplexing Techniques in Wireless communication systems
Wireless communication systems have evolved through several stages of multiple-access control. The foremost controllable resource has always been the frequency spectrum. Other resources such as time, code, and space were initially manipulated in a very precarious and, therefore, ineffective manner. The early systems operated in the simplex mode in the forward link. Halfduplex systems soon appeared, in which forward link and reverse link shared the same channel. Access control was performed on a push-to-talk basis wit...
6. Wireless Networks (WiFi or 802.11)
Millions of people, have embraced the flexibility of a networking system that involves no wires at alla cordless networking technology called WiFi or 802.11 ("eight-oh-two dot eleven"). (Your Macintosh friends probably call the same thing AirPort, because that's what Apple calls it.) To get onto a wireless network, your PC needs a WiFi transmitter. Almost every laptop sold today has WiFi built in. You can also add it to a desktop in the form of a wireless card or USB adapter; either way, you gain a little antenna. Once...
7. VPN and Tunneling Protocols
Let us discuss the most common and widely used real-world VPN protocols. The growing number of users, the ease of accessibility, and the reduced cost of the Internet connection have introduced a greater need for cost-effective and secure communications without purchase of leased lines. Many companies participated in the development that resulted in the creation of different VPN standards and protocols. We discuss the most common ones here. IPSec IPSec is the most widely acknowledged, supported, and standardize...