MOUNT ZION COLLEGE OF

ENGINEERING AND TECHNOLOGY

CCS374- WEB APPLICATION SECURITY

Unit I – FUNDAMENTALS OF WEB
APPLICATION SECURITY
THENMOZHI. P
AP/CSE
1.1 The history of Software Security & Recognizing
Web Application Security Threats
6
The history of Software Security
The history of software security, particularly in the
context of recognizing web application security threats, is
marked by the evolution of technology and the increasing
sophistication of cyber threats.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
7
The Origins of Hacking
In the past two decades, hackers have gained
more publicity and notoriety than ever before.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
8
Example: The Enigma Machine, Circa 1930
 The Enigma machine used electric-powered
mechanical rotors to both encrypt and decrypt text-
based messages sent over radio waves . The device had
German origins and would become an important
technological development during the Second World
War.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
9
Key Milestones and Developments in The History of
Web Application Security:
1.**1990s - The Emergence of the World Wide Web:**
- The World Wide Web became publicly accessible,
leading to the proliferation of websites and web
applications.
- The focus during this period was on building and
expanding the web, with limited attention to
security considerations.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
10
2. **Late 1990s to Early 2000s - Rise of
Common Vulnerabilities:**
- As web applications grew in complexity,
security vulnerabilities became more
apparent.
- Common vulnerabilities such as buffer
overflows, SQL injection, and cross-site
scripting (XSS) started to emerge.
- The concept of input validation gained attention
as a crucial aspect of web application security.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2
 1.1 The history of Software Security & Recognizing
Web Application Security Threats
11

3. **2002 - The Birth of OWASP:**

- The Open Web Application Security Project

(OWASP) was founded to provide resources and

guidelines for improving web application security.
- The OWASP Top Ten, a list of the most critical web

application security risks, was introduced to raise

awareness about common vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
12

4. **Mid-2000s - Proliferation of Web 2.0 and AJAX:**

- The advent of Web 2.0 technologies and the use
of Asynchronous JavaScript and XML (AJAX)
introduced new attack vectors.
- Security researchers and attackers began to
exploit vulnerabilities related to the dynamic and
interactive nature of these technologies.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
13

5. **Late 2000s - Increased Focus on Secure

Development Practices:**
- Organizations started recognizing the
importance of integrating security into the
software development life cycle.
- Secure coding practices and tools became more
prevalent, emphasizing the need to consider
security from the design phase onward.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
14

6. **2010s - Evolution of Threat Landscape:**

- The threat landscape continued to evolve with
the rise of mobile applications, cloud
computing, and APIs.
- Web security standards like HTTP Strict Transport
Security (HSTS) and Content Security Policy (CSP)
gained adoption to enhance protection against
various attacks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
15
7. **2017 - OWASP Top 10 Update:**
- OWASP updated its Top 10 list to reflect
contemporary web application security risks,
including issues like insufficient logging and
monitoring and XML external entity (XXE)
vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
16

8.**2020s - Emphasis on DevSecOps and Automation:**

- The integration of security into DevOps
processes (DevSecOps) gained momentum,
emphasizing collaboration between
development, operations, and security teams.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

1.1 The history of Software Security & Recognizing
Web Application Security Threats
17

9.**Present - Ongoing Challenges and Innovations:**

- Innovations such as artificial intelligence and
machine learning are being employed to
enhance threat detection and response
capabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
18

Definition of Web Application Security:

 Web application security refers to the set of measures
and practices designed to protect web applications from
various cyber threats, vulnerabilities, and unauthorized
access.
 With the increasing reliance on web-based
technologies for business operations, e-commerce, and
communication, ensuring the security of web
applications is crucial to safeguard sensitive data and
maintain the integrity and availability of online services.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2
 1.2 Web Application Security
19

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
20
Types of Web Application Security:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
21
Types of Web Application Security:
1. Network Security:
Focuses on securing the communication channels
between users and web applications. This includes
encryption protocols (HTTPS), firewalls, and intrusion
detection/prevention systems.
2. Authentication and Authorization:
Ensures that users are who they claim to be
(authentication) and that they have the appropriate
permissions to access specific resources or perform
certain actions (authorization).
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2
 1.2 Web Application Security
22

3. Data Validation and Input Sanitization:

-Involves validating and sanitizing user inputs to
prevent injection attacks, such as SQL injection
and cross-site scripting (XSS).
4. Security Misconfigurations:
- Addresses issues related to improperly configured
security settings, server settings, or access
controls that could expose vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
23

5. Cross-Site Request Forgery (CSRF) Protection:

- Mitigates the risk of attackers tricking users into
performing unintended actions on a web
application where they are authenticated.
6. File Upload Security:
- Focuses on securing mechanisms that allow users
to upload files to prevent the execution of
malicious code or the upload of harmful files.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
24

7. Security Headers:
- Involves the implementation of HTTP security
headers, such as HTTP Strict Transport Security
(HSTS) and Content Security Policy (CSP), to control
how browsers handle content.
8. Web Application Firewalls (WAF):
- Adds an additional layer of protection by filtering
and monitoring HTTP traffic between a web
application and the internet to detect and block
potential threats.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2
 1.2 Web Application Security
25
Pros of Web Application Security:
1.Data Protection:
Ensures the confidentiality and integrity of
sensitive data processed by web applications.
2. User Trust:
Building and maintaining trust among users by
providing a secure online experience, protecting their
personal information.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
26
Pros of Web Application Security:
3. Business Continuity:
Mitigates the risk of disruptions caused by security
incidents, ensuring continuous availability and
functionality of web applications.
4. Regulatory Compliance:
Helps organizations comply with data protection
and privacy regulations by implementing necessary
security measures.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
27
Pros of Web Application Security:
5. Cost Savings:
Proactively addressing security issues during
development can save costs compared to dealing with
breaches and their consequences.
6. Brand Reputation:
Protects the reputation of the organization by
preventing data breaches and security incidents that
could damage public perception.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
28
Cons of Web Application Security:
1.Resource Intensive:
Implementing and maintaining robust web application
security measures can be resource-intensive, requiring
time, expertise, and financial investment.
2. Usability Challenges:
Stringent security measures may sometimes
impact user experience and require a careful balance
between security and usability.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
29
Cons of Web Application Security:
3. Complexity:
Web application security can be complex due to the
dynamic and evolving nature of cyber threats, requiring
continuous monitoring and adaptation.
4. False Positives:
Security measures, such as WAFs, may generate false
positives, potentially blocking legitimate traffic and
causing inconvenience to users.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
30
Cons of Web Application Security:
5. Resistance to Change:
Introducing security measures may face
resistance from developers or users to less secure
but more convenient practices.
6. Ongoing Vigilance:
Cyber threats evolve over time, requiring constant
vigilance and updates to security measures to address
new vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.2 Web Application Security
31
Common Web Application Security Threats
• Insecure Design
• SQL Injection
• Faulty Access Control
• Authorization Failure
• Security Misconfiguration
• Outdated Components
• Security Logging and Monitoring Failures

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.1 & 1.2

 1.3 Authentication and Authorization
6

Authentication Vs Authorization:
Authentication and authorization are fundamental
components of web application security, ensuring that
users access only the resources and functionalities they
are allowed to.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.3 Authentication and Authorization
7

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.3 Authentication and Authorization
8
Authentication: Definition
Authentication is the process of verifying the
identity of a user, system, or application. In the context
of web applications, it involves confirming that the user
is who they claim to be.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.3 Authentication and Authorization

Authentication: Key Elements:9

1.Credentials:
Users typically provide credentials such as
usernames and passwords, though other factors like
biometrics, smart cards, or two-factor authentication can be
used for stronger authentication.
2. Authentication Factors:
- Something You Know: Passwords, PINs.
- Something You Have: Smart cards, security tokens.
- Something You Are: Biometrics like fingerprints, retina
scans.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3
 1.3 Authentication and Authorization
10
Authentication Methods:
Single-Factor Authentication (SFA):
-Relies on one authentication factor (e.g., password
only).
Multi-Factor Authentication (MFA):
- Multi-factor authentication involves using two or more
authentication methods.(password and biometric
information)

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.3 Authentication and Authorization
Authentication: Best Practices11
Strong Password Policies:
Encourage users to create complex passwords and
update them regularly.
Multi-Factor Authentication:
Implement MFA method provides an additional layer
of security, making it more difficult for unauthorized
users to gain access.
Secure Transmission:
Ensure that authentication credentials are transmitted
securely over encrypted connections (e.g., HTTPS).
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3
 1.3 Authentication and Authorization
12
 Authorization: Definition
Authorization is the process of granting or denying
access to specific resources, functionalities, or data based
on the authenticated user's permissions.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.3 Authentication and Authorization
13
Authorization: Key Elements
Roles and Permissions:
Users are assigned roles, and each role has specific
permissions defining what actions or data the user can
access.
Access Control Lists (ACLs):
An ACL contains rules that grant or deny access to
certain digital environments. There are two types of ACLs:
• Filesystem ACLs ━ filter access to files and/or directories
• Networking ACLs ━ filter access to the network.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.3 Authentication and Authorization
14
Authorization Models:
Role-Based Access Control (RBAC):
- Users are assigned roles, and roles are associated
with specific permissions.
Attribute-Based Access Control (ABAC):
- Access decisions are based on attributes of the user,
the resource, and the environment.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.3 Authentication and Authorization
15
Best Practices: Authorization
Principle of Least Privilege (PoLP)
- Users should have the minimum level of access

necessary to perform their job functions.

Regular Access Reviews:
- Periodically review and update user roles and

permissions to ensure they align with current

requirements.
Fine-Grained Authorization:
- Implement granular controls, specifying permissions at a

detailed level rather than granting broad access.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3
 1.3 Authentication and Authorization
16
Authentication and Authorization Workflow:
Authentication:
- User provides credentials.

- Credentials are verified against stored credentials

(e.g., in a database).
- If credentials are valid, the user is authenticated.

Authorization:
- Authenticated user's permissions are checked.

- Access is granted or denied based on the user's

permissions.
- Users can access only the resources and perform only

the actions permitted by their role and permissions.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3
 1.3 Authentication and Authorization
17
Authentication and Authorization Workflow:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.3 Authentication and Authorization
18
Challenges and Considerations:
Session Management:
- Securely manage user sessions to prevent unauthorized

access or session hijacking.

Token Security:
- If using tokens for authentication, ensure they are

securely generated, transmitted, and validated.

User Provisioning and Deprovisioning:
- Implement effective processes for adding, updating, and

removing user accounts to ensure accurate access control.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.4 Secure Socket layer
6

Secure Socket Layer (SSL)

• Secure Socket Layer provides security to the data that is

transferred between web browser and server.

• SSL encrypts the link between a web server and a

browser which ensures that all data passed between

them remain private and free from attack.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
7

Secure Socket Layer Protocols:

 SSL record protocol

 Handshake protocol
 Change-cipher spec protocol

 Alert protocol

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
8
SSL Record Protocol:
 SSL Record provides two services to SSL connection.
 Confidentiality
 Message Integrity

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
9
SSL Record Protocol:
 In the SSL Record Protocol application data is divided
into fragments.
 The fragment is compressed and then encrypted MAC
(Message Authentication Code) generated by algorithms
like SHA (Secure Hash Protocol) and MD5 (Message
Digest) is appended.
 After that encryption of the data is done and in last SSL
header is appended to the data.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
10
Handshake Protocol:
Handshake Protocol is used to establish sessions.
This protocol allows the client and server to authenticate
each other by sending a series of messages to each
other.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
11
Handshake Protocol:
Handshake protocol uses four phases to complete
its cycle.
 Phase-1: In Phase-1 both Client and Server send hello-
packets to each other. In this IP session, cipher suite
and protocol version are exchanged for security
purposes.
 Phase-2: Server sends his certificate and Server-key-
exchange. The server end phase-2 by sending the
Server-hello-end packet.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
12
 Handshake Protocol:
 Phase-3: In this phase, Client replies to the server by
sending his certificate and Client-exchange-key.
 Phase-4: In Phase-4 Change-cipher suite occurs and
after this the Handshake Protocol ends.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
13
Change-cipher Protocol:
Change-cipher protocol consists of a single
message which is 1 byte in length and can have only one
value. This protocol’s purpose is to cause the pending
state to be copied into the current state.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
14
Alert protocol:
 This protocol is used to convey SSL-related alerts to the
peer entity.
 Each message in this protocol contains 2 bytes.

 The level is further classified into two parts:

 Warning (level = 1)
 Fatal Error (level = 2)

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
15

Warning (level = 1):

This Alert has no impact on the connection
between sender and receiver.
 Bad certificate: When the received certificate is corrupt.

 No certificate: When an appropriate certificate is not

available.
 Certificate expired: When a certificate has expired.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
16
Warning (level = 1):
 Certificate unknown: When some other unspecified
issue arose in processing the certificate, rendering it
unacceptable.
 Close notify: It notifies that the sender will no longer
send any messages in the connection.
 Unsupported certificate: The type of certificate received
is not supported.
 Certificate revoked: The certificate received is in
revocation list.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
17
Fatal Error (level = 2):
This Alert breaks the connection between sender
and receiver. The connection will be stopped, cannot be
resumed but can be restarted. Some of them are :
 Handshake failure: When the sender is unable to
negotiate an acceptable set of security parameters given
the options available.
 Decompression failure: When the decompression
function receives improper input.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
18
Fatal Error (level = 2):
 Illegal parameters: When a field is out of range or
inconsistent with other fields.
 Bad record MAC: When an incorrect MAC was
received.
 Unexpected message: When an inappropriate
message is received. The second byte in the Alert
protocol describes the error.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
19

Features of Secure Socket Layer:

 The advantage of this approach is that the service can
be tailored to the specific needs of the given
application.
 Secure Socket Layer was originated by Netscape.
 SSL is designed to make use of TCP to provide reliable
end-to-end secure service.
 This is a two-layered protocol

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
20

Versions of SSL:
 SSL 1 – Never released due to high
insecurity.
 SSL 2 – Released in 1995.
 SSL 3 – Released in 1996.
 TLS 1.0 – Released in 1999.
 TLS 1.1 – Released in 2006.
 TLS 1.2 – Released in 2008.
 TLS 1.3 – Released in 2018.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
21

SSL Certificate
 SSL (Secure Sockets Layer) certificate is a digital
certificate used to secure and verify the identity of a
website or an online service.
 The certificate is issued by a trusted third-party called a
Certificate Authority (CA), who verifies the identity of the
website or service before issuing the certificate.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
22

The SSL certificate characteristics (make it a reliable

solution for securing online transactions):
1. Encryption: The SSL certificate uses encryption

algorithms to secure the communication between

the website or service and its users.
2. Authentication: This provides assurance to users

that their information is being transmitted to a

trusted entity.
3. Integrity: This ensures that the data being
transmitted is not modified in any way, preserving
its integrity.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4
 1.4 Secure Socket layer
23

The SSL certificate characteristics

4.Non-repudiation: SSL certificates provide non-
repudiation of data, meaning that the recipient of
the data cannot deny having received it.
5.Public-key cryptography: SSL certificates use
public-key cryptography for secure key exchange
between the client and server.
6.Session management: SSL certificates allow for
the management of secure sessions.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.4 Secure Socket layer
24

HTTP VS HTTPS

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.4

 1.5 Transport layer Security
6

1.5 Transport layer Security

 Transport Layer Securities (TLS) are designed to
provide security at the transport layer.
 TLS was derived from a security protocol called Secure
Socket Layer (SSL).
 TLS ensures that no third party may eavesdrop or
tampers with any message.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
7

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
8

Benefits of TLS:
Encryption:
 TLS/SSL can help to secure transmitted data using
encryption.

Interoperability:
 TLS/SSL works with most web browsers, including
Microsoft Internet Explorer and on most
operating systems and web servers.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
9

There are several benefits of TLS:

Algorithm flexibility:
 TLS/SSL provides operations for authentication
mechanism, encryption algorithms and hashing
algorithm that are used during the secure session.
Ease of Deployment:
 Many applications TLS/SSL temporarily on a
windows server 2003 operating systems.
Ease of Use:
 Because we implement TLS/SSL beneath the
application layer, most of its operations are
completely invisible to client.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3
 1.5 Transport layer Security
10
Working of TLS:
 The client connect to server (using TCP), the client will
be something. The client sends number of specification:
1. Version of SSL/TLS.

2. which cipher suites, compression method it wants to

use.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
11

TLS client and server to communicate with each other:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
12
 Transport Layer Security (TLS) is a cryptographic
protocol designed to provide secure communication
over a computer network.
 TLS is the successor to Secure Sockets Layer (SSL), and
it is commonly used to secure data transmission on the
internet, particularly in web applications.
 TLS ensures the confidentiality, integrity, and
authenticity of the data exchanged between a client
(typically a web browser) and a server.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
13
Key aspects of TLS in web application security:
1. Encryption:
- Purpose: TLS encrypts data during transmission,
ensuring that even if intercepted, the data remains
confidential.
- Symmetric and Asymmetric Encryption: TLS uses a
combination of symmetric and asymmetric
encryption. Symmetric encryption is used for bulk
data transfer, while asymmetric encryption is used
for key exchange and authentication.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5
 1.5 Transport layer Security
