Injection attacks, such as SQL injection or Cross-Site Scripting (XSS), occur when an attacker sends malicious data to an application, which is then processed or executed. The most effective mitigation technique is parameter validation, also known as input validation. This practice involves rigorously checking all data received from a user or external source to ensure it conforms to strict rules for type, length, format, and content. By validating that input is safe and expected before it is used, the application can reject malicious payloads, preventing them from being interpreted as commands or executable code by a backend system.

A. Configure single sign-on (SSO): This is an authentication mechanism that improves user experience but does not inspect or sanitize the content of user input to prevent injection attacks.

C. Require strong passwords: This is an authentication control measure that makes user accounts harder to compromise through guessing or brute force, but it is unrelated to validating application input.

D. Require two-factor authentication (2FA): This enhances authentication security by requiring a second verification factor, but it does not protect the application from malicious input submitted by an authenticated user.

1. OWASP Foundation. (2021). OWASP Top 10:2021. A03:2021-Injection. In the "How to Prevent" section

the primary recommendation is to "Use a safe API

which avoids using the interpreter entirely or provides a parameterized interface

" followed by server-side input validation. This directly supports parameter validation as a key defense. Retrieved from https://owasp.org/Top10/A032021-Injection/

2. Zeldovich

N.

& Kaashoek

F. (2014). 6.858 Computer Systems Security

Fall 2014. MIT OpenCourseWare. Lecture 15: Web Security

Slides 20-23. The lecture explicitly identifies "Check user input" (input validation) and using "prepared statements" (a form of parameterization) as the primary defenses against SQL injection attacks.

3. Scarfone

K.

Souppaya

M.

& Cody

A. (2007). Guide to Secure Web Services (NIST Special Publication 800-95). National Institute of Standards and Technology. Section 5.3

"Input Validation

" states

"Input validation should be performed to ensure that all input is well-formed and trustworthy... This is a defense against many types of attacks

including... SQL injection." (p. 5-4). DOI: https://doi.org/10.6028/NIST.SP.800-95

The question asks which attack is NOT a method to steal data from the connection between a web application and an IoT endpoint. SQL Injection (SQLi), Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF) are all viable attack vectors against a web application. SQLi and XSS are direct methods for data exfiltration from the database and user's browser, respectively. CSRF can be used to trick an authenticated user's browser into performing an action that sends data to an attacker.

LDAP Injection, however, is a highly specific attack that targets applications using an LDAP (Lightweight Directory Access Protocol) server for directory services, primarily user authentication and information. The transactional data exchanged between a web application and an IoT endpoint is typically stored in a relational (SQL) or NoSQL database, not an LDAP directory. Therefore, an LDAP Injection attack would not be a relevant method for stealing this specific data.

A. Cross-Site Request Forgery (CSRF): This attack can force a user's browser to execute a request that sends data to an attacker-controlled location, thus facilitating data theft.

B. SQL Injection (SQLi): This is a primary and highly effective method for attacking the application's backend database to read, modify, or exfiltrate sensitive data.

C. Cross-Site Scripting (XSS): This attack injects malicious scripts into the web application, which can then be used to steal user session cookies, credentials, or other sensitive data from the user's browser.

1. OWASP Foundation

"LDAP Injection Prevention Cheat Sheet." This document specifies that LDAP injection targets applications that use LDAP queries. It states

"LDAP injection is an attack used to exploit web applications that construct LDAP statements from user input." This highlights its specificity to LDAP backends

which are distinct from the typical databases used for application data. (Reference: OWASP LDAP Injection Prevention Cheat Sheet

Introduction section).

2. OWASP Foundation

"Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet." This resource describes CSRF as an attack that "forces an end user to execute unwanted actions." While primarily for performing actions

a crafted request can cause data to be sent to an attacker

making it a method to facilitate data theft. (Reference: OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

Introduction section).

3. Martin

M.

et al. (2012). 6.858 Computer Systems Security

Fall 2014. Massachusetts Institute of Technology: MIT OpenCourseWare. Lecture 13

"Web Security

" details how SQL Injection and Cross-Site Scripting are used to exfiltrate data from databases and user sessions

