Distributed Systems

1. Distributed Systems (DS)

Definition: A collection of independent computers that appears to its users as a single coherent system.

They involve disparate independent entities interacting via common protocols towards a common goal.
Key Aspect 1: Components are autonomous.
Key Aspect 2: Users perceive it as a single system.
This is achieved through a middleware layer that sits between the applications and the local operating systems.

2. Why Build a Distributed System?

Definition: The primary reasons for creating a system that is distributed across multiple computers.

Inherently Distributed: The problem itself is physically distributed (e.g., sending a message from one phone to another).
Better Reliability: The failure of one node does not cause the entire system to fail.
Better Performance: Tasks can be parallelized and data can be fetched from geographically closer nodes.
Solve Large Problems: To tackle computationally intensive tasks (e.g., scientific computing) that require combined power.

3. Characteristics of Distributed Systems

Definition: The fundamental and desirable properties that define a distributed system.

Mandatory Characteristics:
Multiple Entities: Composed of multiple users or sub-systems.
Heterogeneity: Components differ in hardware, software, and policies (e.g., the Internet).
Concurrency: Components run simultaneously, requiring synchronization.
Resource Sharing: The ability to share hardware and software resources.
Desirable Characteristics:
Openness: The system can be extended using open standards.
Scalability: The system can grow in size. It is limited by centralized services, data, or algorithms.
Transparency: The system hides its complex, distributed nature from users. Key types include:
Access: Hides differences in data representation.
Location: Hides where a resource is located.
Replication: Hides that multiple copies of a resource exist.
Failure: Hides the failure and recovery of a resource.

4. Types of Distributed Systems

Definition: The main categories of distributed systems based on their primary function.

1. Distributed Computing Systems: Focused on providing computational power.

Cluster Computing: Homogeneous systems (similar hardware/OS) connected by a high-speed network for parallel processing.
Grid Computing: Highly heterogeneous systems from different organizations forming a Virtual Organization (VO) to collaborate.
2. Distributed Information Systems: Focused on storing, retrieving, and managing data.
Transaction Processing: Uses ACID properties (Atomicity, Consistency, Isolation, Durability).
Nested Transactions: Allows a transaction to be split into smaller sub-transactions run on different machines.
Middleware: Software that connects applications (e.g., CORBA, RPC, MOM).
3. Distributed Pervasive Systems: Next-generation systems embedded in the environment.
Sensor Networks: Networks of small, wireless, battery-powered sensor nodes used for data collection.

5. Distributed Architectures
Definition: The high-level structural designs used to organize components in a distributed system.

Client-Server: Classic model where clients request services from centralized servers. Challenges include scalability.
Multi-Node: The server's role is distributed across multiple processing nodes for performance and fault tolerance.
Peer-to-Peer (P2P): No central server; all nodes are equal peers (e.g., file-sharing networks). Offers scalability but has security challenges.
Service-Oriented Architecture (SOA): Systems are built from loosely-coupled, reusable services.
Three fundamental roles • Service provider• Service requestor• Service registry
Web Services: A common implementation of SOA using web standards (XML, HTTP). They are platform-independent and firewall-friendly.

6. Challenges in Designing Distributed Systems

Definition: The fundamental problems that make designing reliable and efficient distributed systems difficult.

Synchronization: The problem of coordinating actions across multiple independent nodes without a global clock or shared memory. Includes:
Clock synchronization, leader election, and mutual exclusion.
Fault Tolerance: The ability of a system to continue operating correctly in the event of failures.
Failures can occur in processing sites or the communication network, leading to issues like network partitions and outdated information.
Security: The complexity of securing multiple points of vulnerability (nodes, network, clients) in a heterogeneous environment.

7. Distributed Systems Security

Definition: The practice of protecting a distributed system from unauthorized access, use, or destruction.

It is critical and challenging, involving security at every layer of an enterprise's IT infrastructure.

8. Common Security Issues

Definition: The key security problems that must be addressed in a distributed system.

Authentication: Verifying the identity of a user or system.

Authorization: Determining what an authenticated user is allowed to do (e.g., DAC, RBAC, MAC).
Data Integrity: Ensuring data has not been altered illegally.
Confidentiality: Ensuring data is only readable by authorized parties.
Availability: Ensuring systems and data are accessible when needed (threatened by Denial-of-Service attacks).
Trust: The assumption that another entity will behave as expected.
Privacy: Controlling what information is revealed to others.

9. Common Security Techniques

Definition: The standard methods and technologies used to implement security.

Encryption: Scrambling data to protect it.

Symmetric: Same key to encrypt and decrypt.
Asymmetric: Uses a public/private key pair.
Digital Signatures & MACs: Techniques to verify data integrity and authenticity.
Authentication Mechanisms: Methods to verify identity (Passwords, Certificates, Biometrics, Smart Cards).
Public Key Infrastructure (PKI): A framework for managing digital certificates and public keys, involving a Certificate Authority (CA).
Models of Trust: Frameworks for establishing trust (Implicit, Explicit, Intermediary).
Firewalls: Systems that control network traffic between secure and less secure areas.

1. Host-Level Threats and Vulnerabilities: Background

Definition: Security weaknesses and potential dangers that originate from or target individual computers (hosts) within a distributed system.
 Vulnerability: A design or operational weakness in software that can be exploited by an attacker to compromise the system.
Threat: The potential for an attacker to cause damage by exploiting a vulnerability.
Threats arise from two types of code on a host:
Transient Code: Mobile code (binaries, scripts) downloaded and executed from a remote source.
ex:-Malware,EavesDropping,Job faults,Resource starvation
Resident Code: Trusted software installed on the host.
ex:-Overflow,privilege escalation,injection attack

2. Transient Code Vulnerabilities

Definition: Weaknesses exploited by mobile code that is downloaded and executed on a host, often unintentionally by the user.

This includes code executed by web browsers (JavaScript, Java Applets, ActiveX) or email clients.
A user may download and run code with malicious intent, compromising host security.
Common attack vectors include Trojan horses, spyware, and eavesdropping through internet content.
The need for rich web content has forced applications to allow scripts, which attackers can use to take control of a host or damage its content.

3. Resident Code Vulnerabilities

Definition: Weaknesses present in trusted software that is installed on the host with the user's knowledge.

Even trusted software can contain vulnerabilities.

Historically, most attacks have exploited vulnerabilities in resident code.

4. Malware (Malicious Software)

Definition: Software specifically designed to disrupt, damage, or gain unauthorized access to a computer system.

4.1 Trojan Horse

Definition: Malware disguised as legitimate software, tricking users into installing it.

Victims are unaware their system is compromised.

Cannot operate autonomously; requires user action to execute.
Spreads via email attachments, shared media (USB drives), online chats, or downloaded files.
Its intent is to create backdoors for remote access, disable security software (antivirus/firewall), or enlist the host in attacks (e.g., DDoS).
Attackers use social engineering tactics like attractive screen savers or games to lure victims. Hidden file extensions in some OSs can also be exploited.

4.2 Spyware

Definition: Software that secretly records user activity to collect sensitive information for commercial gain or malicious purposes.

Can capture credit card details, monitor browsing habits, and collect personal data.
Examples: SearchSeekFind, ShopAtHomeSelect, Surfairy.

4.3 Worms/Viruses

Definition: Self-replicating malicious programs that infect files and spread across systems.

Viruses: Attach themselves to clean files and spread, infecting executables and macros. They are malicious and require user action to spread.
Worms: A more advanced form of virus that spreads autonomously over networks, making it easier to infect multiple hosts.

5. Eavesdropping

Definition: The unauthorized interception of confidential data, access to privileged binaries, or tampering with computational results on a host.

In collaborative systems like Grids, users share resources. Some may have malicious intent and misuse information passing through their system.
This threat is categorized into three classes:
5.1 Unauthorized Access to Confidential Data – by Users

In distributed computing, a scheduler sends jobs (code + data) to a node based on its load.
Job files are often stored in a shared folder (e.g., /tmp) accessible to all users on that host.
A malicious user can quickly copy this sensitive data, analyze it offline, and misuse it (e.g., brute-forcing encrypted data).
If the data contains credentials (user ID/password), the attacker can impersonate the user, leading to severe, hard-to-trace security issues.

5.2 Unauthorized Access to Protected Binaries – by Users

Attackers copy privileged binaries for three reasons:

1. The binary may contain a proprietary algorithm or trade secret.
2. It may have hard coded credentials (e.g., a database password), giving the attacker elevated privileges.
3. Merely copying such a binary and Simply re-executing the binary can cause unintended changes to external systems, causing disruption.

5.3 Unauthorized Tampering with Computational Results

A malicious user alters the results of a computation to corrupt or mislead the system.
jobs that post their computation results directly to a centralized system without storing them in intermediate files are difficult to tamper with.
Jobs whose source code is available, which runs for several minutes to hours and uses intermediate files to store results, are often easy targets for such attacks.

5.4 Unauthorized Access to Private Data – by Jobs

Grid jobs run with minimal privileges but can still access poorly secured sensitive data on a host.
They can read and expose private information like password files or system configurations.
If multiple jobs run concurrently on a host, a malicious job can eavesdrop on the data of an innocent job running beside it. The host facilitates this attack
unknowingly.

6. Job Faults

Definition: Failures or errors caused by user-written applications running on a grid, either unintentionally or maliciously.

These applications are often untested and uncertified.

Unintentional Faults: The faults are generated unintentionally Can bring down the entire host and all applications running on it.
Intentional Faults (Malicious): A job can be scripted to inject a fault that corrupts a host or forces a reboot/shutdown.
Host applications can also be harmful and inject faults that cause grid applications to fail.

7. Resource Starvation

Definition: A situation where a job consumes so many resources (CPU, memory) that it starves other jobs or host applications, degrading performance.

Job Starvation: A long-running job blocks smaller jobs in a queue.

Grid applications are often resource-intensive (CPU-bound or memory-bound) and lack synchronization points.
Example: A computational fluid dynamics application consumes most physical memory and all available CPU slots for a long time.
The challenge is to use a host's spare capacity without affecting the applications/jobs already running on these hosts.
Adding such hosts to a grid can affect the response time of native applications and jeopardize the interactive nature of desktop nodes.

8. Overflow (Buffer Overflow)

Definition: A software vulnerability where a program writes data beyond the allocated memory bounds of a buffer, leading to crashes or allowing arbitrary code
execution.
Buffers are used by software programs to store data. They typically have an upper and a lower bound.
 Caused by programming errors (allocating too little space or storing too much data).
Occurs in two ways-1) Allocating too little space 2)Storing too much data
A very common attack mechanism. Famous examples: Morris Worm (1988), Code Red (2001), Slammer (2003), Sasser (2004).

8.1 Logical Memory View of a Process

A process's memory is divided into segments:

Text Segment: Contains executable code (read-only).

Initialized Data Segment: Contains global/static variables initialized to non-zero.
Uninitialized Data Segment (BSS): Contains global/static variables initialized to zero.
Heap: Used for dynamic memory allocation.
Stack: Stores information about active function calls (local variables, return addresses).
Environment Variables.

8.2 Stack-Based Buffer Overflow

Definition: An overflow that occurs in the stack memory region, which can overwrite critical control data like function return addresses.

Type 1: Overwriting adjacent variables, causing erratic program behavior or crashes.

Type 2: Modifies a function pointer or return address to execute arbitrarily different [Link] a function's return address. When the function finishes,
control is transferred to a malicious location chosen by the attacker, allowing them to execute arbitrary code.

8.3 Heap-Based Buffer Overflow

Definition: An overflow that occurs in the heap memory region.

The data contained in the heap are predominantly program data allocated dynamically during the lifetime of the program’s execution and do not contain function
pointers/return location

The heap contains program data, not control data like return addresses. Therefore, exploiting it is generally more complex than stack overflows.

9. Privilege Escalation

Definition: An attack where an unauthorized user elevates their access level on a host to perform actions they are not allowed to do.

The goal is often to gain root or admin privileges to take full control of the host.
This can lead to severe impacts, such as the host being used in DDoS attacks.

9.1 Types of Privilege Escalation

