1) Explain A1 Injection vulnerabilities, risks, causes, and mitigation.

A1 Injection Vulnerabilities
1. Definition
Injection vulnerabilities occur when untrusted input is sent to an interpreter (such as SQL, OS shell,
LDAP, or XML parser) and is processed as part of a command or query. This allows attackers to alter
the intended logic of the command.
2. Examples
 SQL Injection – Modifying database queries.
 Command Injection – Executing OS-level commands.
 LDAP Injection – Altering directory service queries.
 NoSQL Injection – Exploiting NoSQL databases.
 XPath Injection – Manipulating XML queries.
3. Risks
 Data Theft – Accessing sensitive information.
 Data Manipulation – Inserting, updating, or deleting records.
 Authentication Bypass – Logging in without valid credentials.
 Remote Code Execution – Running malicious system commands.
 Complete System Compromise – Gaining full control over the server.
4. Causes
 Lack of proper input validation.
 Building queries by concatenating user input directly.
 Overtrusting client-side validation.
 Failure to escape special characters in input.
 Use of insecure APIs or legacy systems.
5. Mitigation Measures
 Parameterized Queries / Prepared Statements – Pass data as parameters, not as part of the
query.
 Input Validation & Whitelisting – Allow only acceptable formats and values.
 Escaping and Encoding – Properly handle special characters before processing.
 Least Privilege Principle – Restrict database permissions to the minimum required.
 Security Testing – Regular vulnerability scans and penetration testing.
6. Conclusion
Injection vulnerabilities are among the most critical security risks due to their potential for severe data
breaches and system compromise. Preventing them requires secure coding practices, strict validation,
and continuous testing.
---------------------------------------------------------------------------------------------------------------------------
2) Compare A2 Broken Authentication with A5 Broken Access Control.

No. Aspect A2: Broken Authentication A5: Broken Access Control

Insecure authentication and session

Failure to enforce proper permissions,
1 Definition management, allowing attackers to
allowing unauthorized resource access.
impersonate users.

Authorization – “What are you

2 Primary Focus Identity verification – “Who are you?”
allowed to do?”

Ensuring only valid users can log in Ensuring users cannot exceed their
3 Main Concern
and maintain secure sessions. granted privileges.

Login forms, session IDs, password Sensitive data endpoints, restricted

4 Attack Target
reset mechanisms. functions, admin panels.

Weak passwords, no MFA, predictable Missing server-side access checks,

Common
5 session tokens, insecure password insecure direct object references, poor
Causes
storage. role-based control.

Exploitation Credential stuffing, brute-force attacks, URL manipulation, parameter

6
Method session hijacking, phishing. tampering, privilege escalation.

Attacker logs in as admin using stolen Normal user accesses /admin page
7 Example
session token. without permission.

Leads to account takeover and identity Leads to data leakage or system

8 Risk Level
theft. control takeover.

Affects individual user accounts but

Can affect the entire application and all
9 Impact Scope may escalate if admin accounts are
user data.
compromised.

Monitor failed login attempts, check Test for access to restricted pages
10 Detection
for unusual session activity. without proper credentials.

Use MFA, strong password policy, Implement role-based access control

Prevention
11 secure session handling, hashing (RBAC), server-side validation, least
Techniques
passwords. privilege principle.

Brute force simulation, session Penetration testing with privilege

12 Testing Methods
hijacking testing. escalation attempts.

OWASP
13 A2 in OWASP Top 10. A5 in OWASP Top 10.
Category

Primary CAPTCHA, account lockout, session Access control middleware, API

14
Mitigation Tools timeouts. gateway authorization.

15 Final Goal of Impersonate another user. Perform actions or access data not
No. Aspect A2: Broken Authentication A5: Broken Access Control

Attacker allowed to them.

3) Demonstrate how XSS attacks work and how they can be prevented.

XSS Attacks – Working and Prevention

1. Definition
Cross-Site Scripting (XSS) is a web security vulnerability that allows attackers to inject malicious
scripts into web pages viewed by other users. These scripts are executed in the victim’s browser,
enabling data theft or unauthorized actions.
2. How XSS Works
1. Attacker injects malicious script into a vulnerable website (e.g., via a comment box or
search field).
2. Website displays the script without proper sanitization.
3. Victim visits the page, and the injected script runs in their browser.
4. Script can steal cookies, redirect to malicious sites, or modify page content.
3. Types of XSS
 Stored XSS – Script is permanently stored on the server (e.g., in a database).
 Reflected XSS – Script comes from the URL or request and is reflected back in the response.
 DOM-based XSS – Script is executed due to insecure handling of data in the browser’s
