The Presentation Tier

Mobile clients and web browsers support rich functionality using JavaScript and client-side technologies that interact with server APIs and endpoints. Processing increasingly occurs on the client system, and HTTP is used to transmit data via standardized formats (e.g., HTML, XML, and JSON).

Here are two protocols used within the presentation tier:

• TLS, which is used to provide transport layer security via HTTPS

• HTTP, including features that support streaming and state tracking

Figure 12-4 demonstrates a native Apple iOS application using TLS to securely interact with a web server and backend application logic. In this example, JSON data is transferred between peers over HTTP.

Figure 12-4. Protocols and data formats used by an iOS application

TLS

Described in Chapter 11, TLS provides the following benefits:

• Authentication through asymmetric cryptography and use of certificates

• Confidentiality through symmetric cryptography

• Integrity through HMAC or use of an authenticated cipher

Security is dependent on client and server configuration (i.e., underlying mathematics is sound, but implementation might be flawed). This was the case when a Apple OS X and iOS defect was identified that permitted MITM attacks to be undertaken.²

HTTP

Servers send data to clients including web browsers, mobile applications, and third parties via HTTP. The protocol is increasingly presented through a secure connection (HTTPS) to mitigate network sniffing risks.

An example HTTP request from a web browser is formatted as follows:

GET / HTTP/1.1
Host: example.org
Proxy-Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/48.0.2564.97 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

The client first provides an HTTP method, target resource, and protocol version. Subsequent lines include HTTP headers and client-supplied data. Methods use differing header and data formats—for example, a GET request is presented in a different format to a POST. Upon receiving a request, the server returns a status code, along with HTTP headers and data to be parsed by the client, for example:

HTTP/1.1 200 OK
Cache-Control: max-age=604800
Content-Type: text/html
Date: Mon, 01 Feb 2016 02:40:08 GMT
Etag: "359670651+gzip"
Expires: Mon, 08 Feb 2016 02:40:08 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (rhv/818F)
Vary: Accept-Encoding
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270

HTTP extensions and features form the building blocks of a web application. In the subsequent sections, I describe the following client and server HTTP features:

• Client request methods

  • HTTP methods

  • WebDAV extensions

  • Proprietary Microsoft extensions

  • Common request method headers

• Server status codes

• Additional server features

  • Support for persistent connections and caching

  • HTTP authentication mechanisms

  • Setting cookies

GET

POST

HEAD

OPTIONS

PUT

DELETE

TRACE

CONNECT

SEARCH

PROPFIND

PROPPATCH

MKCOL

COPY

MOVE

LOCK

UNLOCK

BITS_POST

CCM_POST

RPC_CONNECT

RPC_IN_DATA

RPC_OUT_DATA

HTTP authentication mechanisms

Tracking state is critical to many applications (e.g., knowing the difference between an unauthenticated user and one that is logged-in, or a customer who has paid for goods and one who hasn’t), but HTTP is a stateless protocol. As such, applications track state through the following:

• Setting cookies

• Placing tokens within HTML that are presented when actions are performed

• Processing the HTTP referrer header (showing the last page the user visited)

In Chapter 7, I described Kerberos authentication, whereby a ticket is provided to a user upon successful authentication. This ticket has a given validity period and is subsequently presented with each request. Web applications behave in a similar fashion—authenticated users are provided with a session token (set as a cookie), which is presented with each HTTP request.

Web servers including Microsoft IIS often support HTTP authentication regardless of the application running atop them. An adversary can use the Authorization request header to uploaded malicious content via supported methods (e.g., WebDAV or HTTP PUT functionality). Figure 12-5 summarizes the scenario.

Figure 12-5. Server versus application authentication

Authentication mechanisms supported by most web servers are Basic and Digest.⁷ The Basic mechanism is weak: user credentials are base64-encoded and sent in plaintext, which are easily compromised via network sniffing. The Digest mechanism was proposed to overcome this, utilizing MD5 and a shared secret to avoid sending plaintext credentials; however, it is susceptible to a replay attack.

Microsoft web servers support additional authentication types:

• NTLM⁸

• Negotiate (Simple and Protected Negotiate [SPNEGO])⁹

The NTLM mechanism uses a base64-encoded challenge-response to authenticate users. Negotiate can proxy either NTLM or Kerberos credentials between the client and Security Support Provider (SSP).

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=8C65C3AB20B8BBD157866668B67983B1; Path=""; HttpOnly
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 7
Date: Sun, 31 Jan 2016 15:38:47 GMT