respectively. It establishes them as common data theft vectors in web applications. (Reference: MIT OCW

6.858

Fall 2014

Lecture 13 Notes

Sections 3 & 4).

Network filters that rely on Ethernet burned-in addresses, more commonly known as Media Access Control (MAC) addresses, operate by maintaining an access control list of approved hardware addresses. The fundamental vulnerability of this security measure is that MAC addresses can be easily altered in software. An attacker can monitor network traffic to discover the MAC address of an authorized device and then reconfigure their own network interface to use, or "spoof," that address. This allows the attacker's device to impersonate the legitimate one, thereby bypassing the filter entirely.

B. Buffer overflow: This is a software vulnerability where a process overwrites memory boundaries. It is unrelated to bypassing network layer 2 hardware address filters.

C. Packet injection: While an attacker might inject packets after spoofing a MAC address, packet injection itself is a broader attack and not the specific vulnerability of the MAC filter.

D. GPS spoofing: This attack involves broadcasting false GPS signals to deceive location-aware devices. It has no relevance to MAC address-based network access control.

1. National Institute of Standards and Technology (NIST). (2012). Guidelines for Securing Wireless Local Area Networks (WLANs) (NIST Special Publication 800-153). Section 4.2.1

"MAC Address Filtering

" states

"However

because MAC addresses are sent in the clear

an attacker can easily spoof the MAC address of an authorized client."

2. Kurose

J. F.

& Ross

K. W. (2021). Computer Networking: A Top-Down Approach (8th ed.). Pearson. In Chapter 8.3

"Securing Wireless LANs

" the text explains that MAC filtering is a weak security measure because "the intruder can learn the MAC addresses of stations that are associated with the AP... and then have his or her station pretend to be one of these stations by spoofing its MAC address."

3. Stallings

W. (2017). Cryptography and Network Security: Principles and Practice (7th ed.). Pearson. Chapter 17

"Wireless Network Security

" discusses the security flaws of early Wi-Fi standards

noting that MAC address filtering is easily defeated by sniffing a valid MAC address and then spoofing it.

Resetting an IoT gateway to its factory defaults is a fundamental security best practice before deployment and integration. This process, often called device hardening, ensures the device is in a known, clean state. It erases any non-standard configurations, user accounts, or potential malware that might have been introduced between manufacturing and deployment. By starting from a trusted baseline, the integrator can then proceed to apply a secure configuration, such as creating strong credentials and disabling unnecessary services, thereby minimizing the initial risk profile of the device before it connects to the cloud.

A. Write down the default login and password

This action documents a known, high-risk vulnerability. Security best practices mandate changing default credentials immediately, not recording them for use.

B. Remove all logins and passwords that may exist

This is not a standard or feasible procedure. Devices require administrative accounts for configuration, and attempting to remove all credentials could render the device inaccessible.

C. Create new credentials using a strong password

While this is a critical security step, it should be performed after a factory reset. A reset ensures the underlying system is not already compromised, making the new credentials secure.

---

1. National Institute of Standards and Technology (NIST). (2021). IoT Device Cybersecurity Guidance for the Federal Government. NIST Special Publication 800-213A. In Section 3.2.1

"Device Configuration

" the guidance states

"Organizations should establish and implement a process for configuring IoT devices to a standardized

secure baseline before they are deployed." A factory reset is the primary method to return a device to its original baseline state

from which secure configurations can be applied.