Document Object Model.
4. Risks
 Theft of session cookies and account hijacking.
 Defacement of web pages.
 Redirection to phishing or malicious websites.
 Execution of arbitrary browser actions without user consent.
5. Prevention Methods
1. Input Validation – Allow only expected data formats (e.g., numbers, specific characters).
2. Output Encoding – Encode special characters (<, >, ", ') before displaying user input.
3. Use Security Libraries – Use frameworks or libraries with built-in XSS protection (e.g.,
OWASP ESAPI).
4. Content Security Policy (CSP) – Restrict the sources from which scripts can run.
5. Avoid Dangerous Functions – Minimize use of eval() or innerHTML without sanitization.
6. Conclusion
XSS is one of the most common and dangerous web vulnerabilities, but it can be effectively prevented
through proper input handling, output encoding, and secure coding practices.
---------------------------------------------------------------------------------------------------------------------------
4) Describe Sensitive Data Exposure and mitigation strategies.

Sensitive Data Exposure – Description and Mitigation

1. Definition
Sensitive Data Exposure occurs when sensitive information such as personal details, financial data,
health records, or credentials is not adequately protected and becomes accessible to unauthorized
parties. This may happen during storage, transmission, or processing.
2. Examples of Sensitive Data
 Personal Identifiable Information (PII) – Name, address, phone number, etc.
 Financial Data – Credit card numbers, bank account details.
 Authentication Data – Passwords, session tokens, security answers.
 Health Records – Medical history, prescriptions.
3. Causes
 Storing sensitive data without encryption.
 Using weak or outdated encryption algorithms.
 Transmitting data over insecure channels (e.g., HTTP instead of HTTPS).
 Improper key management.
 Exposure through logs, backups, or error messages.
4. Risks
 Identity theft and financial fraud.
 Unauthorized account access.
 Legal penalties under data protection laws (e.g., GDPR).
 Damage to reputation and customer trust.
5. Mitigation Strategies
1. Data Encryption – Use strong encryption algorithms (AES-256, RSA) for data in storage and
transmission.
2. Secure Protocols – Use HTTPS/TLS for communication.
3. Minimal Data Storage – Store only the required sensitive information.
4. Proper Key Management – Protect encryption keys using hardware security modules or
secure vaults.
5. Masking and Tokenization – Replace sensitive data with non-sensitive substitutes for
processing.
6. Access Control – Limit who can access sensitive information.
 7. Regular Security Audits – Test systems for potential leaks.
6. Conclusion
Sensitive Data Exposure is a critical security threat that can lead to severe consequences if exploited.
Strong encryption, secure communication, minimal storage, and strict access control are essential to
protect sensitive information.
---------------------------------------------------------------------------------------------------------------------------
5) Summarize XML External Entity (XXE) vulnerability with an example.

XML External Entity (XXE) Vulnerability

1. Definition
XML External Entity (XXE) is a security vulnerability that occurs when an XML parser processes
input containing a reference to an external entity. Attackers can exploit it to access local files, perform
denial-of-service attacks, or interact with internal systems.
2. How it Works
 Applications that parse XML without secure configurations may allow XML documents to
define external entities.
 These entities can point to local files, remote resources, or system commands.
 The parser retrieves and processes the external content, exposing sensitive data or enabling
other attacks.
3. Common Causes
 Using older or insecure XML parsers with default settings.
 Failing to disable external entity processing.
 Accepting XML input from untrusted sources without validation.
4. Risks
 Disclosure of local files and sensitive data.
 Server-Side Request Forgery (SSRF).
 Denial of Service (Billion Laughs attack).
 Remote code execution in severe cases.
Explanation:
 The attacker defines an external entity xxe that points to /etc/passwd (a system file).
 When the parser processes this, it replaces &xxe; with the file’s contents, exposing sensitive
system data.
5. Mitigation Strategies
1. Disable external entity resolution in XML parsers.
2. Use secure XML libraries and keep them updated.
3. Validate and sanitize XML input before processing.
 4. Use less complex data formats like JSON when possible.
6. Conclusion
XXE vulnerabilities can be highly dangerous, leading to sensitive data leakage and system
compromise. Secure XML parser configuration and strict input validation are the primary defenses.