Horizontal: A malicious user tries to assume the identity of a peer in the system.
Vertical: A user assumes the identity of a system administrator (e.g., root in Linux, SYSTEM in Windows), gaining full control.
This allows the malicious user to access all information stored on the host and perform tasks that are otherwise not permissible.
Buffer overflows are the most common way to achieve privilege escalation, as they can be exploited to execute code with higher privileges.

10. Injection Attacks

Definition: Injection attacks are attempts by malicious hackers to exploit an application vulnerability that does not handle user inputs securely

10.1 Shell/PHP/ASP Injection

Definition: A code injection vulnerability in applications built on server-side scripting engines (PHP, ASP), where malicious code is injected through user inputs.

10.2 SQL Injection (SQLi)

Definition: An attack where a malicious user injects harmful SQL query strings into an application's input field to manipulate the database, retrieve unauthorized data, or
execute commands.

10.2.1 Types of SQL Injection (Based on Technique)

In-Band SQLi: Uses the same channel to attack and gather results.
Error-based: Forces the database to generate error messages that reveal sensitive data.
Union-based: Uses the UNION SQL operator to combine results from the original query with results from a malicious query, allowing data theft.
Example:

SELECT ItemName, ItemDescription

FROM Items

WHERE ItemID = '999' UNION

SELECT Username, Password FROM Users;

Blind SQLi: No error messages are received from the database.

Boolean-based: Sends a SQL query that forces the application to return a different result depending on whether the query is TRUE or FALSE.
Time-based: Sends a SQL query that forces the database to wait for a specified amount of time before responding. The response time indicates whether the
query is TRUE or FALSE.
Out-of-Band SQLi: Uses a different channel (e.g., DNS or HTTP requests) to retrieve the results of the attack.

10.2.2 Types of SQL Injection (Based on Injection Vector)

User input: Injecting through web forms.

Cookies: "Poisoning" cookies that the web application uses in database queries.
HTTP Headers: Injecting SQL through server variables like headers.
Second-order Injection: Injecting malicious data that is initially benign but becomes malicious when used in a different context later.

10.2.3 SQL Injection Code Example

Vulnerable Code:
sql = "SELECT id FROM users WHERE username='" + user + "' AND password='" + pass + "'"

Malicious Input: password' OR 5=5

Resulting Query:
SELECT id FROM users WHERE username='user' AND password='pass' OR 5=5'

The condition OR 5=5 is always true, allowing login without a valid password.

1. Infrastructure Level Threats and Vulnerabilities: Introduction

Definition: Security weaknesses and potential dangers that target the underlying components that support IT systems, such as networks, grid/cluster computing platforms,
and storage systems.

Infrastructure: The fundamental elements that enable IT systems to function, including networking, middleware, and storage.
Securing this infrastructure is critical for national security and economic stability, as our way of life depends on the secure operation of cyberspace.
The main categories of infrastructure threats are:
Network Level Threats: DoS, DNS attacks, routing attacks, wireless threats.
Grid Computing Threats: Architecture, infrastructure, and management issues,Trust issues
Storage Threats: SAN and Distributed File System vulnerabilities.

2. Network Level Threats and Vulnerabilities

Definition: Attacks and weaknesses that target the networking infrastructure, including routers, servers, protocols, and wireless devices, to disrupt communication, steal
data, or gain unauthorized access.

2.1 Denial-of-Service (DoS) Attack

Definition: An attack with the objective of making a network service unavailable to its intended users.

Packets are routed correctly but the destination and the network become the targets of the attackers.
They are easy to generate but difficult to detect.
In a typical DoS attack, the attacker node spoofs its IP address and uses multiple intermediate nodes to overwhelm other nodes with traffic.
Types:
Ordinary DoS: A single attacker uses a tool to send disabling packets to the target, often with a spoofed source IP.
Distributed DoS (DDoS): A single attacker uses multiple compromised machines ("agents" or "zombies") to amplify the attack effect.

2.1.1 SYN Flood Attack

Definition: A popular DDoS attack that exploits the TCP three-way handshake to exhaust server resources.

The attacker sends a flood of TCP SYN (synchronize) packets with spoofed IP addresses.
The server responds with SYN-ACK and waits for the final ACK, leaving "half-open connections" that consume resources in a backlog queue.
This ties up the server's processor and memory, preventing it from responding to legitimate requests.

2.1.2 PUSH+ACK Attacks

Definition: A DDoS attack that exploits the TCP protocol's PUSH flag to overwhelm a receiver's buffer.

The TCP protocol buffers data to minimize processing overhead.

The PUSH flag tells the receiver to unload the buffer contents immediately.
An attacker can abuse this by sending many packets with the PUSH bit set, forcing the victim to process data constantly.

2.1.3 Smurf Attacks

Definition: A DDoS attack that uses network amplifiers (systems supporting broadcast) to flood a victim with traffic.

The attacker sends ICMP ECHO REQUEST (ping) packets to a broadcast address, with the source IP spoofed to be the victim's IP.
The attacking packets are typically ICMP ECHO REQUESTs, which are packets (similar to a ‘ping’)that request the receiver to generate an ICMP ECHO REPLY
packet.
Every device on that network responds to the victim with an ICMP ECHO REPLY, amplifying the original attack traffic hundreds of times.

2.2 DNS Attack

Definition: An attack targeting the Domain Name System (DNS), which translates human-readable domain names (e.g., [Link]) into numerical IP addresses.

DNS is a critical, distributed component of the internet. Attacking it can have a massive impact.
Impact of Hacking DNS: Denial of Service, Masquerading (impersonation), Information Leakage, Domain Hijacking.

2.2.1 Types of DNS Hacking

Cache Poisoning: An attacker feeds bogus information to a DNS server, which caches it. This redirects users intending to visit a legitimate site to a malicious site
under the attacker's control.
Server Compromising: An attacker gains control of a DNS server itself, allowing them to modify any data it serves, leading to cache poisoning or DoS.
Spoofing: An attacker masquerades as a DNS server and provides false IP address information to clients.

2.3 Routing Attack

Definition: An attack on network routing protocols where routing update packets are maliciously modified, leading to incorrect routing tables.

Routing tables are used to route packets over any network, especially the Internet.
Routing protocols (Distance Vector, Link State, Path Vector) exchange information to build maps of the network.
Routing Table Poisoning: Maliciously modifying these updates to create incorrect routes., resulting in the creation of incorrect routing tables.

2.3.1 Impacts of Routing Table Poisoning

Suboptimal Routing: Packets take longer paths, violating Quality of Service (QoS) for real-time applications (e.g., VoIP, Grid computing).
Congestion: Traffic is artificially directed to specific parts of the network, causing bottlenecks.
Partition: The network is split into isolated segments that cannot communicate with each other.
Overwhelmed Host: Traffic is concentrated on a few servers, taking them down due to excessive load.
Looping: Packets are sent in circles, are eventually dropped, and reduce overall network throughput.
Access to Data: Attackers can snoop on packets by redirecting traffic through a node they control.

2.3.2 Routing Protocols & Attacks

Distance Vector (e.g., RIP): Nodes share a vector of shortest distances to [Link] node has the full topology information and each depends on its neighbors for
creating its routing tables. They don't know the full topology, making them vulnerable to false updates from malicious neighbors.
Link State (e.g., OSPF): Nodes share their connectivity with everyone. Each node then computes the full map. More robust but still vulnerable if a router is
compromised...EX:Open Shortest Path Forwarding (OSPF)
Path Vector (e.g., BGP): Each node sends the full shortest path information of all the nodes in the network to its neighbors.

2.3.3 Categories of Routing Attacks

Routing table poisoning can be broadly categorized into:

(i) link
(ii) router attacks

Link Attacks: Target the communication link between routers.

Interruption: If an attacker stops a routing update from propagating,the victim may still be able to obtain the information from other sources.
Modification/Fabrication: Altering or creating fake routing packets.
Replication: Replaying old, valid routing messages to cause confusion.
Router Attacks: The router itself is malicious or compromised.
Proactive: The malicious router can add a pretend link, delete an already existing link, or change the cost of a link proactively.
Inactive:The router ignores a change in the link state of its neighbors.

2.4 Wireless Security Vulnerabilities

Definition: Weaknesses in wireless networks (Wi-Fi, Bluetooth) that arise from their use of radio waves, making physical containment difficult and introducing new
attack vectors.

2.4.1 Wireless Security Standards Evolution

WEP (Wired Equivalent Privacy): The first standard (1999). Fatally flawed due to short, static encryption keys and a weak algorithm (RC4). Easily
cracked. Should not be used.
WPA (Wi-Fi Protected Access): An interim standard (2004) to fix WEP. Used TKIP for dynamic keys and added integrity protection. Still used RC4, vulnerable to
attacks.
WPA2: Ratified in 2004. Replaced RC4/TKIP with the stronger AES algorithm and CCMP for encryption and authentication. Became the long-standing standard,
though some vulnerabilities exist.
WPA3: The current standard (2018). Uses stronger 192/256-bit encryption, a more secure handshake (Simultaneous Authentication of Equals - SAE) resistant to
offline attacks, and provides forward secrecy.
2.4.2 Types of Wireless Attacks

Passive Attacks:
Traffic Analysis: Monitoring packet size and number to infer activity, locate access points, and identify protocols. Difficult to detect.
Eavesdropping: Intercepting data transmitted over the air.
Active Attacks:
Unauthorized Access: Gaining access to the network to use it or launch further attacks.
Man-in-the-Middle (MitM): Intercepting and potentially altering communication between two parties. e.g., ARP Poisoning.
Session Hijacking: The attacker takes an authorized and authenticated session away from its proper owner .To execute session hijacking successfully, the
attacker must accomplish two tasks.
1. The attacker must masquerade as the target of the wireless network
2. The attacker must stop the target from continuing the session.
Replay Attack: Capturing and retransmitting data packets at a later time to confuse the [Link] or timestamps are generally used to prevent this type
of attack from taking place.
Access Control Attacks:
War Driving: Searching for wireless networks from a moving vehicle using a smartphone or laptop to find vulnerable and capture sensitive information
Rogue Access Point: An unauthorized wireless Access point connected to organization’s network,leaving the network exposed to potential security threats
MAC Address Spoofing: Changing a device's MAC address to bypass MAC filtering.
Integrity Attacks: (Session Hijacking, Replay, Spoofing, 802.11 frame injection/deletion/replay).

1. Spoofing:The attacker changes the destination IP address of the packet to the IP address of a host they control.
2. The attacker can inject known traffic into the network in order to decrypt future packets in the wireless network. This type of attack can be useful in detecting the
session key of the communicating parties

Availability Attacks (DoS):

RF Jamming: Transmitting high-power noise on the same frequency to block communications.
Beacon Flood: Overwhelming the area with fake network advertisements.
Association Flood: Overwhelming an AP with fake connection requests.
De-authentication Flood: Sending spoofed messages to disconnect all clients from an AP.
Authentication Attacks:
Dictionary/Brute Force Attacks: Guessing the Wi-Fi password (PSK).
PSK Cracking: Process of attempting to recover the pre-shared key (PSK) used in Wi-Fi networks
Application Login Theft: Attackers steal a user's login credentials (like usernames and passwords) to gain unauthorized access to an application

2.5 Bluetooth Security

Definition: Security mechanisms and associated vulnerabilities for short-range wireless communication (Bluetooth).

Security Levels:
L1: No Security. No authentication or encryption.
L2: Unauthenticated Pairing. Encryption without user interaction ("Just Works").Devices require pairing, but the pairing process doesn't involve user
interaction
L3: Authenticated Pairing. Encryption with user interaction (e.g., entering a PIN), protects against Man-in-the-Middle (MITM) by user interaction
L4: LE Secure Connections. Uses stronger 128-bit encryption keys and numeric comparison.

2.5.1 Bluetooth Vulnerabilities & Threats

Bluetooth Vulnerability: Encryption key length negotiate

1. Attacker can interfere with the unencrypted process of establishing an encryption key between two Bluetooth BR/EDR (Classic) devices, forcing the key's length to
a very short, 1-byte [Link] allows the attacker to brute-force the key, enabling them to decrypt the data or hijack the devices.

Bluetooth Threats
 Bluesnarfing: Unauthorized access to information on a Bluetooth [Link] to improper device configuration.
