Security Engineer Interview Questions Part-1

Hi Everyone,

With 5+ years of experience in the field of security, I’ve had the opportunity to participate in numerous interviews for Security Engineering roles. Throughout these experiences, I have collected some unique and amazing questions which were asked in the interview which tests both technical knowledge and practical application.

I’m sharing a curated series of questions with answers asked in good companies such as Big 4s, Amazon, Google, Cisco etc.

1. With IDS (Intrusion Detection System), IPS (Intrusion Prevention System), and WAF (Web Application Firewall) in your architecture, how should these components be positioned in sequence?

The ideal placement should look like this :

Reason Behind :

1. The WAF is placed at the front, directly facing web traffic coming from the internet acting as first line of defense, protecting against application-layer attacks like SQLi, (XSS), and other threats.
2. Behind WAF, the IPS should be deployed as it actively monitors incoming traffic and blocks known attack patterns, protecting the system from threats like malware, DoS attacks, and network-based attacks. Since the IPS is capable of taking preventive action, it comes after the WAF to handle more sophisticated attacks that may bypass WAF.
3. The IDS is placed in passive mode as it monitors and analyzes traffic for potential intrusions but does not actively block threats. The IDS will alert administrators if it detects suspicious activity, allowing for further investigation and action if needed. It typically sits deeper in the network, monitoring both internal traffic and residual threats that may have bypassed the IPS.

In summary, the sequence is WAF -> IPS -> IDS to ensure layered protection, with each system targeting different types of threats in your security architecture.

2. What is the importance of using Parameterized Queries and Prepared Statements in preventing SQL Injection attacks?

1. Parameterized queries and prepared statements prevent this by strictly separating the SQL code from the user inputs. This ensures that user inputs are always treated as data, not executable code.
2. Prepared statements automatically handle special characters (like quotes) in user inputs, making it impossible for attackers to alter the structure of the SQL query.
3. Prepared statements allow developers to write consistent and secure SQL queries that can be reused, reducing the chance of SQL injection.
4. Since prepared statements compile the SQL query before execution, it prevents tampering with the query’s structure, blocking attempts to inject malicious code.

3. What is the difference between Buffer Overflow & Stack Overflow ?

Buffer overflow occurs when a program writes more data to a buffer (temporary storage area) than it can hold and stack overflow occurs when the stack exceeds its capacity, often due to deep or infinite recursion.

Major Difference

Buffer Overflow can happen in any type of memory, including the stack, heap, or static memory and Stack Overflow specifically happens in the stack segment of memory.

Stack Overflow is a subset of Buffer overflows and both can lead to memory corruption, crashing the program and also allows attackers to perform remote code execution.

4. What are the various sources and sink for DOM Based XSS?

When the web application’s client-side JavaScript dynamically modifies the HTML document based on user-controlled inputs (sources) without properly sanitizing or validating the data before rendering (sinks), it results in DOM based XSS.

→ Understanding the sources and sinks in a DOM XSS attack

Sources

A source in DOM XSS is any part of the browser environment from which untrusted or user-controllable data can be read or accessed by JavaScript.

a) URL and Location Objects

These include different parts of the URL, which can be controlled by the user and accessed by JavaScript.

• window.location: Represents the entire URL of the current page.

var url = window.location; document.write(url);

• window.location.hash: Represents the fragment identifier (#)

var hash = window.location.hash; document.write(hash);

• window.location.search: Represents the query string of the URL

var query = window.location.search; document.write(query);

b) Document Properties

• document.URL: The current document’s URL.

var url = document.URL; document.write(url);

• document.referrer: The URL of the page that referred the current page

var referrer = document.referrer; document.write(referrer);

c) Cookies

Cookies can be read and manipulated by JavaScript.

• document.cookie: The current cookies can be accessed via this object.

var cookies = document.cookie; document.write(cookies);

d) User-Provided Inputs

• document.forms[]: Represents the HTML form elements & their values.

var input = document.forms[0].elements[0].value; document.write(input);

e) DOM Elements

• element.innerHTML: The HTML content of a specific DOM element.

var content = element.innerHTML; document.write(content);

f) Other Client-Side JavaScript APIs

• window.name: This can be controlled across different pages and domains.

var name = window.name; document.write(name);

• localStorage / sessionStorage: These objects store data that persists across browser sessions and can be accessed via JavaScript.

var data = localStorage.getItem('key'); document.write(data);

Sinks

A sink is any part of the browser environment where user-controlled data is inserted or executed without proper validation or sanitization.

a) HTML Manipulation Methods

These methods are used to modify or inject HTML content into the DOM, and can lead to DOM XSS if user input is injected directly into them.

• element.innerHTML: Inserts HTML content into an element.

element.innerHTML = userInput;

• document.write(): Writes content directly to the document.

document.write(userInput);

• element.outerHTML: Replaces the element and its content with new HTML.

element.outerHTML = userInput;

• element.insertAdjacentHTML(): Inserts HTML into a specified position relative to the element.

element.insertAdjacentHTML('beforeend', userInput);

b) JavaScript Code Execution Sinks

These sinks allow JavaScript to execute arbitrary code, making them highly dangerous if user input is passed into them directly.

• eval(): Evaluates a string as JavaScript code. This is highly insecure if the string contains user input.

eval(userInput);

• setTimeout() and setInterval(): Executes a string of code after a delay. Passing user input to these functions allows code injection.

setTimeout(userInput, 1000);

• new Function(): Creates a new function from a string of JavaScript code. If user input is passed, it can execute arbitrary code.

var func = new Function(userInput); func();

c) URL/Location Redirection Sinks

These sinks allow navigation or redirection to a URL based on user input.

• window.location: If set to untrusted user input, it can redirect users to malicious websites.

window.location = userInput;

• element.src: Dynamically sets the src attribute of elements like iframe, img, etc.

element.src = userInput;

d) Event Handlers

Event handler attributes (such as onclick, onmouseover, etc.) can execute arbitrary JavaScript code. Inserting user-controlled data into event handlers without sanitization can lead to XSS.

element.setAttribute('onclick', userInput);

e) CSS Injection via Style Properties

Some browsers allow CSS injection that can trigger JavaScript code execution, especially through URLs or javascript: protocols.

• element.style: Manipulating the style attributes using unsanitized input.

element.style.cssText = userInput;

Sources and Sinks Interaction in DOM XSS

For a DOM XSS vulnerability to occur, there is typically a flow from a source to a sink.

→ For example: A malicious user modifies the window.location.hash (a source) to inject a script, and the application inserts this value into element.innerHTML (a sink) without validation. This results in the execution of the malicious script.

Example:

var userInput = window.location.hash;  // Source
document.getElementById('output').innerHTML = userInput;  // Sink

If an attacker controls the URL and adds a hash fragment like #<script>alert('XSS')</script>, the script will be injected and executed when the page processes the untrusted hash value.

Happy Hacking!!! 😊