6) Analyze A6 Security Misconfiguration in web applications.

A6 Security Misconfiguration – Analysis

1. Definition
Security Misconfiguration occurs when security settings in web applications, servers, databases, or
frameworks are improperly set, left at insecure defaults, or not updated. It is one of the most
common vulnerabilities in web applications.
2. Causes
 Using default credentials and passwords.
 Unnecessary features enabled (e.g., directory listing, debug mode).
 Outdated software or components.
 Improper file permissions.
 Detailed error messages exposing system details.
 Lack of regular security configuration reviews.
3. Risks
 Unauthorized access to sensitive functions or data.
 Exposure of system information that aids attacks.
 Increased attack surface due to unused services or open ports.
 Exploitation of outdated software vulnerabilities.
4. Examples
 Admin panel accessible with default username and password.
 Application running with unnecessary open ports.
 Detailed stack traces shown in production environment.
 Using outdated CMS versions with known vulnerabilities.
5. Mitigation Strategies
1. Change Default Credentials – Use strong, unique passwords.
2. Disable Unused Features – Turn off directory listing, debug mode, and unnecessary
services.
3. Keep Software Updated – Apply patches regularly.
4. Enforce Least Privilege – Grant minimal required permissions to users and services.
5. Secure Error Handling – Display generic error messages to users.
6. Regular Configuration Audits – Review and test security settings periodically.
6. Conclusion
Security misconfiguration is a preventable vulnerability, but negligence in settings, updates, and
reviews makes applications easy targets. Following secure configuration guidelines and
performing regular audits are essential to protect web applications.

7) Discuss CSRF attacks and prevention techniques with real examples.

CSRF Attacks – Discussion and Prevention

1. Definition
Cross-Site Request Forgery (CSRF) is a web security attack where an attacker tricks a victim into
unknowingly performing actions on a web application where they are already authenticated. This
exploits the trust that a website has in the user’s browser.
2. How CSRF Works
 1. Victim logs into a legitimate website (e.g., online banking).
2. Without logging out, the victim visits a malicious website controlled by the attacker.
3. The malicious site sends a hidden request to the legitimate site using the victim’s active
session.
4. The action (e.g., money transfer) is performed without the victim’s consent.
3. Real Example
 A logged-in bank user visits a malicious page containing:

Html code:

<img src="https://bank.com/transfer?amount=5000&to=attacker" />

When the victim’s browser loads the page, it automatically sends the request with the victim’s
session cookies, transferring money to the attacker.
4. Risks
 Unauthorized fund transfers.
 Changing account details or passwords.
 Purchasing items without consent.
 Privilege escalation in admin accounts.
5. Prevention Techniques
1. CSRF Tokens – Include unique, unpredictable tokens in forms and verify them on the server.
2. SameSite Cookies – Set cookies with the SameSite attribute to prevent cross-site sending.
3. Re-authentication for Critical Actions – Ask for password or OTP before sensitive
transactions.
4. Check Referer and Origin Headers – Verify requests come from the same domain.
5. User Logout on Inactivity – Reduce session hijacking chances.
6. Conclusion
CSRF attacks exploit user trust in a website and can cause severe unauthorized actions.
Implementing CSRF tokens, secure cookies, and strict verification measures are effective defenses.

--------------------------------------------------------------------------------------------------------------------------

8) Identify the dangers of using components with known vulnerabilities.

Dangers of Using Components with Known Vulnerabilities

1. Definition
This vulnerability occurs when applications use libraries, frameworks, software modules, or other
components that have publicly known security flaws. Attackers can exploit these flaws to
compromise systems.

2. Causes
 Failure to update third-party libraries and frameworks.
 Using unsupported or outdated software.
 Not monitoring vulnerability databases (e.g., NVD, CVE).
 Including unnecessary or unused components.

3. Dangers / Risks
1. Remote Code Execution – Attackers can run malicious code on the server.
2. Data Breach – Sensitive information can be stolen.
3. System Compromise – Entire application or server can be taken over.
4. Malware Injection – Vulnerable components may allow malicious uploads or downloads.
5. Denial of Service (DoS) – Exploitation of known flaws can crash the system.
6. Privilege Escalation – Attackers gain higher access than intended.
 7. Regulatory Violations – Non-compliance with security standards like GDPR or PCI-DSS.

4. Real Example
 Equifax Breach (2017) – Caused by failure to patch a known vulnerability in Apache Struts,