14
2. Authentication:
- Purpose: TLS provides a mechanism for both the
client and the server to authenticate each other,
ensuring that they are communicating with the
intended and legitimate parties.
- Digital Certificates: TLS relies on digital certificates
to verify the identity of the server (and optionally,
the client). Certificates are issued by Certificate
Authorities (CAs) and contain information such as
the public key and details about the entity's identity.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5
 1.5 Transport layer Security
15
3. Data Integrity:
- Purpose: TLS ensures that the data transmitted
between the client and the server has not been
tampered with during transmission.
- Hash Functions: Cryptographic hash functions are
used to generate checksums (hashes) for the
transmitted data. The recipient can verify the
integrity of the data by comparing the received hash
with the calculated hash.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
16
4. Secure Handshake:
- Purpose: Before establishing a secure connection, the
client and server perform a handshake to negotiate
the encryption algorithms, exchange necessary
parameters, and authenticate each other.
- Key Exchange: During the handshake, a process
called key exchange occurs, where the client and
server agree on a shared secret key for encrypting
and decrypting data.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
17
5. Forward Secrecy:
- Purpose: TLS supports Perfect Forward Secrecy (PFS),
ensuring that even if a long-term secret key is
compromised, past communication cannot be
decrypted.
- Key Agreement Protocols: PFS is typically
achieved using key agreement protocols like
Diffie-Hellman.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.5 Transport layer Security
18
6. Versions:
- Evolution: TLS has undergone several versions, with
each version addressing security vulnerabilities and
improving cryptographic mechanisms.
- Current Versions: As of my last knowledge update in
January 2022, TLS 1.3 is the latest version, offering
improved security and performance compared to
earlier versions.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
19
8. **TLS in HTTPS:**
- **Implementation:** In web applications, TLS is
commonly implemented through HTTPS (HTTP Secure).
This ensures that the communication between the
client and the server occurs over a secure, encrypted
connection.
- **URL Prefix:** URLs using HTTPS start with
"https://" instead of "http://".

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.5 Transport layer Security
20

8. **TLS in HTTPS:**
- **Implementation:** In web applications, TLS is
commonly implemented through HTTPS (HTTP
Secure). This ensures that the communication
between the client and the server occurs over a
secure, encrypted connection.
- **URL Prefix:** URLs using HTTPS start with
"https://" instead of "http://".

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.3

 1.5 Transport layer Security
21
 TLS is a critical component of web application
security, providing a secure foundation for the
transmission of sensitive data.
 As cyber threats evolve, it's essential to stay
informed about the latest TLS versions,
vulnerabilities, and best practices to ensure the
continued security of web applications

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.5

 1.6 Session Management-Input Validation

Session Management in Web Application Security:

 Session management is a crucial aspect of web
application security that involves the creation,
maintenance, and termination of user sessions.
 A session is a period of interaction between a user
and a web application, typically starting when a user
logs in and ending when they log out or their session
becomes inactive.
 Proper session management is essential for protecting
user data and preventing unauthorized access.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

Session Management in Web Application Security:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

Key considerations :
 Session ID Security:
 Use secure methods for generating and transmitting
session IDs, ensuring they cannot be easily guessed
or intercepted.
 Implement secure random number generators for
creating session IDs.
 Avoid exposing session IDs in URLs, as they can be
more easily compromised.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

 Session Timeout:
 Define reasonable session timeout values to
automatically log out users after a period of inactivity.
 Notify users before sessions expire to allow them to
extend their session if needed.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

 Session Fixation:
 Implement measures to prevent session fixation
attacks where an attacker sets a user's session ID
to a known value.
 Generate a new session ID upon login or after
certain privileged operations.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

 Secure Cookie Attributes:

 Set secure attributes for session cookies, such as the
'Secure' attribute to ensure they are transmitted only
over secure (HTTPS) connections.
 Use the 'HttpOnly' attribute to prevent client-side
script access to cookies.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

 Logout Functionality:
 Provide a secure logout mechanism that effectively
terminates a user's session.
 Invalidate session data on the server side upon
logout.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

 Session Revocation:
 Enable administrators to revoke sessions in the case
of suspicious activity or a compromised account.
 Implement mechanisms to force a re-authentication
after certain sensitive operations.
 Session Data Protection:
 Avoid storing sensitive information in session
variables whenever possible.
 Encrypt session data if it needs to be stored on the
server.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6
 1.6 Session Management-Input Validation

 Cross-Site Request Forgery (CSRF) Protection:

 Implement anti-CSRF tokens to protect against CSRF
attacks, where an attacker forces a user to perform
unintended actions without their consent.
 IP Address Checking:
 Optionally, consider associating sessions with specific
IP addresses to prevent session hijacking.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

 Cross-Site Request Forgery (CSRF) Protection:

 Implement anti-CSRF tokens to protect against CSRF
attacks, where an attacker forces a user to perform
unintended actions without their consent.
 IP Address Checking:
 Optionally, consider associating sessions with specific
IP addresses to prevent session hijacking.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

 Input Validation in Web Application Security:

 Input validation is a critical component of web
application security that involves checking user inputs
for correctness, security, and adherence to
predefined criteria.
 Proper input validation helps prevent a range of
vulnerabilities, including injection attacks and cross-
site scripting.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation
 Input validation: Types
 Whitelist

 Blacklist.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

Whitelist
Whitelisting only allows data which is present on a
pre approved list to be entered into the application, all
other input that is not on the list is not accepted.
Blacklist
 Blacklisting is the reverse of whitelisting, and depends
on programmers predicting all unexpected dangerous
input data.
 Typically blacklisting is more error prone, as a single
mistake could be made more easily with blacklisting
which attackers could potentially identify with
enumeration.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6
 1.6 Session Management-Input Validation

Whitelist

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

Blacklist

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

Key considerations :
 Data Type Validation:
 Ensure that input conforms to the expected data type
(e.g., numbers, dates) to prevent unexpected
behavior or security issues.
 Length and Size Checks:
 Validate that input lengths are within acceptable
ranges to prevent buffer overflows and other related
vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

Whitelisting Input:
 Define and enforce a whitelist of allowed characters,
rejecting input that includes disallowed or special
characters.
 Avoid using blacklists, as they can be less effective and
prone to evasion.
Regular Expressions:
 Use regular expressions to define and enforce patterns
for valid input.
 Be cautious with complex regular expressions to avoid
security issues like denial-of-service (DoS) attacks.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6
 1.6 Session Management-Input Validation

 HTML Entity Encoding:

 Encode user input to prevent cross-site scripting
(XSS) attacks. Convert special characters to their
HTML entity equivalents.
 Parameterized Queries:
 When dealing with databases, use parameterized
queries or prepared statements to prevent SQL
injection attacks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

 File Upload Validation:

 Ifyour application allows file uploads, implement
strict validation on file types, size, and content to
prevent malicious file uploads.
 Client-Side Validation:
Implement client-side validation for a smoother
user experience, but always validate inputs on the server
side as well to ensure security.
 Do not rely solely on client-side validation for
security.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 1.6 Session Management-Input Validation

 Error Handling:
 Customize error messages to avoid revealing too
much information about the system or underlying
infrastructure.
 Provide generic error messages to users and log
detailed errors for administrators.
 Security Headers:
 Use security headers, such as Content Security Policy
(CSP), to mitigate the risk of certain types of injection
attacks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 1/1.6

 MOUNT ZION COLLEGE OF
ENGINEERING AND TECHNOLOGY

CCS374- WEB APPLICATION SECURITY

UNIT II: SECURE DEVELOPMENT AND
DEPLOYMENT
YEAR/SEM:III/VI THENMOZHI. P
DEPT:CSE AP/CSE
 2.1Web Applications Security :Security
Testing
6

Web Applications Security:

 Securing web applications is a critical aspect of
software development and deployment.
 The goal is to protect the application and its users from
various security threats and vulnerabilities.
 Here are key practices for secure development and
deployment of web applications:
 Secure Development Practices
 Secure Deployment Practices

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
7

Secure Development Practices

1.Input Validation:
•Validate and sanitize all user inputs to prevent injection
attacks (e.g., SQL injection, cross-site scripting).
•Use parameterized queries to prevent SQL injection.
2.Authentication and Authorization:
•Implement strong authentication mechanisms, including
multi-factor authentication when possible.
•Follow the principle of least privilege for user
permissions.
•Regularly review and update access controls.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1
 2.1Web Applications Security :Security
Testing
8

3.Session Management:
•Use secure and random session IDs.
•Implement session timeout and reauthentication for
sensitive actions.
•Store session data securely, preferably on the server
side.
4.Cross-Site Request Forgery (CSRF) Protection:
•Include anti-CSRF tokens in forms.
•Ensure that state-changing requests require proper
authentication.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
9
5.Cross-Origin Resource Sharing (CORS):
•Implement proper CORS policies to control which domains
can access resources.
•Avoid overly permissive CORS configurations.
6.Security Headers:
•Utilize security headers like Content Security Policy (CSP),
Strict- Transport-Security (HSTS), and X-Content-Type-
Options.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
10

7.Error Handling:
•Provide custom error pages to avoid leaking sensitive
information.
•Log errors securely without exposing sensitive data.
8.Code Reviews and Static Analysis:
•Regularly conduct code reviews to identify security
vulnerabilities.
•Use static analysis tools to scan code for potential security
issues.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
11

9.Dependency Management:
•Keep all dependencies up-to-date to patch known
vulnerabilities.
•Use a secure package manager and regularly audit
dependencies.
10.File Upload Security:
•Validate file types and enforce size limits.
•Store uploaded files in a secure location outside the web
root.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
12

Secure Deployment Practices

1.Web Application Firewall (WAF):
•Deploy a WAF to filter and monitor HTTP traffic
between a web application and the Internet.
•Configure the WAF to protect against common web
application attacks.
2.HTTPS:
•Enforce the use of HTTPS to encrypt data in transit.
•Use strong, up-to-date encryption protocols and
ciphers.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
13

3.Secure Configuration:
•Disable unnecessary services and features.
•Follow security best practices for server and database
configurations.
4.Continuous Monitoring:
•Implement monitoring solutions to detect and respond
to security incidents.
•Regularly review logs for suspicious activities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
14

5.Incident Response Plan:

•Develop and document an incident response plan.
•Test the plan regularly to ensure a swift and effective
response.
6.Data Backups:
•Regularly backup data and ensure the backups are
secure.
•Test data restoration procedures to guarantee
recoverability.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1
 2.1Web Applications Security :Security
Testing
15

7.Environment Isolation:
•Isolate production, development, and testing
environments.
•Limit access to production systems to only authorized
personnel.
8.Regular Security Audits:
•Conduct regular security audits and penetration testing.
•Address and remediate any vulnerabilities discovered
during audits.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1
 2.1Web Applications Security :Security
Testing
16

9.Security Training:
•Provide security awareness training for development
and operations teams.
•Keep teams informed about the latest security threats
and best practices.
10.Compliance:
•Ensure compliance with relevant security standards and
regulations (e.g., GDPR, HIPAA).

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
17

Security Testing:
 Security testing is an important aspect of software
testing focused on identifying and addressing security
vulnerabilities in a web application.
 It aims to ensure that the software is secure from
malicious attacks, unauthorized access, and data
breaches.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
18

Security Testing:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
19

1.Penetration Testing:
•Purpose: To identify vulnerabilities and weaknesses in
the application or network.
•Method: Ethical hackers simulate real-world attacks to
uncover security issues.
•Frequency: Conduct regular penetration tests, especially
after major updates or changes.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
20

2.Code Review:
 Purpose: Identifying security vulnerabilities in the
source code.
 Method: Manual or automated review of the
application's source code.
 Frequency: Regularly integrate code reviews into the
development process.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
21

3.Vulnerability Scanning:
Purpose: Automated tools scan systems for known
vulnerabilities.
Method: Regularly scan networks, applications, and
systems for known security issues.
Frequency: Implement continuous scanning to detect and
address vulnerabilities promptly.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
22

4.Security Audits:
•Purpose: Comprehensive review of security policies,
configurations, and practices.
•Method: Evaluate all aspects of security, including
physical security, policies, and procedures.
•Frequency: Conduct periodic security audits to ensure
ongoing compliance and effectiveness.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.1Web Applications Security :Security
Testing
23

5.Security Automation:
• Purpose: Automating security tests and checks.

• Method: Use tools for automated security testing, such

as static analysis tools, dynamic analysis tools, and
security scanning tools.
• Frequency:Integrate automation into the development
and testing pipeline.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.1

 2.2 Security Incident Response Planning
6

Security Incident Response Plan (SIRP)

A SIRP is a comprehensive set of guidelines and
procedures developed by an organization to effectively
detect, respond to, and recover from security incidents.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.2 Security Incident Response Planning
7

Incident Response Phases:

Preparation:
• Objective: Define the objectives and scope of the
incident response plan.
• Measures taken to prepare for potential incidents.

• Training and awareness programs.

• Components:
• Risk Assessment

• Policy Development

• Team Formation
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3
 2.2 Security Incident Response Planning
8

Detection and analysis Phase:

• Objective: Detect and classify security incidents.
• Components:
• Incident Detection

• Classification

• Identification

• Procedures for recognizing and confirming

incidents.
• Initial assessment of the incident.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.2 Security Incident Response Planning
9
Containment and Eradication:
• Objective: Contain and eliminate the security incident.
• Components:
• Containment

• Eradication

• Containment:
• Steps to prevent further damage and limit the
incident's impact.
• Isolation of affected systems.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.2 Security Incident Response Planning
10
Containment and Eradication:
• Eradication:
• Procedures for completely removing the threat from
the environment.
• Elimination of vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.2 Security Incident Response Planning
11

Recovery Phase:
• Objective: Recover affected systems and services.
• Steps to restore systems to normal operation.

• Verification of system integrity.

• Components:
• Recovery Planning

• System Restoration

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle (SDL)
12
Microsoft Security Development Lifecycle
 The Microsoft Security Development Lifecycle (SDL) is a
set of software development practices that Microsoft
uses to improve the security of its software and services.
 It is designed to help developers build more secure
software from the ground up.
 The SDL encompasses various stages, each emphasizing
security considerations.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

2.3 The Microsoft Security Development
Lifecycle (SDL)
13

Microsoft's SDL key phases:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle (SDL)
14

Pre-SDL Requirements: Security Training

Assess organizational knowledge on security and

privacy – establish training program as necessary

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle (SDL)
15

• Establish training criteria

– Content covering secure design, development, test
and privacy
• Establish minimum training frequency
– Employees must attend n classes per year

• Establish minimum acceptable group training

thresholds
– Organizational training targets (e.g. 80% of all
technical personnel trained prior to product RTM)

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle (SDL)
16

Phase One: Requirements

Opportunity to consider security at the outset of a

project
• Development team identifies security and privacy
requirements
• Development team identifies lead security and privacy
contacts
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3
 2.3 The Microsoft Security Development
Lifecycle (SDL)
17

• Security Advisor assigned

• Security Advisor reviews product plan, makes
recommendations, may set additional requirements
• Mandate the use of a bug tracking/job assignment
system
• Define and document security and privacy bug bars

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security
Development Lifecycle (SDL)
18
Phase Two: Design
Implementation Verification Release Response

Define and document security architecture, identify

security critical components
• Identify design techniques (layering, managed code,
least privilege, attack surface minimization)
• Document attack surface and limit through default
settings

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security
Development Lifecycle (SDL)
19

• Define supplemental security ship criteria due to

unique product issues
– Cross-site scripting tests
– Deprecation of weak crypto

• Threat Modeling
– Systematic review of features and product
architecture from a security point of view
– Identify threats and mitigations

• Online services specific requirements

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle
20
(SDL)
Phase Three: Implementation
Verification Release Response

Full spectrum review – used to determine

processes, documentation and tools necessary to
ensure secure deployment and operation

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle (SDL)
21

• Specification of approved build tools and options

• Static analysis (PREFix, /analyze (PREfast), FXCop)
• Banned APIs
• Use of operating system “defense in depth”
protections (NX, ASLR and HeapTermination)
• Online services specific requirements (e.g., Cross-
site scripting , SQL Injection etc)
• Consider other recommendations (e.g., Standard
Annotation Language (SAL))

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security
Development Lifecycle
22
(SDL)
Phase Four: Verification
Release Response

Started as early as possible – conducted after “code

complete” stage
• Start security response planning – including
response plans for vulnerability reports
• Re-evaluate attack surface

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle
23 (SDL)

• Fuzz testing – files, installable controls and network

facing code
• Conduct “security push” (as necessary, increasingly rare)
–Not a substitute for security work done during
development
–Code review
–Penetration testing and other security testing
–Review design and architecture in light of new threats
• Online services specific requirements

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle (SDL) 24

Phase Five: Release – Response Plan

Response

Creation of a clearly defined support policy –

consistent with MS corporate policies

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle
25 (SDL)

• Provide Software Security Incident Response Plan

