Week 10

Security Mindset

Threat Modeling Basics

Common Backend Vulnerabilities

Handling Sensitive Data

Hashing vs. Encryption

Authentication & Authorization

Spring Security

Practice

Assignment

• Teachers

Back end Track

Under construction

<aside> 🚧

This page is currently under construction. Please check back later.

</aside>

Introduction

Our methodology for this section is "Exploit First, Then Fix." For each vulnerability, we will first put on our "attacker hat" to understand how it can be exploited. And will focus on the concepts and the attacker's strategy. Then we will look into how can this be translated in code.

SQL Injection

Imagine you ask a librarian for a book by "John Smith." Now imagine you ask for "John Smith's book, and also, give me the keys to the rare books room." SQL Injection is like that second request. It's when an attacker tricks the application into running unintended database commands by hiding them inside what looks like normal user input (like a username or a search query).

The Attacker's Goal: bypass the application's logic and talk directly to the database to:

• Steal sensitive data: Access user tables to get emails, passwords, or personal information.
• Bypass authentication: Log in as any user, including an administrator, without knowing their password.
• Modify or destroy data: Delete records, tables, or the entire database.

A Practical Example:

Think of a login page with a username and password field. The application expects a username like ‘testuser’.

An attacker might enter something like this in the username field:

' OR '1'='1' --.

When the application builds its database query to check the user, this malicious input breaks the original logic. The '1'='1' part is always true, and the -- tells the database to ignore the rest of the command (like the part that checks the password). The result? The database thinks the login is valid, and the attacker is let in.

How to avoid It as a backend engineer:

Leverage Object-Relational Mapping (ORM): Modern frameworks like Spring Data JPA use prepared statements behind the scenes. By using an ORM correctly, you inherit these security benefits without having to write SQL queries manually.

Cross-Site Scripting (XSS)

XSS happens when an application takes untrusted data (like an attackers crafted javascript code in a comment section) and sends it to a web browser without cleaning it first, causing a malicious script to run in the victim's browser. Example

<p>Hi, my name is Bob.</p><script>steal_user_cookie();</script>

The Attacker's Goal:

• Steal session cookies to impersonate the user.
• Perform actions on behalf of the user (e.g., change their email).
• Redirect the user to a malicious website.

How to avoid It as a backend engineer:

• Never trust user’s input: Whatever a user put in your website is something you need to first validate. You need to make sure they have not inserted anything that you don’t want on that page.
• Encode Output: This is the primary defense. Before displaying any user-generated content in an HTML page, you must encode it. Encoding converts special characters like < and > into their safe equivalents (< and >). This ensures the browser displays the characters as text, not as HTML elements.
• Use Modern Frontend Frameworks: Frameworks like React and Angular are designed with XSS protection in mind and automatically encode data rendered on the page by default. This provides a strong, built-in layer of security.

Cross-Site Request Forgery (CSRF)

CSRF tricks a logged-in user into unknowingly performing an action they did not intend, by forcing their browser to submit a malicious request to an application where they are already authenticated

The Attacker's Goal:

• Changing the victim's password or email address.
• Transferring money or making purchases from different accounts .
• Deleting their account or data.

How to avoid It as a backend engineer:

Use Anti-CSRF Tokens (Synchronizer Token Pattern): This is the classic defense. The server embeds a unique, secret, and unpredictable token in every web form. When the user submits the form, the token is sent back. The server validates that the received token is the one it expected. An attacker cannot guess this token, so any forged request they create will be rejected.

Improper Error Handling: Information Disclosure

This is when an application reveals sensitive internal details (like stack traces or database error messages) to the end-user when it encounters an error.

The Attacker's Goal: Gather intelligence for a future attack by learning about the technologies used (database, framework), internal file paths, and application logic.

How to avoid It as a backend engineer:

• Configure Generic Error Messages: Configure your application to show a generic, user-friendly error page in a production environment. The message should not contain any technical details.
• Log Details Internally: While hiding details from the user, you must log the full, detailed error (including the stack trace) to a secure, server-side location. This is crucial for developers to debug the problem.

Insufficient Rate Limiting

This vulnerability exists when an application doesn't limit how many times a user or IP address can attempt an action in a given period of time.

The Attacker's Goal:

• Brute-force attacks: Rapidly guess passwords, API keys, or 2FA codes.
• Denial of Service (DoS): Overwhelm the server with requests to make the application slow or unavailable for legitimate users.

How to avoid It as a backend engineer:

• Implement Rate Limiting on Key Endpoints: Apply strict limits on authentication endpoints (login, password reset, registration) to prevent brute-force attacks. A common rule is "5 failed attempts per IP address per 15 minutes."
• Limit Resource-Intensive Operations: Apply more general rate limits to computationally expensive operations (e.g., search, report generation) to prevent DoS attacks.
• Use Infrastructure-Level Protection: While you can implement rate limiting in your application code, it's often more efficient to handle it at the infrastructure level using an API Gateway, Load Balancer, or Web Application Firewall (WAF). This protects your application before the malicious traffic even reaches it.

The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*

Built with ❤️ by the HackYourFuture community · Thank you, contributors

Found a mistake or have a suggestion? Let us know in the feedback form.