Welcome to the very first lesson of the "Security Misconfiguration" course! In this lesson, we'll explore the concept of default credentials and their impact on web application security. Default credentials are pre-set usernames and passwords that come with many applications and devices. While convenient for initial setup, they pose significant security risks if not changed.

By the end of this lesson, you'll learn how to identify, exploit, and secure endpoints that use default credentials. Let's dive in! 🚀

Default credentials are the factory-set usernames and passwords that come with many applications and devices. They are intended for initial setup but can become a security risk if not changed. For example, an admin panel might come with a default username admin and password admin123. If these credentials remain unchanged, anyone with access to the application can log in and potentially access sensitive data.

Default credentials exist primarily to help developers quickly test and set up applications during development. However, they often find their way into production environments due to rushed deployments, poor documentation, or simple oversight. Sometimes, teams intentionally keep them unchanged for "easier maintenance," which creates significant security risks. It's crucial to change default credentials to prevent unauthorized access and protect your application from potential breaches.

Let's look at a code snippet that demonstrates the use of default credentials in an admin panel. This example shows how an attacker might exploit these credentials to gain unauthorized access.

In this code, the admin panel uses default credentials (admin and admin123). If these credentials are not changed, anyone can log in as an admin, posing a significant security risk. This vulnerability can be exploited to access sensitive data or perform unauthorized actions.

Let's look at another vulnerable endpoint that demonstrates how an attacker can exploit default credentials to access sensitive user data:

This endpoint is particularly vulnerable because it relies on a simple header check for authentication. An attacker who has logged in with default credentials can easily access all user data by including the FULL_ADMIN access header in their request.

Now, let's see how an attacker might exploit the vulnerable code using a simple curl command. This demonstration will show how easy it is to gain unauthorized access when default credentials are left unchanged.

In this example, the attacker uses a curl command to send a POST request to the admin login endpoint with the default credentials. If the credentials are still active, the attacker will receive a response indicating a successful login, granting them access to the admin panel.

Let's look at how to properly set up admin users using environment variables and secure password hashing. Up until now, we've been simply hardcoding these values when creating the database, but let's change it to use environment variables instead.

Here's how your .env file should look:

When choosing credentials for your default admin user, use a complex username that doesn't reveal the admin role (avoid "admin" or "root"), and generate a strong password of at least 16 characters with a mix of uppercase, lowercase, numbers, and special characters.

Remember to change these credentials immediately after the first deployment to production.

Next, we'll implement JWT-based authentication to protect the admin panel. This ensures that only authorized users can access the admin panel.

In this code, we use JWT to generate a token for authenticated users. Instead of our previous simple credential check, we now use bcrypt to securely compare passwords and issue a short-lived JWT token. The token is signed with a secret key and includes an expiration time of one hour, ensuring that even if compromised, the token can only be used for a limited time.

Now that we have our authentication mechanism in place, let's see how we can use it to secure our user data endpoint.

Let's look at how we can protect sensitive endpoints using our JWT authentication:

This version uses the authenticateToken middleware to verify the JWT, and the isAdmin middleware to ensure that only users with an admin role can access sensitive user information.

With these security measures in place, we've significantly improved our application's security posture. Let's wrap up what we've learned and look at what's coming next.

In this lesson, we explored the risks associated with default credentials and how they can be exploited. We learned how to identify vulnerable endpoints and secure them using environment variables and JWT-based authentication. By implementing these best practices, you can protect your application from unauthorized access and potential breaches.

As you move on to the practice exercises, remember the importance of securing your endpoints and managing credentials properly. Good luck, and see you in the next lesson! 🎉