(SSIRP)
– Identify contacts for MSRC and resources to respond
to events
– 24x7x365 contact information for 3-5 engineering, 3-
5 marketing, and 1-2 management (PUM and higher)
individuals
• Ensure ability to service all code including “out of band”
releases and all licensed 3rd party code.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security
Development Lifecycle (SDL)
26

Response

Verify SDL requirements are met and there

are no known security vulnerabilities
• Provides an independent view into “security ship
readiness”

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle
27 (SDL)

• The FSR is NOT:

– A penetration test – no “penetrate and patch”
allowed
– The first time security is reviewed
– A signoff process
– Key Concept: The tasks for this phase are used as a
determining factor on whether or not to ship – not
used as a “catchall” phase for missed work in earlier
phases

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.3 The Microsoft Security Development
Lifecycle (SDL) 28

Phase Five: Release – Archive

Response

Security response plan complete

• Customer documentation up-to-date
• Archive RTM source code, symbols, threat models
to a central location
• Complete final signoffs on Checkpoint Express –
validating security, privacy and corporate
compliance policies
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3
2.3 The Microsoft Security Development Lifecycle
(SDL)
29

Post-SDL Requirement: Response

“Plan the work, work the plan…”

• Execution on response tasks outlined during
Security Response Planning and Release Phases

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.2 & 2.3

 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
6

What is CLASP?
 Comprehensive, Lightweight, Application Security
Process
 OWASP project
 “Activity driven, role-based set of process components
whose core contains formalized best practices for
building security into your existing or new-start
software development life cycles in a structured,
repeatable, and measurable way”

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
7

What is CLASP?
 Method for applying security to an organization's
application development process
 Adaptable to any organization or development process
 OWASP CLASP is intended to be a complete solution
that organizations can read and then implement
iteratively
 Focuses on leveraging a database of knowledge (CLASP
vulnerability lexicon, security services, security
principles, etc) and automated tools/processes
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
8
CLASP Best Practices
 Institute security awareness programs
 Provide security training to stakeholders
 Present organization's security policies, standards,
and secure coding guidelines
 Perform application assessments
 Is a central component in overall strategy
 Find issues missed by implemented “Security
Activities”
 Leverage to build a business case for implementing
CLASP
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
9
CLASP Best Practices
 Capture security requirements
 Specify security requirements along side
business/application requirements
 Implement secure development process
 Include “Security Activities”, guidelines, resources,
and continuous reinforcement
 Build vulnerability remediation procedures
 Define steps to identify, assess, prioritize, and
remediate vulnerabilities

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
10
CLASP Best Practices
 Define and monitor metrics
 Determine overall security posture
 Assess CLASP implementation progress
 Publish operational security guidelines
 Monitor and manage security of running systems
 Provide advice and guidance regarding security
requirements to end-users and operational staff

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
11
 CLASP ORGANIZATION:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
12

Concepts View – CLASP Security Services

 Fundamental security goals that must be satisfied for
each resource:
 Authorization (access control)‫‏‬
 Authentication
 Confidentiality
 Data Integrity
 Availability
 Accountability
 Non-Repudiation
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.4 OWASP Comprehensive Lightweight Application
Security Process (CLASP)
13
Role-Based View - Introduction
 CLASP ties “Security Activities” to roles rather than
development process steps
 Roles:
 Project Manager
Drives the CLASP initiative
 Requirements Specifier
 Architect
 Designer
 Implementer
 Test Analyst
 Security Auditor
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
14

Role-Based View – Project Manager

 Drives CLASP initiative
 Management buy-in mandatory
 Security rarely shows up as a feature
 Responsibilities:
 Promote security awareness within team
 Promote security awareness outside team
 Manage metrics
Hold team accountable
Assess overall security posture (application and
organization)‫‏‬

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight Application
Security Process (CLASP)
15
Role-Based View – Requirements Specifier
 Generally maps customer features to business
requirements
 Customers often don't specify security as a requirement
 Responsibilities:
 Detail security relevant business requirements
 Determine protection requirements for resources
(following an architecture design)‫‏‬
 Attempt to reuse security requirements across
organization
 Specify misuse cases demonstrating major security
concerns
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
16
Role-Based View – Architect
 Creates a network and application architecture
 Specify network security requirements such as firewall,
VPNs, etc.
 Responsibilities:
 Enumerate all resources in use by the system
 Identify roles in the system that will use each resource
 Identify basic operations on each resource
 Help others understand how resources will interact
with each other.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight Application
Security Process (CLASP)
17
Role-Based View – Designer
 Keep security risks out of the application
 Have the most security-relevant work
 Responsibilities:
 Choose and research the technologies that will satisfy
security requirements
 Assess the consequences and determine how to
address identified vulnerabilities
 Support measuring the quality of application security
efforts
 Document the “attack surface” of an application
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.4 OWASP Comprehensive Lightweight Application
Security Process (CLASP)
18
 Role-Based View – Designer
 Designers should:
 Push back on requirements with unrecognized security
risks
 Give implementers a roadmap to minimize the risk of
errors requiring an expensive fix
 Understand security risks of integrating 3rd party
software
 Respond to security risks

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
19
Role-Based View – Implementer
 Application developers
 Traditionally carries the bulk of security expertise
 Instead this requirement is pushed upward to other
roles
 Responsibilities:
 Follow established secure coding requirements,
policies, standards
 Identify and notify designer if new risks are identified
 Attend security awareness training
 Document security concerns related to deployment,
implementation, and end-user responsibilities
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.4 OWASP Comprehensive Lightweight Application
Security Process (CLASP)
20

Role-Based View – Test Analyst

 Quality assurance
 Tests can be created for security requirements in
addition to business requirements/features
 Security testing may be limited due to limited
knowledge
 May be able to run automated assessment tools
 May only have a general understanding of security
issues

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
21

Role-Based View – Security Auditor

 Examines and assures current state of a project
 Responsibilities:
 Determine whether security requirements are
adequate and complete
 Analyze design for any assumptions or symptoms of
risk that could lead to vulnerabilities
 Find vulnerabilities within an implementation based
on deviations from a specification or requirement

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight Application
Security Process (CLASP)
22
Activity-Assessment View Overview
 There are 24 CLASP “Security Activities”
 Added iteratively
 Activity-Assessment View allows a project manager to
determine appropriateness of CLASP activities
 Guide provides:
 Activity applicability
 Risks due to omission of activity
 Estimation of implementation cost
 Roles that will execute activity

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight
Application Security Process (CLASP)
23

Activity-Assessment and Roles

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4

 2.4 OWASP Comprehensive Lightweight Application
Security Process (CLASP)
24
Activity-Implementation View Introduction
 Defines the purpose or goals for the “Security Activity”
 Provides details regarding:
 Sub goals such as:
“Provide security training to all team members”
“Appoint a project security officer”
 Describes in detail how to carry out tasks or
accomplish goals
Details which CLASP resources support these tasks
ex: vulnerability lexicon to examine secure coding
practices
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.4 OWASP Comprehensive Lightweight Application
Security Process (CLASP)
25
Vulnerability View-CLASP Security Services
 Problem types:
104 types
Example: Buffer Overflow
 Categories:
Range and Type Errors
Environmental Problems
Synchronization & Timing Errors
Protocol Errors
General Logic Errors
 Exposure periods
Development artifact
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.4 OWASP Comprehensive Lightweight Application Security
Process (CLASP)
26
Vulnerability (Continued)‫‏‬
 Consequences
Violated Security Service
 Platforms
Language, OS, DB, etc.
 Resources
 Risk assessment
Severity
Likelihood
 Avoidance and mitigation periods
 Additional Info
Overview, description, examples, related problem
MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.4
 2.5 The Software Assurance Maturity Model
(SAMM)

What is SAMM?
 The Software Assurance Maturity Model (SAMM) is
an open framework to help organizations formulate
and implement a strategy for software security that
is tailored to the specific risks facing the
organization.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 6

 2.5 The Software Assurance Maturity Model
(SAMM)

The resources provided by SAMM :

• Evaluating an organization’s existing software security
practices
• Building a balanced software security assurance
program in well-defined iterations
• Demonstrating concrete improvements to a security
assurance program
• Defining and measuring security-related activities
throughout an organization

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 7

 8

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5

 2.5 The Software Assurance Maturity Model
(SAMM)

Governance: The Strategy & Metrics (SM) Practice is focused

on establishing the framework within an organization for a
software security assurance program.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 9

 2.5 The Software Assurance Maturity Model
(SAMM)

 Governance: The Policy & Compliance (PC) Practice is focused on

understanding and meeting external legal and regulatory requirements while
also driving internal security standards to ensure compliance in a way that’s
aligned with the business purpose of the organization.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 10

 2.5 The Software Assurance Maturity Model
(SAMM)

 Governance: The Education & Guidance (EG) Practice is focused on arming

personnel involved in the software life-cycle with knowledge and
resources to design, develop, and deploy secure software.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 11

 2.5 The Software Assurance Maturity Model
(SAMM)
 Construction: The Threat Assessment (TA) Practice is centered on
identification and understanding the project-level risks based on the
functionality of the software being developed and characteristics of the
runtime environment.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 12

 2.5 The Software Assurance Maturity Model
(SAMM)
 Construction: The Security Requirements (SR) Practice is
focused on proactively specifying the expected behavior
of software with respect to security.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 13

 2.5 The Software Assurance Maturity Model
(SAMM)
 Construction: The Security Requirements (SR) Practice is
focused on proactively specifying the expected behavior
of software with respect to security.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 14

 2.5 The Software Assurance Maturity Model
(SAMM)
 Construction: The Secure Architecture (SA) Practice is
focused on proactive steps for an organization to design
and build secure software by default.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 15

 2.5 The Software Assurance Maturity Model
(SAMM)
 Verification: The Design Review (DR) Practice is focused
on assessment of software design and architecture for
security-related problems.
.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 16

 2.5 The Software Assurance Maturity Model
(SAMM)
 Verification: The Code Review (CR) Practice is focused
on inspection of software at the source code level in
order to find security vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 17

 2.5 The Software Assurance Maturity Model
(SAMM)
 Verification: The Security Testing (ST) Practice is focused
on inspection of software in the runtime environment in
order to find security problems.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 18

 2.5 The Software Assurance Maturity Model
(SAMM)
 Deployment: The Vulnerability Management (VM)
Practice is focused on the processes within an
organization with respect to handling vulnerability
reports and operational incidents.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 19

 2.5 The Software Assurance Maturity Model
(SAMM)
 Deployment: The Environment Hardening (EH) Practice
is focused on building assurance for the runtime
environment that hosts the organization’s software.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 20

 2.5 The Software Assurance Maturity Model
(SAMM)
 Deployment: The Operational Enablement (OE) Practice is
focused on gathering security critical information from the project
teams building software and communicating it to the users and
operators of the software.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 2/2.5 21

 MOUNT ZION COLLEGE OF
ENGINEERING AND TECHNOLOGY

CCS374- WEB APPLICATION SECURITY

UNIT III: SECURE API DEVELOPMENT

YEAR/SEM:III/VI
THENMOZHI. P
DEPT:CSE
AP/CSE
 3.1 API Security :Session Cookies

API security:
• Application programming interface (API) security refers to the
practice of preventing or mitigating attacks on APIs.
• APIs work as the backend framework for mobile and web
applications. Therefore, it is critical to protect the sensitive data
they transfer.
• An API is an interface that defines how different software
interacts. It controls the types of requests that occur between
programs, how these requests are made, and the kinds of data
formats that are used.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 6

 3.1 API Security :Session Cookies

API security:
 The primary goal of API security is to protect the data and
functions exposed through an API by ensuring that only
authorized users have access, securing communication, and
preventing common security risks.
 Session cookies and token-based authentication are both crucial
elements in API security, providing mechanisms to authenticate
users and authorize access to resources.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 7

 3.1 API Security :Session Cookies
Session Cookies:
 Session cookies are cookies that last for a session. A
session starts when you launch a website or web app
and ends when you leave the website or close your
browser window.
 Session cookies contain information that is stored in a
temporary memory location which is deleted after
the session ends.
 Unlike other cookies, session cookies are never stored
on your device.
 Therefore, they are also known as transient cookies,
non-persistent cookies, or temporary cookies.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 8

 3.1 API Security :Session Cookies
Session Cookies:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 9

 3.1 API Security :Session Cookies
Session Cookies: Attributes

Attributes Meaning
Secure cookies are only ever sent over a HTTPS
Secure connection and so cannot be stolen by network
eavesdroppers.
Cookies marked HttpOnly cannot be read by
HttpOnly JavaScript, making them slightly harder to steal
through XSS attacks.
SameSite cookies will only be sent on requests
SameSite
that originate from the same origin as the cookie.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 10

 3.1 API Security :Session Cookies
Session Cookies : Attributes
public void validateToken(Request request, Response response) {
// WARNING: CSRF attack possible
tokenStore.read(request, null).ifPresent(token -> {
if (now().isBefore(token.expiry)) {
request.attribute("subject", token.username);
token.attributes.forEach(request::attribute);
}
});
}

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 11

 3.1 API Security :Session Cookies
Session fixation attack

 The attacker first logs in to obtain a valid session token.

 They then inject that session token into the victim’s browser and
trick them into logging in.

 If the existing session is not invalidating during login then the

attacker’s session will be able to access the victim’s account.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 12

 3.1 API Security :Session Cookies

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 13

 3.1 API Security :Session Cookies
Session Cookies : Characteristics

Authentication Persistence:

 Session cookies are often used in traditional web applications to

maintain user authentication across multiple requests.

 When a user logs in, a unique session cookie is generated and

sent to the client, allowing the server to recognize and
authenticate subsequent requests from the same user during
the session.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 14

 3.1 API Security :Session Cookies
Session Cookies : Characteristics

Stateful Communication:

 Session cookies enable stateful communication between the

client and server, as they store information about the user's
session on the server side.

 This helps maintain context and user-specific data throughout

their interaction with the application.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 15

 3.1 API Security :Session Cookies
Session Cookies : Characteristics

Vulnerability Concerns:

 However, session cookies come with security concerns, such as

the risk of session hijacking if the cookie is intercepted.

 Proper measures, like using secure cookies (encrypted and

transmitted over HTTPS) and implementing secure session
management practices, are essential to mitigate these risks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.1 16

 3.2 Token based authentication
Token-Based Authentication:
 Token-based authentication is a two-step authentication strategy
to enhance the security mechanism for users to access a network.
 The users once register their credentials, receive a unique
encrypted token that is valid for a specified session time.
 During this session, users can directly access the website or
application without login requirements.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 6

 3.2 Token based authentication
Token-Based Authentication:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 7

 3.2 Token based authentication
Token-Based Authentication:
 It enhances the user experience by saving time and security by
adding a layer to the password system.
 A token is stateless as it does not save information about the user
in the database.
 This system is based on cryptography where once the session is
complete the token gets destroyed. So, it gets the advantage
against hackers to access resources using passwords.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 8

 3.2 Token based authentication
What is an Authentication Token?
 A Token is a computer-generated code that acts as a digitally
encoded signature of a user.
 They are used to authenticate the identity of a user to access any
website or application network.
 A token is classified into two types:
 Physical token

 Web token.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 9

 3.2 Token based authentication
Physical token:
• A Physical token use a tangible device to store the information of
a user.
• Here, the secret key is a physical device that can be used to prove
the user’s identity.
• Two elements of physical tokens are hard tokens and soft tokens.
Hard tokens use smart cards and USB to grant access to the
restricted network like the one used in corporate offices to access
the employees.
• Soft tokens use mobile or computer to send the encrypted code
(like OTP) via authorized app or SMS.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 10

 3.2 Token based authentication
Web token:
• The authentication via web token is a fully digital process. Here,
the server and the client interface interact upon the user’s
request.
• The client sends the user credentials to the server and the server
verifies them, generates the digital signature, and sends it back to
the client.
• Web tokens are popularly known as JSON Web Token (JWT), a
standard for creating digitally signed tokens.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 11

 3.2 Token based authentication
Token-Based Authentication: Drivers
some important drivers of token-based authentication
• User: A person who intends to access the network carrying
his/her username & password.
• Client-server: A client is a front-end login interface where the
user first interacts to enroll for the restricted resource.
• Authorization server: A backend unit handling the task of
verifying the credentials, generating tokens, and send to the user.
• Resource server: It is the entry point where the user enters the
access token. If verified, the network greets users with a welcome
note.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 12
 3.2 Token based authentication
How does Token-based Authentication work?
 Token-based authentication has become a widely used security
mechanism used by internet service providers to offer a quick
experience to users while not compromising the security of their
data.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 13

 3.2 Token based authentication
How does Token-based Authentication work?
1. Request:
 The user intends to enter the service with login credentials on the
application or the website interface.
 credentials involve a username, password, smartcard, or
biometrics
2. Verification:
 The login information from the client-server is sent to the
authentication server for verification of valid users trying to enter
the restricted resource.
 If the credentials pass the verification the server generates a
secret digital key to the user via HTTP in the form of a code
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 14
 3.2 Token based authentication
How does Token-based Authentication work? .
The token is sent in a JWT open standard format which includes-
• Header: It specifies the type of token and the signing algorithm.
• Payload: It contains information about the user and other data
• Signature: It verifies the authenticity of the user and the
messages transmitted.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 15

 3.2 Token based authentication
