Flag 10: Understanding Data Manipulation through SQL Injection Objective: This exercise aims to demonstrate how insufficient input sanitization and a lack of proper access controls can lead to unauthorized data modification within a "toy" financial transaction system. Your goal is to understand how an attacker could manipulate transaction records and balances if an application is vulnerable to SQL Injection.

Scenario Details: After gaining simulated access (as per Flag 9), you are presented with a user's transaction history and balance. One of the transactions is a simulated "overdraw fee." The backend system processes transaction updates and insertions, likely using a JSON payload that is directly integrated into SQL queries without proper sanitization.

Educational Focus:

Identifying Data Deletion Vulnerabilities:

Goal: Understand how a crafted SQL Injection payload could be used to simulate the deletion of a specific transaction entry (e.g., the overdraw fee). This includes exploring how to bypass any simulated "audit trail" mechanisms if they are also vulnerable to direct SQL manipulation.

Key Learning: Recognize the severe impact of unauthorized data deletion and the importance of robust input validation and database permissions to prevent such actions.

Identifying Data Insertion Vulnerabilities:

Goal: Explore how a crafted SQL Injection payload could be used to simulate the insertion of a new, unauthorized transaction. The target is to understand how such an injection could alter the total balance to a specific, predetermined value (e.g., $2150.50), while maintaining a specific number of total entries.

Key Learning: Understand the dangers of uncontrolled data insertion and the necessity of validating all financial transactions and ensuring they originate from legitimate, authorized sources.

Technical Considerations for Understanding the Vulnerability:

JSON Payload Integration: Consider how a JSON structure, when directly used to construct SQL queries, can introduce injection points. This highlights the need for careful parsing and sanitization of structured data before it's used in database operations.

SQL INSERT Syntax: This task encourages you to explore common SQL INSERT syntax variations (INSERT INTO table (...) VALUES (...) vs. INSERT INTO table (...) SELECT ... FROM ...) to understand how different application backend implementations might be vulnerable. In a real-world scenario, identifying the exact syntax helps in crafting precise attacks, but in a defensive context, it highlights the need for generalized protection.

Maintaining Data Integrity (Simulated): The requirement to maintain a specific number of transactions demonstrates the need for comprehensive SQL injection payloads that might involve both DELETE and INSERT operations in a single, complex injection. This showcases the power and flexibility an attacker gains with such vulnerabilities.

Simulated Outcome: Successfully demonstrating this vulnerability would result in the "toy" website's transaction history displaying the manipulated state: the overdraw fee removed, and the balance updated to the target value, while the total number of transactions remains consistent. This outcome serves as a clear indicator of the potential for unauthorized data modification.

Learning Points:

This exercise emphasizes the importance of comprehensive input sanitization for all user-supplied data, regardless of its format (e.g., JSON).

It highlights the critical role of least privilege for database accounts and the need for strong access controls to prevent unauthorized data manipulation.

Understanding these vulnerabilities is crucial for developing robust and secure financial or data-sensitive applications.

POST Request: '{"fromRout":"X","fromAcct":"X","toAcct":"eff452b077d3","amt":"1"}'

Transactions Schema TRANSACTIONS ( [Account] VARCHAR(32) NOT NULL ,[TransID] UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID() ,[TransDate] DATETIME NOT NULL DEFAULT GETDATE() ,[Location] VARCHAR(128) NOT NULL ,[Description] VARCHAR(128) NOT NULL ,[Direction] VARCHAR(1) NOT NULL DEFAULT 'O' ,[Amount] DECIMAL(10,2) NOT NULL ,CONSTRAINT [PK_TRANSACTIONS] PRIMARY KEY ([Account] ASC, [TransID] ASC) ,AFTER INSERT TRIGGER AIT_TRANSACTIONS_HISTORY )

History Schema HISTORY ( [HistID] INT NOT NULL IDENTITY(1,1) [HistDate] DATETIME NOT NULL DEFAULT GETDATE() ,[Account] VARCHAR(32) NOT NULL ,[TransID] UNIQUEIDENTIFIER NOT NULL ,[TransDate] DATETIME NOT NULL ,[Direction] VARCHAR(1) NOT NULL ,[Amount] DECIMAL(10,2) NOT NULL ,CONSTRAINT [PK_AUDIT] PRIMARY KEY ([HistID] ASC] ASC) ,CONSTRAINT [FK_AUDIT_TRANSACTIONS] FOREIGN KEY ([Account], [TransID]) REFERENCES TRANSACTIONS([Account], TransID]) )







Focus first on the overdraft fee



The backend uses SQL in one of these forms:INSERT INTO table (...) VALUES (...)

INSERT INTO table (...) SELECT ... FROM ...

Determine which one is used by guessing or trial/error