GET / HTTP/1.1
Host: example.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: JSESSIONID=8C65C3AB20B8BBD157866668B67983B1

CDNs

CDNs are used to reduce latency within web applications by serving static assets (e.g., images, downloadable files, and streamed content) from systems that are “closer” to the client.

Operators maintain points of presence (POPs) around the globe. When a user makes a request to a CDN hostname, DNS and BGP are used to route the request to a server IP, based on location, availability, cost, and other metrics.

Problems arise, however, when CDNs are used to serve sensitive or private content, such as photographs of Facebook and Instagram users. If an attacker knows a valid URL to an image, he can present it without authentication to the CDN and obtain the material. An unpredictable identifier like the one that follows is the only thing protecting content from prying eyes:

https://scontent.xx.fbcdn.net/hphotos-xfl1/t31.0-8/12605432_10153295691921611_6636405252616106021_o.jpg

If the identifier used is predictable, attackers can obtain content inexpensively. A sufficiently random value should be used to protect sensitive data presented without authentication through a CDN.

Load Balancers

Load balancing systems are used to distribute inbound sessions across many application servers in physical, virtual, and cloud environments, as previously demonstrated by Figure 12-2.

Product vendors, including F5 Networks, produce bare-metal and virtual systems, and cloud providers including Amazon, Microsoft, and Google, provide load balancing within their Infrastructure as a Service (IaaS) platforms. As demonstrated, TLS is usually terminated at the load balancer, and plaintext HTTP used internally within an environment.

Presentation-Tier Data Formats

The HTTP Content-Type header is used to describe the format of data being transferred. In particular, a type, subtype, and optional parameters (e.g., language or character set) are defined. Common media types include markup and object notation languages (HTML, XML, and JSON), image formats (JPEG, GIF, and PNG), and JavaScript. IANA maintains a list of registered media types, which include the following:¹⁰

application/javascript
application/json
application/xml
image/gif
image/jpeg
image/png
text/html

The Content-Encoding header is often used to describe compression of data. Clients use encoding and media type headers to process data (e.g., executing JavaScript, or decompressing and rendering a web page and its images). Type confusion flaws can be exploited to perform persistent XSS, as demonstrated by Jack Whitton against Facebook, by which malicious JavaScript was placed into a PNG image and retrieved as HTML.¹¹

The Application Tier

Application servers support the execution of code written in languages including Microsoft ASP.NET, Java, Python, and Ruby. Connectors and adaptors are used to broker communication between clients and applications (e.g., the mod_jk connector used within Apache HTTP Server, as demonstrated by Figure 12-6).

Protocols used by Java application server components include JMX, RMI, and AJP. Microsoft applications tend to use RPC, HTTP, and COM mechanisms for communication. External dependencies might also include LDAP to support external authentication providers (e.g., Microsoft Active Directory).

Figure 12-6. The Apache mod_jk connector in-use

Application-Tier Data Formats

Media types used within the application tier are similar to those used in the presentation tier, including JSON and XML. SAML and other formats support single sign-on and other features.

Application components often serialize material before transmission. Serialization (known as marshalling) is the process of translating data structures or object state into a format that can be stored and later reconstructed in the same or another environment (known as unmarshalling). Figure 12-7 demonstrates the process.

Web application frameworks including Rails¹² and Django¹³ have known serialization weaknesses, by which malicious content sent to the application server can lead to exploitation upon unmarshalling and processing (resulting in code execution, information leak, and other issues). Gabriel Lawrence and Chris Frohoff’s AppSecCali presentation details practical exploitation of these flaws.¹⁴

Figure 12-7. Marshalling and unmarshalling an object

The Data Tier

Data stores used within web applications include databases, key-value stores, and distributed file systems. Connectors are used to interface with data tier components in the same way as they are between presentation and application tiers, including the following:

• ODBC and JDBC drivers for MySQL, PostgreSQL, Microsoft SQL Server, etc.

• Proprietary protocols used by MongoDB, Memcached, Redis, and so on.

• REST APIs over HTTP (as used by Amazon S3, WebHDFS, and others)

Services might also run over UDP to reduce overhead and improve throughput (e.g., Memcached and NFS). Authentication mechanisms vary (e.g., Redis does not offer authentication by default and Apache Hadoop uses Kerberos), and data formats can range from human-readable documents to machine-readable XML, JSON, and binary material.