Application & Web Security
Application & Web Security
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.
http://www.pcwebopedia.com/index.html in the browser, this sends a request to the server whose domain name is pcwebopedia.com. 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.
ComputerSecuritychapter6
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
SSLAlert Protocol
HTTP
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
ComputerSecuritychapter6
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
5
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.
ComputerSecuritychapter6
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
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.
ComputerSecuritychapter6
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.
ComputerSecuritychapter6