How does Token-based Authentication work? .
3. Token validation:
 The user receives the token code and enters it into the resource
server to grant access to the network.
 The access token has a validity of 30-60 seconds and if the user
fails to apply it can request the Refresh token from the
authentication server.
 There’s a limit on the number of attempts a user can make to get
access. This prevents brute force attacks that are based on trial
and error methods.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 16

 3.2 Token based authentication
How does Token-based Authentication work? .
4. Storage:
 Once the resource server validated the token and grants access to
the user, it stores the token in a database for the session time you
define.
 The session time is different for every website or app. For
example, Bank applications have the shortest session time of
about a few minutes only.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 17

 3.2 Token based authentication
Token-Based Authentication : Characteristics

Stateless Communication:

 Token-based authentication is commonly used in modern API

architectures, providing a stateless approach.

 When a user logs in, the server issues a token (usually a JSON
Web Token or JWT) containing user information and permissions.

 The client includes this token in each API request for

authentication.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 18

 3.2 Token based authentication
Token-Based Authentication : Characteristics

Enhanced Security:

 Tokens can include expiration times and are typically signed or

encrypted, enhancing security.

 They reduce the risk of session hijacking because the token itself
doesn't contain sensitive information, and its contents can be
verified for integrity.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 19

 3.2 Token based authentication
Token-Based Authentication : Characteristics

Cross-Origin Resource Sharing (CORS):

 Token-based authentication is better aligned with modern web

practices, especially in scenarios involving cross-origin requests.

 It allows for the inclusion of tokens in API requests from different

origins, facilitating secure communication between services.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 20

 3.2 Token based authentication
Token-Based Authentication : Characteristics

Scalability and Performance:

 Token-based authentication is well-suited for distributed and

scalable systems since it eliminates the need for server-side
storage of session information.

 Each request carries the necessary authentication details in the

token, making the server-independent and improving
performance.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.2 21

 3.3 Securing Natter APIs
Natter APIs:
• An API is a set of rules and protocols that allows different
software applications to communicate with each other.
• It defines the methods and data formats that applications can
use to request and exchange information.
• APIs are commonly used in software development to enable
integration between different systems, services, or platforms.
• In January 2022 ,widely recognized or documented API called
"NATTER API."
• The Natter API is split into two REST endpoints, one for
normal users and one for moderators who have special
privileges to tackle abusive behavior.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 6

 3.3 Securing Natter APIs

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 7

 3.3 Securing Natter APIs
The Natter API operations:
• A HTTP POST request to the /spaces URI creates a new social
space. The user that performs this POST operation becomes
the owner of the new space. A unique identifier for the space is
returned in the response.
• Users can add messages to a social space by sending a POST
request to /spaces/<spaceId> /messages where spaceId is the
unique identifier of the space.
• The messages in a space can be queried using a GET request to
/spaces/ <spaceId> /messages. A since <timestamp>query
parameter can be used to limit the messages returned to a
recent period.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 8

 3.3 Securing Natter APIs