leading to theft of millions of personal records.

5. Mitigation Strategies
1. Regular Updates – Keep all components up-to-date with latest patches.
2. Use Trusted Sources – Download components from verified repositories.
3. Remove Unused Components – Reduce attack surface.
4. Vulnerability Scanning – Use tools to detect outdated dependencies.
5. Maintain Software Inventory – Track all components and their versions.

6. Conclusion
Using components with known vulnerabilities is dangerous because exploits are often public,
making attacks easier. Regular updates, secure sourcing, and vulnerability scanning are essential to
prevent such risks.

---------------------------------------------------------------------------------------------------------------------------
9) Evaluate the role of secure design principles in modern software development.

Secure Design Principles – Role in Modern Software Development

1. Definition
Secure design principles are guidelines that ensure security is built into software from the very
beginning of the development lifecycle, rather than added later as a patch or fix.

2. Importance in Modern Development

With increasing cyber threats, integrating security into the design phase is critical to prevent
vulnerabilities, reduce costs of fixing issues later, and ensure compliance with regulations.

3. Key Secure Design Principles and Their Role

Principle Role in Modern Development
Ensures each user or component has only the access necessary to perform its
Least Privilege
function, reducing potential damage from breaches.
Defense in Uses multiple layers of security (e.g., firewalls, authentication, encryption) so
Depth that failure of one layer does not compromise the system.
Fail-Secure Configures systems to deny access by default and grant it only when
Defaults explicitly allowed, minimizing unauthorized actions.
Separation of
Distributes responsibilities among different roles to prevent fraud and misuse.
Duties
Secure by Ships software with secure settings enabled, reducing risk from
Default misconfiguration.
Regular
Designs systems for easy patching and updating to address emerging threats.
Updates
Input Prevents attacks like SQL injection and XSS by checking and sanitizing all
Validation user input.

4. Benefits
 Reduces security vulnerabilities early in the SDLC.
 Lowers long-term maintenance costs.
 Improves trust and customer confidence.
 Helps meet compliance and legal requirements.
 5. Conclusion
Secure design principles are a foundation of modern software development. They ensure that
applications are resilient against attacks, maintain integrity, and protect sensitive data from
evolving cyber threats.

---------------------------------------------------------------------------------------------------------------------------
10) Develop a secure application plan using threat modeling and Microsoft SDL.

Secure Application Plan – Using Threat Modeling & Microsoft SDL

1. Introduction
Building secure applications requires identifying potential threats early and embedding security
into every stage of development. Threat modeling and the Microsoft Security Development
Lifecycle (SDL) provide structured approaches to achieve this.

2. Threat Modeling
Definition: A systematic process to identify, evaluate, and address security risks in an application.
Steps:
1. Identify Assets – Determine what needs protection (data, systems).
2. Create an Architecture Diagram – Understand data flows and system components.
3. Identify Threats – Use frameworks like STRIDE (Spoofing, Tampering, Repudiation,
Information Disclosure, Denial of Service, Elevation of Privilege).
4. Assess Risks – Rank threats based on impact and likelihood.
5. Define Mitigations – Plan security controls to reduce or eliminate risks.

3. Microsoft SDL (Security Development Lifecycle)

Overview: A set of practices integrated into the software development process to reduce
vulnerabilities.
Key Stages:
1. Training – Educate developers on secure coding and security tools.
2. Requirements – Define security and privacy requirements early.
3. Design – Apply threat modeling to plan defenses.
4. Implementation – Use secure coding practices and code analysis tools.
5. Verification – Perform security testing (static, dynamic, penetration).
6. Release – Establish a secure deployment plan.
7. Response – Prepare incident response procedures for vulnerabilities.

4. Secure Application Plan (Integrated Approach)

Step Action
1. Requirements
Identify security goals, compliance needs, and privacy requirements.
Phase
Perform threat modeling, identify STRIDE threats, and plan
2. Design Phase
mitigations.
3. Development Follow secure coding standards, use safe libraries, and apply SDL
Phase coding practices.
4. Testing Phase Conduct static/dynamic analysis and security penetration testing.
Configure systems securely, enable monitoring, and apply least
5. Deployment Phase
privilege.
6. Maintenance
Continuously patch vulnerabilities and update threat models.
Phase

5. Conclusion
By combining Threat Modeling with Microsoft SDL, organizations can proactively identify and
mitigate security risks, ensuring that applications remain secure throughout their lifecycle.