Security Interview Prep Series — 5. Application Security

Cross-Site Scripting (XSS)

XSS is a vulnerability where an attacker injects a malicious script into a trusted website or application, which then executes in the victim’s browser.

Target: Victim’s browser

Exploitation vector: Input fields, URLs or scripts on the website

Types:

1. Stored XSS: Malicious script is permanently stored on the server and served to users.
2. Reflected XSS: Malicious script is part of the request and reflected in the response.
3. DOM-based XSS: The script is executed on the client side, manipulated in the browser’s DOM.
4. Blind XSS: The attacker injects malicious code into a page that is not directly visible to the user.

Security risks: Steal cookies, session tokens or execute unauthorized actions in the context of the user.

Prevention: Input validation, output encoding, CSP

Cross-Site Request Forgery (CSRF)

CSRF tricks authenticated users into performing unintended actions on a web application where they are logged in.

Target: Victim’s authenticated session.

Exploitation vector: Forged requests sent to the server

How it works: Attacker crafts a malicious link or form that, when visited, sends requests using the victim’s credentials (e.g. transfer funds)

Security risks: Execute state-changing(unauthorized) actions without user consent.

Prevention: CSRF tokens, SameSite cookies, User confirmation

XML External Entity (XXE)

XXE is a security vulnerability that exploit XML parsers’ capability to process external entities. An attacker can manipulate an XML input to access sensitive files, execute remote code, or perform DDoS

How it works: An application processes an XML document provided by the attacker. The XML includes a reference to an external entity (e.g. a local file or remote resource). The parser resolves the entity and exposes sensitive data or performs unintended actions.

Security risks: File disclosure, SSRF, remote code execution

Prevention: Disable external entity processing in XML parsers (DisallowDoctypeDecl). Use secure libraries (e.g. defuse/xml). Validate and sanitize XML input.

Server Side Request Forgery (SSRF)

SSRF is a vulnerability where an attacker tricks a server into making unauthorized (outgoing) requests to internal or external resources (makes requests originate from server).

How it works: The attacker sends a crafted request to an endpoint that fetches resources from URLs. The server performs the request, potentially exposing internal services or sensitive data.

Security risks: Unauthorized actions, RCE, access data, cloud metadata exfiltration, internal network scanning

Prevention: Sanitize user input, no raw responses, no redirects, use allowlist, restrict allowed outbound requests, use network firewalls to block unnecessary traffic

Same-Origin policy (SOP)

A security feature that restricts web scripts from accessing data from a different origin (protocol, domain or port).

Example: A script from https://example.com cannot access https://anotherexample.com directly

Usage: Prevents XSS and CSRF attacks.

Cross-Origin Resource Sharing (CORS)

CORS allows controlled access to resources across origins using HTTP/HTTPS headers.

How it works: The server sends CORS headers (e.g. Access-Control-Allow-Origin). The browser enforces restrictions based on these headers.

Usage: API(s) allowing cross-origin access.

Code review a project and look for vulnerabilities

• Understand the scope: Determine the purpose of the app, its dependencies and the sensitive data it processes.
• Focus areas:

1. Authentication & authorization: Look for hardcoded credentials, improper session handling or missing access controls.
2. Input validation: Check for unsanitized input that could lead to injection attacks (e.g., SQLi, XSS)
3. Sensitive data handling: Ensure proper encryption for data at rest and in transit; look for exposed secrets.
4. Error handling: Inspect error messages for leakage of stack traces or sensitive information.
5. Dependency vulnerabilities: Review package versions for known CVEs and outdated libraries.

• Automation tools: Use static analysis tools (e.g. SonarQube, Snyk, Checkmarx) to flag vulnerabilities
• Testing: Validate identified risks through proof-of-concept exploits or fuzz testing.

How would you conduct a security code review?

