Introduction to Web Application Vulnerabilities
Welcome to one of the most exciting (and critical) parts of your H2 Computing journey! As you’ve learned to build web applications using Flask, HTML, and SQL, you also need to understand how to protect them. A vulnerability is essentially a "weak spot" or a flaw in a web application's design or code that an attacker can exploit to do something they shouldn't—like stealing data or pretending to be another user.
In this chapter, we will look at three common "attacks" and, more importantly, how you can build "shields" to stop them. Don't worry if the technical terms seem a bit scary at first; we will break them down using simple analogies!
1. SQL Injection (SQLi)
What is it?
SQL Injection occurs when an attacker inserts (or "injects") malicious SQL code into an input field (like a login box or a search bar). If the application isn't careful, it sends this malicious code directly to the database.
How it works:
Imagine a login query that looks like this in the background:
\(SELECT * FROM users WHERE username = 'user_input' AND password = 'password_input'\)
If an attacker types \(admin' --\) into the username field, the query becomes:
\(SELECT * FROM users WHERE username = 'admin' --' AND password = '...' \)
Because \(--\) is a comment in SQL, the database ignores the password check entirely and logs the attacker in as the administrator!
Impact:
- Data Theft: Attackers can dump the entire database of user records.
- Data Loss: They could use the \(DROP TABLE\) command to delete everything.
- Unauthorized Access: Logging in without a valid password.
The Solution: Prepared SQL Statements
The best way to stop this is using prepared statements (also called parameterized queries). Instead of building a string, you use placeholders (like \(?\)). The database is told exactly what is "code" and what is "data," so even if the attacker types SQL commands, the database treats it as just a harmless string of text.
Quick Takeaway: Never trust user input! Always treat it as "dirty" until it is handled by a prepared statement.
2. Cross-Site Request Forgery (CSRF)
What is it?
CSRF (pronounced "see-surf") is a trick where an attacker forces a victim's browser to perform an unwanted action on a different website where the victim is currently logged in.
The Analogy:
Imagine you are logged into your bank's website. Your browser has a "key" (a cookie) that says you are authenticated. While you have the bank tab open, you click a link on a "shady" site. That shady site has a hidden form that sends a request to your bank: "Transfer \$1000 to Attacker." Because your browser still has the "key," the bank thinks you sent the request and processes the transfer!
Impact:
- Unwanted state changes: Changing passwords, deleting accounts, or making financial transactions without the user's knowledge.
The Solution: CSRF Tokens
To prevent this, web apps use a CSRF Token. This is a unique, secret, and unpredictable string generated by the server for each user session. This token must be included in any "action" request (like submitting a form). Since the attacker's "shady" site doesn't know your secret token, the bank will reject the forged request.
Did you know? This is why many web frameworks, like Flask, have built-in tools to automatically generate and check these tokens for you!
3. File Inclusion
What is it?
File Inclusion vulnerabilities happen when a web application allows a user to submit a filename or path as input, which the server then uses to "include" or load a file.
How it works:
Imagine a URL like: \(mysite.com/view?page=contact.html\).
The server sees this and looks for \(contact.html\) in its folders. However, an attacker might change it to: \(mysite.com/view?page=../../etc/passwd\).
If the server isn't protected, it might go "up" two levels and show the attacker the system's sensitive password files!
Impact:
- Information Disclosure: Attackers can read sensitive system files or source code.
- Remote Code Execution: In some cases, they can trick the server into running malicious code from an external site.
The Solution: File Permissions and Input Validation
- File Permissions: Set the server's settings so it can only read files in specific "safe" folders.
- Input Validation: Instead of letting users type any filename, use a "whitelist" (a list of allowed filenames) or only allow simple alphanumeric characters.
Summary of Defences
Building a secure web application is about layers of protection. Here is a quick review of the "Shields" you need to know:
- Input Validation: Check all data entered by users. Is it the right type? Is it the right length? Does it contain illegal characters?
- Prepared SQL Statements: The primary defense against SQL Injection. It separates logic from data.
- CSRF Tokens: A secret handshake between the server and the browser to prove a request is genuine.
- File Permissions: Restricting the server's access so it can't wander into sensitive system folders.
Common Mistake to Avoid:
"I have a firewall, so I don't need to worry about SQL Injection."
Wrong! Firewalls are great, but they often can't tell the difference between a legitimate login attempt and a cleverly disguised SQL Injection. Security must be built into the code itself.
Connection to Singapore Statutes
In Singapore, exploiting these vulnerabilities is a serious legal matter. Under the Computer Misuse Act, unauthorized access to computer material (even if the door was "left unlocked" by a vulnerability) is an offense. Additionally, if a vulnerability leads to a leak of names or IC numbers, the organization could be in breach of the Personal Data Protection Act (PDPA) for failing to have "reasonable security arrangements."
Key Takeaway for Exams: When asked about the impact of a vulnerability, remember to mention both the technical impact (data loss/unauthorized access) and the legal/ethical impact (breach of PDPA or CMA).