The Natter API operations:
• Finally, the details of individual messages can be obtained using
a GET request to /spaces/ <spaceId> /messages/ <messgeId>.
• The moderator API contains a single operation to delete a
message by sending a DELETE request to the message URI.
• Postman (https://www.postman.com) is a widely used tool for
exploring and documenting HTTP APIs.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 9

 3.3 Securing Natter APIs
Implementation overview
 The Natter API is written in Java 11 using the Spark
Java (http://sparkjava.com) framework .
 Maven is used to build the code examples, and an H2
in-memory database (https://h2database.com) is
used for data storage.
 The Dalesbred database abstraction library
(https://dalesbred.org) is used to provide a more
convenient interface to the database than Java’s JDBC
interface, without bringing in the complexity of a full
object-relational mapping framework.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 10

 3.3 Securing Natter APIs
Setting up the project
 Use Maven to generate the basic project structure, by running
the following command in the folder where you want to create
the project:
mvn archetype:generate \
➥ -DgroupId=com.manning.apisecurityinaction \
➥ -DartifactId=natter-api \
➥ -DarchetypeArtifactId=maven-archetype-quickstart \
➥ -DarchetypeVersion=1.4 -DinteractiveMode=false

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 11

 3.3 Securing Natter APIs
Setting up the project
project structure, containing the initial Maven project file
(pom.xml), and an App class and AppTest unit test class under the
required Java package folder structure.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 12

 3.3 Securing Natter APIs
Initializing the database
 To get the API up and running, need a database to store the
messages that users send to each other in a social space, as well
as the metadata about each social space, such as who created it
and what it is called.
 The schema is very simple and shown in figure . It consists of just
two entities: social spaces and messages.
 Spaces are stored in the spaces database table, along with the
name of the space and the name of the owner who created it.
 Messages are stored in the messages table, with a reference to
the space they are in, as well as the message content (as text),
the name of the user who posted the message, and the time at
which it was created.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 13

 3.3 Securing Natter APIs
Initializing the database

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 14

 3.3 Securing Natter APIs
Initializing the database

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 15

 3.3 Securing Natter APIs
Initializing the database

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 16

 3.3 Securing Natter APIs
Initializing the database

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 17

 3.3 Securing Natter APIs
Addressing threats with security controls :
To protect the Natter API against common threats by applying
some basic security mechanisms (also known as security controls).
 Rate-limiting
 Encryption
 Authentication
 Audit logging
 Access control

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 18

 3.3 Securing Natter APIs
Addressing threats with security controls

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 19

 3.3 Securing Natter APIs
Addressing threats with security controls
 Rate-limiting is used to prevent users overwhelming your API
with requests, limiting denial of service threats.
 Encryption ensures that data is kept confidential when sent to or
from the API and when stored on disk, preventing information
disclosure. Modern encryption also prevents data being
tampered with.
 Authentication makes sure that users are who they say they are,
preventing spoofing. This is essential for accountability, but also
a foundation for other security controls.
 Audit logging is the basis for accountability, to prevent
repudiation threats.
 Access control to preserve confidentiality and integrity,
preventing information disclosure, tampering and elevation of
privilege attacks.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 20
 3.3 Securing Natter APIs
Rate-limiting for availability:
 Rate-limiting for availability is a crucial aspect of protecting
your system from abuse, ensuring fair resource allocation,
and maintaining consistent performance, especially during
periods of high traffic or potential denial-of-service (DoS)
attacks.
 Denial of Service (DoS) attack aims to prevent legitimate
users from accessing your API.
 This can include physical attacks, such as unplugging
network cables, but more often involves generating large
amounts of traffic to overwhelm your servers.
 A distributed DoS (DDoS) attack uses many machines
across the internet to generate traffic, making it harder to
block than a single bad client.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 21
 3.3 Securing Natter APIs
Rate-limiting for availability:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 22

 3.3 Securing Natter APIs
Rate-limiting for availability:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 23

 3.3 Securing Natter APIs
Using encryption to keep data private:
 Encryption ensures that data is kept confidential when sent to or
from the API and when stored on disk, preventing information
disclosure.
 Modern encryption also prevents data being tampered with.
 HTTPS is normal HTTP, but the connection occurs over Transport
Layer Security (TLS), which provides encryption and integrity
protection.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 24

 3.3 Securing Natter APIs
Using encryption to keep data private:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 25

 3.3 Securing Natter APIs
Audit logging
 Audit logging is the basis for accountability, to prevent
repudiation threats.
 Audit logging should occur after authentication, so that you
know who is performing an action, but before you make
authorization decisions that may deny access .
 Audit logs should be written to durable storage, such as the file
system or a database, so that the audit logs will survive if the
process crashes for any reason.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 26

 3.3 Securing Natter APIs
Audit logging

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.3 27

 3.4 Securing service-to-service APIs
Securing service-to-service APIs
• Securing service-to-service APIs is critical in modern software
development, especially in distributed systems and
microservices architectures.
• Implement strong authentication mechanisms to verify the
identities of the communicating services.
• This can include techniques such as
• API keys
• OAuth tokens
• JWT (JSON Web Tokens)
• Mutual TLS (Transport Layer Security) authentication

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 6

 3.4 Securing service-to-service APIs
Securing service-to-service APIs
• These service-to-service API calls can occur within a single
organization, such as between microservices, or between
organizations when an API is exposed to allow other
businesses to access data or services.
• This is needed for billing or to apply limits according to a
service contract, but it’s also essential for security when
sensitive data or operations may be performed.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 7

 3.4 Securing service-to-service APIs
API keys:
• An API key is a token that identifies a service client rather
than a user.
• API keys are typically valid for a much longer time than a
user token, often months or years.
• The API key is added to each request as a request
parameter or custom header.
• An API key identifies a service or business rather than a
user and usually has a long expiry time.
• Typically, a user logs in to a website (known as a developer
portal) and generates an API key that they can then add to
their production environment to authenticate API calls.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 8

 3.4 Securing service-to-service APIs
API keys:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 9

 3.4 Securing service-to-service APIs
OAuth 2.0:
• OAuth 2.0 is an authorization framework that enables third-
party applications to obtain limited access to a user's protected
resources without exposing their credentials.
• OAuth 2.0 is widely used for secure authorization and
delegated access in various scenarios, including web and
mobile applications, APIs, and Internet of Things (IoT) devices.
• OAuth 2.0 provides a flexible and standardized way to handle
authorization and access control, enabling secure interactions
between clients and resource servers in distributed systems.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 10

 3.4 Securing service-to-service APIs
OAuth 2.0 components and how it works:
1.Roles:
•Resource Owner: The entity that owns the protected resources,
typically the end-user.
•Client: The application requesting access to the protected
resources on behalf of the resource owner.
•Authorization Server: The server responsible for authenticating
the resource owner and issuing access tokens to the client after
successful authorization.
•Resource Server: The server hosting the protected resources that
the client wants to access.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 11

 3.4 Securing service-to-service APIs
OAuth 2.0 components and how it works:
2.Authorization Grant Types:
•Authorization Code:
•Used by web applications that can securely store client secrets.
•After the resource owner approves access, the authorization
server redirects the user back to the client with an authorization
code.
• The client exchanges this code for an access token.
•Implicit: Designed for browser-based or mobile applications
where the client cannot securely store secrets.
•The access token is returned immediately after the user grants
access, without requiring an additional authorization code
exchange.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 12
 3.4 Securing service-to-service APIs
OAuth 2.0 components and how it works:
3.Access Token:
1. The access token represents the authorization granted to
the client to access protected resources on behalf of the
resource owner.
2. Access tokens are typically short-lived and scoped to
specific permissions (scopes).
3. Clients include the access token in API requests to the
resource server to authenticate and authorize their access.
4.Token Endpoint:
1. The token endpoint is a server endpoint where the client
exchanges an authorization grant for an access token.
2. Clients authenticate with the authorization server to obtain
the access token.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 13
 3.4 Securing service-to-service APIs

OAuth 2.0 components and how it works:

5.Refresh Token:
•Optionally issued alongside the access token, a refresh token allows
the client to obtain a new access token without requiring the user to
re-authenticate.
•Refresh tokens have a longer lifespan and are used to request new
access tokens when the current one expires.
•Service accounts:
• A service account is an account that identifies a service rather
than a real user.
• Service accounts can simplify access control and account
management because they can be managed with the same tools
you use to manage users.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 14
 3.4 Securing service-to-service APIs

OAuth 2.0 components and how it works:

Service accounts:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.4 15

 3.5 Securing Microservice APIs

Securing Microservice APIs

• Microservices architecture decomposes an application into
smaller, independent services, each responsible for a specific
business capability.
• These services communicate with each other via APIs
(Application Programming Interfaces), forming the backbone of
the distributed system.
• Securing microservice APIs involves implementing measures to
protect the confidentiality, integrity, and availability of data and
resources exchanged between microservices, as well as
ensuring that only authorized entities can access and
manipulate these APIs.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 6

 3.5 Securing Microservice APIs

1.Authentication:
• Authentication ensures that the identities of clients
accessing microservice APIs are verified.
• It involves mechanisms to validate the credentials
provided by the client, such as usernames, passwords,
API keys, or tokens. Common authentication protocols
include OAuth 2.0, JWT (JSON Web Tokens), and basic
authentication.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 7

 3.5 Securing Microservice APIs

Components of Securing Microservice APIs:

2.Authorization:
• Authorization determines what actions clients are allowed
to perform once they are authenticated.
• It involves defining access control policies based on roles,
permissions, or attributes.
• Authorization mechanisms like RBAC (Role-Based
Access Control) and ABAC (Attribute-Based Access
Control) help enforce fine-grained access control to
microservice APIs.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 8

 3.5 Securing Microservice APIs

Components of Securing Microservice APIs:

3.Encryption:
• Encryption ensures that data exchanged between
microservices is protected from unauthorized access or
tampering.
• It involves encrypting data both at rest and in transit using
cryptographic protocols like TLS/SSL (Transport Layer
Security/Secure Sockets Layer).
• Encryption prevents eavesdropping, man-in-the-middle
attacks, and data breaches.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 9

 3.5 Securing Microservice APIs
Components of Securing Microservice APIs:
4. API Gateway:
• API gateway acts as a central entry point for microservices,
providing security features such as authentication,
authorization, rate limiting, and logging.
• It terminates SSL/TLS connections, offloads security-related
tasks from microservices, and enforces security policies
consistently across all APIs.
5. Service Identity and Secrets Management:
• Each microservice should have a unique identity and
credentials for secure authentication and communication.
• Secrets management systems store sensitive information
like API keys, passwords, and encryption keys securely,
reducing the risk of unauthorized access or exposure.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 10
 3.5 Securing Microservice APIs
Components of Securing Microservice API
6.Input Validation and Sanitization:
• Input validation ensures that data received by microservice
APIs is valid and conforms to expected formats, preventing
common security vulnerabilities such as injection attacks
(e.g., SQL injection, XSS).
• Sanitization techniques remove potentially malicious content
from input data to protect against security threats.
7.Logging and Monitoring:
Comprehensive logging of API activities helps track usage,
detect anomalies, and investigate security incidents. Monitoring
tools monitor system metrics, logs, and events for security
events, potential attacks, and compliance violations, enabling
timely response and mitigation.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 11
 3.5 Securing Microservice APIs
Components of Securing Microservice API
8.Container Security:
• Microservices often run in containers, which need to be
secured against vulnerabilities and attacks.
• Container security involves scanning container images for
vulnerabilities, applying security patches regularly, and
enforcing security policies using container orchestration
platforms like Kubernetes.
9.Code Security:
• Secure coding practices minimize security vulnerabilities in
microservice code.
• Regular security code reviews, static code analysis, and
penetration testing identify and remediate security issues,
reducing the risk of exploitation and compromise.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 12
 3.5 Securing Microservice APIs
Components of Securing Microservice API
10.Access Controls:
• Access controls restrict access to microservice APIs based on
factors like IP whitelisting, network policies, and authentication
tokens.
• Implementing proper access controls ensures that only authorized
entities can access sensitive resources and functionalities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 13

 3.5 Securing Microservice APIs
service mesh
• A service mesh is a set of components that secure
communications between pods in a cluster using proxy sidecar
containers.
• In addition to security benefits, a service mesh provides other
useful functions such as
• load balancing
• monitoring
• logging
• automatic request retries
• To enable a service mesh, you need to install the service mesh
control plane components such as the CA into your cluster.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 14

 3.5 Securing Microservice APIs
service mesh: control plane
• The control plane of a service mesh is the set of components
responsible for configuring, managing, and monitoring the
proxies.
• The proxies themselves and the services they protect are
known as the data plane.
• To install Linkerd, you first need to install the linkerd
command-line interface (CLI), which will be used to
configure and control the service mesh.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 15

 3.5 Securing Microservice APIs
service mesh

MZCET/CSE/VI Sem/CCS374_WAS/Unit 3/3.5 16

 MOUNT ZION COLLEGE OF
ENGINEERING AND TECHNOLOGY

CCS374- WEB APPLICATION SECURITY

UNIT IV :VULNERABILITY ASSESSMENT AND
PENETRATION TESTING

YEAR/SEM:III/VI
THENMOZHI. P
D E P T: C S E
A P/ C S E
 4.1 Vulnerability Assessment Lifecycle
What is a vulnerability Assessment lifecycle?
• Vulnerability management lifecycle is a systematic process of
discovering, analyzing, prioritizing, and mitigating
vulnerabilities in an organization’s systems and software for
continuous improvement.
• It helps detect and report security weaknesses continuously for
patch applications and protecting against cyber threats.
• The Vulnerability Assessment Lifecycle outlines the steps
involved in identifying, assessing, prioritizing, and mitigating
vulnerabilities within an organization's IT infrastructure.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 6

 4.1 Vulnerability Assessment Lifecycle
Benefits of vulnerability Assessment lifecycle:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 7

 4.1 Vulnerability Assessment Lifecycle

vulnerability Assessment lifecycle

Preparation
|
v
Vulnerability Identification
|
v
Vulnerability Analysis
|
v
Risk Assessment
|
v
Remediation Planning
|
v
Remediation Implementation
|
v
Verification and Validation
|
v
Monitoring and Review
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 8
 4.1 Vulnerability Assessment Lifecycle
vulnerability Assessment lifecycle
Preparation:
•Define the scope and objectives of the vulnerability assessment.
•Identify the assets, systems, and networks to be assessed.
•Gather information about the organization's infrastructure,
including hardware, software, and configurations.
•Establish the criteria for classifying vulnerabilities based on
severity, impact, and likelihood.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 9

 4.1 Vulnerability Assessment Lifecycle
vulnerability Assessment lifecycle
Vulnerability Identification:
•Use automated scanning tools, such as vulnerability
scanners, to identify potential vulnerabilities across the
network, systems, and applications.
•Conduct manual inspections and analysis to discover
vulnerabilities that may not be detected by automated tools.
•Classify and prioritize identified vulnerabilities based on
their severity, potential impact, and exploitability.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 10

 4.1 Vulnerability Assessment Lifecycle
vulnerability Assessment lifecycle
Vulnerability Analysis:
•Evaluate the identified vulnerabilities to understand their
underlying causes, potential attack vectors, and possible
consequences.
•Research and gather information about known exploits, patches,
and security best practices related to each vulnerability.
•Analyze the potential impact of exploiting each vulnerability on
the organization's operations, data confidentiality, integrity, and
availability.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 11

 4.1 Vulnerability Assessment Lifecycle
vulnerability Assessment lifecycle
Risk Assessment:
•Assess the risks associated with each identified vulnerability by
considering factors such as likelihood of exploitation, business
impact, and potential mitigation measures.
•Calculate risk scores or ratings for prioritizing vulnerabilities
based on their severity and impact on the organization.
•Determine acceptable levels of risk based on organizational
policies, compliance requirements, and industry standards.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 12

 4.1 Vulnerability Assessment Lifecycle
vulnerability Assessment lifecycle
Remediation Planning:
•Develop a prioritized remediation plan outlining actions to
address identified vulnerabilities.
•Assign responsibilities and deadlines for implementing
remediation measures.
•Consider various mitigation strategies, including patching,
configuration changes, software updates, and security controls
implementation.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 13

 4.1 Vulnerability Assessment Lifecycle
vulnerability Assessment lifecycle
Remediation Implementation:
•Implement the remediation measures according to the
prioritized plan.
•Apply patches, updates, and fixes to vulnerable systems and
applications.
•Configure security controls and settings to mitigate identified
risks.
•Verify that remediation measures are effectively applied and do
not introduce new vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 14

 4.1 Vulnerability Assessment Lifecycle
vulnerability Assessment lifecycle
Verification and Validation:
•Verify that remediation measures have been successfully
implemented and vulnerabilities have been addressed.
•Perform validation tests, such as vulnerability scans and
penetration tests, to confirm that vulnerabilities have been
properly remediated.
•Validate that the implemented security controls are functioning
as intended and effectively mitigating risks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 15

 4.1 Vulnerability Assessment Lifecycle
vulnerability Assessment lifecycle
Monitoring and Review:
•Continuously monitor the organization's infrastructure for new
vulnerabilities, emerging threats, and changes that may impact
security.
•Review and update the vulnerability assessment process and
procedures based on lessons learned, feedback, and changes in
the threat landscape.
•Conduct periodic reviews and audits to ensure compliance with
security policies, standards, and regulatory requirements.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.1 16

 4.2 Vulnerability Assessment Tools
What is a vulnerability Assessment Tool?

• Vulnerability Assessment Tools refer to software applications or

solutions designed to identify, analyze, and prioritize
vulnerabilities within computer systems, networks,
applications, and other IT assets.
• These tools are crucial components of cybersecurity strategies
as they help organizations proactively identify weaknesses in
their digital infrastructure before malicious actors can exploit
them.
• Vulnerability assessment tools are essential for identifying
weaknesses and potential security risks within computer
systems, networks, and applications.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 6
 4.2 Vulnerability Assessment Tools
Vulnerability Assessment Tool : Example
Here's a list of some popular vulnerability assessment tools
used by cybersecurity professionals:
1.Nessus: Nessus is one of the most widely used
vulnerability assessment tools. It scans networks for
vulnerabilities, misconfigurations, and other security issues.
2.OpenVAS (Open Vulnerability Assessment System):
OpenVAS is an open-source vulnerability scanner that
detects security issues in networks and provides a
comprehensive report on the findings.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 7

 4.2 Vulnerability Assessment Tools
Vulnerability Assessment Tool : Example
3.Nmap (Network Mapper): While primarily known as a
network mapping tool, Nmap also includes powerful
vulnerability scanning capabilities. It can detect open ports,
running services, and potential vulnerabilities.
4.Qualys: Qualys offers a cloud-based vulnerability
management platform that provides continuous monitoring,
assessment, and remediation of security vulnerabilities
across networks and endpoints.
5.Acunetix: Acunetix is a web vulnerability scanner that
identifies security flaws in web applications, including SQL
injection, cross-site scripting (XSS), and other vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 8

 4.2 Vulnerability Assessment Tools
Vulnerability Assessment Tool : Example
6.Rapid7 InsightVM: InsightVM is a vulnerability
management solution that provides real-time visibility into
the security posture of an organization's assets and
prioritizes remediation efforts based on risk.
7.OpenSCAP: OpenSCAP is an open-source security
compliance solution that includes vulnerability scanning
capabilities. It provides automated security auditing and
compliance checks based on industry standards like SCAP
(Security Content Automation Protocol).

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 9

 4.2 Vulnerability Assessment Tools
Vulnerability Assessment Tool : Example
8.Burp Suite: Burp Suite is a comprehensive web application
security testing tool. It includes features for manual and
automated testing, as well as scanning for various types of
vulnerabilities.
9.Metasploit: Metasploit is a penetration testing framework that
includes a wide range of tools for exploiting vulnerabilities. It can
also be used for vulnerability assessment to identify weaknesses
in systems and networks.
10.Retina Network Security Scanner: Retina is a vulnerability
scanner designed for enterprises to assess and prioritize security
risks across their networks, endpoints, and virtual environments.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 10

 4.3 Types of Vulnerability Assessment
Tools

What is a vulnerability Assessment Tool?

• Vulnerability Assessment Tools refer to software

applications or solutions designed to identify, analyze, and
prioritize vulnerabilities within computer systems,
networks, applications, and other IT assets.
• These tools are crucial components of cybersecurity
strategies as they help organizations proactively identify
weaknesses in their digital infrastructure before malicious
actors can exploit them.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 11
 4.3 Types of Vulnerability Assessment
Tools
Cloud-based Vulnerability Scanners:
•Description: Cloud-based vulnerability scanners are specifically
designed to assess the security posture of cloud environments,
including infrastructure as a service (IaaS), platform as a service
(PaaS), and software as a service (SaaS) offerings.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 12

 4.3 Types of Vulnerability Assessment
Tools
•Functionality:
• They leverage APIs provided by cloud service providers to gain
visibility into cloud resources, configurations, and metadata.
• These scanners identify misconfigurations, access control
issues, and vulnerabilities within cloud infrastructure
components such as virtual machines, containers, storage
services, databases, and networking configurations.
• Cloud-based vulnerability scanners often offer features for
continuous monitoring, compliance checks, and integration
with cloud-native security services and solutions.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 13

 4.3 Types of Vulnerability Assessment
Tools
Cloud-based Vulnerability Scanners:
Examples:
• Qualys Cloud Platform
• Rapid7 InsightVM
• Nessus Cloud
• AWS Security Hub
• Azure Security Center

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 14

 4.3 Types of Vulnerability Assessment
Tools
Cloud-based Vulnerability Scanners : Pros
•Accessibility: They can be accessed from anywhere with an
internet connection, facilitating ease of use and management.
•Scalability: Cloud-based scanners can scale up or down based
on demand, accommodating organizations of varying sizes.
•Integration: They often integrate seamlessly with cloud
environments and services, providing comprehensive visibility
and coverage.
•Automatic Updates: Cloud-based scanners typically receive
regular updates and patches, ensuring the latest vulnerability
signatures and detection capabilities.
•Collaboration: They allow for easy collaboration among
distributed teams, enabling efficient vulnerability management
and remediation.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 15
 4.3 Types of Vulnerability Assessment
Tools
Cloud-based Vulnerability Scanners : Cons
•Dependency on Internet Connectivity: Requires a stable internet
connection for operation, which may pose challenges in certain
environments or during network outages.
•Data Privacy Concerns: Organizations may have concerns about
storing sensitive vulnerability assessment data in the cloud, especially
if compliance regulations mandate strict data handling requirements.
•Cost Considerations: While often cost-effective, subscription-based
pricing models may incur ongoing operational expenses, which may
not be suitable for all organizations, especially those with budget
constraints.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 16

 4.3 Types of Vulnerability Assessment
Tools
Host-based Vulnerability Scanners:
•Description: Host-based vulnerability scanners focus on evaluating
the security posture of individual systems or hosts by scanning and
analyzing their configurations, installed software, and running
processes.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 17

 4.3 Types of Vulnerability Assessment
Tools
•Functionality:
• These scanners are installed directly on individual hosts,
allowing for detailed assessment of operating systems,
applications, and configurations.
• They conduct scans locally on target systems,
examining system logs, registry settings, file
permissions, and installed software versions to identify
vulnerabilities and security weaknesses.
• Host-based vulnerability scanners detect issues such as
missing patches, insecure configurations, outdated
software, and unauthorized changes to system files or
settings.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 18

 4.3 Types of Vulnerability Assessment
Tools
Examples:
•Tenable.io
•Qualys Agent
• OpenVAS
•Microsoft Defender for Endpoint
• McAfee Vulnerability Manager for Databases.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 19

 4.3 Types of Vulnerability Assessment
Tools
Host-based Vulnerability Scanners : Pros
•Granular Analysis: Host-based scanners provide detailed
insights into individual systems, including operating system
configurations, installed software, and user privileges.
•Offline Scanning: They can perform scans even when the
target systems are disconnected from the network, ensuring
comprehensive coverage.
•Endpoint Protection Integration: Many host-based scanners
integrate seamlessly with endpoint protection platforms (EPP),
allowing for unified vulnerability management and response.
•Compliance Auditing: They assist in compliance audits by
providing detailed reports on system configurations and
security posture.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 20
 4.3 Types of Vulnerability Assessment
Tools
Host-based Vulnerability Scanners :Cons
•Installation Overhead: Requires installation and configuration
on each target system, which can be time-consuming and
resource-intensive, especially in large-scale environments.
•Limited Network Visibility: Host-based scanners may not
detect vulnerabilities that are only visible at the network level,
such as open ports or network misconfigurations.
•Endpoint Impact: Scanning activities may impact system
performance or disrupt user activities, particularly during
intensive scans or on resource-constrained endpoints.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 21

 4.3 Types of Vulnerability Assessment
Tools
Network-based Vulnerability Scanners:
•Description: Network-based vulnerability scanners are designed to
assess the security of network infrastructure, including routers,
switches, firewalls, and other devices, by scanning and analyzing
network traffic and configurations.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 22

 4.3 Types of Vulnerability Assessment
Tools
•Functionality:
• They conduct scans across network segments, identifying
open ports, running services, and potential vulnerabilities in
network devices and services.
• Network-based vulnerability scanners utilize techniques such
as port scanning, service identification, and vulnerability
detection to identify weaknesses that could be exploited by
attackers.
• These scanners provide detailed reports with prioritized
recommendations for remediation based on the severity of
identified vulnerabilities.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 23

 4.3 Types of Vulnerability Assessment
Tools
Examples:
•Nessus
•OpenVAS
• Qualys Network Security
•Rapid7 Nexpose
•Microsoft Defender for Identity (formerly Azure Advanced Threat
Protection).

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 24

 4.3 Types of Vulnerability Assessment
Tools
Pros:
•Comprehensive Coverage: Network-based scanners assess
vulnerabilities across multiple systems and devices connected to the
network, providing broad visibility.
•Rapid Deployment: They can be deployed quickly and easily across
the network, allowing for immediate vulnerability assessment and
detection.
•Real-time Monitoring: Many network-based scanners offer
continuous monitoring capabilities, enabling organizations to detect
and respond to new vulnerabilities as they arise.
•Remote Access: They can scan devices located in remote or
geographically dispersed locations without requiring installation on
individual endpoints.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 25
 4.3 Types of Vulnerability Assessment
Tools
Cons:
•Network Complexity: Network-based scanners may struggle to
accurately assess vulnerabilities in complex network environments,
especially those with segmented or virtualized infrastructures.
•False Positives: Without proper configuration and tuning, network-
based scanners may generate false positives, leading to
unnecessary alerts and remediation efforts.
•Limited Visibility: They may not provide visibility into vulnerabilities
on endpoints that are not connected to the network or operate
outside of the organization's perimeter defenses.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 26

 4.3 Types of Vulnerability Assessment
Tools
Database-based Vulnerability Scanners:
•Description: Database-based vulnerability scanners focus on
evaluating the security of database management systems (DBMS)
and the data stored within them by scanning and analyzing
database configurations, access controls, and data integrity
mechanisms.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 27

 4.3 Types of Vulnerability Assessment
Tools
•Functionality:
• They assess database servers and instances for vulnerabilities
such as weak authentication mechanisms, SQL injection
vulnerabilities, excessive user privileges, misconfigured access
controls, and sensitive data exposure.
• Database-based vulnerability scanners provide
recommendations for securing databases, including applying
patches, implementing encryption, restricting access rights,
and enforcing strong authentication mechanisms.
• These scanners often integrate with database management
systems and security solutions to provide continuous
monitoring and real-time threat detection.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 28

 4.3 Types of Vulnerability Assessment
Tools
Examples:
•IBM Guardium
• Trustwave DbProtect
•Imperva Database Security
•McAfee Database Security
• Oracle Audit Vault and Database Firewall.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 29

 4.3 Types of Vulnerability Assessment
Tools
Pros:
•Database-specific Analysis: These scanners are specifically tailored
to assess vulnerabilities in database management systems (DBMS),
providing in-depth analysis of database configurations, access
controls, and data integrity mechanisms.
•Compliance Assurance: Database scanners assist in compliance
audits by identifying vulnerabilities and misconfigurations that may
violate regulatory requirements or industry standards.
•Real-time Monitoring: Many database scanners offer continuous
monitoring capabilities, allowing organizations to detect and
respond to database-related threats in real-time.
•Integration with Database Security Solutions: They often integrate
seamlessly with database security solutions, enhancing overall
database protection and response capabilities.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 30
 4.3 Types of Vulnerability Assessment
Tools
Cons:
•Limited Scope: Database scanners focus exclusively on
vulnerabilities within database systems and may not provide
visibility into vulnerabilities in other areas of the IT infrastructure.
•Complexity: Database scanning may require specialized knowledge
of database management systems and SQL queries, making it
challenging for organizations without dedicated database
administrators.
•Impact on Performance: Intensive database scans may impact
database performance or disrupt normal operations, particularly on
production systems during peak usage hours.
•False Negatives: Database scanners may fail to detect certain
vulnerabilities or misconfigurations, leading to gaps in security
coverage and potential exposure to database-related threats.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3 31
 SUMMARY
32

4.2 Vulnerability Assessment Tools

 What is a vulnerability Assessment Tool?
 Vulnerability Assessment Tools : Example
4.3 Types of Vulnerability Assessment Tools
 Cloud-based vulnerability scanners
 Host-based vulnerability scanners
 Network-based vulnerability scanners
 Database- based vulnerability scanners

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.2 & 4.3

 4.4-4.6 :Types of Penetration Tests
What is penetration testing?
• Penetration testing, or pen testing, is an ethical cybersecurity
evaluation focused on discovering and addressing
vulnerabilities within a company’s network and applications.
• Pen testing can simulate various attack scenarios, depending
on whether it is conducted externally or internally.
• The objectives and outcomes of each pen test are tailored to
the specific requirements of the organisation undergoing the
assessment.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 6

 4.4-4.6 :Types of Penetration Tests
Benefits of Penetration testing
•Proactive Risk Mitigation
•Strategic Security Investments
•Regulatory Compliance
•Customer Trust
•Incident Response Preparedness
•Competitive Advantage
•Cost Savings

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 7

 4.4-4.6 :Types of Penetration Tests
Types of Penetration Test

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 8

 4.4-4.6 :Types of Penetration Tests
External Penetration Testing:
•This type of testing focuses on assessing the security of systems
and networks from an external perspective.
•Testers attempt to exploit vulnerabilities that external attackers,
such as open ports, web applications, and remote access points,
could target.
Internal Penetration Testing:
•Internal penetration testing assesses the security of systems and
networks from an insider’s perspective.
•Testers may have some level of access or credentials, allowing
them to evaluate the effectiveness of internal security controls,
user privileges, and potential lateral movement within the
organisation.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 9
 4.4-4.6 :Types of Penetration Tests
Web Application Penetration Testing:
•This specific type of testing focuses exclusively on web
applications.
•Testers look for vulnerabilities in web apps, such as cross-site
scripting (XSS), SQL injection, and authentication flaws.
Mobile Application Penetration Testing:
•Mobile application testing is geared toward assessing the security
of mobile apps on various platforms.
•Testers check for vulnerabilities that could be exploited through
mobile devices, including data leakage and insecure APIs.
Wireless Network Penetration Testing:
•This type of testing evaluates the security of wireless networks,
including Wi-Fi and Bluetooth.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 10
 4.4-4.6 :Types of Penetration Tests
Internal penetration testing :
Internal penetration testing is an effective way to enhance an
organization’s security by identifying potential vulnerabilities in
your IT infrastructure before a hacker enters it. Also, the best part
of internal pentest is it provides a dynamic and regular means of
monitoring your system.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 11

 4.4-4.6 :Types of Penetration Tests
Internal penetration testing :

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 12

 4.4-4.6 :Types of Penetration Tests
Internal Penetration Testing Methodology
An ethical hacker performs pentests on these entities, exploiting
them for vulnerabilities. Following is a step-by-step guide
explaining the methodology of Internal pentesting.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 13

 4.4-4.6 :Types of Penetration Tests
Internal Penetration Testing Methodology
1. Requirement Gathering and Reconnaissance
• The preliminary stage of penetration testing begins with
fixating on the scope of the testing process. It involves
analyzing the essential documents defining the intended
business behavior.
• This stage defines the entire roadmap, from identifying testing
assets to deploying various techniques and penetration tools.
2. Vulnerability Scanning
• The target code is scanned for vulnerabilities using static and
dynamic automated tools.
• In static analysis, the tool entirely scans the code and intrudes
it for various inputs. While in dynamic testing, code is analyzed
at its execution stage.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 14
 4.4-4.6 :Types of Penetration Tests
Internal Penetration Testing Methodology
3. Bug exploitation
• Probably, the most exciting and important part of the
pentesting, where hacking is actually performed, is termed bug
exploitation.
• Here, the vulnerabilities detected at the previous stage are
exploited to determine the extent of the problem they can
cause. This phase’s goal is to gain access to the decryption key.
If the hacker gains access to the target system, they can use it
to their advantage.
• Various tools such as Nmap, Wireshark, Metasploit, Nessus,
Burp Suite, and others are used for bug exploitation. These
tools, however, are dependent on the project’s requirements.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 15

 4.4-4.6 :Types of Penetration Tests
Internal Penetration Testing Methodology
4. Reporting
• Reports usually come with PoC(proof of concept) for pen
testers to attach evidence to their findings.
• The report must contain all the vulnerabilities detected along
with a detailed explanation of the issues arising out of it. It
should include the sensitive data that an ethical hacker could
retrieve it and for how long they could remain undetected.
5. Refactoring and Retesting
Post initial pentest, the developers are supposed to work there as
per the test report findings. After making the required
amendments, rechecking is performed to ensure the correctness
of the code.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 16

 4.4-4.6 :Types of Penetration Tests
Tools of Internal Penetration Testing
Here are a few Internal penetration testing tools deployed
by penetration testers to make your project bug-free.
•Burp Suite Pro
•Wireshark
•Nikto
•Sqlmap
•Nessus
•Archini
•Metasploit Framework
•Nmap

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 17

 4.4-4.6 :Types of Penetration Tests
Pros of Internal Penetration Testing :
•Insider Threat Assessment: Identifies vulnerabilities that could
be exploited by insiders or attackers who have gained
unauthorized access to the internal network.
•Segmentation Assessment: Evaluates the effectiveness of
network segmentation and access controls in preventing
unauthorized access to sensitive systems or data.
•Compliance Requirements: Assists organizations in meeting
regulatory compliance requirements related to internal network
security and access controls.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 18

 4.4-4.6 :Types of Penetration Tests
Cons of Internal Penetration Testing :
•Disruption Risk: Internal penetration tests may disrupt normal
business operations or cause unintended consequences if not
carefully planned and executed.
•Limited Visibility: May not detect vulnerabilities in external-
facing systems or cloud-based services not directly accessible
from within the internal network.
•Scope Limitations: Focuses exclusively on internal network
security and may not address vulnerabilities in remote work
environments or third-party services.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 19

 4.4-4.6 :Types of Penetration Tests
External Penetration Test:
• External penetration testing involves simulating real-world
attacks from outside an organization's network perimeter.
• It aims to identify vulnerabilities in internet-facing systems that
could be exploited by external threat actors.
• These include web servers, email servers, VPN gateways, and
other entry points accessible from the internet.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 20

 4.4-4.6 :Types of Penetration Tests
External Penetration Test:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 21

 4.4-4.6 :Types of Penetration Tests
External Penetration Testing Methodology
External Pentest can be broken down into a 5-step process and
described below.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 22

 4.4-4.6 :Types of Penetration Tests
External Penetration Testing Methodology
Step 1: Planning and Reconnaissance
• The initial step of the procedure includes defining the scope
and aim of the penetration technique, along with the type of
pentest to use.
• From recognizing the testing assets to deploying diverse
techniques and penetration tools, a complete roadmap of the
process is defined at this stage.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 23

 4.4-4.6 :Types of Penetration Tests
External Penetration Testing Methodology
Step 2: Scanning and Vulnerability Assessment
• In the next stage, the tester understands the target system’s
response to various intrusion attempts. This is done using static
and dynamic techniques, as explained below.
•Static assessment
It examines an application’s code to scrutinize its functioning.
These tools scan the code in its entirety.
•Dynamic assessment
It analyzes the code during its execution state, providing a real-
time performance of an application under question.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 24

 4.4-4.6 :Types of Penetration Tests
External Penetration Testing Methodology
Step 3: Exploitation
• Exploitation is the actual performance stage of penetration
testing. In this phase, the testers try to exploit systemic errors
with a range of attacks.
• They employ web application attacks to identify a range of
vulnerabilities, such as cross-site scripting, SQL injection,
backdoors, and others. Testers then attempt to exploit these
vulnerabilities, typically by breaking access control, stealing
data, intercepting traffic, and so on, to gain an understanding of
the potential harm they can cause.
• Different tools like Nmap, Wireshark, Metasploit, Nessus, Burp
Suite, and more are used to exploit bugs. Although, these tools
depend on the project’s requirements
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 25
 4.4-4.6 :Types of Penetration Tests
External Penetration Testing Methodology
Step 4: Detailed analysis Report
• A compilation of the entire penetration test findings and results
are created into a report, including:
•The specific vulnerabilities were discovered during the test.
•Accessed sensitive information.
•The time the tester was able to remain undetected in the system.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 26

 4.4-4.6 :Types of Penetration Tests
External Penetration Testing Methodology
Step 5: Refactoring and Rescanning
• This step involves developers making the required changes in
the code based on the vulnerabilities detected during
pentesting.
• Post-refactoring, the code is then assessed by the testers to
confirm that the code is performing as per its intended
behavior.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 27

 4.4-4.6 :Types of Penetration Tests
External penetration testing tools :
External penetration testing tools deployed by penetration
testers to make your project bug-free.
•Burp Suite Pro
•wireshark
•Nikto
•Sqlmap
•Nessus
•Archini
•Metasploit Framework
•Nmap

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 28

 4.4-4.6 :Types of Penetration Tests
External penetration testing :
Pros:
•Realistic Assessment: Provides a realistic assessment of an
organization's external security posture by simulating how
external threat actors might attempt to breach defenses.
•Risk Reduction: Helps reduce the risk of external attacks and data
breaches by identifying and prioritizing vulnerabilities in internet-
facing systems.
•Compliance Requirements: Assists organizations in meeting
regulatory compliance requirements by identifying vulnerabilities
that could lead to unauthorized access or data breaches.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 29

 4.4-4.6 :Types of Penetration Tests
External penetration testing :
Cons:
•Limited Scope: Focuses solely on external-facing systems and
may not assess internal network security or employee awareness.
•False Positives/Negatives: May generate false positives or false
negatives due to limitations in scanning techniques or network
configurations.
•Scope Creep: The scope may expand beyond the organization's
control, involving third-party services or external factors not
directly under their management.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 30

 4.4-4.6 :Types of Penetration Tests
Web Application Penetration Test:
• A web application penetration test focuses specifically on
assessing the security of web applications, websites, and APIs.
• It evaluates both frontend and backend components, including
client-side code, server-side logic, and database interactions.
• Penetration testers attempt to identify vulnerabilities such as
SQL injection, cross-site scripting (XSS), and authentication
bypass that could be exploited by attackers to gain unauthorized
access or steal sensitive data.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 31

 4.4-4.6 :Types of Penetration Tests

Web Application Penetration Test : Phases

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 32

 4.4-4.6 :Types of Penetration Tests

Web Application Penetration Test: Phases

1) Planning Phase
• During the planning phase, a number of important decisions
are made that directly impact other phases of penetration
testing.
• It includes defining the scope, timeline, and people
involved among other things.
• The organization and the provider of pen testing services for
web applications must agree on the scope.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 33

 4.4-4.6 :Types of Penetration Tests

Web Application Penetration Test:Phases

2) Pre-Attack Phase
• In this phase, the reconnaissance is done which is important
for paving the way for the next phase of testing.
• Especially, it includes looking for Open Source
Intelligence (OSINT), or any other information available
publicly that can be used against you.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 34

 4.4-4.6 :Types of Penetration Tests

Web Application Penetration Test:Phases

3) Attack Phase
• During the attack phase, the pentester tries to exploit the
vulnerabilities found in the last phase.
• They try to go one step further by identifying and mapping
the attack vectors.
• In an attack phase, the pentester gets into a web application’s
internal structure and tries to compromise the host.
• This may involve social engineering attacks, physical security
breaching, web application exploits, phishing employees or
CXOs of an organization, etc.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 35

 4.4-4.6 :Types of Penetration Tests

Web Application Penetration Test:Phases

4) Post-Attack Phase
• After the penetration testing is complete, a full detailed
report is generated.
• This report can vary from organization to organization or the
type of application that is pen-tested.
• But generally, the penetration testing report includes a list of
vulnerabilities, an analysis of the finding, proposed
remediations, and a conclusion.
• Apart from that, the pentester is also responsible for
restoring the systems and network configurations to their
original states in the post-attack phase.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 36

 4.4-4.6 :Types of Penetration Tests