(DOI: https://doi.org/10.6028/NIST.SP.800-213A)

2. European Union Agency for Cybersecurity (ENISA). (2020). Guidelines on Securing the IoT - Secure Software Development Lifecycle. In Section 5.3

"Secure deployment and maintenance

" the document emphasizes the need for a secure initial state. It states

"The device should be in a secure state when delivered to the customer... This includes having a procedure to reset the device to a secure state (e.g. factory reset)." This highlights the factory reset as a core mechanism for ensuring a secure starting point.

(Reference: Page 29

Section 5.3)

3. Carnegie Mellon University

Software Engineering Institute. (2019). SEI-CMU IoT Security and Privacy Checklist. The checklist for "Device Integrator/Operator" includes the step: "Change all default passwords and configuration settings on the device." To ensure all settings are known and secure

starting from a factory default state is the most reliable method before applying new

secure configurations.

(Reference: "Device Integrator/Operator Checklist

" Item 1)

The question addresses the need to protect a cloud portal from compromised credentials. The most effective control for this threat is Multi-Factor Authentication (MFA). Option C describes a standard MFA implementation, combining two distinct authentication factors: "something you know" (the strong password) and "something you have" (the mobile device that receives the SMS token). If an attacker compromises the password, they would still need physical access to the user's phone to complete the login, thus protecting the account.

A. This is multi-step authentication, not multi-factor. Both credentials are passwords, which fall under the same factor type: "something you know."

B. A strong password policy hardens the credential itself but does not protect against its compromise through methods like phishing, keylogging, or credential stuffing.

D. This uses two tokens from a single hardware device, representing only one factor type: "something you have." This does not meet the definition of multi-factor authentication.

1. National Institute of Standards and Technology (NIST). (2017). Special Publication 800-63B

Digital Identity Guidelines: Authentication and Lifecycle Management.

Section 5.1

"Authenticator and Verifier Requirements

" states: "Multi-factor authentication (MFA) requires at least two of the three factor types to be used for a successful authentication event." It defines these types as something you know

something you have

and something you are. This supports option C as the only true MFA implementation.

2. Amazon Web Services (AWS). (2023). Security best practices in IAM. AWS Identity and Access Management Documentation.

In the section "Require multi-factor authentication (MFA)

" the documentation states: "For extra security

we recommend that you require MFA for all IAM users... With MFA

users have a user name and password (the first factor—what they know)

and an authentication code from their AWS MFA device (the second factor—what they have)." This directly applies to securing a cloud portal.

3. Rivest

R. L. (2014). Lecture 15: Authentication. MIT OpenCourseWare

6.857 Computer and Network Security.

The lecture notes discuss authentication methods

highlighting that passwords ("what you know") can be stolen. It introduces two-factor authentication as a solution combining passwords with a token ("what you have") to mitigate this risk

directly aligning with the logic in option C.

The scenario describes a classic case of Domain Name System (DNS) poisoning, also known as DNS spoofing. In this attack, a malicious actor corrupts the data in a DNS server's cache, causing it to return an incorrect IP address for a legitimate domain name. When the administrator attempts to navigate to the administrative website, their system queries the compromised DNS server, which then resolves the domain to the IP address of the fake website. This effectively redirects the user's traffic to the attacker-controlled site without their knowledge, matching the described outcome perfectly.

A. Buffer overflow: This is a memory-based vulnerability exploitation technique used to execute arbitrary code or crash a system, not to redirect network traffic via domain names.

B. Denial of Service (DoS): This type of attack aims to make a network resource or website unavailable to its intended users, typically by flooding it with traffic, rather than redirecting users to a different site.

C. Birthday attack: This is a cryptographic attack that exploits probability theory to find collisions in hash functions, primarily used for forging digital signatures, and is unrelated to website redirection.

1. Stallings

W.

& Brown

L. (2018). Computer Security: Principles and Practice (4th ed.). Pearson. In Chapter 21.5

"DNS Attacks

" the text describes DNS poisoning as an attack where "an attacker is able to intercept a DNS request and reply with a forged DNS response... The forged response redirects the user to a different Web site."

2. Kuhrer

M.

Hupperich

T.

Holz

T.

& Rossow

C. (2014). Going Wild: Large-Scale Classification of Open DNS Resolvers. In Proceedings of the 2014 Conference on Internet Measurement Conference (IMC '14). Association for Computing Machinery

New York

NY

USA

233–246. The paper discusses DNS vulnerabilities

stating

"An attacker can poison the cache of a DNS resolver to redirect clients to a malicious server" (Section 2.1

DNS Cache Poisoning). DOI: https://doi.org/10.1145/2663716.2663733

3. MIT OpenCourseWare. (2014). 6.858 Computer Systems Security

Lecture 15: Network Security. Massachusetts Institute of Technology. The lecture notes explain DNS spoofing: "Goal: get victim to talk to a malicious server

by sending a fake DNS reply with a bad IP address." (Section 3

DNS Spoofing).

4. National Institute of Standards and Technology (NIST). (2010). NIST Special Publication 800-81-2: Secure Domain Name System (DNS) Deployment Guide. Section 2.2

"DNS Vulnerabilities

" details how cache poisoning allows an attacker to "redirect unsuspecting users to a malicious Web site."

Secure boot is a security process that establishes a root of trust. It ensures that each component loaded during the boot sequence, from the initial bootloader to the operating system kernel, is cryptographically signed and verified. If the digital signature of any component is invalid or untrusted, the boot process is halted. This mechanism directly prevents the IoT gateway from loading and executing unauthorized or malicious firmware images, thereby achieving the engineer's goal of only loading verified software.

A. Implement Over-The-Air (OTA) updates: This is a method for delivering firmware updates, not a mechanism for verifying the integrity of the image during the device's boot process.

C. Enforce a measured boot function: Measured boot records cryptographic hashes of boot components into a Trusted Platform Module (TPM) for later attestation but does not inherently prevent an unverified image from loading.

D. Harden the update server: This is a crucial server-side security measure but does not protect the gateway itself from loading a malicious image obtained through other channels (e.g., physical access).

1. Sadeghi

A.-R.

Wachsmann

C.

& Waidner

M. (2015). "Security and Privacy Challenges in Industrial Internet of Things." 52nd ACM/EDAC/IEEE Design Automation Conference (DAC). In Section III.A

"Trusted Platform

" the paper emphasizes that a secure boot process is fundamental to establishing a trusted computing base on an IoT device by verifying the authenticity and integrity of firmware. DOI: 10.1145/2744769.2747942.

2. NXP Semiconductors. (2021). AN4581: HABv4 Secure Boot on i.MX 6/7 Series. In Section 2

"High Assurance Boot (HAB) Introduction

" p. 5

it is stated that "HAB allows customers to sign their boot images... On every boot

the i.MX processor authenticates the image signature. If the authentication fails

the boot is terminated." This directly describes the function of secure boot.

3. Stancill

B. (2021). Building a Secure Boot Chain for an IoT Device. Courseware

University of Colorado Boulder. In the "Secure Boot" section

the material explains that the process creates a "chain of trust" where each stage verifies the next

ensuring "that the device is running authentic software."

This attack is a form of vishing, which is a portmanteau of "voice" and "phishing." Vishing attacks use voice communication technology, such as a phone call or voicemail, to conduct phishing. In this scenario, the attacker leaves a fraudulent voicemail, impersonating a legitimate company to deceive the recipient into revealing sensitive financial information (a credit card number). The use of a voice message as the attack vector is the defining characteristic of vishing, making it the most accurate and specific answer.

A. Phishing: This is a general term for attacks seeking sensitive information via electronic communication. Vishing is a more specific and accurate description of this voice-based attack.

B. Spear phishing: This describes a targeted attack, which this is, as it references a recent purchase. However, "vishing" is more precise as it specifically identifies the voice-based medium used.

C. Whaling: This is a type of spear phishing that specifically targets high-profile individuals like executives or celebrities. The scenario does not indicate the victim is a high-value target.

1. National Institute of Standards and Technology (NIST). Glossary of Key Information Security Terms

NISTIR 7298 Rev. 3. Page 207. "Vishing: A type of phishing attack that is conducted over the phone

using voice technology (e.g.

a phone call or voice message)."

This source also defines spear phishing (p. 178) as a targeted attack and whaling (p. 210) as targeting high-profile individuals

supporting the distinctions made above.

2. Purdue University. Information Security and Policy

Social Engineering. "Vishing is another type of phishing attack that is conducted by phone... Spear phishing is a more targeted phishing attack. The attacker finds out information about the target..."

This university resource clearly distinguishes the terms

defining vishing by its voice medium and spear phishing by its targeted nature. The scenario's most explicit detail is the voice message

making vishing the most precise classification.

3. Carnegie Mellon University

Software Engineering Institute (SEI). Common Social Engineering Attacks. "Vishing

or voice phishing

is the use of telephony... to trick individuals into revealing sensitive information."

This further solidifies the definition of vishing as an attack conducted over voice channels

directly matching the scenario described.

Hashing is the correct technique for this purpose. A hash function creates a unique, fixed-length digital fingerprint (a "hash" or "digest") of a file. The developer can compute the hash of the original software and publish it. Users can then download the software, compute the hash on their end using the same algorithm (e.g., SHA-256), and compare it to the one provided by the developer. If the hashes match, the user can be confident the software has not been modified. This process ensures data integrity.

A. Encryption: Encryption is used for confidentiality to make data unreadable to unauthorized parties, not primarily to verify that the data has not been altered.

B. Obfuscation: This technique makes code difficult for humans to read or reverse-engineer but does not provide a verifiable method to detect modifications.

D. Fuzzing: Fuzzing is a software testing method used to find vulnerabilities by inputting random data; it is not a tool for end-users to verify file integrity.

1. National Institute of Standards and Technology (NIST)

Special Publication 800-183

Networks of 'Things'

July 2016. Section 3.3.2

"Data Confidentiality

Integrity

and Origin Authentication

" discusses the need for data integrity and mentions cryptographic mechanisms like digital signatures

which are fundamentally based on hashing

to ensure data has not been altered.

2. CertNexus

ITS-110 Exam Objectives

Version 2.0. Domain 3.3

"Given a scenario

implement security measures for IoT devices

" covers the application of cryptographic controls. Hashing is a primary cryptographic control used to ensure the integrity of data and software.

3. Paar

C.

& Pelzl

J.

Understanding Cryptography: A Textbook for Students and Practitioners. (Material commonly used in university curricula). Chapter 11

"Hash Functions

" Section 11.1.2

"Digital Signatures

" explains that a core application of hash functions is to compute a short digest of a message or file for integrity verification as part of a digital signature scheme.

4. University of California

Berkeley

CS 161: Computer Security Course Notes

Fall 2020. Lecture 8: "Cryptographic Hash Functions

" page 2

explicitly states: "A major application of cryptographic hash functions is to verify file integrity." It details the exact process described in the explanation.

A session replay attack occurs when an attacker intercepts and records a valid data transmission (e.g., an authentication sequence or command) and then re-transmits it later to impersonate the legitimate device. By requiring a unique, randomly generated token (often called a nonce or "number used once") for each new connection or session, the system ensures that any captured transmission becomes invalid for future use. When the attacker replays the old message, the server will reject it because the token has already been used or has expired, thus effectively mitigating the replay attack.

A. Malformed URL injection: This is primarily mitigated by input validation and sanitization on the server-side, not by session tokens.

B. Buffer overflow: This is a memory corruption vulnerability prevented by secure coding practices like bounds checking, not by application-layer tokens.

C. SSL certificate hijacking: This is mitigated by strong Public Key Infrastructure (PKI) management, certificate pinning, and secure key storage, not by session tokens.

---

1. National Institute of Standards and Technology (NIST). (2017). NIST Special Publication 800-63B: Digital Identity Guidelines

Authentication and Lifecycle Management.

Section 4.3.3

Replay Resistance: "The verifier SHALL implement a mechanism that is resistant to replay attacks... Common mechanisms for replay resistance include nonces

timestamps

or the use of challenges." This directly links the use of nonces (randomly generated tokens) to the prevention of replay attacks.

2. Perrig

A.

Canetti

R.

Tygar

J. D.

& Song

D. (2002). The TESLA Broadcast Authentication Protocol. RSA CryptoBytes

5(2).

Section 2

Basic TESLA: "To prevent replay attacks

the receiver needs to check that the MAC key... has not been disclosed yet." While discussing a specific protocol

the underlying principle of using time-sensitive or single-use cryptographic material to prevent replays is a foundational concept in network security academic literature. The use of a unique token serves a similar purpose.

3. Kurose

J. F.

& Ross

K. W. (2017). Computer Networking: A Top-Down Approach (7th ed.). Pearson.

Chapter 8

Security in Computer Networks: In discussions on authentication protocols (e.g.

Section 8.3)

the text explains the use of a nonce to defend against replay attacks. It states that by having a party send a nonce and requiring it to be returned (often in an encrypted form)

the party can verify the message is fresh and not a replay. This is a standard university-level textbook.