1. Preparation: Understand the application architecture, frameworks and programming languages used. Identify critical components and areas that process sensitive data.
2. Automated scanning: Run static analysis tools to identify common vulnerabilities (e.g., Flawfinder, CodeQL). Scan for hardcoded credentials, misconfigurations and insecure dependencies.
3. Manual review: Authentication (validate secure password storage and session management). Input validation (look for unescaped inputs, improper data type checks or injection risks). Error messages (ensure exceptions do not reveal system data).
4. Review business logic: Ensure that access control, workflows and calculations are implemented securely.
5. Dependency analysis: Check 3rd party libraries and frameworks for vulnerabilities.
6. Document the findings.

How can Github webhooks be used in a malicious way?

1. Sensitive payload exposure: If webhook payloads are sent over with HTTP or without authentication, an attacker can intercept sensitive data such as commit information or user credentials.
2. Code execution: If the webhook triggers automated scripts (e.g. CI/CD pipelines), an attacker could manipulate payload to execute malicious commands on the server.
3. DoS attacks: An attacker can spam webhook endpoints, overwhelming the server.
4. Unauthorized access: If access tokens or secrets are exposed, attackers can abuse them to trigger unauthorized access.
5. Mitigation: Use HTTPS for webhooks. Validate payload signatures. Restrict webhook events to essential ones. Implement rate limiting on the receiving server.

If I hand you a repo of source code to security audit, what’s the first few things you would do?

1. Set up the environment: Clone the repository and review its README for setup instructions. Identify the dependencies and ensure that they are compatible with your tools.
2. Understand the application: Review the architecture and identify the key components. Map out inputs, output and data flows.
3. Automated scans: Run static code analysis tools to flag vulnerabilities and hard-coded secrets. Use dependency scanning tools to identify CVEs in 3rd-party libraries.
4. Review key areas: Authentication and session management. Input validation and output encoding. API security and access controls.
5. Focus on sensitive files: Configuration files, scripts, .env, .gitignore.
6. Look for sensitive secrets: Use secret-scanning tools to identify exposed tokens or keys.

Can I write a tool that would search our Github repos for secrets, keys, etc?

Steps to build the tool:

1. Repository access: Use the Github API to clone or list files in repositories.
2. Secret patterns: Define regex patterns for secrets (e.g. AWS keys, database credentials).
3. Entropy analysis: Detect strings with high randomness, including potential keys.
4. Reporting: Log and alert on findings, categorizing them by severity.
5. Existing tools: truffleHog, git-secrets or Gitleaks.
6. Enhancements: Integrate with CI/CD pipelines for continuous scanning. Implement notifications for newly pushed secrets.

Slack vulnerability exposing secrets in public repositories

1. Attack scenario: Sensitive tokens or webhook URLs for slack are inadvertently committed to a Github repository. An attacker searches public repositories for Slack-specific patterns (e.g., xoxp- tokens). With the token, the attacker can impersonate users, post messages, or exfiltrate sensitive conversations.
2. Mitigation: Use secret-scanning tools to prevent exposed tokens. Rotate tokens regularly. Restrict token permissions to essential scopes.

If You Were Going to Break Into a Database-Based Website, How Would You Do It?

Ethical context: Assume this is for understanding vulnerabilities to secure the system.

Approach:

1. SQL Injection: Attempt to inject malicious SQL queries in input fields to access or manipulate the database. Example: ‘ OR 1=1 — .

2. Default Credentials: Check for weak or default admin credentials.

3. Exposed Endpoints: Identify insecure APIs or endpoints revealing database details.

4. Unpatched Vulnerabilities: Exploit known CVEs in the database or web application framework.

5. Brute Force: Attempt to guess database credentials if protections are weak.

Mitigation: Use parameterized queries, WAFs, and strong authentication.

Are Open-Source Projects More or Less Secure Than Proprietary Ones?

Open-Source Security:

• Pros: Transparent code allows for community-driven vulnerability discovery and fixes. Regular updates from a broad user base.
• Cons: Potentially faster exploitation if vulnerabilities are discovered and disclosed irresponsibly. Dependency on community support for timely patches.
• Proprietary Security:
• Pros: Controlled access to source code reduces exposure to attackers. Dedicated support for maintenance and patches.
• Cons: Security flaws may remain hidden due to lack of public scrutiny. Patches may be slower without external contributions.

