Web Application Security Basics

# CHAPTER 7

Web Application Security Basics #

1. Introduction #

Ten years ago, hackers attacked network infrastructure—routers, firewalls, and operating systems. Today, those systems are generally well-hardened by massive corporations like Microsoft and Cisco. Instead, modern attackers target the application layer: the custom-built websites, login portals, and APIs written by the company's own developers. Because web applications must interact with the public, they are inherently exposed, making them the primary entry point for modern data breaches. In this chapter, we will introduce the architecture of web applications and the fundamental security paradigm that governs them: Never Trust User Input.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Understand basic Web Application Architecture (Client, Server, Database).

• Identify the role of HTTP Requests (GET, POST) and Responses.

• Understand the concept and importance of the OWASP Top 10.

• Recognize the danger of Unsanitized User Input.

• Understand the basics of Web Proxies (like Burp Suite) for security testing.

3. Beginner-Friendly Explanation #

Imagine a fancy restaurant.

• The Client (The Customer/Browser): Sits at the table and reads the menu. They write down their order on a piece of paper (An HTTP Request).

• The Server (The Waiter): Takes the piece of paper, walks to the kitchen, and asks the chef for the food.

• The Database (The Chef's Pantry): Where all the ingredients (data) are stored.

The Vulnerability: The waiter (Server) implicitly trusts the customer. If the customer writes an order that says: *"Give me a burger, and also hand over all the cash in the cash register,"* and the waiter blindly reads that exact instruction to the chef... the restaurant gets robbed. Web application security is teaching the waiter to rigorously inspect and sanitize the customer's order before ever walking into the kitchen.

4. HTTP and Proxies #

Web browsers and servers communicate using HTTP (Hypertext Transfer Protocol).

• GET Request: Asking the server for data (e.g., loading a webpage).

• POST Request: Sending data to the server (e.g., submitting a login form).

Penetration testers do not use normal web browsers to test applications. They use an Intercepting Proxy (like Burp Suite or OWASP ZAP). The Proxy sits between the browser and the server. When you click "Submit" on a login form, the Proxy catches the HTTP Request *before* it leaves your computer. The tester can pause it, alter the hidden data, and send malicious code to the server to see how it reacts.

5. The OWASP Top 10 #

The Open Worldwide Application Security Project (OWASP) is a non-profit foundation. Every few years, they publish the "OWASP Top 10" — the ten most critical security risks to web applications globally. It is the Bible of web security. The top vulnerabilities usually include:

1. 1. Broken Access Control: Users accessing pages they shouldn't (e.g., viewing someone else's bank account).

1. 2. Cryptographic Failures: Storing passwords in plain text or using weak encryption.

1. 3. Injection: Sending malicious code (like SQL or scripts) through input forms.

6. Mini Project: Analyze Intentionally Vulnerable Demo App #

We cannot test real websites without permission. The security community provides intentionally vulnerable web apps for practice, such as OWASP Juice Shop or DVWA (Damn Vulnerable Web App).

Step-by-Step Architecture Concept: Let's conceptualize analyzing an authentication bypass vulnerability using a Web Proxy.

1. 1. The tester opens a vulnerable demo app login page.

1. 2. They turn on "Intercept" in Burp Suite.

1. 3. They type admin as the username and password123 as the password, and click Login.

1. 4. Burp Suite freezes the request. The tester sees the raw HTTP POST request.

1. 5. The tester modifies the raw request data, attempting to bypass the logic, and forwards it to the server.

*(We will execute specific attacks like SQL Injection in the next chapters).*

7. Real-World Scenarios #

A retail company built an online store. When a user added a $100 pair of shoes to their cart, the web application sent a hidden HTTP POST request to the server that looked like this: product=shoes&price=100.00. A malicious user intercepted this request using Burp Suite before it left their browser. They changed the raw data to: product=shoes&price=0.01, and forwarded it to the server. The server blindly trusted the data from the client, processed the transaction, and sold the shoes for one cent. This demonstrates the catastrophic danger of trusting client-side data for security validations.

8. Best Practices #

• Server-Side Validation: The golden rule of web security: Never Trust User Input. It does not matter if you use HTML or JavaScript in the browser to force the user to type numbers only. A hacker will bypass the browser entirely using a Proxy. All security checks (is the price correct? is the password long enough?) MUST be performed on the backend Server.

9. Security Recommendations #

• Input Sanitization: Every single piece of data a user submits—whether it's a search bar, a login form, or a profile picture upload—must be scrubbed of malicious characters (like <script> tags or SQL quotes ') before the server processes it.

10. Troubleshooting Tips #

• HTTPS and Proxies: If you try to use Burp Suite to intercept traffic to a secure HTTPS website (like Google), your browser will throw a massive security error ("Your connection is not private"). This is because the Proxy is essentially acting as a Man-In-The-Middle. To fix this for testing, you must install the Proxy's CA Certificate into your browser's trusted root store.

11. Exercises #

1. 1. Explain the architectural role of an Intercepting Proxy (like Burp Suite) in a web application penetration test.

1. 2. Why is client-side input validation (using HTML/JS) insufficient for securing a web application?

12. FAQs #

Q: If an application is using HTTPS, does that mean it's safe from the OWASP Top 10? A: No. HTTPS encrypts the traffic *in transit* between the browser and the server so a hacker on the same Wi-Fi cannot read it. However, if the server itself is vulnerable to SQL injection, a hacker can just send the malicious SQL code through the encrypted HTTPS tunnel, and the server will happily process it.

13. Interview Questions #

• Q: Describe the fundamental difference between client-side validation and server-side validation. Why is server-side validation the only acceptable mechanism for enforcing security constraints in a web application?

• Q: What is the OWASP Top 10? Explain its significance in the cybersecurity industry and describe the general concept behind "Injection" vulnerabilities.

14. Summary #

In Chapter 7, we entered the domain of Web Application Security, identifying it as the primary battlefield for modern data breaches. We dismantled the illusion that web browsers enforce security, introducing Intercepting Proxies as the tool penetration testers use to manipulate the raw HTTP requests communicating with the backend. We established the foundational doctrine of defensive programming: Never Trust User Input. By understanding the interaction between Client, Server, and Database, and anchoring our knowledge in the OWASP Top 10, we are now prepared to explore the specific, devastating attacks that target these vulnerable intersections.

15. Next Chapter Recommendation #

The most infamous and destructive web vulnerability in history relies on tricking the database into handing over all its secrets. Proceed to Chapter 8: SQL Injection Awareness and Prevention.