Bluejacking: Sending unsolicited messages over Bluetooth to Bluetooth devices.
Bluebugging: Hacker can gain unauthorized access to e apps and control them as per their wish through bluebugging,can listen to calls, read messages, etc.

3. Grid Computing Threats and Vulnerabilities

Definition: Security challenges specific to grid computing systems, which connect distributed, often heterogeneous, computing resources to solve large-scale problems.

Concerns include lack of universal standards and the complexity of security across different administrative domains.
Grid security issues are grouped into three categories:1)Architecture-related issues,2)Infrastructure-related issues,3)Management-related issues

3.1 Architecture-Related Issues

Definition: Security problems related to the design and protocols of the grid system [Link] related to the information exchanged between different hosts or
between hosts and users.

Information Security:
Unauthorized Access: Requires strong, flexible authentication mechanisms at all entry points, supporting various methods across different sites.
Confidentiality: Ensuring data is secret both in transit (point-to-point) and at rest (store-and-forward). Requires defining and sharing security contexts.
Integrity: Ensuring messages are not tampered with in [Link] change made to the messages or documents can be identified by the receiver
Single Sign-On (SSO): A user should authenticate once to access multiple resources across different security domains within the grid.
Delegation Vulnerabilities: A service might need to act on a user's behalf (e.g., a job accessing a database). Delegated authority must be strictly scoped and time-
limited to prevent misuse.
Authorization: Determining what resources a user can access. Challenges include:
Scalability: Handling a large number of dynamic users.
Security: Risk of compromise at both user and system levels.
Revocation: Quickly removing a user's access if compromised.
Inter-operability: Making different authorization systems from different organizations work together.
Service Level Security: Securing the "service" concept in a grid.
A service has a provider, consumers, an infrastructure, and publishers.
Threats: QoS Violation (breaking SLAs), Unauthorized Access, DoS Attacks.

3.2 Infrastructure-Related Issues

Definition: Security problems related to the physical and software components that make up the grid (nodes and network).Host-level security issues: Data protection and
Job starvation

Includes all Host-Level threats (from the previous PDF) like data protection and job starvation.
Network Security: Critical due to the heterogeneity and high-speed needs of grid apps. Challenges include integrating with existing enterprise security like
firewalls.
Globus and Firewalls: Globus is open-source grid software. Its modules (GSI, GRAM, GridFTP, MDS) use specific ports, requiring careful firewall configuration
to allow grid traffic without creating vulnerabilities.

3.3 Management-Related Issues

Definition: Security challenges related to the ongoing operation and administration of the grid.

Credential Management (CM): Securely managing the many different credentials (passwords, certificates) needed for various systems in the grid.
Requirements: Secure initiation, storage, accessibility, renewal, translation between domains, delegation, control, and revocation.
Trust Management: A complex issue of establishing and managing trust relationships in the grid.
Lifecycle:
Creation: Deciding on a trust model (policy-based or reputation-based).
Negotiation: When a new node joins, policies are exchanged to establish trust (e.g., exchanging certificates).
Management: Computing trust values, distributing this information securely, storing it, and updating it based on events or time.
 Trust Management phase-1)Trust computation-trust value is computed based on trust function2)Trust distribution-secure distribution of trust to
other nodes(CIA to be maintained)3)Trust storage- Secure storage of trust info.(credential repositories can be used)4)Trust update- done based on
event by event basis or in timely manner

4. Storage Threats and Vulnerabilities

Definition: Attacks and weaknesses targeting data storage architectures, primarily Storage Area Networks (SANs) and Distributed File Systems (DFS).Storage Area
Networks (SANs) are network architecture entities that provide large amounts of storage access

4.1 Storage Area Network (SAN) Security

Definition: Protecting data within a high-speed network dedicated to providing block-level storage access to servers.

Fibre Channel (FC) Protocol: A high-speed (Gbps) technology commonly used in SANs to transfer data. It uses a layered model (FC-0 to FC-4) similar to TCP/IP.
FC Frame Structure: Frames have a header, optional header, payload (0-2112 bytes), and CRC. The header contains source/destination addresses and sequence
info.

4.1.1 Threats to SANs

Session Hijacking: Possible due to:

Clear Text Messaging: Performance constraints often mean data is not encrypted.
Lack of Authentication: The basic FC protocol does not authenticate devices.
Predictable Frame Sequence: Sequence IDs are sent in clear text and increment predictably.
Address Spoofing: Spoofing a 24-bit Fabric Address.
A malicious node can spoof a valid address during the Fabric Login (FLOGI) or Port Login (PLOGI) process to impersonate a legitimate device.
Zone Spoofing:
SAN switches use zoning (like VLANs) to restrict which devices can communicate, often based on World Wide Names (WWNs - like MAC addresses).
Switch zoning is a technique that allows specific nodes to access other nodes in the fabric using different zoning policies
An attacker can spoof a WWN to gain access to a zone they shouldn't be in.
LUN Masking Attacks:
LUN Masking presents only specific parts of storage (Logical Unit Numbers) to a specific server.
Logical unit number (LUN) masking is the process of hiding or revealing parts of the storage disk or LUN to the client node
If masking is done on the server's Host Bus Adapter (HBA) driver, an attacker with OS access can simply disable the masking, revealing all LUNs.
Switch Zoning:
Switch zoning allows specific nodes on a fabric to access to other nodes based on the hard/soft zoning policies
Hard Zoning: Enforcement-based; traffic is physically restricted between zones.
Soft Zoning: Information-based; devices see only permitted devices in name tables, but traffic isn't physically blocked (less secure).
Zoning is a segmentation tool, not a strong security tool. WWN-based zoning is vulnerable to WWN spoofing.
Zone Hopping: The act of bypassing zoning restrictions, often through WWN spoofing.

4.2 Distributed File System (DFS) Security

Definition: Securing file systems where data is stored across multiple networked computers.

Examples: NFS, CIFS, Network-Attached Storage (NAS).

Network-Attached Secure Disks (NASDs): Allow clients direct access to storage objects using cryptographic secrets for authentication and encryption.
Highly-Distributed Systems (e.g., OceanStore): Use a massive number of untrusted servers. Data is encrypted, replicated, and identified by Globally Unique
Identifiers (GUIDs). This makes data deletion/revocation hard but provides decentralization.

4.2.1 Threats to Distributed File Systems

Passive Attacks: Eavesdropping on unencrypted traffic, capturing authentication info.

Active Attacks: Trying to break protection mechanisms, inject malicious code, or steal/modify data.
 🗂 Main Headings Overview (Table of Contents)
1. Introduction – Application-Level Threats and Vulnerabilities
2. Application-Layer Vulnerabilities
Injection Vulnerabilities
SQL Injection
LDAP Injection
XPath Injection
Blind Injection
Cross-Site Scripting (XSS)
Non-persistent (Reflected) XSS
Persistent (Stored) XSS
Improper Session Management
Session ID Attacks (Interception, Prediction, Brute Force, Fixation)
Improper Error Handling
Improper Use of Cryptography
Insecure Configuration Issues
Denial of Service (DoS)
Canonical Representation Flaws

📘 Introduction – Application-Level Threats and Vulnerabilities

🔹 Overview
Modern attackers focus more on exploiting weaknesses in application design and code rather than network or host vulnerabilities.

🔹 Reasons for Increased Application-Level Attacks

1️⃣ Lack of security awareness among developers → buggy, insecure software.
2️⃣ Availability of public vulnerability data (e.g., OWASP, WASC).
3️⃣ Easily available attack tools that automate exploitation.
4️⃣ Less security focus during software development.
⚠️ Fact: Around 75% of malicious attacks originate from application-layer vulnerabilities, not network or OS-level flaws.

🔹 Key Sources for Threat Information

OWASP (Open Web Application Security Project)
WASC (Web Application Security Consortium)

🧩 Application Layer Vulnerabilities

1️⃣ Injection Vulnerabilities

🔹 Definition
Injection vulnerabilities occur when user input is not properly validated or sanitized, allowing attackers to inject malicious commands or queries.

🔹 Effects

Loss of confidentiality, integrity, or authentication.

Can lead to arbitrary command execution or even complete system compromise.

🔸 a) SQL Injection (SQLi)

🔹 Description

Occurs when unvalidated user input is concatenated into an SQL query, altering its logic.
Example Vulnerable Code:

SELECT * FROM Users WHERE UserName = '" + strUserName + "' AND Password = '" + strPassword + "'";

Malicious Input Example:

UserName = '' OR 1=1 --

Resulting Query:

SELECT * FROM Users WHERE UserName = '' OR 1=1 -- ' AND Password = '';

→ Always returns true → attacker logs in without credentials.

🔹 Prevention

Use parameterized queries / stored procedures.

Validate and sanitize all user inputs.
Deny unexpected inputs.

🔸 b) LDAP Injection

🔹 Description

LDAP (Lightweight Directory Access Protocol) stores sensitive organizational data (e.g., user credentials, printers, etc.) and store information in hierarchical(tree)
structure
When user inputs are used directly in LDAP queries without validation, attackers can inject LDAP statements.
An attacker can exploit this vulnerability by supplying carefully crafted LDAP statements as part of the input, changing the semantics of the LDAP statement.

🔹 Impact

Unauthorized access to sensitive directory data.

Bypassing authentication & access control.

🔹 Example

Attacker inputs crafted data that changes LDAP query semantics.

🔹 Prevention

Validate and escape special LDAP characters.

Use parameterized LDAP queries.

🔸 c) XPath Injection

🔹 Description
XPath is the language used to query XML documents.
If user inputs are directly inserted into XPath queries without validation, attackers can alter query [Link] attacker can inject XPath constructs as part of the user input,
changing the semantics of the originally intended XPath statement.
Example Query:

String xpathQuery = "//user[name/text()='" + [Link]("username") +"' and password/text()='" + [Link]("password") + "']";

Malicious Input:

lol' or 1=1 or 'a'='a

🔹 Impact

Unauthorized access to XML data.

Disclosure of confidential information.

🔹 Prevention

Validate and sanitize user inputs.

Use parameterized XPath queries.

🔸 d) Blind SQL Injection

🔹 Description

Used when attackers cannot see query outputs directly.

A blind SQLi attack is a technique wherein the attacker poses some queries to a database and derives the [Link] plans his next course of action depending on the
answers which were generated by the database.
Difficult SQLi attack since the attacker does not have any prior knowledge regarding the database

🔹 Types

1️⃣ Boolean-Based Blind SQLi – relies on conditional responses (true/false).

2️⃣ Time-Based Blind SQLi – measures response delays to infer query success.

🔹 Example

Attacker sends payloads that cause delays or changes in responses to determine database details.

⚠️ 2️⃣ Cross-Site Scripting (XSS)

🔹 Definition

Cross-site scripting (XSS) attacks are made possible by injection vulnerabilities in the application code.
XSS typically occurs in sites which allow user input, and echoes this back to the client without proper validation.
XSS allows attackers to inject malicious scripts (usually JavaScript) into web pages viewed by other users., which is subsequently echoed back to the client browser
Because the browser trusts scripts from the legitimate server, a malicious script runs with site privileges and can read/steal cookies,alter data, and silently modify
page content.

🔹 Cause

Occurs when applications echo user input back to the browser without proper validation.

🔹 Process
 1. Attacker injects malicious script into an input field.
2. Server sends it back to the client’s browser.
3. Browser executes it, trusting the server.

🔹 Impact

Theft of cookies, session tokens, or user data.

Manipulation of web content.
Redirection to malicious websites.

🔸 Example
An attacker posts:

<script>alert('XSS');</script>

on a public forum.
When another user views it, the script executes.

🔸 Types of XSS
1️⃣ Non-Persistent (Reflected) XSS

Occurs when input is immediately returned by the server (e.g., search bar).
Attacker sends a crafted URL containing a malicious script.

2️⃣ Persistent (Stored) XSS

Malicious script stored on server (e.g., in forum posts or DB) which stores it in a repository
Every user who accesses the page gets affected.

🔹 Prevention

Validate and encode user inputs/outputs.

Use Content Security Policy (CSP).
Avoid directly echoing untrusted data.

🔒 3️⃣ Improper Session Management

🔹 Overview