What tools are used for web application penetration

testing?
•Astra Security Scan
•Acunetix
•HackerOne
•Burp Suite
•Browser’s Developer Tools
•NMap
•Zenmap
•ReconDog
•Nikto

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 37

 4.4-4.6 :Types of Penetration Tests

web application penetration testing:Pros

•Comprehensive Assessment: Provides a comprehensive
assessment of security vulnerabilities specific to web
applications, including input validation flaws, authentication
weaknesses, and insecure direct object references.
•Compliance Requirements: Helps organizations meet
regulatory compliance requirements related to web application
security, such as the OWASP Top 10 and PCI DSS.
•Protection of Sensitive Data: Ensures the protection of
sensitive user data processed or stored by web applications,
such as personal information, financial transactions, or medical
records.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 38

 4.4-4.6 :Types of Penetration Tests

web application penetration testing:Cons

•Complexity: Web application penetration testing requires
specialized knowledge and skills in web development,
programming languages, and web security testing tools.
•Scope Limitations: May not assess vulnerabilities in underlying
infrastructure or third-party services that support web
applications, such as cloud platforms or content delivery
networks.
•False Positives/Negatives: Vulnerability scanners used in web
application penetration tests may produce false positives or
negatives due to complexities in web application logic and
dynamic content.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 39

 4.4-4.6 :Types of Penetration Tests

Mobile Application Penetration Test:

• Mobile application penetration testing evaluates the security
of mobile apps developed for platforms such as iOS and
Android.
• It assesses the security of both client-side and server-side
components, including the app's source code, backend APIs,
and data storage mechanisms.
• Testers attempt to identify vulnerabilities such as insecure
data storage, insecure communication channels, and
improper session management that could be exploited by
attackers to compromise the app or steal sensitive user data.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 40

 4.4-4.6 :Types of Penetration Tests

Mobile Application Penetration Test:Functionality:

•Binary Analysis: Analyze the binary code of mobile apps for
security vulnerabilities.
•API Security Testing: Assess the security of backend APIs used
by mobile apps for vulnerabilities such as insecure API endpoints
and improper access controls.
•Data Storage Security: Evaluate the security of data storage
mechanisms, including encryption, access controls, and data
leakage prevention.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 41

 4.4-4.6 :Types of Penetration Tests

Mobile Application Penetration Test: Functionality:

•Communication Channel Testing: Test communication channels
used by mobile apps for vulnerabilities such as insecure
transmission of sensitive data.
•Authentication Testing: Assess the strength of authentication
mechanisms and identify authentication bypass vulnerabilities.
•Reverse Engineering: Reverse engineer mobile apps to identify
security vulnerabilities and bypass security controls.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 42

 4.4-4.6 :Types of Penetration Tests

Mobile Application Penetration Test : tools

