You are on page 1of 9


Application & Web Security

6.1 Application Hardening
The Concept of Application Hardening Application Hardening is a security feature designed to prevent exploitation of various types of vulnerabilities in software applications. It is the process to address application security weaknesses by implementing the latest software patches, hotfixes and updates, using the latest and secured versions of protocols and following procedures and policies to reduce attacks and system down time. The critical applications that need hardening are Web servers, email servers, DNS servers, etc. Vulnerabilities are mostly introduced by programmers that fail to check properly the input data entering into the application. If an application contains vulnerability, it can be exploited by an attacker. In the worst case, the attacker can take over the control of the computer on which the vulnerable application is running. Application Hardening provides three types of defense mechanisms explained below. The three defenses 1st Defense: Process spawning control One of the methods used by hackers or worms to break into the system is to trick the vulnerable application into spawning executable files of their choice on the system. The Process spawning control defense uses the fact that in most cases, the application does not need the ability to launch other executables for its proper function. By taking away the process spawning ability from the application, hackers will not be able to perform process spawning attack. 2nd Defense: Executable files protection Another method used to break into the system is to trick the vulnerable application into modifying or creating executable files of their choice on the system (to copy the worm's main code). Then the worm gets eventually executed and activated. The Executable files protection defense is based on the fact that in most cases, the application does not need to create or modify executable files for its proper function. By disallowing the application to modify executable files, hackers will not be able to perform attacks tampering with executable files on the system. 3rd Defense: System tampering protection Yet another method used to break into the system is to trick the vulnerable application into modifying special sensitive areas of the operating system and taking advantage of those modifications. Those sensitive areas for example include Windows Registry keys
ComputerSecuritychapter6 1

used to control launching of applications upon system startup, the system.ini and win.ini files etc. The System tampering protection defense is based on the fact that in almost all cases normal applications do not need to perform such operations for their proper function. By not allowing applications to modify special areas of the OS, hackers will not be able to perform attacks tampering with the sensitive special areas of the system. In the Application Hardening rule, all protections of this kind are grouped under a single option. Exclusions Some applications may have legitimate needs to perform actions that are normally disallowed by the enabled defenses. For example, an FTP service process may need the ability to create and modify executable files in its upload directory. For these situations, the Application Hardening allows definition of per-process exceptions for Process spawning control and Executable files protection defenses. The exception can be set specifically for the exact action of the application so that the effectiveness of the defense is not compromised. Logging is important Actions captured by Application Hardening rule can be logged into a log file. It is recommended that the logging is enabled for all created rules. If a hacking attempt is detected, the log file contains valued information about the event. Setting up hardening rules The key approach when setting up application hardening rules is:

Identify applications that are potentially at risk because they process data from insecure sources (web servers, mail servers...). The Network Status page can be of great help in identifying those processes. Create hardening rules for the respective application processes and activate the defense mechanisms. Define exceptions, if necessary. If there is any uncertainty about what defenses should be enabled for individual processes or what exceptions they needs, it is possible to enable only logging (without activated defenses) to learn the legitimate needs of the process and set the defenses based on the log accordingly.

6.1.1 Web server

A web server is a computer program that delivers (serves) content, such as web pages, using the Hypertext Transfer Protocol (HTTP), over the World Wide Web. A computer that delivers (serves up) web pages are called web server. Every Web server has an IP address and possibly a domain name. For example, the URL
ComputerSecuritychapter6 2 in the browser, this sends a request to the server whose domain name is The server then fetches the page named index.html and sends it to the browser.
Any computer can be turned into a Web server by installing server software and connecting the machine to the Internet. There are many Web server software applications, including public domain software from NCSA and Apache, and commercial packages from Microsoft, Netscape and others.

6.2.2 Active directory

An active directory is a directory structure used on Microsoft Windows based computers and servers to store information and data about networks and domains. It is primarily used for online information and was originally created in 1996. It was first used with Windows 2000. An active directory (sometimes referred to as an AD) does a variety of functions including the ability to provide information on objects, helps organize these objects for easy retrieval and access, allows access by end users and administrators and allows the administrator to set security up for the directory. An active directory can be defined as a hierarchical structure and this structure is usually broken up into three main categories, the resources which might include hardware such as printers, services for end users such as web email servers and objects which are the main functions of the domain and network.


6.2 Web security threats

Secure Sockets Layer (S S SSL)

The Secur Sockets Layer (SSL is an in re L) nternet pro otocol for se ecure exch hange of information between a Web browser and a Web server. It provides two basic security services: d c authentica ation and confidentia . SSL uses a prog c ality u gram layer located bet tween the Internet's Hypertext Transfer Protocol (H t HTTP) and Transport Control Protocol ( d l (TCP) laye ers. Three higher lay protoco are def yer ols fined as pa of SSL the Han art L: ndshake Pr rotocol, th Change he Cipher Sp Protoco and the Alert Proto pec ol A ocol. These SSSL spe e ecific proto ocols are us in the sed manageme of SSL exchanges SSL is in ent s. ncluded as part of bo the Mic s oth crosoft and Netscape d browsers and most Web server products. a W

What Hap ppens When a Web Br n rowser Con nnects to a Secure We Site? eb A browser attempts to connect to a Web site secured with SSL r t s d L.

Two impo ortant SSL concepts are the SSL sessio and the SSL con L S on nnection, w which are e defined in the specifi ication as follows: f
ComputerSe ecuritychapte er6 4

Connection: A connection is a transport that provides a suitable type of service. Every connection is associated with one session. Session: An SSL session is an association between a client and a server. Sessions are created by the Handshake Protocol. Sessions define a set of cryptographic security parameters, which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.

Between any pair of parties there may be multiple secure connections. SSL Protocol Stack

SSLHandshake SSLChangeCipher SpecProtocol Protocol

SSLAlert Protocol


SSLRecordProtocol TCP IP

SSL has three sub-protocols, namely the Handshake Protocol, the Record Protocol and the Alert Protocol. These three protocols constitute the overall working of SSL. Handshake Protocol : This protocol allows the server and client to authenticate each other and to negotiate an encryption and MAC algorithm and cryptographic keys to be used to protect data sent in an SSL record. The Handshake Protocol is used before any application data is transmitted. The Handshake Protocol consists of a series of messages exchanged by client and server.
Type Length Content

1 byte

3 byte

1 or more bytes

SSL Handshake Protocol Message Types Message Type hello_request client_hello server_hello certificate server_key_exchange certificate_request

Parameters null version, random, session id, cipher suite, compression method version, random, session id, cipher suite, compression method chain of X.506v3 certificate parameter, signature type, authorities

server_done certificate_verify client_key_exchange finished

null signature parameters, signature hash value

Each message has three fields: Type (1 byte): Indicates one of 10 messages. Length (3 bytes): The length of the message in bytes. Content ( 0 bytes): The parameters associated with this message. Exchange needed to establish a logical connection between client and server. The exchange can be having four phases. 1. Establish Security Capabilities: This phase is used to initiate a logical connection and to establish the security capabilities that will be associated with it. It includes protocol version, session id, cipher suit, compression method and initial random numbers. 2. Server Authentication and Key Exchange: The server begins this phase by sending its certificate, if it needs to be authenticated; the message contains one or a chain of X.509 certificates. 3. Client Authentication and Key Exchange: Upon receipt of the server_done message, the client should verify that the server provided a valid certificate if required and check that the server_hello parameters are acceptable. If all is satisfactory, the client sends one or more messages back to the server. 4. Finish: This phase completes the setting up of a secure connection. The client sends a change_cipher_spec message and copies the pending CipherSpec into the current CipherSpec. The client then immediately sends the finish message under the new algorithms, keys and secrets. The finished message verifies that the key exchange and authentication process were successful.


SSL Recor Protocol: rd After succ cessful han ndshake is completed between the clien and serv s n nt ver, the SS record SL protocol comes in to picture. That is, after the client and the serv c t d ver have o optionally authentica ated each other and have decid what a o ded algorithms to use for secure information r exchange, we enter into the SS record protocol. SL This proto ocol provide two serv es vices to an SSL conne ection:

Con nfidentiality The han ty: ndshake pr rotocol defi ines a shar secret key that is used for red
conv ventional encryption of SSL pay e yload. Mes ssage Integ grity: The Handshak protocol also defin a share secret k that is ke nes ed key used to form a message authentica d a ation code ( (MAC)
Applic cationdata Fragm mentation

Comp pression

AdditionofMA A AC

Encryption E Appendhead A der

ComputerSe ecuritychapte er6

The SSL record protocol takes an application message as input. First, it fragments it into smaller blocks, optionally compresses each block, adds MAC (Message Authentication Code), encrypts it, adds a header and gives it to the transport layer, where the TCP protocol processes it like any other TCP block. At the receivers end, the header of each block is removed; the block is then decrypted, verified, decompressed and reassembled into application messages. Alert Protocol When either the client or the server detects an error, the detecting party sends an alert message to the other party. If the error is fatal, both the parties immediately close the SSL connection. Both the parties also destroy the session identifiers, secrets and keys associated with the connection before it is terminated. Other errors, which are not so severe, do not result in the termination of the connection. Instead, the parties handle the error and continue. Each alert message consists of two bytes. The first byte signifies the type of error. If it is warning, this byte contains 1. If the error is fatal, this byte contains 2. The second byte specifies the actual error.
Severity Cause

Byte1 Byte2 Change Cipher Spec Protocol This protocol consists of single message, which consists of a single byte with the value 1. The sole purpose of this message is cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.


Code Injection
Code Injection is a term used when code is injected straight into a program/script from an outside source for execution at some point in time. Code Injection is the general name for a lot of types of attacks which depend on inserting code, which is interpreted by the application. Such an attack may be performed by adding strings of characters into a cookie or argument values in the URI. This attack makes use of lack of accurate input/output data validation, for example:

class of allowed characters (standard regular expressions classes or custom) data format amount of expected data for numerical input, its values

Code Injection and Command Injection are measures used to achieve similar goals. The concept of Code Injection is to add malicious code into an application, which then will be executed. Added code is a part of the application itself. It's not external code which is executed, like it would be in Command Injection.

Buffer Overflow
A buffer overflow occurs when a program or process tries to store more data in a buffer (temporary data storage area) than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra information - which has to go somewhere - can overflow into adjacent buffers, corrupting or overwriting the valid data held in them. Although it may occur accidentally through programming error, buffer overflow is an increasingly common type of security attack on data integrity. In buffer overflow attacks, the extra data may contain codes designed to trigger specific actions, in effect sending new instructions to the attacked computer that could, for example, damage the user's files, change data, or disclose confidential information. Buffer overflow attacks are said to have arisen because the C programming language supplied the framework, and poor programming practices supplied the vulnerability.