HTTP is stateless meaning every request from a browser is treated as independent, so web apps use sessions to maintain user state (via cookies, hidden fields, or URL
rewriting).
In all these techniques, a session identifier that identifies a user session on server will be exchanged in every subsequent request and response between client and
server.
Weak session management leads to broken authentication and session hijacking.
Different attacks are possible, depending on how the session management is designed and implemented.

🔸 Common Session Attacks

1️⃣ Session ID Interception

Occurs when session IDs are sent over insecure channels.

Attackers intercept traffic to capture session IDs.
 Stolen IDs are used to hijack the victim’s session.
Prevention: Use SSL/TLS (HTTPS) to encrypt communication.

2️⃣ Session Prediction

Attacker predicts valid session IDs due to weak generation.

Caused by predictable patterns (e.g., sequential or low-entropy IDs).
Consequence: attacker forges IDs and hijacks sessions.
Prevention: use cryptographically secure RNGs with strong entropy and random seeds.
Additional mitigations: sufficient ID length, rotate/regenerate IDs on login, avoid exposing IDs in URLs.

3️⃣ Brute-Force Analysis

Brute-force analysis of session IDs is where an attacker tries all possible combinations of session IDs in an exhaustive manner.
Use long random session tokens to prevent guessing.

4️⃣ Session Fixation

Attacker forces/fixes a session ID (of their choice) and tricks victim into using it.
Session fixation is possible when the session identifiers are either chosen by the user or set by the server.

After login, attacker reuses the same ID to hijack the session.

Example Scenario:online banking application that has a session management flaw

Attacker gets session ID before victim login.

Victim logs in using same session ID.
Attacker reuses it to access victim’s account.

🔹 Prevention

Regenerate session IDs after login.

Use HTTPS for session transmission.
Invalidate old sessions.

⚠️ 4️⃣ Improper Error Handling

🔹 Description

Improper error handling vulnerabilities in applications lead to disclosure of sensitive information like database details, platform version details, SQL statements, stack
traces and soon to attackers.
Attackers inject malformed inputs to specifically force applications to [Link] helps the attacker either in getting the sensitive useful information that is leaked
through error messages or,causing denial of service (DoS).

🔹 Example

Error message during login reveals:

Invalid usernameInvalid password

→ Helps attacker identify valid usernames.

Or a full stack trace showing DB table names.

🔹 Prevention
 Use generic error messages for users.
Log detailed errors securely on the server.
use Centralize exception handling to avoid leaks.

🔐 5️⃣ Improper Use of Cryptography

🔹 Key Points

cryptography is not the solution for every security problem.; it only provides solutions for specific problems like authentication, data secrecy, nonrepudiation
Its strength lies in the secrecy of keys, not in “hidden algorithms”.
Cryptographic operations require random numbers for generating keys.
characteristics for crypto random numbers are that there should be even distribution, the random numbers should be highly unpredictable

🔹 Common Mistakes

Using custom (in-house) encryption algorithms.

Weak random number generation.
Poor key management or password-based keys.

🔹 Prevention

Use standard algorithms (AES, RSA).

Ensure high-quality randomness.
Avoid predictable key generation.

⚙️ 6️⃣ Insecure Configuration Issues

🔹 Description

Applications can fail security due to misconfiguration, even with secure code.

🔹 Common Causes

Default admin passwords left unchanged.

Configuration files storing credentials in plain text.
Applications running with excessive privileges.

🔹 Prevention

Change default credentials.

Encrypt configuration data.
Restrict file and user permissions.
Use secure communication channels (even in internal networks).

💥 7️⃣ Denial of Service (DoS)

🔹 Definition

Availability to genuine users when they need access is a key requirement for any application to be successful.
A DoS attack aims to make applications or services unavailable to legitimate users.

🔹 Types

Network-level DoS – floods or overloads system resources.

Application-level DoS – exploits logic flaws like unbounded loops, weak validation, or excessive requests.

🔹 Example

Login page with no account lockout → attacker can run brute-force attacks.
Automated features abused to overload systems.

🔹 Prevention

Implement account lockouts.

Rate-limit requests.
Use CAPTCHA to prevent automation.

🧩 8️⃣ Canonical Representation Flaws

🔹 Definition

Data should be represented in its canonical (standardized) form.

If the system fails to validate all possible representations of the same data,and takes a decision based on the noncanonical representation of the data, attackers can bypass
validation.

🔹 Example

Multiple representations of file paths can allow directory traversal attacks.

🔹 Risks

Spoofing
Broken access control
Information disclosure

🔹 Prevention

Normalize all inputs before validation.

Use canonical path resolution functions.

🧠 Summary Table
Vulnerability Type Cause Example Prevention
SQL/LDAP/XPath Injection Improper Input Validation ' OR 1=1 Parameterized Queries
XSS Echoing Unvalidated Input <script>alert(‘XSS’)</script> Input Sanitization
Session Management Flaws Weak Session IDs Session Fixation SSL, Regenerate IDs
Error Handling Leaking System Info Stack Trace Generic Error Messages
Cryptography Misuse Weak Keys or Algorithms Predictable RNG Standard Crypto APIs
Insecure Config Default Passwords Admin/admin Encrypt Configs
DoS Lack of Limits Unlimited Login Attempts Lockout, Throttling
Canonical Flaws Non-Standard Input ..\..\etc\passwd Normalize Input
1. Service-Oriented Architecture (SOA) & Web Services

Definition: A design paradigm where systems are built from well-encapsulated, reusable software bundles (services) that are accessible over networks via well-defined,
open, implementation-independent, standards-based interfaces.

Web Services are the most popular implementation of SOA.

While they enable business efficiency and integration, their openness and location at the edge of the enterprise ecosystem make them highly vulnerable.
Their use of human-readable messages (XML) further increases the attack surface.

2. The SOA Standards Stack

Definition: A layered set of open standards that define how different facets of SOA and Web Services operate, ensuring interoperability.
The stack is built upon XML as its universal language. The key standards are:

SOAP (Simple Object Access Protocol): An XML-based protocol or schema to provide for standards-based packaging of messages sent between service
providers and consumers irrespective of transport protocol (can use HTTP, SMTP, etc.).
WSDL (Web Services Description Language): An XML-based contract that provides a standard for describing the communication and location details of a
service to all service consumers to help them get access to all the details necessary
UDDI (Universal Description, Discovery, and Integration): An XML-based standard for a service registry, acting like a "Yellow Pages" where businesses
can publish and discover services.
WS-BPEL (Web Services Business Process Execution Language): A standard for describing and executing business processes that orchestrate multiple Web
services.
Security Standards: Cross-cutting standards (e.g., WS-Security) that apply security measures like encryption and signatures across all layers, also using XML.

3. Service-Level Security Requirements

Definition: The specific security needs that must be addressed to protect services in an SOA, which traditional security measures are often inadequate to handle

Traditional Security (like Firewalls & SSL) Is Not Enough for Web Services

Web services use HTTP, which firewalls usually allow without strict checks.
HTTP tunneling can bypass network restrictions.
XML filtering slows down firewalls.
Messages can pass through intermediaries, increasing risk.
SSL/TLS only secures point-to-point links, not the entire message path — allowing MITM attacks in between.

3.1 Authentication

Definition: Verifying the identity of a service invoker.

diverse mechanisms (username/password, certificates, Kerberos, etc.) need to be provided for in Web services.
Must allow interoperability between different systems and accept credentials from external partners.

3.2 Authorization and Access Control

Definition: Determining what an authenticated user is allowed to do.

Requires operation-level access control (e.g., permission to execute a specific method).

Must handle dynamic updates during multi-hop invocations and enforce complex business/security policies.
3.3 Auditing and Non-Repudiation

Definition: The ability to log and review service invocations to provide a verifiable record of events.

Auditing captures details of users, access attempts, and failures for analysis.
Non-repudiation provides proof that a specific party invoked a service, preventing them from denying it later.

3.4 Availability

Definition: In any distributed SOA implementation Ensuring that a service is accessible to genuine users when needed, typically guaranteed via Service Level
Agreements (SLAs).

Requires protection against Denial-of-Service (DoS) attacks that use malicious data that appears harmless to firewalls to overload the service.
May necessitate specialized firewalls that can inspect the content of service requests.
Code Inspection of service requests can provide a clue about repeated requests

3.5 Confidentiality

Definition: Ensuring that data is not disclosed to unauthorized parties.

In SOA, a single XML message may pass through many systems — some parts are for all, others are private.
So, only specific sections of the XML are encrypted, allowing each intermediary to see only the parts meant for them

3.6 Data Integrity

Definition: Ensuring that data has not been altered in an unauthorized manner during storage or transmission.

In SOA, this may require ensuring the integrity of only specific portions of an XML document, while allowing other parts (like routing headers) to be modified by
intermediaries.

3.7 Privacy

Definition: Controlling the use and disclosure of personal information provided by clients, in accordance with stated policies and legal requirements.

Organizations must publish privacy policies and ensure clients follow them.

3.8 Trust

Definition: The confidence that one entity has in another. In SOA, trust must often be established dynamically between entities from different domains based on
message-level information (proof of trust).Trust intermediaries are important in the context of SOA.

3.9 Federation and Delegation

Delegation: The ability for one service to transfer its security rights and policies to another trusted service.
Federation: An architecture that allows for Single Sign-On (SSO) across different systems without requiring a central identity store.

4. Service-Level Vulnerabilities and Attacks

Definition: Weaknesses in service design or coding, and the exploits that target them, which can lead to unauthorized access or damage.

4.1 Attacks Targeting Service Definitions (WSDL/UDDI)

[Link] Probing/Scanning:

Definition: An attack where an attacker analyzes a service's WSDL file to gather intelligence.
 WSDL is the XML representation of a service contract.
A complete WSDL definition contains all of the information necessary to invoke a Web service.
The WSDL reveals methods, parameters, underlying technologies, and invocation patterns, providing a blueprint for further attacks.

[Link] Registry Attacks:

Definition: Attacks that exploit the service registry.

An open, platform-independent registry for publishing and discovering web services.
Works like a Yellow Pages for businesses.
Provides:
1. Standard way to describe services.
2. Simple method to invoke services.
3. Central registry for easy access and search.
UDDI registries provide details about the purpose of a Web service, as well as detailed informationon how to access it
Attackers can query UDDI to mine information about all available services.
UDDI registries do not provide a robust mechanism for verifying theauthenticity of entries.

3. Simple Object Access Protocol SOAP-Based Attacks

SOAP Routing Attacks:

SOAP messages can travel through intermediaries.
Threats include message modification, vulnerable headers, and false routing instructions (WS-Routing) leading to MITM or DoS.
It provides a full description of the required actions taken by a SOAP node on receiving a SOAP message.
The intention of SOAP was purely to act as a message exchange standard between the service provider and service requestor.
Hence SOAP specifications do not provide any ‘out of the box’ mechanisms to perform authentication between [Link] are no techniques to
ensure data integrity or confidentiality, either at endpoints or during transit

B. Known Bug Attacks

Many Web services use popular open-source components (e.g., Apache Web Server, Axis) with publicly known bugs and security warnings.
Security consortiums issue warnings for proprietary products as well.
While fixes are released via patches, organizations are often slow to apply them.
If fixes are not quickly applied it allows Attackers exploit these known, unpatched vulnerabilities to gain access to underlying systems and hosts.

C. Injection Attacks

1. SQL Injection

Malicious input in SOAP messages alters SQL query logic.

Example:

<orderList> <dealer_code> X' OR 1=1 --</dealer_code> <order_type>P</order_type>

This input changes the intended SQL query:

-- Intended Query:String sql = Select ... From Order Where dealer_code = "'+[Link]()+"' And dealer_status='C'

-- Resulting Malicious Query:Select ... From Order Where dealer_code = 'X' OR 1=1 --' And dealer_status='C'

The -- comments out the rest of the query, and OR 1=1 makes the condition always true, returning all orders.

2. XPath and XQuery Injection

Injecting malicious code into XPath queries to manipulate XML data retrieval.
Example: Given an XML database of customers, a legitimate query to find an active customer with ID 'cust1' is:
xpath
 //customers/customer[customerID/text()='cust1' and status/text()='A']

An attacker can inject input to subvert the logic:

xpath

//customers/customer[customerID/text()='' or 1=1 or ''='' and status/text()='' or 1=1 or ''='']