1. MobSF (Mobile Security Framework)
2. QARK (Quick Android Review Kit)
3. Dynamic Analysis Tools
4. Burp Suite
5. OWASP ZAP (Zed Attack Proxy
6. Network Analysis Tools:
7. Wireshark
8. Charles Proxy
9. Apktool
10.IDA Pro

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 43

 4.4-4.6 :Types of Penetration Tests

Mobile Application Penetration Test: Pros

•Platform-specific Assessment: Provides a targeted assessment
of security vulnerabilities specific to mobile applications,
including platform-specific APIs, frameworks, and security
controls.
•Compliance Requirements: Helps organizations meet
regulatory compliance requirements related to mobile
application security, such as the OWASP Mobile Top 10 and
GDPR.
•Protection of Sensitive Data: Ensures the protection of
sensitive user data stored or processed by mobile applications,
such as location data, contact lists, or financial transactions.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 44

 4.4-4.6 :Types of Penetration Tests

Mobile Application Penetration Test : Cons:

•Device Fragmentation: Mobile application penetration tests
may encounter challenges related to device fragmentation, as
mobile apps must be tested across various device models,
operating system versions, and network configurations.
•Emulator Limitations: Testing on emulated environments may
not accurately replicate real-world conditions, leading to
discrepancies in vulnerability detection and exploitation.
•Dynamic Content: Mobile applications often rely on dynamic
content and server-side interactions, making it challenging to
assess security vulnerabilities in client-side code alone.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 45

 4.4-4.6 :Types of Penetration Tests

Mobile Application Penetration Test : Cons:

•Device Fragmentation: Mobile application penetration tests
may encounter challenges related to device fragmentation, as
mobile apps must be tested across various device models,
operating system versions, and network configurations.
•Emulator Limitations: Testing on emulated environments may
not accurately replicate real-world conditions, leading to
discrepancies in vulnerability detection and exploitation.
•Dynamic Content: Mobile applications often rely on dynamic
content and server-side interactions, making it challenging to
assess security vulnerabilities in client-side code alone.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 46

 4.4-4.6 :Types of Penetration Tests

Wireless Penetration Test:

Wireless penetration testing involves identifying and examining
the connections between all devices connected to the business’s
wifi. These devices include laptops, tablets, smartphones, and
any other internet of things (IoT) devices.
Steps To Performing A Wireless Penetration Test

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 47

 4.4-4.6 :Types of Penetration Tests

Steps To Performing A Wireless Penetration Test

1.Reconnaissance:
1. Perform passive reconnaissance to gather information
about the target wireless network, such as SSIDs (Service
Set Identifiers), signal strength, encryption methods used,
and MAC addresses of connected devices.
2. Use tools like Wireshark, Kismet, or Airodump-ng to
passively capture and analyze wireless traffic in the vicinity
of the target network.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 48

 4.4-4.6 :Types of Penetration Tests

Steps To Performing A Wireless Penetration Test

2.Active Scanning:
1. Conduct active scanning to identify access points (APs)
and their characteristics, including encryption types (e.g.,
WEP, WPA, WPA2, WPA3), authentication methods, and
signal strength.
2. Utilize tools such as NetStumbler, WiFi Pineapple, or
Aircrack-ng to actively scan for nearby wireless networks
and gather detailed information about them.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 49

 4.4-4.6 :Types of Penetration Tests

Steps To Performing A Wireless Penetration Test

3.Exploitation:
1. Exploit discovered vulnerabilities to gain unauthorized
access to the wireless network or its connected devices.
2. Attempt common attacks such as brute-force attacks,
dictionary attacks, or WPS (Wi-Fi Protected Setup) PIN
attacks against weakly secured networks.
3. Utilize tools like Metasploit, Aircrack-ng, or Reaver to
automate exploitation attempts and gain access to the
network.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 50

 4.4-4.6 :Types of Penetration Tests

Steps To Performing A Wireless Penetration Test

4.Reporting:
1. Compile a detailed report outlining the methodology,
findings, and recommendations resulting from the
wireless penetration test.
2. Provide actionable recommendations for mitigating
identified vulnerabilities and improving the overall
security posture of the wireless network.
3. Present findings to the stakeholders in a clear and
understandable manner, highlighting the importance of
addressing identified security issues.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 51

 4.4-4.6 :Types of Penetration Tests

Steps To Performing A Wireless Penetration Test

5.Follow-Up:
1. Work with the network owner or responsible parties to
implement recommended security measures and address
identified vulnerabilities.
2. Conduct follow-up assessments periodically to ensure that
security improvements are effectively implemented and
maintained over time.
Throughout the wireless penetration testing process, it's
essential to prioritize ethical and responsible behavior, adhere to
applicable laws and regulations, and respect the privacy and
confidentiality of sensitive information.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 52

 4.4-4.6 :Types of Penetration Tests

Wireless Penetration Test:Pros

1.Identify Vulnerabilities: Penetration tests can uncover security
weaknesses and vulnerabilities in the wireless network
infrastructure, including misconfigurations, outdated software,
and inadequate encryption methods.
2.Enhance Security Posture: By identifying and addressing
vulnerabilities, organizations can improve their overall security
posture, reducing the risk of unauthorized access, data
breaches, and other security incidents.
3.Compliance Requirements: Penetration testing is often
required to comply with industry regulations and standards such
as PCI DSS, HIPAA, and GDPR, demonstrating a commitment to
maintaining robust security practices.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 53
 4.4-4.6 :Types of Penetration Tests

Wireless Penetration Test:Cons

1.Cost: Penetration testing can be expensive, requiring
specialized tools, expertise, and resources to conduct
comprehensive assessments effectively. Small organizations with
limited budgets may find it challenging to afford regular testing.
2.Disruption: Penetration testing can disrupt normal business
operations, especially if active exploitation techniques are used,
leading to network downtime, service interruptions, and
potential impact on productivity.
3.False Positives: Penetration tests may produce false positive
results, where vulnerabilities are incorrectly identified or
reported, leading to unnecessary remediation efforts and
wasted resources.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 4/4.4-4.6 54
 MOUNT ZION COLLEGE OF
ENGINEERING AND TECHNOLOGY

CCS374- WEB APPLICATION SECURITY

UNIT V :HACKING TECHNIQUES AND TOOLS

YEAR/SEM:III/VI
THENMOZHI. P
D E P T: C S E
A P/ C S E
 5.1 Social Engineering, Injection

What is Social Engineering?

•Social Engineering is the term used for a BROAD range of
malicious activities accomplished through simple human
interaction and a fair share of “trickery”
•Social Engineering uses “psychological manipulation” to basically
trick employees into making security mistakes or giving away
sensitive information
• No one is immune: Many smart and careful people can fall
victim to a social engineering attack without even realizing it until
it is too late
. • Vigilance and common sense are the keys to protection

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 6

 5.1 Social Engineering, Injection

What is Social Engineering?

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 7

 5.1 Social Engineering, Injection

Foundations of a Social Engineering Attack

Social Engineering relies on these five basic emotional traits for its
success, including:

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 8

 5.1 Social Engineering, Injection

How Does Social Engineering Work?

Social Engineering is a multi-faceted attack and includes:
• The perpetrator first investigates the intended victim and gathers
necessary background information, such as potential points of entry
and weak security protocol needed to proceed with the attack
• The attacker then moves to gain the victim’s trust and provides a
stimuli for subsequent action that breaks established security
practices, such as revealing sensitive information and granting
access to critical resources (www.imperva.com)

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 9

 5.1 Social Engineering, Injection

How Does Social Engineering Work?

• Social Engineering is simply the most efficient, cost-effective and
capable tool used by cyber-criminals in so many different types of
crimes .
• The original master of social engineering was one of the most
famous hackers our generation, Kevin Mitnick. They have literally
written books about him and how he used social engineering to
effectuate his attacks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 10

 5.1 Social Engineering, Injection

Additional Common Social Engineering Attacks

• Social Engineering is simply the most efficient, cost-effective and
capable tool used by cyber-criminals in so many different types of
crimes .
• The original master of social engineering was one of the most
famous hackers our generation, Kevin Mitnick. They have literally
written books about him and how he used social engineering to
effectuate his attacks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 11

 5.1 Social Engineering, Injection

Additional Common Social Engineering Attacks

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 12

 5.1 Social Engineering, Injection

Social Engineering Prevention (Awareness)

• Create a “security awareness” culture in the organization
• Management should regularly conduct awareness campaigns on
importance of protecting data from social engineering attacks
• Post visual reminders (posters, etc.) throughout office space
• Send regular email reminders on vigilance against social engineer
attacks
• Publicly reward staff who embody good security awareness

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 13

 5.1 Social Engineering, Injection

Injection attack
• An injection attack is a type of security exploit where malicious
code is injected into an application or system, typically through
input fields such as forms on a website or database queries.
• The goal of an injection attack is to manipulate the behavior of
the application in order to gain unauthorized access to data,
execute arbitrary commands, or perform other malicious actions.
SQL Injection: Involves injecting SQL (Structured Query
Language) code into a database query through input fields or
parameters, allowing attackers to manipulate the database or
retrieve sensitive information.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 14

 5.1 Social Engineering, Injection

What Is SQL?
• Structured Query Language, or SQL, extracts data and data
structures in relational databases.
• Relational databases store data in tables; each row in a table is a
data item (for example, a user, or a product being sold).
• SQL syntax allows applications such as web servers to add rows to
the database by using INSERT statements, read rows by using
SELECT statements, update rows by using UPDATE statements,
and remove rows by using DELETE statements.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 15

 5.1 Social Engineering, Injection

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 16

 5.1 Social Engineering, Injection

Anatomy of a SQL Injection Attack

• SQL injection attacks occur when the web server insecurely
constructs the SQL statement it passes to the database driver.
• This allows the attacker to pass arguments via the HTTP request
that cause the driver to perform actions other than those the
developer intends.
• Let’s look at an insecurely constructed SQL statement that reads
user data from the database when a user attempts to log in to a
website, as shown in the Java code .

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 17

 5.1 Social Engineering, Injection

Anatomy of a SQL Injection Attack: Example 1

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 18

 5.1 Social Engineering, Injection

Anatomy of a SQL Injection Attack : Example 1

SQL databases typically store information about the website’s users
in a users table.
1.When a user first signs up and chooses a username and password,
the web server runs an INSERT statement on the database to create
a new row in the users table .
2. The next time a user logs in to the website, the web server runs a
SELECT statement to attempt to find the corresponding row in the
users table
3.If the user changes their password, the web server runs an
UPDATE statement to update the corresponding row in the users
table
4. Finally, if the user closes their account, the website might run a
DELETE statement to remove their row from the users table x.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 19
 5.1 Social Engineering, Injection

Anatomy of a SQL Injection Attack : Example 2

SQL injection attack that runs a DROP command to remove
the users table entirely, in order to corrupt the database.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 20

 5.1 Social Engineering, Injection

Anatomy of a SQL Injection Attack : Example 3

In this example, the attacker passes the user email
parameter as [email protected]'--, which terminates the SQL
statement early and causes the password-checking logic to not
execute

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 21

 5.1 Social Engineering, Injection

Mitigating SQL injection vulnerabilities:

Mitigating SQL injection vulnerabilities requires a
combination of secure coding practices, proper configuration, and
ongoing monitoring. Here are some effective mitigation strategies:
1.Use Parameterized Queries or Prepared Statements: Instead of
concatenating user input directly into SQL queries, use
parameterized queries or prepared statements provided by your
database API. These methods separate the SQL code from the data,
preventing attackers from injecting malicious SQL.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 22

 5.1 Social Engineering, Injection

Mitigating SQL injection vulnerabilities:

2.Input Validation and Sanitization:
Validate and sanitize all user input before using it in SQL queries.
Ensure that input matches expected data types, length limits, and
acceptable character sets. Use whitelists (allowlists) to restrict input
to expected values.
3.Least Privilege Principle:
Limit the permissions of the database user account used by the
application. Follow the principle of least privilege by granting only
the necessary permissions required for the application to function
properly. This limits the potential damage that an attacker can cause
if a SQL injection vulnerability is exploited.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.1 23

 5.2 Cross-Site Scripting(XSS)

What is XSS ?
• Cross site scripting (XSS) is a common attack vector that injects
malicious code into a vulnerable web application.
• XSS differs from other web attack vectors (e.g., SQL injections),
in that it does not directly target the application itself.
• Instead, the users of the web application are the ones at risk.
• A successful cross site scripting attack can have devastating
consequences for an online business’s reputation and its
relationship with its clients.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 6

 5.2 Cross-Site Scripting(XSS)

What is XSS ?
• Cross site scripting (XSS) is a common attack vector that injects
malicious code into a vulnerable web application.
• XSS differs from other web attack vectors (e.g., SQL injections),
in that it does not directly target the application itself.
• Instead, the users of the web application are the ones at risk.
• A successful cross site scripting attack can have devastating
consequences for an online business’s reputation and its
relationship with its clients.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 7

 5.2 Cross-Site Scripting(XSS)
Types of XSS
There are mainly three different types of Cross-site Scripting
vulnerability;
•Reflected XSS
A reflected XSS vulnerability happens when the user input from a
URL or POST data is reflected on the page without being stored.
•Persistent or Stored XSS
Stored Cross-site scripting vulnerabilities happens when the payload
is saved, for example in a database and then is executed when a user
opens the page. Stored cross-site scripting is very dangerous for a
number of reasons
•DOM-based XSS
The DOM Based XSS vulnerability happens in the DOM (Document
Object Model) instead of part of the HTML.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 8
 5.2 Cross-Site Scripting(XSS)
Stored XSS (Persistent XSS):
•This type of XSS attack involves injecting a malicious script
into a vulnerable web application, where it is stored on the
server and subsequently served to all users who access the
affected page.
•The injected script is permanently stored in a database, file, or
other data storage mechanism associated with the web
application.
•Victims do not need to be directly targeted by the attacker;
instead, they become vulnerable simply by visiting the
compromised page.
•Stored XSS attacks are often more damaging than reflected
XSS attacks because they can affect multiple users over an
extended period.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 9
 5.2 Cross-Site Scripting(XSS)

DOM-based XSS

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 10

 5.2 Cross-Site Scripting(XSS)
Reflected XSS (Non-Persistent XSS):
•In this type of attack, the malicious script is injected into a
vulnerable web application, and the script is reflected off the
web server to the victim's browser.
•Typically, the attacker sends a link containing the malicious
script to the victim via email, social media, or other means.
•When the victim clicks on the link, the script executes in their
browser within the context of the vulnerable web application,
potentially compromising their session or stealing sensitive
information.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 11

 5.2 Cross-Site Scripting(XSS)

Reflected XSS (Non-Persistent XSS):

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 12

 5.2 Cross-Site Scripting(XSS)
Impact of XSS
The impact of an exploited XSS vulnerability varies a lot. It ranges
from
• Redirection
• Session Hijacking
• Cross Site Request forgery
• Keylogging
• Phishing
By exploiting a cross-site scripting vulnerability an attacker
can impersonate the victim and take over the account. If the victim
has administrative rights it might even lead to code execution on the
server, depending on the application and the privileges of the
account

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 13

 5.2 Cross-Site Scripting(XSS)
Ways to identify & verify XSS vulnerabilities
Cross-site Scripting vulnerabilities can be identified in 2 ways
namely;
• Static Analysis (Source code review)
• Dynamic analysis (Fuzzing)
Static Analysis Tools
• OWASP WAP - Web Application Protection Project
• RIPS - A static source code analyser
• Codacy: Automated code reviews & code analytics
Dynamic Analysis Tools
• Burp suite
• Hack bar Firefox addon or burp addon
• Automated vulnerability scanner (eg. Arachni)

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 14

 5.2 Cross-Site Scripting(XSS)
Ways to Preventing Cross-Site Scripting
Recall that an XSS attack is a type of code injection: user input is
mistakenly interpreted as malicious program code. In order to
prevent this type of code injection, secure input handling is needed.
For a web developer, there are two fundamentally different ways of
performing secure input handling:
• Encoding: which escapes the user input so that the browser
interprets it only as data, not as code.
• Validation: which filters the user input so that the browser
interprets it as code without malicious commands.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 15

 5.2 Cross-Site Scripting(XSS)
Preventing XSS - Encoding
Encoding is the act of escaping user input so that the browser
interprets it only as data, not as code. The following pseudocode is
an example of how user input could be encoded using HTML
escaping

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 16

 5.2 Cross-Site Scripting(XSS)

Preventing XSS - Validating

 Validation is the act of filtering user input so that all malicious
parts of it are removed, without necessarily removing all code
in it. One of the most recognizable types of validation in web
development is allowing some HTML elements (such as
<em>and<strong> ) but disallowing others (such as <script>)
 There are two main characteristics of validation that differ
between implementations:
 Classification strategy: User input can be classified using
either blacklisting or whitelisting.
 Validation outcome: User input identified as malicious can
either be rejected or sanitised.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 17

 5.3 Broken authentication and session
management

Broken authentication and session management

 Broken authentication and session management are closely
related security vulnerabilities that often occur together.
 Broken authentication refers to flaws in the authentication
process, such as weak password policies or improper session
management, which can lead to unauthorized access to user
accounts.
 Session management vulnerabilities, on the other hand, involve
insecure handling of session tokens or cookies, which can result
in session fixation, session hijacking, or session replay attacks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 18

 5.3 Broken authentication and session
management

Broken Authentication:
1. Weak Password Policies:
Vulnerability: Lack of password complexity requirements or
enforcement of weak passwords.
Mitigation:
 Enforce strong password policies including minimum length,
complexity requirements, and password expiration.
 Educate users about creating strong, unique passwords or
passphrases.
 Implement multi-factor authentication (MFA) to add an extra
layer of security.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 19

 5.3 Broken authentication and session
management
Broken Authentication:
2. Insecure Authentication Mechanisms:
Vulnerability: Vulnerabilities in authentication mechanisms such as
weak secret questions, predictable password reset tokens, or lack
of CAPTCHA protection.
Mitigation:
 Use secure authentication mechanisms, including CAPTCHA
protection, randomized password reset tokens, and robust secret
question mechanisms.
 Employ account lockout mechanisms to prevent brute-force
attacks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 20

 5.3 Broken authentication and session
management

Broken Authentication:
3. Credential Exposure:
Vulnerability: Storing sensitive credentials in plaintext,
transmitting them over insecure channels, or exposing them
through error messages or logs.
Mitigation:
 Hash passwords using strong cryptographic algorithms with
unique salts.
 Encrypt sensitive data in transit using secure protocols like
HTTPS.
 Avoid exposing sensitive information in error messages or logs.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 21

 5.3 Broken authentication and session
management

Session Management:
1. Session Fixation:
Vulnerability: Attackers can force users to authenticate using
session identifiers controlled by the attacker, allowing them to
hijack the victim's session.
Mitigation:
 Generate new session identifiers upon successful
authentication.
 Invalidate any existing session identifiers to prevent session
fixation attacks.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 22

 5.3 Broken authentication and session
management
2. Session Hijacking:
Vulnerability: Attackers steal or guess valid session tokens or
cookies to impersonate legitimate users and gain unauthorized
access to their accounts.
Mitigation:
Implement secure session management practices, such as using
HTTPS to encrypt session tokens in transit and rotating session
identifiers after authentication.
Detect and prevent session hijacking attempts using monitoring
mechanisms.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 23

 5.3 Broken authentication and session
management

3. Session Timeout and Expiration:

Vulnerability: Sessions with no or excessively long timeouts can
increase the window of opportunity for attackers to hijack active
sessions.
Mitigation:
 Set appropriate session timeouts and expiration periods
based on application requirements and sensitivity of data.
 Implement session logout mechanisms to invalidate sessions
after periods of inactivity.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 24

 5.3 Broken authentication and session
management

4. Cross-Site Request Forgery (CSRF) Protection:

Vulnerability: Lack of protection against CSRF attacks can allow
attackers to perform actions on behalf of authenticated users
without their consent.
 Mitigation:
 Use anti-CSRF tokens to validate the origin of requests and
prevent CSRF attacks.
 Employ SameSite cookie attributes to mitigate CSRF attacks
involving session cookies.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.2 &5.3 25

 5.4 Cross-Site Request Forgery

What is CSRF ?
CSRF stands for Cross-Site Request Forgery. It is a type of security
vulnerability that occurs when a malicious website, email, or
other mechanism tricks a user's web browser into performing an
unwanted action on a trusted site where the user is
authenticated.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5

 5.4 Cross-Site Request Forgery

Anatomy of a CSRF Attack:

1.User Authentication: The victim user is typically authenticated
to a legitimate website. This authentication is usually maintained
through session cookies.
2.Malicious Website or Link: The attacker tricks the victim into
visiting a malicious website or clicking on a crafted link.
3.Automatic Execution: Since the victim is authenticated to the
targeted website, the browser automatically includes the
necessary session cookies in the request, making it appear as if
the request originated from the victim.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5

 5.4 Cross-Site Request Forgery

Anatomy of a CSRF Attack:.

3.Crafted Request: Once the victim is on the malicious
website or clicks the malicious link, the attacker initiates a
request to the targeted website on behalf of the victim. This
request typically includes parameters to perform a specific
action (e.g., changing the victim's email address, transferring
funds, etc.).
4.Unwanted Action: The targeted website processes the
forged request, unaware that it was initiated by an attacker,
and carries out the action, causing harm to the victim.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5

 5.4 Cross-Site Request Forgery
Mitigation Strategies for CSRF:
1.Anti-CSRF Tokens: Implement anti-CSRF tokens or synchronizer
tokens. These are unique tokens generated by the server and
embedded in each form or request. The server verifies the presence
and correctness of these tokens with each request. As the attacker
cannot obtain these tokens due to the same-origin policy, it prevents
CSRF attacks.
2.SameSite Cookies: Set cookies to be SameSite to restrict when they
are sent with cross-origin requests. This prevents the browser from
sending cookies along with cross-origin requests, effectively
mitigating CSRF attacks to a great extent.
3.Security Headers: Utilize security headers like X-Content-Type-
Options, X-Frame-Options, and X-XSS-Protection to enhance the
overall security posture of your web application.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5
 5.4 Cross-Site Request Forgery

Mitigation Strategies for CSRF:

4.Use of GET vs. POST: Be cautious about using GET requests for
actions that modify data or have side effects. POST requests are
generally safer for such actions as they are not susceptible to being
included in URLs and are not cached or pre-fetched by browsers.
5.Content Security Policy (CSP): Implement CSP headers to prevent
the execution of unauthorized scripts on your web pages. This can
help mitigate the risk of attacks that exploit XSS vulnerabilities to
initiate CSRF attacks.
6.Session Management: Implement robust session management
practices, such as using secure, HttpOnly cookies, enforcing session
timeouts, and regularly rotating session identifiers.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5

 5.4 Cross-Site Request Forgery

Mitigation Strategies for CSRF:

7.Custom Request Headers: Include custom headers in requests
and validate them on the server. This approach adds an extra layer
of protection against CSRF attacks, as attackers cannot forge
requests with the required custom headers.
8.Referer Header Checking: Validate the Referer header of
incoming requests. Although this is not a foolproof method due to
its susceptibility to spoofing, it can still add another layer of
defense against CSRF attacks.
9.User Interaction Requirements: Implement user interaction
requirements for critical actions. For example, require users to
confirm sensitive actions (such as changing account settings or
making transactions) with an additional prompt or verification
step.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5
 5.5 Security Misconfiguration

What is Security Misconfiguration ?

Security misconfiguration refers to the failure to implement
secure configurations or settings in a system, application,
server, or any other IT infrastructure component. It is a
common security issue that can lead to various
vulnerabilities and attacks if not addressed properly.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5

 5.5 Security Misconfiguration

Anatomy of Security Misconfiguration:

1.Default Settings: Failing to change default configurations
provided by software vendors or frameworks can leave systems
vulnerable. Attackers often target systems with default settings
because they are well-known and widely documented.
2.Unused Features: Enabling unnecessary features or services
increases the attack surface of a system. These unused features
may have vulnerabilities that could be exploited by attackers.
3.Outdated Software: Running outdated software with known
vulnerabilities poses a significant risk. Failure to apply patches or
updates promptly leaves systems exposed to exploitation.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5

 5.5 Security Misconfiguration

Anatomy of Security Misconfiguration:

4.Default Settings: Failing to change default configurations
provided by software vendors or frameworks can leave systems
vulnerable. Attackers often target systems with default settings
because they are well-known and widely documented.
5.Unused Features: Enabling unnecessary features or services
increases the attack surface of a system. These unused features
may have vulnerabilities that could be exploited by attackers.
6.Outdated Software: Running outdated software with known
vulnerabilities poses a significant risk. Failure to apply patches or
updates promptly leaves systems exposed to exploitation.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5

 5.5 Security Misconfiguration

Mitigation Strategies for Security Misconfiguration:

• Configuration Management: Establish a robust configuration
management process to ensure that all systems and software
components are configured securely. This includes regular
reviews, audits, and updates of configuration settings.
• Least Privilege: Implement the principle of least privilege to
restrict access rights and permissions to only those necessary
for users, processes, and services to perform their required
tasks. Avoid granting excessive permissions or privileges.
• Regular Updates and Patching: Keep all software, frameworks,
libraries, and dependencies up to date by applying patches and
security updates promptly. Establish a patch management
process to automate the deployment of updates.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5
 5.5 Security Misconfiguration

Mitigation Strategies for Security Misconfiguration:

• Secure Defaults: Configure systems with secure default settings
and disable unnecessary features, services, or ports to
minimize the attack surface. Follow security best practices
provided by software vendors and industry standards.
• Security Headers: Utilize security headers (e.g., Content
Security Policy, X-Content-Type-Options, X-Frame-Options) to
enhance the security posture of web applications and protect
against common attacks such as cross-site scripting (XSS) and
clickjacking.
• Secure Development Practices: Incorporate secure coding
practices into the software development lifecycle (SDLC) to
mitigate security misconfigurations at the code level. This
includes input validation, output encoding, and proper error
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5
handling.
 5.5 Security Misconfiguration
Mitigation Strategies for Security Misconfiguration:
• Automated Testing and Scanning: Implement automated tools and
vulnerability scanners to identify and remediate security
misconfigurations proactively. Regularly scan systems, applications,
and infrastructure components for misconfigurations and
vulnerabilities.
• Security Hardening Guides: Follow security hardening guides and
recommendations provided by software vendors, industry
organizations, and regulatory bodies to secure operating systems,
databases, web servers, and other components effectively.
• Incident Response and Monitoring: Establish incident response
procedures and monitoring mechanisms to detect and respond to
security misconfigurations, breaches, or unauthorized changes
promptly. Monitor system logs, audit trails, and security events for
suspicious activities.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.4 &5.5
 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
What is Insecure Cryptographic Storage ?
• Insecure cryptographic storage refers to the improper handling
or storage of sensitive information, such as passwords,
cryptographic keys, or other confidential data, using weak
encryption methods or inadequate protection mechanisms.
• When cryptographic storage is insecure, it can lead to severe
security vulnerabilities and expose sensitive information to
unauthorized access or decryption.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 6

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Anatomy of Insecure Cryptographic Storage:
• Weak Encryption Algorithms: Using weak or outdated
encryption algorithms, such as MD5 or SHA-1, which are
vulnerable to cryptographic attacks, can compromise the
confidentiality of stored data. These algorithms can be easily
brute-forced or exploited using known vulnerabilities.
• Inadequate Key Management: Poor key management
practices, such as storing encryption keys alongside encrypted
data or using weak key generation techniques, weaken the
security of cryptographic storage. If attackers gain access to
encryption keys, they can decrypt the protected data.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 7

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Anatomy of Insecure Cryptographic Storage:
• Insufficient Key Length: Using short encryption keys or
insufficient key lengths reduces the strength of encryption and
makes it easier for attackers to perform brute-force attacks or
cryptographic attacks to recover the original data.
• Hardcoded Keys or Passwords: Embedding encryption keys or
passwords directly into source code, configuration files, or
database schemas is a common mistake that exposes sensitive
information to unauthorized access. Hardcoded keys are easily
discoverable and exploitable by attackers.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 8

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Anatomy of Insecure Cryptographic Storage:
• Unprotected Storage: Storing sensitive information, such as
passwords or cryptographic keys, in plaintext or weakly
encrypted format (e.g., Base64 encoding) in databases, files, or
other storage mechanisms without adequate protection leaves
it vulnerable to unauthorized access or disclosure.
• Insecure Transport: Transmitting sensitive data over insecure
channels or protocols without encryption (e.g., plaintext HTTP)
exposes it to interception and eavesdropping by attackers. It's
essential to encrypt data in transit using secure protocols (e.g.,
HTTPS, TLS) to protect confidentiality.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 9

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Mitigation Strategies for Insecure Cryptographic Storage:
• Use Strong Encryption Algorithms: Employ modern, widely-
accepted encryption algorithms (e.g., AES, RSA) with sufficient
key lengths and cryptographic strength to protect sensitive data
effectively. Stay updated with cryptographic best practices and
recommendations from reputable sources.
• Implement Proper Key Management: Follow secure key
management practices, such as storing encryption keys
securely in hardware security modules (HSMs), key
management systems, or using secure key vaults. Separate keys
from encrypted data and restrict access to authorized users.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 10

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Mitigation Strategies for Insecure Cryptographic Storage:
• Ensure Adequate Key Length: Use encryption keys with
sufficient length to provide adequate security against brute-
force attacks. Follow recommended key length guidelines
provided by cryptographic standards and best practices.
• Avoid Hardcoded Keys or Passwords: Refrain from embedding
encryption keys, passwords, or other sensitive information
directly into source code, configuration files, or database
schemas. Instead, use secure key storage mechanisms and
environment variables for key management.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 11

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Mitigation Strategies for Insecure Cryptographic Storage:
• Regularly Update Encryption Mechanisms: Stay informed
about cryptographic vulnerabilities, weaknesses, and updates.
Regularly update encryption libraries, algorithms, and
configurations to address known security issues and maintain a
strong security posture.
• Perform Security Audits and Assessments: Conduct regular
security audits, vulnerability assessments, and penetration
tests to identify and remediate insecure cryptographic storage
practices. Use automated scanning tools and manual reviews to
detect vulnerabilities and weaknesses.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 12

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Failure to Restrict URL Access
• Failure to restrict URL access refers to a vulnerability where
certain resources or functionalities within a web application
are accessible via direct URL manipulation, bypassing proper
authentication and authorization mechanisms.
• This oversight can lead to unauthorized access to sensitive
data, functionality, or administrative features.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 13

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Anatomy of Failure to Restrict URL Access:
• Direct Access to Protected Resources: Certain URLs within a
web application may provide access to sensitive information or
functionalities that should only be available to authenticated
and authorized users. However, if these URLs are not properly
protected, attackers can access them directly without
authentication.
• Missing Access Controls: The absence of proper access
controls, such as role-based access control (RBAC) or access
control lists (ACLs), allows anyone with knowledge of specific
URLs to access restricted resources or perform unauthorized
actions.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 14

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Anatomy of Failure to Restrict URL Access:
• Predictable URL Patterns: If URL patterns follow a predictable
structure (e.g., sequential IDs or predictable naming
conventions), attackers can guess or brute-force URLs to access
resources they are not supposed to.
• Insecure Direct Object References (IDOR): Failure to validate or
authorize user inputs used in URLs can lead to IDOR
vulnerabilities, where attackers manipulate parameters to
access unauthorized resources or manipulate data associated
with other users.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 15

 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Mitigation Strategies for Failure to Restrict URL Access:
• Role-Based Access Control (RBAC): Implement RBAC to enforce
access controls based on users' roles and permissions. Ensure
that each user is only granted access to resources and
functionalities appropriate for their role.
• Access Control Lists (ACLs): Utilize ACLs to define granular
access controls for specific resources or functionalities.
Explicitly specify which users or groups have access to each
resource and restrict access as necessary.
• Parameterized Access Control: Validate and authorize user
inputs used in URLs and requests to prevent IDOR
vulnerabilities. Implement server-side input validation and
authorization checks to ensure that users can only access
resources they are authorized to.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 16
 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Mitigation Strategies for Failure to Restrict URL Access:
• Obscure or Encrypt Sensitive URLs: If URLs contain sensitive
information, such as session tokens or user IDs, consider
obscuring or encrypting them to prevent unauthorized access
or tampering.
• Use of Access Tokens: Implement access tokens or session
identifiers that are securely generated and validated to
authenticate and authorize users. Ensure that access tokens are
properly invalidated and refreshed to prevent session fixation
or hijacking attacks.
• URL Signing: Employ URL signing techniques to ensure the
integrity and authenticity of URLs. Sign URLs with cryptographic
signatures or tokens to prevent tampering and verify the
source of requests.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 17
 5.6 Insecure Cryptographic Storage, Failure
to Restrict URL Access
Mitigation Strategies for Failure to Restrict URL Access:
• Security Headers: Utilize security headers, such as Content
Security Policy (CSP) and X-Frame-Options, to mitigate the risk
of URL-based attacks, such as clickjacking or cross-site scripting
(XSS).
• Regular Security Testing: Conduct regular security
assessments, including penetration testing and code reviews,
to identify and remediate vulnerabilities related to URL access
controls. Use automated tools and manual testing techniques
to identify misconfigurations and weaknesses.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 18

 5.7 Tools: Comodo, OpenVAS, Nexpose,
Nikto, Burp Suite
Tools:
The tools serve various purposes in the realm of cybersecurity,
including vulnerability scanning, web application testing, network
analysis, and more.
• Comodo
• OpenVAS
• Nexpose
• Nikto
• Burp Suite

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 19

 5.7 Tools: Comodo, OpenVAS, Nexpose,
Nikto, Burp Suite
Comodo: Comodo offers a suite of cybersecurity products and services
designed to protect endpoints, networks, and online transactions. Some
key offerings include:
•Antivirus Software: Comodo provides antivirus solutions that detect
and remove malware, viruses, and other threats from endpoints.
•Firewall Protection: Comodo Firewall protects against unauthorized
access and malicious activities by monitoring network traffic and blocking
suspicious connections.
•Endpoint Security: Comodo Endpoint Security solutions offer
comprehensive protection for endpoints against malware, ransomware,
and zero-day threats.
•SSL Certificates: Comodo SSL certificates provide encryption and
authentication for websites, ensuring secure online transactions and
protecting sensitive data.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 20

 5.7 Tools: Comodo, OpenVAS, Nexpose,
Nikto, Burp Suite
OpenVAS (Open Vulnerability Assessment System): OpenVAS is an open-
source vulnerability scanning tool that helps organizations identify and
manage security vulnerabilities in their IT infrastructure. Key features
include:
• Network Scanning: OpenVAS scans networks for open ports, services,
and vulnerabilities, helping organizations identify potential security risks.
• Vulnerability Detection: OpenVAS detects common vulnerabilities,
misconfigurations, and weaknesses in network devices, servers, and
applications.
• Comprehensive Reports: OpenVAS generates detailed reports that
highlight identified vulnerabilities, severity levels, and remediation
recommendations.
• Integration: OpenVAS integrates with other security tools and platforms,
allowing organizations to incorporate vulnerability scanning into their
overall security workflows.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 21
 5.7 Tools: Comodo, OpenVAS, Nexpose,
Nikto, Burp Suite
Nexpose (InsightVM): Nexpose, now known as InsightVM, is a
vulnerability management solution developed by Rapid7. It offers
advanced capabilities for vulnerability assessment, risk prioritization, and
remediation. Key features include:
• Asset Discovery: Nexpose automatically discovers and inventories assets
within an organization's IT environment, including devices, servers, and
applications.
• Vulnerability Scanning: Nexpose conducts vulnerability scans to identify
security weaknesses, misconfigurations, and outdated software versions
across the IT infrastructure.
• Risk Prioritization: Nexpose prioritizes identified vulnerabilities based on
severity, exploitability, and potential impact, helping organizations focus on
addressing the most critical security risks.
• Remediation Guidance: Nexpose provides actionable recommendations and
guidance for remediating identified vulnerabilities, enabling organizations to
mitigate security risks effectively.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 22
 5.7 Tools: Comodo, OpenVAS, Nexpose,
Nikto, Burp Suite
Nikto: Nikto is an open-source web server scanner that helps organizations
identify and remediate security vulnerabilities in web servers and web
applications. Key features include:
• Comprehensive Scanning: Nikto scans web servers and web applications
for common vulnerabilities, including outdated software versions,
misconfigurations, and known security weaknesses.
• Web Server Fingerprinting: Nikto performs web server fingerprinting to
identify the type, version, and configuration of web servers, providing
valuable insights for security assessments.
• Vulnerability Detection: Nikto detects various vulnerabilities, such as
SQL injection, cross-site scripting (XSS), directory traversal, and server
misconfigurations, helping organizations secure their web infrastructure.
• Customization: Nikto offers flexibility and customization options,
allowing users to specify scan parameters, exclude certain tests, and
tailor the scanning process to their specific requirements.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 23
 5.7 Tools: Comodo, OpenVAS, Nexpose,
Nikto, Burp Suite
Burp Suite: Burp Suite is a leading web application security testing tool
developed by PortSwigger. It offers a comprehensive suite of features
for web security testing, including:
• Proxy Server: Burp Suite acts as a proxy server, intercepting and
modifying HTTP/S requests and responses between clients and web
servers, facilitating manual security testing and analysis.
• Web Vulnerability Scanner: Burp Suite includes a web vulnerability
scanner that automates the detection of security vulnerabilities,
such as SQL injection, XSS, CSRF, and insecure direct object
references (IDOR).
• Web Application Spider: Burp Suite's web application spider crawls
web applications to identify and map out the site's structure,
helping testers understand the application's functionality and attack
surface.
MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 24
 5.7 Tools: Comodo, OpenVAS, Nexpose,
Nikto, Burp Suite
Burp Suite:
• Intruder: Burp Suite's Intruder tool performs automated attacks,
such as brute-force attacks, parameter fuzzing, and payload
manipulation, to identify vulnerabilities and security weaknesses in
web applications.
• Repeater: Burp Suite's Repeater tool allows testers to manipulate
and replay individual HTTP/S requests, enabling detailed analysis
and testing of specific functionalities within web applications.

MZCET/CSE/VI Sem/CCS374_WAS/Unit 5/5.6 &5.7 25