Source code manipulation is used as a defensive strategy in the SQL Injection Lab by replacing insecure code with secure, immune versions that leverage prepared statements. By copying code segments from a 'SAFE_HOME_PHP' file and pasting them into an 'UNSAFE_HOME_PHP' file, developers are shown how introducing parameterized queries can effectively neutralize SQL injection threats. This manipulation centralizes the SQL logic in a controlled manner, ensuring that attacker inputs cannot alter the originally intended commands, thus transforming vulnerable code into a secure equivalent .

The SQL Injection Lab emphasizes the practice of using prepared statements—or parameterized queries—as a critical technique for protecting against SQL injection attacks. This practice involves defining the SQL code separately from the input data, allowing the database to distinguish between code and data. By doing so, user inputs are treated strictly as data and are not allowed to alter the intended execution of SQL commands. Consequently, even if a user-inputted field is injected with malicious code, the database only runs predefined SQL commands, thus nullifying any injection attempts .

An SQL injection attack from the command line, as illustrated in the SQL Injection Lab, can be initiated using command-line tools like curl. The attacker crafts a URL that includes an SQL injection payload, which is used to send a malicious request to the vulnerable web application. In the lab, this is demonstrated by running a command such as "curl 'http://www.seedlabsqlinjection.com/unsafe_home.php?username=Admin%27% 20%23'", where the username parameter contains an SQL code ('Admin' followed by a comment symbol '%20%23') that affects the SQL query processing, bypassing authentication mechanisms or performing unauthorized data retrieval .

The vulnerability that allows for the modification of another user's password is due to the lack of input validation and the improper handling of user inputs in the SQL query execution within the user profile editor. To exploit this flaw, an attacker like Alice can inject an SQL command into a field, in this case, using the password hash update. The process involves creating a SHA1 hash of a desired password using a command-line tool (e.g., 'echo -n "tedwashere" | sha1sum'), copying the resulting hash, and injecting this into the profile editor's input field with a crafted SQL query such as ', password=(code you copied) where name = 'Boby' #'. This allows unauthorized modification of another user's password .

Using SHA1 hashing is relevant in the context of SQL injection attacks focused on password changes because it involves the creation of a fixed-length hash from a plaintext password. When an attacker gains the ability to modify passwords through SQL injection, they must ensure the new password is stored in the correct hashed format expected by the authentication system. By generating a SHA1 hash of the new password, the attacker can inject this into the SQL query, making the database believe it is a legitimate update. This is crucial because password validation typically involves comparing hashed values, ensuring the injected password is usable for further unauthorized access .

The SQL Injection Lab illustrates the impact of improper user input validation on web security by demonstrating how vulnerabilities in input handling can be exploited to perform unauthorized actions on a database. Through tasks such as altering salaries, changing passwords, and bypassing authentication, the lab shows how failing to adequately validate and sanitize user inputs allows attackers to inject malicious SQL commands. These commands can manipulate or access sensitive data and application functionality beyond the attacker's privileges, highlighting the critical need for robust input validation mechanisms and adoption of prepared statements to prevent such security breaches .

The Apache service plays a crucial role in executing the SQL Injection Lab tasks by serving as the web server that hosts the web applications vulnerable to SQL injection. It is responsible for handling HTTP requests, which include those that carry SQL injection payloads. By running commands such as 'sudo service apache2 reset', the lab simulates changes in the code or environment, thus restarting the server to apply these changes. This ensures that newly added security measures, such as the implementation of prepared statements, are effectively deployed and tested .

To reduce Boby's salary using SQL injection, the technique employed is known as an 'in-band SQL injection,' specifically utilizing an update operation within the SQL query. Alice executes this by injecting a crafted SQL statement into a field, such as the NickName input, within her profile editor. The injection includes: ', Salary=1 where name = 'Boby' #', which is appended to the legitimate SQL update operation, directly altering Boby's record in the database to change his salary to 1 dollar. This directly modifies the data because it exploits the improper validation of user input in dynamic queries .

The primary objective of Task 3.1 in the SQL Injection Lab is to modify one's own salary using an SQL injection vulnerability in a web application. This is achieved by exploiting the SQL injection flaw in the 'Edit Profile' page, where the user is normally restricted from changing their salary. The injection involves entering a crafted SQL statement into the NickName field, which alters the user Alice's salary to a specified amount, such as 10000, by appending the statement ', Salary=10000 where name = 'Alice' #'. This exploits improper input validation and lack of parameterized queries in the web application .

Task 4 proposes to prevent SQL injection attacks by utilizing prepared statements in the web application's code. The key technique employed is replacing vulnerable SQL query execution with safer prepared statements that separate SQL code from data inputs. Specifically, the task involves copying secure code snippets from a 'SAFE_HOME_PHP' file into an 'UNSAFE_HOME_PHP' file to ensure that inputs are handled safely and that SQL queries are executed with parameterization. This approach prevents unauthorized or unintended SQL command execution due to malicious input .