Verdict: Security depends on how well the project is maintained, regardless of being open-source or proprietary.

Describe the Last Program or Script You Wrote, What Problem Did It Solve? (Need to change the answer)

Example: Wrote a Python script to automate vulnerability scans across a network.

• Problem: Manual scanning was time-intensive and prone to errors.
• Solution:
• Integrated nmap for network scanning and OpenVAS for vulnerability detection.
• Output organized into a structured CSV report for analysis
• Impact: Reduced scanning time by 70% and provided a consistent, error-free process.

Role of Information Security in Each Phase of the SDLC

1. Planning: Conduct risk assessments and define security requirements.
2. Design: Implement secure architecture and threat modeling (e.g., STRIDE).
3. Development: Enforce secure coding practices (e.g., input validation, avoiding hardcoded secrets).
4. Testing: Perform vulnerability scans, penetration testing, and code reviews.
5. Deployment: Configure secure environments (e.g., firewalls, encryption).
6. Maintenance: Continuously monitor and patch vulnerabilities.

How Would You Implement a Secure Login Field on a High-Traffic Website Where Performance Is a Consideration?

1. Use HTTPS: Encrypt communication to secure credentials during transmission.
2. Input Validation: Sanitize inputs to prevent injection attacks.
3. Rate Limiting: Throttle requests to mitigate brute force attacks.
4. Hashing Passwords: Use strong algorithms like bcrypt with per-user salts.
5. Token-Based Authentication: Reduce reliance on session state by using JWTs.
6. Performance Optimization: Use lightweight encryption (e.g., TLS 1.3) and caching for login-related assets.

What Are the Various Ways to Handle Account Brute Forcing?

1. Rate Limiting: Restrict the number of login attempts per IP.
2. Account Lockout: Temporarily lock accounts after repeated failed attempts.
3. MFA: Implement multi-factor authentication for added security.
4. Captcha: Use CAPTCHAs to differentiate between humans and bots.
5. Logging and Monitoring: Detect and block suspicious login patterns.
6. Password Policies: Enforce strong password requirements.

What Is Cross-Site Request Forgery (CSRF)?

CSRF is an attack where an authenticated user is tricked into performing unauthorized actions on a website.

Example: A user logged into their bank account clicks a malicious link, unknowingly transferring money to an attacker.

How Does One Defend Against CSRF?

1. CSRF Tokens: Include unique, per-session tokens in forms to verify legitimate requests.
2. SameSite Cookies: Restrict cookies from being sent in cross-origin requests.
3. User Confirmation: Require re-authentication for sensitive actions.

If You Were a Site Administrator Looking for Incoming CSRF Attacks, What Would You Look For?

1. Absence of CSRF Tokens: Requests lacking valid CSRF tokens.
2. Referrer Headers: Cross-origin requests from untrusted sources.
3. Suspicious Patterns: Unusual or unauthorized state-changing actions.

What’s the Difference Between HTTP and HTML?

HTTP (Hypertext Transfer Protocol): A protocol for transferring data between a client and server.

HTML (Hypertext Markup Language): A language used to structure content on the web.

How Does HTTP Handle State?

HTTP is Stateless: It does not retain information about previous interactions.

State Management Techniques: Cookies, Sessions, URL parameters.

What Exactly Is Cross-Site Scripting (XSS)?

XSS is a vulnerability where an attacker injects malicious scripts into a trusted website, which then executes in a user’s browser.

Impact: Stealing cookies, session tokens, or executing malicious actions.

What’s the Difference Between Stored and Reflected XSS?

Stored XSS: The malicious script is permanently stored on the server and executed whenever accessed (e.g., in a database).

Reflected XSS: The script is embedded in a request and reflected back to the user without being stored.

Common Defenses Against XSS

1. Input Validation and Output Encoding: Sanitize and encode inputs.
2. Content Security Policy (CSP): Restrict script execution to trusted sources.
3. Escaping Data: Use proper escaping functions for HTML, JavaScript, and CSS.