This altered query returns all customers because the condition or 1=1 is always true.

Blind XPath Injection:

XPath Crawling: Crawl an XML document from a known XPath.
Query Booleanization: Inject queries that behave differently if true/false, allowing data extraction.

3. Cross-site Scripting (XSS) Attacks

Can be orchestrated as a second step to WSDL phishing and session hijacking attacks.
Attackers use XSS to send malicious scripts/code to victims, giving access to sensitive information.
Possible Results:
1. Encrypted SSL connections can become vulnerable.
2. Persistent attacks can be launched, and keystrokes can be monitored.
3. Domain-based security policies can be violated.
Types of XSS Attacks:
Persistent Code Attack: Malicious code is injected and stored on the server. The victim gets infected when requesting data from the server (e.g., via 'search
the Website' or forums).
Reflected Code Attack: Orchestrated after WSDL phishing. The victim is tricked into clicking a malicious link, which injects code that reflects back from a
trusted source.
XSS Testing & Vectors:
Simple Check Attack: A string (";!--"<XSS>=&{()}) to test for vulnerable JavaScript.

XSS Locator: Injecting a specific string to make 'XSS' appear if vulnerable. Using deprecated tags like <PLAINTEXT> can also test vulnerability by messing
up output.

C. Parameter-Based Attacks

Parameter Tampering: A popular and simple attack targeting the application business logic by altering parameters in URL query strings, form fields, and cookies.
Classic Example: Changing values in HTML form fields, especially hidden fields used for status information (e.g., changing a
price VALUE="700.00" to VALUE="70.00").
Web Service Manifestation:
Bad security assumptions during design (e.g., assuming other systems handle authentication and input validation).
Web services invoked via asynchronous JavaScript (XMLHttpRequest) are vulnerable to malicious scripts that change the request object and data.
If the method is GET, parameters are visible in the URL query string and can be tampered with.
Custom session management mechanisms (tokens, pseudo-cookies) passed across requests and stored in hidden fields can be manipulated.
Example Scenario: Amazon cart total stored in a hidden field (<INPUT TYPE="HIDDEN" NAME="COST" VALUE="700.00">). A hacker can save the page, change the
value to 70.00, and invoke the payment Web service, paying a fraction of the price

D. Authentication Attacks

1. Request Authentication Attacks

Forced Entry: Guessing weak passwords manually or automatically.

Dictionary Attack: Using predefined wordlists (dictionaries) with tools like WebCracker, Brutus.
Brute-Force Attack: Similar to dictionary attacks but targets cryptographic schemes.
Computed Authentication Attacks: Reverse-engineering the algorithm used to generate passwords or session IDs from a captured series.
2. Stealth and Hijacking Attacks

Session Fixation: Attacker sets a known session ID, tricks user into logging in, then impersonates them.
Session Hijacking:
Sniffing network traffic (e.g., packets) to steal session keys/cookies after authentication.
Allows impersonation if post-auth traffic is unencrypted.

3. Response Authentication Attacks

Malicious party poses as the legitimate service.

WSDL Phishing:
Hosting manipulated WSDLs on fake URLs.
Service consumers unknowingly send their login credentials to the attacker.

E. Man-in-the-Middle (MITM) Attacks

Eavesdropping/Sniffing:
Read plaintext SOAP/XML traffic (passwords, config data).
Crack lightly encrypted packets.
Replay Attacks (Spoofing Attacks):
Intercept and resend valid messages (even digitally signed ones).
Can create DoS floods or carry out checksum spoofing (recomputing the hash for a modified message).
Data Integrity Attacks:
Eavesdrop and modify message data (e.g., change target account number in a payment gateway).

F. XML-Based Attacks

1. Coercive Parsing Attacks

Misusing CDATA: Using CDATA sections to sneak system commands past parsers, leading to injection attacks (XPath, XSS) or host manipulation.
xml

<?xml version="1.0"?><?xml-stylesheet type="text/xsl" href="[Link] ?><xsl:stylesheet xmlns:xsl="[Link]

XML Extended Entity (XXE) Attacks:

Exploit XML's ability to reference external data (<!ENTITY name SYSTEM "URI">).
Can force the parser to open files or HTTP connections, potentially exposing sensitive data (e.g., the PeopleSoft vulnerability).

2. XML Denial of Service (XDoS) Attacks

XML Bombs: Specially crafted messages to overwhelm the parser (crash, memory consumption, DoS).
Flooding: Sending a large number of legitimate-looking requests to consume resources.
Complex Payload:
Excessive element nesting.
Flooding <any> attributes.

Creating numerous element attributes.

Excessive tag opening/closing (stack push/pop operations).
Sending oversized parameter data (buffer/stack overflow).
Oversized Payload:
Exploiting unbounded elements (e.g., <any>) to create gigantic (GBs) payloads.

3. Schema-Based Attacks

Manipulating the XML schema to cause:

Schema poisoning.
 Denial-of-Service.
Format changes (date, currency).

G. Other Attacks

Parameter-Based Attacks:
Tampering: Modifying parameters in URL query strings, form fields, cookies, or hidden fields (e.g., changing a VALUE="700.00" to VALUE="70.00" in a

payment request).
Web services invoked via JavaScript (XMLHttpRequest) are vulnerable to malicious script injection altering request data.

Cross-site Scripting (XSS) Attack:

Can follow WSDL phishing/session hijacking.
Results: SSL vulnerability, persistent attacks (keystroke monitoring), violation of security policies.
Persistent Code Attack: Malicious code injected and stored on the server.
Reflected Code Attack: Victim tricked into clicking a malicious link; code reflects from a trusted source.
Simple Check Attack & XSS Locator: Strings to test for XSS vulnerabilities.
Simple Check string: ";!--"<XSS>=&{()

XSS Locator string:

javascript

';alert([Link](88,83,83))//\';alert([Link](88,83,83))//";alert([Link](88,83,83))//\";alert(St

1. Host-Level Solutions: Introduction

Core Problem: Transient code is untrusted and can be malicious, while resident code, though trusted, can contain bugs.
Primary Solution Strategy: Create 'isolated' environments to contain the ill-effects of code execution, preventing damage to the overall system.
Key Techniques:
Isolation: Sandboxing, Virtualization.
Trust Verification: Proof-Carrying Code (PCC).
Resource Fairness: Resource Management.
Attack Prevention: Memory Firewall, Antimalware.

2. Sandboxing

Definition: A technique for achieving isolation by controlling or restricting an application's access to system resources via system calls.
Principle: By restricting system call access, the harm from malicious code can be contained.
Types of Sandboxing:
2.1 Kernel-Level Sandboxing:
A kernel module hooks the system call entry table to inspect every system call.
A policy engine (in user or kernel space) decides to allow or deny calls based on resources, users, and processes.
Pros: No changes needed to the application.
Cons: Can introduce significant performance overhead.
2.2 User-Level Sandboxing:
Uses OS debugging features (e.g., UNIX ptrace) to let a parent process trace and control the system calls of its child process.
The parent sandboxing process consults a policy engine.
Cons: Higher overhead than kernel-level; requires running the app under a parent sandboxing process.
2.3 Delegation-Based Sandboxing:
In this approach, when a user process invokes a system call the system makes a callback to an emulation library in the user space, which provides
isolation service.
 Solves race conditions in other methods by using a user-space delegation agent to execute system calls on behalf of the application.
The kernel module is minimal and more portable.
2.4 File-System Isolation:
Uses system-call interception to create an isolated "shadow" file system.
The hook implemented with the system creates an isolated shadow file system, which records allfile-system changes while leaving the primary file
system untouched.
When a file is updated, the solution uses copy-on-write to duplicate the file and maintain a separate copy, leaving the original as it was.
Allows administrators to review changes before committing them.

3. Virtualization

Definition: A technique that uses a Virtual Machine Monitor (VMM) or hypervisor to create isolated virtual machines (VMs) with properties of a real machine.
Key Properties: Resource control,Efficiency,Equivalence.
Types of Virtualization:
3.1 Full-System Virtualization:
The VMM sits directly on the hardware and fully abstracts it to create VMs.
The VMM handles all resource access; no VM has direct hardware access.
Instructions, other than ones used for resource access, execute directly on the physical hardware,thus reducing any CPU virtualization overheads.
Example: VMware ESX.
3.2 Para-Virtualization:
an instruction set of the hardware which does not support virtualization is modified to a fully virtualizable instruction set, such that the system can
be fully virtualized
The guest Operating System kernel is modified (ported) to run on a hypervisor using a "virtualizable instruction set."
No run-time translation is needed, offering near-native performance.
Drawback: Requires modifying the OS kernel, which is difficult for proprietary OSs like Windows and the kernel needs porting for the hypervisor.
Example: Xen.
3.3 Shared-Kernel Virtualization (OS Virtualization):
Partitions a single OS kernel into multiple isolated containers or zones.
Each container has its own file system, process space, and network identity.
Each container has its own context; the kernel blocks access to resources outside that context.
Pros: Highly efficient. Cons: Less robust isolation; the host kernel must be modified.
Examples: Solaris Zones, Linux VServer.
3.4 Hosted Virtualization:
In this model, the VMM is actually an add-on to an existing OS, which exists as a host, with all theVMs as guests
The VMM runs as an application on top of a host operating system.
The major difference between this and the others is that the hosted virtualization uses the device drivers in the host OS for I/O virtualization.
Examples: VMware Workstation, Microsoft Virtual PC.
3.5 Hardware Assists (e.g., Intel VT):
Modern processors include hardware support for virtualization (e.g., Intel VT, AMD-V).

Problem: IA32 architecture has ~17 non-virtualizable instructions.

The lowest ring level, 0, is where the OS runs, and ring level 3 is where the user applications run. Ring levels 1 and 2 are reserved or not used
Ring deprivileging (running VMM at ring 0, guest OS at a higher ring) causes issues:
1. Ring Aliasing
2. Address-Space Compression
3. Nonfaulting Access to Privileged State
4. Ring Compression
Solution: Intel VT introduces a VMM ring level (VMX root operation).
Process:
VMM runs in VMX root.
 Guest OSs run in VMX non-root.
Transition via VM entry and VM exit.
Instructions needing VMM intervention cause unconditional VM exits.
Benefit: Allows unmodified guest OSs to run with minimal overhead.

3.6 Security Using Virtualization:

Isolation: Provides fault and resource isolation, addressing eavesdropping, job faults, and resource starvation.
Trusted Platforms: Projects like Terra use a Trusted VMM (TVMM) to host VMs. "Closed-box" VMs can provide attestation to remote clients, proving
they haven't been tampered with.
Resource Management: The VMM can allocate CPU, memory, etc., based on shares or priorities to prevent resource starvation.
Future Trends: Running security stacks (IDS, firewalls) in a separate, isolated Security VM to protect them from compromise.
Application Streaming/VDI: Hosting applications and data in a central data center and streaming only the user interface to desktops. This limits damage
from transient code on the endpoint.
Examples: Microsoft SoftGrid, VMware VDI.

4. Resource Management

Goal: Prevent resource starvation in shared environments (e.g., grids/clusters) by ensuring fair sharing of resources among competing jobs.
Techniques:
4.1 Advance Reservation: Explicitly reserving resources (CPU, memory) for specific jobs or types of jobs (e.g., dedicating one CPU core to grid jobs).
4.2 Priority Reduction: Lowering the priority of grid jobs to ensure native host jobs are not starved. Can create a simple "cycle-stealing" environment.
Workload Management Solutions:
4.3 Solaris Resource Manager (SRM):
Manages resources for workloads (groups of processes).
SRM has notions of projects and tasks, which are logical groupings of processes owned by a user or a group, to which relative or discrete resources can
be assigned.
Allocates CPU shares and caps physical memory (RSS) for projects and tasks.
Uses a fair-share scheduler to enforce controls.
The memory cap for each project can be set, and SRM will ensure that the physical memory consumption by the project does not exceed the cap.
4.4 Windows System Resource Manager (WSRM):
Creates resource-allocation policies by user or process.
Sets soft CPU caps (percentage) and manages process priorities.
Limits physical memory (working set size) and paging.
4.5 Citrix ARMTech:
Similar to SRM; allocates CPU and memory based on users, applications, or application groups using a share-based model.
Supports tiered policy paths.
ARMTech publishes accounting information on resource usage through the standard Window Management Instrumentation(WMI) interface available
on Windows server platforms.
4.6 Entitlement-Based Scheduling (EBS):
A scheduler for Linux that uses share-based entitlements to manage CPU allocation for processes.
In Linux, the Resident Set Size (RSS) of a process can be directly managed through system calls
EBS is an external add-on to the Linux kernel.
These system calls and EBS help prevent resource starvation

5. Proof-Carrying Code (PCC)

Principle:It is the responsibility of the transient code author to show that the code is [Link] execution host simply verifies that the claim by the author is true
and confirms that the code has not been tampered with
Parties:
Code Producer: Generates code and a proof of its safety.
Code Consumer (Host): Defines a safety policy and validates the proof.
 Stages:
1. Certification: Producer computes and attaches the safety proof to the code.
2. Validation: Consumer verifies the proof against the safety policy. This is a one-time cost.
3. Execution: Code is [Link] runs with no run-time overhead.
Challenge: Difficult to implement for internet-scale distribution with millions of potential consumers with different policies.

6. Memory Firewall (Program Shepherding)

Goal: Protect against code injection and control-flow hijacking attacks (e.g., buffer overflows).Monitoring control flow transfers to enforce a security policy

Method: Uses dynamic code optimization to interpret binary code.

Principle:
The target binary code is separated and broken into basic blocks (sequences of instructions ending with a single control-transfer instruction).
A security policy is defined for control transfers (based on origin, function returns, etc.).
The system monitors all control transfers during execution to ensure they comply with the policy.
Benefit: Prevents injection attacks by controlling all control flow.
Example: SecureCode from Determina.

7. Antimalware

Definition: Software designed to identify and remove malware (viruses, worms, Trojan horses, spyware).
Examples: eTrust, McAfee, TrendMicro.
Approaches:
7.1 Signature-Based Scanning:
Compares files against a dictionary of known malware signatures.
Action: Infected files are cleaned, quarantined, or deleted.
Limitation: Relies on an up-to-date [Link] against zero-day attacks (new, unknown malware) and can be evaded by
encryption/polymorphism.
7.2 Real-Time Scanning (Behavioral):
Uses system-call interception to monitor I/O and resource access in real-time.
Checks for anomalous behavior against a [Link] protect against unknown viruses.
Limitation: Can cause significant performance overhead.
7.3 Heuristics-Based Worm Containment:
Uses heuristics to detect anomalies in network or file I/O patterns.
Example: Intel vPro
Inline Processing Unit: Briefly analyzes outgoing packets.
Sideband Processing Unit: A hardware component that runs packet data through a heuristics engine.
Action: If suspicious behavior is detected, the node is isolated from the network.
Benefit: Provides tamper-resistant, hardware-level security against zero-day worms.
7.4 Agent Defense:
Protects the antimalware software itself from being disabled.
Solution: Hardware assists to guarantee agent safety.
Example: Intel's System Integrity Service (SIS), a firmware-based solution that ensures:
Agent Locality: Protects the memory where the agent resides.
Agent Integrity: Verifies the agent code has not been tampered with.
Agent Execution State: Monitors the agent's state via tamper-proof heartbeats.
1. Infrastructure level Solutions

A. Information Security Protocols

Goal: Provide Confidentiality, Integrity, and Authentication (CIA) via encryption and authentication.
Secure Socket Layer / Transport Layer Security (SSL/TLS):
Secures the transport layer (on top of TCP) and provides security in managing sessions over the transport channel
Protocol Steps:
1. ClientHello: The client contacts the server to initiate an SSL [Link] sends supported crypto algorithms & random number R_C.

2. ServerHello: Server replies by sending its certificate & random number R_S.
3. Client Authentication: Client verifies certificates, extracts server's public key, selects random S, and computes master secret K = f(R_C, R_S, S).

4. Key Exchange: Client sends S and hash of K, encrypted with server's public key.
5. Secure Communication: All subsequent data encrypted with session key K.

Primarily provides server authentication. Mutual authentication is possible if the client has a certificate, but typically uses username/password.
IP Security (IPSec):
Operates at the network layer (IP) to secure all distributed applications.
The principal feature of IPSec is that it can encrypt or authenticate all traffic at the Internet protocol (IP) level.
Can be implemented in networking devices (routers, firewalls) or directly on workstations/servers.
Main Components:
1. Security Mechanisms:
Authentication Header (AH): Authentication only.
Encapsulating Security Payload (ESP): Combined authentication and encryption.
2. Security Associations (SA): Agreement between two peers on security services for an IP traffic stream.
3. Key Management Infrastructure: Sets up SAs between two communicating peers
Modes of Operation:
Transport Mode: AH/ESP applied only to the packet payload;while original IP header untouched.
Tunnel Mode: AH/ESP applied to the entire original IP packet, which is then encapsulated into a new IP packet packet Used for VPNs.

B. Virtual Private Networks (VPNs)

Provides secure, dynamic access to confidential resources over public networks.

One prominent communication service that allows access to resources anywhere and anytime is VPN
The connection is torn down as soon as it is not required, resulting in bandwidth savings.
Types:
Layer 2 VPN (L2VPN): Provider uses Layer 2 (data-link layer) info (MAC, MPLS label) for forwarding. Unaware of Layer 3 (IP) info.
VPWS (Virtual Private Wire Service): Service between two [Link] sites are connected in a partial or full mesh
VPLS (Virtual Private LAN Service): Service across multiple sites, emulating a LAN where a site automatically gains connectivity to all the other
sites attached to the same LAN
Layer 3 VPN (L3VPN): Provider offers Layer 3 (IP) (network layer) connectivity between the different customer sites
BGP/MPLS VPN: Uses Multiprotocol BGP (MPBGP) for route distribution and MPLS labels for traffic isolation in tunnels.
Virtual Router (VR): PE nodes run a separate VR instance for each VPN, connected via tunnels.

C. Denial-of-Service (DoS) Solutions

1. Preventive Countermeasures:Take precautionary steps in preventing DoS attacks.

Packet Filtering:based on some prior information,on the basis of which the filtering is carried out
Egress Filtering: The practice of scanning the packet headers of IP packets leaving a network (egress packets) and checking to see if they meet certain
criteria.
If the packets pass the criteria, they are routed outside of the [Link], the packets will not be sent to the intended target.
If the network administrator places a firewall or packet sniffer in the subnetwork to filter out any traffic without an originating IP address
 Ingress Filtering: the filtering is done on all packets coming into the network
Distributed Packet Filtering (DPF): Drops packets based on route information (expected source interface).
Application Filtering (XML Firewalls):
Examines the content of SOAP/XML messages to block application-level attacks like XML Denial-of-Service (XDoS)
Applies security policies based on target address, caller identity, and message content to block attacks like entity-expansion (XDoS).
High performance overhead.
Location Hiding (Secure Overlay Service - SOS):
Hides the actual target server behind a network of proxies
Filters only allow traffic from known overlay nodes.
Concerns: Added latency, ineffective against insider attacks.
Throttling:
To prevent servers from going down, use max–min fair server-centric router throttles
An allocation is considered max-min fair if no user's allocated rate can be increased without decreasing the rate of another user who is receiving an
equal or lesser allocation preventing server flooding.
D-WARD: A source-end DDoS defense system deployed at source-end networks that observes traffic, classifies flows, and applies rate-limiting to malicious
flows.
Challenge: Differentiating legitimate from malicious traffic.
Intrusion Detection Systems (IDS):detect attacks based on a set of policies and information
Anomaly Detection: Detects deviations from normal behavior.
Signature Detection: Matches against known attack patterns.
Grid-based IDSs use sensors to monitor and SNORT to analyze.

2. Reactive Countermeasures:Aim at identifying the source of attacks.

Identifying the attacker after the attack has been completed assumes that the attack remains active after the completion of the trace.
Link Testing: Iteratively checks upstream links until the source is [Link]
Input Debugging: Routers develop an attack signature based on some attack pattern
Controlled Flooding :The victim floods all the links, based on the assumption that the packet drop taking place from an attacked link (can itself cause DoS).
Logging:
Source Path Isolation Engine (SPIE): Routers (Data Generation Agents - DGAs) compute packet hashes and store them in Bloom filters. As soon as the
attack is detected, the SPIE Traceback Manager (STM) calculates the attack signature of the packets used for the attack.
Problems: High resource usage, scalability issues, ineffective against distributed reflector attacks.
ICMP Traceback: Routers periodically send ICMP messages with packet info to the destination. Vulnerable to ICMP-based DoS attacks.
IP Traceback:
Probabilistic Packet Marking: Routers mark packets with a low [Link] router sends an ICMP traceback message for stored packets, enabling the
destination to trace attacks back to the source.
Node Sampling: Marks node info only(can be overwritten).
Edge Sampling: Marks node info and distance, reducing packets needed for traceback.

D. DNS Security (DNSSEC)

Provides data-origin authentication and integrity for DNS using digital signatures.
The digital signature contains the encrypted hash of the resource record set (RR set).The recipient can then check the digital signature against the received data
Each DNS message is signed. The DNS tree hierarchy is used to create a chain of trust from the [Link] node in the DNS tree is associated with a public key
Limitation: Does not provide confidentiality (information leakage is still possible).

E. Routing Attack Solutions:Are mostly concerned with the routing packets flowing between the routers

1. Link State Solutions:If links interrupt selectively, it is possible to have unsynchronized routing tables throughout the [Link]-effects of such routing
tables are looping and DoS

Digital Signatures: The routing updates increase by the size of the [Link] a PKI.
 Sequence Information: Uses sequence numbers or timestamps to prevent replay attacks.

2. Router Attack Solutions

Intrusion-Detection: Centralized attack-analyzer module detects attacks based on possible alarm-events sequences (not scalable for the Internet).
Protocol-Driven:where attack detection capability is incorporated in the routing protocol itself
Secure Link State Protocol (SLSP): Requires 'confirmation' from both ends of a link. Works only in symmetric, non-colluding networks.
Consistency-Check (CC) Algorithm: Uses predecessor info in distance-vector updates to trace paths and detect inconsistencies. Whenever a node receives
the distance vector from its neighbors, it carries out CC by tracing the path from each [Link] be defeated by intelligent attackers.

F. Wireless Security (WEP)

Aims for confidentiality, availability, and integrity in Wireless LANs.

Uses RC4 stream cipher with an Initialization Vector (IV) and a shared WEP key are used to encrypt/decrypt transferred packets
WEP uses CRC (cyclical redundancy checking)to verify message integrity.
Weaknesses:
Short key length (40-bit, later 104-bit in WEP2).
Lack of key management (users rarely change keys).
No mutual authentication (vulnerable to rogue APs).
Uses linear CRC for integrity, which is cryptographically weak (WEP key can be resolved).

2. Grid-Level Solutions

A. Architecture Security

1. Information Security - Grid Security Infrastructure (GSI)

Virtualizes security semantics for interoperability.

Based on Web services standards (WS-Security, WS-Policy, WS-Trust).
Uses TLS/SSL (HTTPS) for point-to-point security and WS-Security for traversing intermediaries.
Authentication: Primarily certificate-based (PKI-public-key infrastructure), also supports Kerberos and passwords.
Delegation: Uses proxy certificates (short-lived) to allow resources to act on a user's behalf, simplifying multi-resource transactions.A proxy is made up of a new
certificate containing two parts: a new public and a new private key.

2. Authorization Systems

VO-Level Systems:
Centralized authorization for an entire Virtual Organization that provides credentials for users to access resources.
Community Authorization Service (CAS): A trusted third-party server that manages and enforces access policies for the community's resources.
Other examples: VOMS, EALS.
Resource-Level Systems:
Allow access to resources based on the credentials presented by the users.
Implement authorization decisions for specific resources.
Akenti: Accesses resources via a resource gateway Policy Enforcement Point (PEP). Stakeholders define access policies via self-signed certificates. The
Akenti server evaluates these to grant access.
Other examples: PERMIS, GridMap.

3. Grid Service Security

Focuses on DoS and QoS/SLA violation attacks.

SLA Violation Detection:
Intrusive Method: Encode timestamps into user data packets (requires packet modification).
 Nonintrusive Method: Inject probe packets for measurement, then delete them.
Loss Measurement: Core routers count drops, edge routers count total packets (Loss Ratio = Drops / Total Packets).

B. Grid Infrastructure Solutions

Adaptive Firewall for Grid (AGF): Dynamically opens and closes firewall ports based on authenticated service [Link] firewall will open the ports when it
receives authenticated [Link] will close them again when there is no service activity on them.
HOSE Service Model: A flexible VPN model where customers specify aggregate traffic requirements, allowing on-demand resource adjustment. Fits the grid
vision but lacks strong QoS guarantees.

C. Grid Management Solutions

1. Credential-Management Solutions

Credential Repositories (Storage):

Securely store and issue credentials on demand and sometimes generating proxy credentials on a user’s behalf for delegation purposes.
Examples: Smart Cards, Virtual Smart Cards, MyProxy.
MyProxy: An online repository where users store long-term credentials and fetch short-term credentials or proxy from the MyProxy server so that the long-
term credentials are safe. Vulnerable to dictionary attacks as the private key is exposed to the server.
Credential-Federation Systems (Sharing):
Responsible for sharing the credentials across different domains or realms
Specific Solutions: VCMan (for CAS interoperability), KX.509 (X.509 & Kerberos interoperability).
Generic Solutions: Frameworks for sharing attribute information in a distributed manner across entities in a trusted domain called the Circle of Trust
(COT).

2. Trust-Management Solutions (TMS)

Policy-Based TMS:
Establishes trust based on the exchange of credentials and pre-defined policies.
TrustBuilder: An infrastructure for trust negotiation where credentials are disclosed in a need-to-know manner over TLS, SMTP, etc.
Reputation-Based TMS:
Evaluates trust based on global/local reputation and policies.
PeerTrust: A distributed TMS where each peer stores a portion of global trust data does not use a centralized database for storing trust information
XenoTrust: Built on the XenoServer platform (XenoServers, XenoCorp, XIS) for reputation management in a service-for-payment model.
NICE Framework: A platform for cooperative applications (like grids) to manage trust among peers sharing resources.

3. Storage-Level Solutions

A. Fiber-Channel Security Protocol (FC-SP) for SANs

A standard for securing Storage Area Networks (SANs).

Mechanisms: Authentication, session key setup, frame integrity/confidentiality, policy distribution.
Authentication Infrastructure:
Secret-Based: Uses shared secrets or a RADIUS server with DH-CHAP protocol.
Certificate-Based: Uses PKI with Fiber-Channel Authentication Protocol (FCAP).
Password-Based: Uses Fiber-Channel Password Authentication Protocol (FCPAP).
All methods can use the established session key with the ESP Header for frame security.
Integrity and Confidentiality: Achieved via the ESP Header based on traffic selectors in the Security Association Database (SADB).
Authorization: Enforced through policies.
Fabric-Wide Policies: Control switch/node membership, topology, management access.
Switch-Wide Policies: Per-switch data, including zoning policies.
 Policy enforcement is local to the entity involved in the connection attempt.

B. Distributed File System (DFS) Security

1. Network File System (NFS) Security

Security levels:
Identification:determining the user ID associated with an operation, Authentication, Authorization, Access Control.
User Information Storage: Local files, NIS (Network Information Service), or LDAP.
Client Authentication: IP address validation, IPSec, or Kerberos.

2. Network-Attached Secure Disks (NASD)

Since the server must interact with every file-access request for every client, this can quickly become a bottleneck.
NASD’s primary goal is to relieve the server bottleneck by only interacting with each user onetime, and providing a ‘capability key’.With the capability key, the
user can access the appropriate disk(s) directly, without any further server interaction.
Process:

1. User authenticates with an authentication server.

2. User requests file access from the file server.
3. Server provides a capability object (token + key) granting specific access rights.
4. User communicates directly with the disk using this capability object for the session.
There are two servers in the NASD design, one to provide authentication and then the actual file server.
The capability key is a MAC using a secret shared between the file server and the disk, ensuring integrity.
Since the MAC can only be interpreted using the drive/server-shared secret key, any modifications to the arguments or false arguments will result in a denied request
Disks handle authorization, encryption, and data transmission directly with the client.

3. OceanStore Security

OceanStore uses a large number of untrusted storage devices to store redundant copies of encrypted files and directories in persistent objects.
Data is replicated and encrypted by clients.
Objects are identified by a GUID (hash of owner's public key + name).
Heavy use of replication and public keys makes access revocation and data deletion difficult but provides a robust decentralized model.

Application level Solutions

1. Introduction: The Shift to Application-Level Attacks

Attackers are now focusing on exploiting design and coding weaknesses in applications.
Reasons for this shift:
Lack of security awareness among software developers.
Wide availability of public information on vulnerabilities and exploits.
Availability of sophisticated tools that automate exploitation.
Solution: Secure application development requires considering security at every stage of the development lifecycle (requirements, design, testing, deployment,
maintenance).

2. Core Application-Level Security Solutions

A. Input Validation Techniques

Primary Cause of Vulnerabilities: Insufficient or no input validation leads to SQL/LDAP/XPath Injection, XSS, and buffer-overflow attacks.
 Injection Vulnerability: Occurs when user-supplied input is used in a command or query without proper sanitization, allowing an attacker to change its semantics.
Impact: Loss of confidentiality/integrity, broken authentication, arbitrary command execution, full system compromise.

Key Principles for Input Validation:

1. Don’t Excessively Trust User Input

Treat all input from less trusted sources as potentially malicious.
Untrusted sources include:
Data from users (form fields, hidden variables, cookies, headers).
Data from files (may contain viruses/malcrafted data).
Data from databases which is updated by other applications.
Data from Web service calls in integration scenarios.
Best Practice: Consider all input as "bad" and subject it to strict validation. Understand the application's trust boundaries.
2. Use Centralized Validation Routines
Oftentimes developers develop validation routines to address specific validation [Link] disadvantage with this approach is that these validation
routines are not well tested and are not flexible when dealing with other, similar data
It is good practice to centralize the use of all input-validation routines
Advantages of a Centralized Library:
Easier development and maintenance.
Uniform and consistent validation rules across applications.
Single point of update for new vulnerabilities.
3. Don’t Use Client-Side Validations for Security
Client-side validations (e.g., JavaScript) are easily bypassed and exist for user experience and performance, not security.
Best Practice: Always perform input validation on the server side, even if client-side validation is present.
4. Accept Known Good Input and Reject All Known Bad Input
"Allow Only Known Good Input": Define and validate input against strict rules for type, length, format, and range. This is the most effective strategy.
"Reject Known Bad Input": Can be used for defense-in-depth after the primary check (e.g., blacklisting SQL keywords).
Sanitization: Encode input to make it "safe" before displaying it back to the user (prevents XSS).

B. Secure Session Management

HTTP is stateless; sessions are used to link requests from the same user via session identifiers.
The client and server exchange the session identifier between them as long as the session is valid.
Common Attacks: Session hijacking (stealing a valid session ID) and session fixation (forcing a user to use a known session ID).

Key Principles for Secure Session Management:

1. Session-Identifier Generation
Session IDs can be stored in cookies,appended to URLs, or hidden form fields.
These session identifiers play a crucial role in session-hijacking attacks, in which the attacker’s main objective is to get hold of an active and valid ion
identifier
Requirements for Secure Generation:
Large size to avoid collisions.
Highly random and unpredictable.
Use cryptographically secure random number generators, not standard pseudorandom generators.
2. Session-Identifier Communication
This HTTP traffic includes the session identifiers and once these are known the attacker can launch session-hijacking attacks
Prevent sniffing by exchanging session IDs only over encrypted channels such as SSL/TLS.
For cookies, set the 'SSL only' attribute.
Encrypt the session cookie contents using cryptography to protect against theft via XSS.
 3. Session-Data Protection
Store all session data on the server side.
Avoid storing sensitive data in client-side cookies.
Separate session authentication data from other data in different cookies.
Employ appropriate access controls on server-side session storage.
In a Web farm, ensure session data is stored in a shared, authenticated repository.
4. Session Lifetime
Invalidate sessions after a period of inactivity.
Keep the session timeout period as short as possible to reduce the window for hijacking or replay attacks.

C. Cryptography Use

Cryptography is crucial for authentication, confidentiality, integrity, and non-repudiation, but it does not solve all security problems (e.g., DoS).

Key Principles for Secure Cryptography:

1. Never Develop Custom Algorithms or Rely on Proprietary Algorithms

Adhere to the principle of "security not by obscurity".
The strength lies in the key secrecy, not algorithm secrecy.
Use crypto-algorithms that are published, time-tested, and publicly analyzed algorithms.
2. Choose the Right Algorithms and Key Sizes
Select algorithms based on the specific security requirement and context.
All crypto-algorithms are not equally secure
Algorithm Comparisons:
Stream Cipher Block Cipher
Fast; good for short-lived data (sessions) Good for long-term data protection
Encrypts data bit-by-bit; good for unknown length Encrypts in blocks; requires padding for non-multiples
Use Strong, Modern Algorithms:
Avoid: DES (broken), MD5 (broken), SHA-1 (weakened).
Use: AES Advanced Encryption Standard for symmetric encryption, SHA-256/SHA-512 for hashing.
Use Sufficient Key Lengths:
Symmetric (e.g., AES): Minimum 128-bit keys.
Asymmetric (e.g., RSA): Minimum 1024-bit keys (512-bit is broken).
Be aware of import/export regulations on cryptography.
3. Choose Secure Random Algorithms
Use cryptographically secure random number generators for keys, passwords,otps etc.
Standard pseudorandom generators (e.g., default in Java) are not secure for crypto purposes.
A secure random-number generator is one that produces highly-random numbers that are difficult to guess and has a large number of space with uniform
distribution
The source of randomness (entropy) is critical.
4. Ensure Secure Key Management
The strength of a cryptosystem depends on key secrecy but not in the secrecy of the algorithm itself. The importance of storing keys securely.
Key Lifecycle: key generation, key exchange, keystorage, key archival and key destruction
Storing the keys on a secure hardware is a recommended best practice
Best Practices:
Avoid hardcoding keys in executables.
Store keys in tamper-resistant, secure hardware where possible.
Protect key files with strict access controls.
Change keys regularly.
5. Choose Certified Crypto-Libraries
 Use libraries from trusted sources that are certified by standards like Common Criteria (CC) or FIPS (Federal Information Processing Standards).
Certification provides assurance that the implementation is secure and without backdoors.

D. Preventing Cross-Site Scripting (XSS)

Cause: Dynamic HTML pages that write back the user input to the browsers without validating the input can cause cross-site scripting.
The user input can come from anywhere including query strings, form variables, cookies, headers and so on.
Risk Applications: Search engines, bulletin boards, blogs – any app that constructs output from user input.

Best Practices to Prevent XSS:

1. Input Filtering
Remove special characters (< > ; % & + - etc.) from all input (query strings, form data, cookies).
Disadvantage: Can cause data loss and may not be suitable if the application requires those characters.
Always perform filtering on the server side.
2. Output Encoding (Safer Approach)
Encode data before writing it to the browser.
Encoding prevents any embedded scripts from executing on the client browser by removing the meaning associated with the special characters.
Advantage: No data loss.
Best Practice: Encode data based on the output context HTML or URL etc.

E. Error-Handling Best Practices

Poor error handling can leak sensitive information (stack traces, technology versions, database schemas, credentials) to attackers.
These may reveal a lot about the specific technologies used, along with version details, database schema details, SQL query strings, login credentials, directory
structure and so on, giving the attackers a deeper understanding of the application and enabling them to launch more targeted attacks
Inconsistent error states can leave the application vulnerable.
Some language platforms like Java and .NET support a more structured exception-handling technique, but others, such as C and PHP, do not provide
support for exceptions

Best Practices for Secure Error Handling:

1. Fail Safe
Ensure the application fails into a safe, determinate state. Also Review handling of fatal errors.
2. Display Safe Error Messages
Show generic, user-friendly error messages to clients.
Never display detailed stack traces, system information, or credentials to the user.
Log detailed errors with stack traces securely for administrators.
3. Use Appropriate Exception Handling
In languages with support (e.g., Java, .NET), implement a structured exception-handling architecture.
Catch all exceptions, log the details, and display a generic message.
In languages without exception support (e.g., C, PHP), diligently check all function return values for errors and handle them.

MODULE 3: SERVICE-LEVEL SOLUTIONS

1. Service Security Policy

Introduction:
A corporate security policy's main goal is to protect data by defining procedures, guidelines, and practices. With the rise of Service-Oriented Architecture (SOA), this
policy must be extended to secure assets exposed as services.
A. Core Principles of a Service Security Policy

Extended Scope: It is not limited to network requirements but also includes rules for the design and development of secure Web services.
Foundation: Typically, the service security policy is an extension of the existing corporate information security policy.

B. Threat Classification & Risk Assessment

The first step in creating an effective policy is to evaluate assets and identify threats.

Asset Valuation:
Quantitative(monetary) Value: Calculate the financial impact if the asset (data, network, system) is compromised.
Qualitative(Intrinsic) Value: Consider the impact on credibility, reputation, and stakeholder relationships after a security incident.
Threat Evaluation:
Consider both external and internal threats.
Classify services based on parameters like:
1. Classification of information the service manages.
2. Whether it's deployed on the Internet or an intranet.
3. The business criticality of the underlying host system.
4. Results from qualitative and quantitative risk assessments.
5. A risk probability and assessment matrix.
Policy Data Requirements:
The policy should specify requirements for items such as:
1. Transport-level security (SSL, VPNs).
2. Allowed communication protocols (HTTP, SMTP, SOAP, JMS).
3. Port numbers to be exposed for the firewall
4. Network-address translation or IP hiding requirements.
5. Single sign-on (SSO)
6. Authentication mechanisms (PKI, Kerberos, Username/Password).
7. Authorization schemes (SAML, custom).
8. Access control requirements
9. Message-level security and validation.
10. Trusted domains and certificate authorities.
11. Non-functional requirements (scalability, availability).

C. Balancing Security and Cost

Security is often seen as a "dead investment," leading to under-investment.

Conversely, some organizations over-invest in securing publicly available information.
Solution: Perform a risk assessment to weigh security costs against the level of exposure and potential risk.
Goal: Find the optimal balance between security expenditure and risk mitigation for proper resource allocation.

2. SOA Security Standards Stack

Introduction:
Web services security standards extend traditional mechanisms (encryption, digital signatures) to handle XML. The stack builds from basic network standards to complex
federated identity management.

Key Security Standards In-Depth

A. Inadequacy of SSL for Web Services
SSL refers to a session-layer protocol where a series of exchanges of digital keys happens between a client and a server, ending in a secure channel of
communication between the two ends, where messages are sent in encrypted form.
While scalable security algorithms like SSL is successful for web security, it is insufficient for Web services because:

Point-to-Point Only: SSL secures only a single hop, but Web services often involve multiple intermediaries (multi-hop), creating weak points.
Certificate Distribution: Distributing client-side SSL certificates to all potential service requesters is impractical.
No Non-Repudiation: SSL sessions are stateless and do not provide proof that a specific transaction occurred, which is critical for Web services.
No Multi-Party Support: SSL cannot establish secure sessions between more than two parties.

B. XML Signature
In Web services, sometimes it is necessary to partially encrypt only specific parts of a SOAP message to ensure secure transmission with authenticity and
integrity.

Purpose: Provides data integrity, authentication, and non-repudiation for XML documents and parts of SOAP messages.
Need: Standard digital signatures don't work well with multi-hop XML messages where different parties need to sign different [Link] mechanisms have been
provided in the XML Signature specification.
Key Features:
Allows multiple parties to sign different parts of an XML message.
XML Signature validation requires that the data object that was signed be [Link] XML Signature itself will generally indicate the location of the
original signed object
Supports various forms: enveloped (signature inside data), enveloping (data inside signature), or detached (external reference).
Requires Canonicalization (C14N) to convert XML to a standard byte-for-byte form before signing, ensuring structurally identical documents produce
identical signatures.
Canonicalization refers essentially to the process of conversion of any XMLdocument to its canonical form and is necessary for XML Signature
computation.

C. XML Encryption
XML Encryption provides end-to-end security for applications that require a secure exchange of data.

Purpose: Provides confidentiality for all or part of an XML message (or non-XML data).
Need: SSL cannot handle partial message encryption or multi-hop confidentiality.
Core requirements for XML Encryption are that it must be able to encrypt an arbitrarily sized XML message and it must do so efficiently.
Key Features:
Built on symmetric-key encryption for efficiency.
Enables persistent confidentiality - data remains encrypted even at rest
Can encrypt an entire XML document, a specific XML element, or just the content within a XML element.
XML Encryption can handle both XML and nonXML (e.g. binary) data.
XML Encryption is the best choice if the application requires a combination of secure and insecure communication
Use Case: Securing only the credit card details in an otherwise plaintext purchase order.

D. WS-Security (Web Services Security)

Purpose: The foundational standard for message-level security in SOAP messages.

key requirements of SOA security:loose coupling and [Link] coupling is enabled by separating the information about security from the actual body
content
Core Concept: Transmits security tokens (e.g., usernames, X.509 certificates, Kerberos tickets) within the SOAP header.
Salient Features:
1. Protects message integrity and confidentiality.
2. Associates security claims with the message.
3. Improves interoperability between other standards like SAML and XML Signature.
4. Supports multiple security tokens, trust domains, and encryption technologies.
 5. Leverages existing mechanisms (e.g., username/password, X.509).
6. It uses the header in SOAP to store the information.
Web-Services Security Model:

1. Service Policy:
A Web service specifies what claims (like identity, keys, permissions) a request must include. If these claims are missing, the service rejects the message.
2. Requester Proof:
The requester attaches security tokens to the message to prove the required claims and show they are allowed to make the request.
3. Getting Required Claims:
If the requester doesn’t have the needed claims, they can obtain them from Security Token Services (STSs), which issue tokens and help build trust between
different systems.

E. Security Tokens in WS-Security

Username Token: Used when a password is already shared between client and server.A digest (hash of password, nonce, timestamp) is sent to prevent replay
attacks.
Binary Security Token: For embedding X.509 certificates or Kerberos tickets. The message is signed with a private key to prove authenticity and prevent
[Link] server, the signature is verified by getting the decrypted hash back using the client’s public key and comparing it with the hash of data sent with the
message.
Security Token Reference: A reference to claims located elsewhere, avoiding the overhead of embedding large tokens.
One of the main drawbacks associated with WS-Security is its use of asymmetric cryptographic algorithms for encryption, which are computationally intensive

F. SAML (Security Assertions Markup Language)

Purpose: An XML-based framework for exchanging authentication and authorization information between different Web-access management and security
domains.
Security information can be expressed as an XML document and securely transmitted from one application to another.
Core Component: Assertions ..An assertion is a declaration of one or more facts (statements) about a subject(eg:user)
Three Types of Assertions:
1. Authentication Statement: Asserts that a user was authenticated at a certain time and in a certain way.
2. Attribute Statement: Asserts information about a user (e.g., role, department).
3. Authorization Decision Statement: Asserts whether a user is permitted to access a resource.

G. WS-Policy

Purpose: Proposed as a standard to capture generic policy requirements and general characteristics of entities in an XML Webservices-based [Link] work in
conjunction with WS-Security
Key Concepts:
Defines a policy to be a collection of policy alternatives, where each policy alternative is a collection of policy assertions
Does not specify how policies are discovered or attached to a Web service.
It works in conjunction with WS-Security to define what is required.

H. WS-Trust

Purpose: An extension to WS-Security that defines how to issue, renew, and validate security tokens across different trust domains.
its main functions are:

1. Brokering Trust Across Domains

It helps share and manage security credentials between systems that belong to different trust environments.
2. Managing Security Tokens
WS-Trust provides methods to issue, renew, and validate security tokens.
3. Building Trust Relationships
It defines ways for systems to check and establish trust with each other.
4. Flexible Security Support
 It supports different types of security protocols using a flexible framework.

Core Mechanism: Uses a Security Token Service (STS) as a broker that issues trusted security tokens in response to requests, enabling secure communication
between entities that don't inherently trust each other.

I. WS-Secure Conversation

Purpose: Builds on WS-Security and WS-Trust to manage secure, long-lived sessions (conversations) across multiple message exchanges.
Benefit: Establishes a security context and derives efficient session keys, improving performance and security for repeated interactions.

J. XKMS (XML Key Management Specification)

XKISS defines a protocol for resolving or validating public keys contained insigned and encrypted XML documents

Defines how an XKMS client (your application) talks to an XKMS server.

The XKMS server does all the PKI tasks like:
✔ Validating public keys
✔ Registering keys
✔ Recovering lost keys
✔ Revoking compromised keys
So the client does not need to implement complex PKI logic.
XKMS lets a server handle all public-key management tasks for XML security, making it easier for applications to use and trust public keys.

K. WS-Privacy & P3P (Platform for Privacy Preferences)

WS-Privacy and P3P

WS-Privacy explains how to include privacy rules inside Web service policies.
It works with WS-Security, which can attach privacy-related claims to messages (like what data is collected or how it is used).
WS-Privacy is being developed through P3P (Platform for Privacy Preferences), a project that helps websites express their privacy policies in a standard format.

What P3P Does:

P3P lets websites publish privacy preferences in a format that software (browsers, agents) can automatically understand.
A P3P user agent (like a browser extension) helps users:
See what data a site collects
Understand how the site uses the data
Make automatic decisions (accept, warn, block) based on user preferences
WS-Privacy embeds privacy rules into Web services, and P3P provides a standard, machine-readable way for websites to express how user data is collected and
used.

P3P specifications:

Standard data schema (what user data can be collected)

XML format for privacy policies
Mechanism to send policies over HTTP

4. Deployment Architectures for SOA Security

A. Message-Level Security & Policy Infrastructure

Goal: Create a loosely-coupled, scalable SOA security architecture.

 Design: Decouples security policies from business logic of system. Policies are managed centrally in Policy Decision Points (PDPs) and enforced at Policy
Enforcement Points (PEPs).
Advantage: The architecture is able to manage multiple existing mechanisms and integrate with existing identity stores (e.g., LDAP).

B. XML Firewalls-Operate at or above the application layer in the conventional TCP/IP stack.

Purpose: Protect against XML and Web service-specific attacks that traditional firewalls cannot detect (e.g., XML Injection, packet-filtering,malformed SOAP,
WSDL probing).
XML firewalls can be configured to perform authentication, authorization and auditing, and prevent the various Web-service attacks.
They are typically deployed behind the IP firewall, and control the message flow before it reaches the Web services
Operation: Inspect incoming/outgoing SOAP messages at the application layer before the messages pass on to an application or client.
Deployment Forms: Can be software proxies or hardware appliances (the latter offer higher performance).

XML Firewall Request Processing (Steps):

1. Parse Headers: Check source IP and requested resource.

2. Logging & IDS: Log request and send to intrusion detection systems.
3. SSL Check: Validate client certificates if using HTTPS.
4. Classify Request: Based on URL, IP, and SOAP headers.
5. Credential Check: Authenticate using various handlers (Username/Password, WS-Security token, Kerberos, SAML, SSO).
6. Message Validation: Check for well-formedness, schema conformance, message size (anti-DoS), and content (anti-injection attacks).
7. Security Processing: Decrypt content, validate XML signatures, and check for tampering.
8. Attachment Check: Scan SOAP attachments for viruses and size.
9. Routing & Auditing: Determine final destination, apply transformations, generate an audit trail, and route the message.

Deployment Scenarios:

1. Demilitarized Zone (DMZ) Scenario:

An XML Security Gateway is placed in a DMZ between two IP firewalls.
It acts as a gatekeeper, inspecting all XML/SOAP traffic before it reaches the protected internal network where the actual Web service resides.
Provides "defense-in-depth."
2. Federated Trust (B2B) Scenario:
Used for secure integration with business partners.
Each partner (service requester and provider) has its own XML gateway.
These gateways must be interoperable, often using SAML to federate identity and enable Single Sign-On (SSO) across organizational boundaries.
The security of the entire federated network is only as strong as its weakest link.