Authentication techniques are continually evolving as social media sites continue to grow in popularity. The ability to log into web apps using social network accounts is a helpful advance in this area.

This article discusses how you can enhance the user login process for web applications by employing social media authentication through Firebase. It goes into the benefits, setup methods, and integration approaches while offering helpful guidelines.

Here's what we'll cover:

1. Why Use Social Media Authentication?
2. Prerequisites
3. What is Firebase and Why Use it for Authentication?
4. How to Set Up Firebase for Social Media Authentication
5. How to Set Up Your React App
6. How to Integrate Social Media Authentication in Your App
7. Offering Both Social Media and Email/Password Authentication
8. Conclusion

Why Use Social Media Authentication?

I'm sure you've grown weary of the usual username-password routine when logging into a new platform. It often entails creating a new password on the spot or resorting to insecure password conventions that could grant unauthorized access to your many accounts.

Fortunately, social media authentication offers some advantages:

1. Effortless User Experience: Social media login choices simplify the registration process, making it convenient for users to initiate their app usage.
2. Heightened Security: Social media platforms implement strong security measures that can bolster the safety of your app's users.
3. Elimination of Password Hassles: Through social media authentication, users are relieved from the burden of remembering numerous passwords, reducing the inconvenience of managing credentials.
4. Reduced Account Abandonment: Social media login prompts users to join and interact with your app, minimizing the chances of them leaving the registration process unfinished.
5. Access to Trustworthy User Information: Social media platforms provide substantial user information, which can be harnessed to personalize the experience offered by your app.
6. Streamlined Account Recovery: In instances of forgotten passwords, social media authentication presents a straightforward approach for users to regain entry to their accounts.

In summary, social media authentication offers a convenient and secure method for users to join and use your app. It leads to an improved user experience, and decreased account abandonment, and grants you access to valuable user insights.

Prerequisites

This article is intended for those with a solid grasp of the following concepts:

• HTML, CSS, and JavaScript
• React and React Routing
• Fundamental familiarity with using Firebase

What is Firebase and Why Use it for Authentication?

Firebase serves as a comprehensive platform, providing developers with backend services and tools to create web and mobile applications.

One of its key offerings is an authentication service that streamlines the process of integrating authentication features into apps.

With Firebase, implementing authentication becomes more straightforward, thanks to its provision of pre-built user interface components, developer-friendly APIs, and support for various authentication methods.

How to Set Up Firebase for Social Media Authentication

Step 1: Create a Firebase Project

1. Go to the Firebase Console and sign in with your Google account.
2. Click the "Add Project" button.
3. Enter a name for your project and select a location for your data storage.
4. Click the "Create" button.

Firebase console homepage

Step 2: Register a Web app

This feature enables you to register your web applications to access the features of Firebase via web apps.

1. In the Firebase Console, click the "Web" (</>) icon.
2. Click the "Add App" button.
3. Enter a name for your app and select the "Web" app type.
4. Click the "Register" button.

After you have created a Firebase project and registered a web app, you can start using Firebase for social media authentication.

Step 3: Discover Social Media Sign-In Methods

To do this, once your project is created, you'll need to navigate to the "Authentication" section on the left-hand menu.

Showing the Authentication sidebar

Under the "Sign-in method" tab, you'll find a list of authentication providers from which you can choose one:

Displaying various Authentication methods

Step 4: Configure Social Media Providers

How to configure Google auth:

To configure Google auth, simply add a support email, and you’re all set.

Adding a support mail for google auth

How to configure GitHub auth:

To configure GitHub auth, you'll need a Client ID and Client Secret. To get these, sign in to your GitHub account and go to Settings > Developer settings.

Github settings panel

Then, navigate to OAuth and create a new OAuth application.

Creating a github OAuth application

In order to get the Authorization callback, go back to your Firebase console and copy the URL in the GitHub setup.

GitHub callback URL

Note: To complete this process, you’d need to have your app already hosted or at least a URL to where your app is going to be hosted.

Next, you’ll be routed to a page where your app has been registered and you have your Client ID and Secret.

GitHub Client ID and secret Generated

Copy those details and use them to register GitHub as an auth service on Firebase.

Filling GitHub details on Firebase

How to configure Twitter auth:

Similar to Github, start by logging into your Twitter developer account. If you don’t have one, sign up with the Twitter Developer Portal. It looks something like this:

Twitter Developer Signup

After filling in the details, you’ll be routed to the homepage.

Twitter Dev homepage

Click on your default app, and set up user authentication.

Twitter OAuth app setup

Don’t forget to get the callback URL from Firebase and set the Website URL to the URL where your app is hosted.

After setting it up, navigate to your project’s keys and tokens and generate new ones.

Generating new App Key and Secret

Paste those details back in Firebase to set up Twitter auth.

And with that, your three social media platforms have be set up for authentication.

All Auth's set up

How to Set Up Your React App

Now we need to get your React app set up. You'll start by creating a new React app using Vite.

Create a folder on your computer and open that folder with your preferred IDE. Open that IDE’s terminal and run this command:

npm create vite@latest

When the details load, select React and wait for the installation to complete.

Creating a React App with Vite

You’ll be left with a handful of files and some boilerplate code that you can get rid of.

Next, run npm run dev in the terminal to start a development server on port http://localhost:5173/.

React app running in browser

To use Firebase in your app, you must first define a Firebase config file. This file contains all the necessary data used to identify your Firebase app.

So create a folder in your src directory called firebase. Then nest a config.js file in that folder and paste the config file details from your Firebase console you saved earlier.

Firebase config details

Finally, install Firebase via your terminal to use its services in your app.

npm i firebase

How to Integrate Social Media Authentication in Your App

Considering how large this section would be, it’ll be divided into several sub-sections.

1. Setting up the UI logic for authentication
2. Setting up the Authentication logic
3. Implementing Global Authentication State
4. Creating a custom hook for Social Media Authentication
5. Creating Routes and Implementing Routing
6. Social Media Authentication
7. Route Guarding via the User State
8. Creating a useLogout hook
9. Testing the logout functionality

How to set up the UI logic for authentication

Create a folder (pages) in the src directory that houses the pages you want in your application.

For this implementation, there will be 2 files in the pages folder, Auth.jsx and Home.jsx. These files will act as the pages the user can see either when authenticated or not.

How to set up the authentication logic

Start by importing and initializing Firebase auth, as well as the social media platforms enabled on Firebase in your config.

import {
  getAuth,
  GoogleAuthProvider,
  GithubAuthProvider,
  TwitterAuthProvider,
} from "firebase/auth";

// Initialize Firebase
const app = initializeApp(firebaseConfig);
const auth = getAuth(app);

const googleProvider = new GoogleAuthProvider();
const githubProvider = new GithubAuthProvider();
const twitterProvider = new TwitterAuthProvider();

Then export these initialized functions to use them in other parts of your application.

export { auth, googleProvider, githubProvider, twitterProvider };

How to implement Global Authentication State

To ensure a consistent authentication state throughout your application, consider using the React Context approach.

Step 1: Create an AuthContext

Start by generating a context folder within your src directory and then create an AuthContext.jsx file within it. In the AuthContext file, import essential hooks from React and Firebase.

import { createContext, useReducer, useEffect, useContext } from "react";
import { auth } from "../firebase/config";

export const AuthContext = createContext();

Step 2: Define a reducer function

Construct a reducer function to manage state changes for authentication-related actions using the following code:

export const authReducer = (state, action) => {
  switch (action.type) {
    // When the action type is "LOGIN", update the state with the new user information
    case "LOGIN":
      return { ...state, user: action.payload };

    // When the action type is "LOGOUT", update the state to remove the user information
    case "LOGOUT":
      return { ...state, user: null };

    // When the action type is "AUTH_IS_READY", update the state with user information and
    // set a state to indicate that the authentication process is complete
    case "AUTH_IS_READY":
      return { user: action.payload, authIsReady: true };

    // For any other action type, return the current state without any changes
    default:
      return state;
  }
};

Step 3: Create AuthContextProvider Component

Create a provider component that wraps your entire App component, using the reducer for authentication state management.

import { useEffect, useReducer } from "react";
import { onAuthStateChanged } from "firebase/auth"; 


// Authentication context provider component
export const AuthContextProvider = ({ children }) => {
  // Initialize authentication state using a reducer
  const [state, dispatch] = useReducer(authReducer, {
    user: null,
    authIsReady: false,
  });

  // Effect to determine initial authentication state and update context
  useEffect(() => {
    // Subscribe to authentication state changes
    const unsub = onAuthStateChanged(auth, (user) => {
      // Dispatch an action to update the state with the user information
      dispatch({ type: "AUTH_IS_READY", payload: user });

      // Unsubscribe to avoid further unnecessary updates
      unsub(); // Unsubscribe once the initial auth state is determined
    });
  }, []);

  // Provide authentication state and dispatch function to children components
  return (
    <AuthContext.Provider value={{ ...state, dispatch }}>
      {children}
    </AuthContext.Provider>
  );
};

Step 4: Implement useAuthContext custom hook

You can simplify access to the authentication context with a custom hook, like this:

import { useContext } from "react";

// Custom hook to access the authentication context
export function useAuthContext() {
  // Get the authentication context from the nearest AuthContextProvider
  const context = useContext(AuthContext);

  // Check if the context was successfully obtained
  if (!context) {
    throw Error("useAuthContext must be used inside an AuthContextProvider");
  }

  // Return the authentication context object for use in components
  return context;
}

How to integrating the AuthContextProvider

Finally, integrate the AuthContextProvider into your main application setup

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.jsx";
import "./index.css";
import { AuthContextProvider } from "./context/AuthContext.jsx";

ReactDOM.createRoot(document.getElementById("root")).render(
  <React.StrictMode>
    <AuthContextProvider>
      <App />
    </AuthContextProvider>
  </React.StrictMode>
);

With that, all parts of your app can access the context values from the AuthContext.

How to create a custom hook for Social Media Authentication

Firebase authentication processes are similar in pattern and code structure. So it's a good idea to follow the DRY principle and create a utility hook that performs authentication for all social media platforms. This allows you to reuse the same code for each platform, making your code more efficient and easier to maintain.

Here is the step-by-step process to follow to create a custom hook for social media authentication.

Step 1: Create the custom hook

In your source directory, establish a hooks folder and within it, create a file named useSocialSignup.jsx.

Step 2: Import dependencies

Import the necessary functions from React and Firebase into your useSocialSignup file.

import { useEffect, useState } from "react";
import { signInWithPopup } from "firebase/auth";
import { auth } from "../firebase/config";
import { useAuthContext } from "../context/AuthContext";

Step 3: Define the hook function

Develop the useSocialSignup function, which takes a provider as a parameter and returns an object containing an error state, pending state, and the sign-in function for the social provider.

export const useSocialSignup = (provider) => {
  // State variables to manage sign-up process
  const [error, setError] = useState(null);
  const [isPending, setIsPending] = useState(false);
  const [isCancelled, setIsCancelled] = useState(false);

  // Accessing the authentication context's dispatch function
  const { dispatch } = useAuthContext();

  // Function to initiate the social sign-up process
  const signInWithSocial = async () => {
    setError(null);
    setIsPending(true);

    try {
      const res = await signInWithPopup(auth, provider);

      dispatch({ type: "LOGIN", payload: res.user });

      if (!isCancelled) {
        setIsPending(false);
        setError(null);
      }
    } catch (err) {
      setError(err.message);
      setIsPending(false);
    }
  };

  // Effect hook to set isCancelled to true when component unmounts
  useEffect(() => {
    return () => setIsCancelled(true);
  }, []);

  // Return values and functions for component usage
  return { error, isPending, signInWithSocial };
};

This hook encapsulates the process of signing in with social providers. It manages error, pending, and cancellation states, interacts with Firebase authentication, and utilizes the authentication context to dispatch actions.

How to create routes and implementing routing

To ensure smooth navigation and user experience, setting up routes becomes crucial after implementing authentication logic. These well-organized steps guide you through the process.

Step 1: Install react-router-dom

Install the react-router-dom package, a popular choice for managing routing in React applications.

npm i react-router-dom

Step 2: Import dependencies

In your App.jsx file, import necessary components and functions for routing.

import { BrowserRouter, Navigate, Route, Routes } from "react-router-dom";
import "./App.css";
import Home from "./pages/Home";
import Auth from "./pages/Auth";

Step 3: Define routes

Wrap your application content in a BrowserRouter component and use the Routes component to define your routes. Utilize the Route component to map each route path to its corresponding component.

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/auth" element={<Auth />} />
      </Routes>
    </BrowserRouter>
  );
}

At the moment, you can freely navigate between routes, like so:

Moving between Routes without Auth

Social Media Authentication

To ensure your efforts haven't been in vain, head over to the Auth.jsx to implement authentication.

Step 1: Import dependencies

In your Auth.jsx file, start by importing necessary providers, context, and the custom signup hook.

import {
  googleProvider,
  twitterProvider,
  githubProvider,
} from "../firebase/config";
import { useSocialSignup } from "../hooks/useSocialSignup";
import {useEffect} from ‘react’

import {useAuthContext} from “../context/AuthContext”

Step 2: Create instances of the hook

Create instances of the useSocialSignup custom hook for each authentication provider.

const google = useSocialSignup(googleProvider);
const twitter = useSocialSignup(twitterProvider);
const github = useSocialSignup(githubProvider);

Step 3: Add buttons for social sign-up

Create buttons for each social sign-up option (Google, Twitter, GitHub) and attach onClick event handlers to call the signInWithSocial function from the respective hook.

return (
  <div className="utility__page">
    <h1>Welcome to my Auth Page</h1>

    <button onClick={google.signInWithSocial}>
      <img src={GoogleIcon} alt="" />
      <span>Google</span>
    </button>

    <button onClick={twitter.signInWithSocial}>
      <img src={TwitterIcon} alt="" />
      <span>Twitter</span>
    </button>

    <button onClick={github.signInWithSocial}>
      <img src={GithubIcon} alt="" />
      <span>GitHub</span>
    </button>
  </div>
);

Step 4: Apply styling

You can use the provided CSS below to style your components for a clean and organized appearance.

* {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

html {
  font-size: 62.5%;
  color: #121212;
}

.utility__page {
  display: flex;
  width: 100%;
  height: 100vh;
  justify-content: center;
  align-items: center;
  font-family: "Segoe UI", Tahoma, Geneva, Verdana, sans-serif;
  row-gap: 2rem;
  flex-direction: column;
  background: #e2dbd9;
}

h1 {
  font-size: 5rem;
}

button {
  padding: 1rem 4rem;
  font-size: 2rem;
  border: none;
  cursor: pointer;
  border-radius: 5px;
  display: flex;
  justify-content: center;
  align-items: center;
  gap: 1rem;
}

button img {
  width: 20px;
  height: 20px;
}

.user {
  font-size: 3rem;
  display: flex;
  align-items: center;
  column-gap: 1rem;
}

.logout {
  background: rgb(208, 84, 84);
  color: #fff;
}

.profile_img {
  width: 5rem;
  height: 5rem;
  border-radius: 50%;
}

At the moment, your auth page looks something like this:

Auth page after applying styling

Step 5: Test the authentication

To test authentication, import the user from your AuthContext and log it to the console using a useEffect.

  const { user } = useAuthContext();
  useEffect(() => console.log(user), [user]);

Testing the auth now gives the following:

Authentication confirmed in the console via the user object

As you can see, you’ve successfully logged a user in using Social Media Authentication. Kudos!

To confirm, head over to your Firebase auth page and check for valid users.

Confirming signed up user on Firebase

Feel free to try other login methods as they all work the same.

Route Gaurding via the User State

To prevent unauthorized access, set up route guards that check the user's authentication state in your App.jsx file.

const { user, authIsReady } = useAuthContext();

if (!authIsReady) {
  return null; // Return null while waiting for authIsReady
}

return (
  <BrowserRouter>
    <Routes>
      {user ? (
        <>
          {/* Authenticated routes */}
          <Route path="/" element={<Home />} />
          {/* Route guards */}
          <Route path="*" element={<Navigate to="/" />} />
        </>
      ) : (
        <>
          {/* Authentication routes */}
          <Route path="/auth" element={<Auth />} />
          {/* Route guards */}
          <Route path="*" element={<Navigate to="/auth" />} />
        </>
      )}
    </Routes>
  </BrowserRouter>
);

Routed to home page after adding route guards

As you can see, you’ve been routed to the home page, and even if you attempt to go the auth page, you’d be routed back here.

How to customize the home page

For the home page, fetch the user's details and display them if a user is authenticated.

import { useAuthContext } from "../context/AuthContext";

export default function Home() {
  const { user } = useAuthContext();
  return (
    <div className="utility__page ">
      <h1> Home Page</h1>
      {user && (
        <>
          <div className="user">
            <p> You&apos;re logged in as: </p>

            <span>{user.displayName} </span>
            <img className="profile_img" src={user.photoURL} alt=""/>
          </div>
         </>
      )}
    </div>
  );
}

Home page showing custom user details

And voilà! You’ve been able to fetch some details about that user based on the info on the social media they used to log in.

How to create a useLogout hook

The final step to complete your authentication process is to provide users with the ability to log out of your application. Here's how to create a useLogout hook:

Step 1: Create the hook

Create a new file called useLogout.jsx in your hooks folder. Import the necessary hooks and functions.

import { useEffect, useState } from "react";
import { auth } from "../firebase/config";
import { signOut } from "firebase/auth";
import { useAuthContext } from "../context/AuthContext";

Step 2: Create the hook states

Create states to manage the logout process, including error, pending, and cancellation states.

// Error state for potential errors during logout 
const [error, setError] = useState(null); 
// State to indicate if logout is in progress 
const [isPending, setIsPending] = useState(false); 
// State to track if the operation is cancelled
const [isCancelled, setIsCancelled] = useState(false);

Step 3: Extract the dispatch function from the authentication context

This function will be used to indicate a logout action has been called:

const { dispatch } = useAuthContext();

Step 4: Create the hook logic

Use a try-catch block create the logic of logging a user out:

try { 
// Initiating the logout using Firebase's signOut function 
    await signOut(auth); 
    dispatch({ type: "LOGOUT" }); // Dispatching a LOGOUT action 
// If the operation wasn't cancelled, reset pending state and error 
   if (!isCancelled) { 
       setIsPending(false); // Resetting isPending after the asynchronous call completes 
       setError(null); // Clearing any error that might have occurred 
     } 
   } catch (err) { 
      // Handling logout error 
     if (!isCancelled) { 
        console.log(err.message); // Logging the error message
        setError(err.message); // Setting the error state in case of an error 
        setIsPending(false); // Resetting pending state if an error occurs 
   } 
}

Step 5: How to handle unmounting

In the case where the component is unmounted (the page closes or there’s a route change), you’ll want to handle that occurrence to prevent errors.

// Effect hook to set isCancelled to true when component unmounts
   useEffect(() => { 
       return () => setIsCancelled(true); // The cleanup function runs when the component unmounts }, []);

Step 5: Exporting values

Return the relevant values and functions for other components to use.

 return { logout, error, isPending };

For ease of accesibility, here’s the full useLogout hook.

// Importing necessary hooks and functions
import { useEffect, useState } from "react";
import { auth } from "../firebase/config"; // Importing Firebase auth instance
import { signOut } from "firebase/auth"; // Importing signOut function from Firebase
import { useAuthContext } from "../context/AuthContext"; // Importing the custom hook to access the authentication context

// Custom hook for handling user logout
export const useLogout = () => {
  // State variables to manage logout process
  const [error, setError] = useState(null); // Error state for potential errors during logout
  const [isPending, setIsPending] = useState(false); // State to indicate if logout is in progress
  const [isCancelled, setIsCancelled] = useState(false); // State to track if the operation is cancelled
  const { dispatch } = useAuthContext(); // Accessing the authentication context's dispatch function

  // Function to initiate the logout process
  const logout = async () => {
    setError(null); // Clearing any previous errors
    setIsPending(true); // Indicating that the logout process is in progress

    try {
      // Initiating the logout using Firebase's signOut function
      await signOut(auth);
      dispatch({ type: "LOGOUT" }); // Dispatching a LOGOUT action

      // If the operation wasn't cancelled, reset pending state and error
      if (!isCancelled) {
        setIsPending(false); // Resetting isPending after the asynchronous call completes
        setError(null); // Clearing any error that might have occurred
      }
    } catch (err) {
      // Handling logout error
      if (!isCancelled) {
        console.log(err.message); // Logging the error message
        setError(err.message); // Setting the error state in case of an error
        setIsPending(false); // Resetting pending state if an error occurs
      }
    }
  };

  // Effect hook to set isCancelled to true when component unmounts
  useEffect(() => {
    return () => setIsCancelled(true); // The cleanup function runs when the component unmounts
  }, []);

  // Returning the relevant values and functions for component usage
  return { logout, error, isPending };
};

How to test the logout functionality

In your Home.jsx component, import the useLogout hook and extract the logout function. Attach the logout function to a button's onClick event to enable users to log out.

import { useLogout } from "../hooks/useLogout";

export default function Home() {
  const { user } = useAuthContext();
  const { logout } = useLogout(); //logout function extracted

  return (
    <div className="utility__page ">
      <h1> Home Page</h1>
      {user && (
        <>
          <div className="user">
            <p> You&apos;re logged in as: </p>
            <span>{user.displayName} </span>
            <img className="profile_img" src={user.photoURL} alt="" />
          </div>
           //logout function used
          <button className="logout" onClick={logout}>
             Log out
          </button>
        </>
      )}
    </div>
  );
}

At the moment, your home page looks like this;

Home page before logging the user out

Click on the button and log out the user.

Testing the log in and log out functionality

With that, your authentication process is completely set up, congrats!

Striking the Right Balance: Offering Both Social Media and Email/Password Authentication

User authentication is a key part of the user experience on any web app. Social media authentication can offer a streamlined experience and enhanced security, but it's important to strike a balance by also offering the option for email/password authentication. This ensures inclusivity, caters to various user preferences, and addresses privacy concerns.

By offering both options, you create a versatile and user-centric authentication process that contributes to a positive user experience.

An example of an ideal authentication page can be seen below.

Standard Auth Page

Guidelines for Building Auth Pages

It is important to apply some basics best practices when building authentication pages, such as:

1. Showing all the possible ways a user can get authenticated in a clear and concise manner.
2. Using authentic company icons to build trust. You can find free company SVGs on sites like Font Awesome, Google icons, and so on.
3. Use intuitive icons to label inputs such as envelope for mail and padlock for password.
4. Address privacy concerns by clearly communicating how user data will be used and protected during the authentication process.

For ease of accessibility, here’s a link to the repo.

Conclusion

In conclusion, using social media login with Firebase is a smart strategy. It brings together user-friendliness, safety, and privacy.

By offering various ways to log in, websites can accommodate different user choices, be more inclusive, and adapt to new trends.

Balancing authentication options like this makes users happy and builds trust. This is important for creating modern websites and ensuring smooth, user-focused logins.

Contact Information

Want to connect or contact me? Feel free to hit me up on the following:

• Twitter / X : @jajadavid8
• LinkedIn: David Jaja
• Email: Jajadavidjid@gmail.com

Using these open source libraries provides tremendous productivity benefits. However, it also comes with disadvantages – namely in relation to security.

Cyber-criminals and hackers have been increasingly exploiting vulnerabilities in applications and IT systems. It has, therefore, become more and more important to ensure that code bases minimize or totally eliminate vulnerabilities.

However, keeping tabs on all the vulnerabilities, let alone updated ones, in projects can be very daunting. That’s why in this article we’ll take a look at eight tools that automate the detection and fixing of vulnerable spots in a project.

DeepScan

DeepScan is a tool that analyzes JavaScript and TypeScript code. At its core, it not only inspects for code quality à la ESLint, but it also employs data-flow analysis and looks into the execution flow. Errors and quality issues are detected even without running the code.

DeepScan works with most JavaScript libraries such as React and Vue.js.

Teams can simply integrate their projects’ GitHub repository with DeepScan. Every time a push is made into a repository, DeepScan provides a real time report on test results.

One of the best things about this is that code quality standards are more enforceable. DeepScan motivates teams to write quality code by grading the project as Poor, Normal, or Good.

SonarQube

SonarQube is an open-source platform that continuously inspects a project for code quality, bugs, code-smells and even security vulnerabilities.

It's a tool written in Java but has the ability to analyze other languages through the use of plugins.

Unlike most of the others in this list, SonarQube isn’t integrated into a project as a simple GitHub extension. It needs to be installed in the local machine for you to be able to use it.

It works by receiving the project’s files as input and then making the necessary analysis. It then generates data based on the analysis, stores that data in a database, and displays it in a dashboard.

Dependabot

Dependabot is a tool you use inside of GitHub that automatically creates pull requests upon detection of vulnerabilities.

This tool performs scans on all of a repository’s dependency files and searches for outdated or insecure dependencies. It then generates a single pull request for each outdated or insecure dependency. The developer can then check those pull requests and merge as necessary.

The great thing about Dependabot is that it’s owned by GitHub so that it can be seamlessly integrated into any repository. It performs constant monitoring and quickly updates users when there's a new vulnerability.

It can be very chaotic to receive daily notifications, so users can configure the frequency that the tool performs scans and creates pull requests.

SourceClear

SourceClear is a tool that helps developers understand more about the open source libraries they are using. SourceClear provides information on those libraries such as who created them, what they do, and which dependencies of such libraries have vulnerabilities.

SourceClear meshes well with a developer’s workflow and provides real-time reports on open-source code risks. It has machine-learning tools that makes it possible to provide such detailed information for each library used.

One of its main features is the prioritization of vulnerabilities that are directly in the code’s execution path. This can reduce remediation time for big projects by up to 90%.

SpotBugs

SpotBugs, a successor to FindBugs, is a static code analyzer for Java code bases. It can either be used as a stand-alone tool or integrated to other platforms/tools.

Most Java programs compile cleanly but are still buggy. Compilation captures mostly only syntax and references errors, among others. Usage of static analysis tools such as SpotBugs provides a more comprehensive solution in catching bugs and even vulnerabilities.

SpotBugs inspects Java bytecode (not the source code) and checks for bug patterns. It then classifies errors or potential errors based on how severe they are: Of Concern, Troubling, Scary, Scariest.

This tool is very good at identifying bug patterns (over 400).

Arxan Application Protection

Arxan Application Protection is a total solution to “protect apps inside and out”. This tool’s main selling point - Protecting applications against reverse engineering.

A lot of today’s attacks such as clickjacking are engineered by cyber-criminals through hacking the app’s binary code and then creating a replica app. Users are then lured into trusting this fake app and giving away their data such as banking passwords.

Arxan protects an application from such attacks by “hardening” the application’s code by inserting “code guards” into them. These code guards are tiny security units which protect the application and each other against compromise and they detect attacks at runtime.

GitLab

One of GitLab’s core value propositions to developers is that it is one of the most exquisite devops tools out there. Added to this is GitLab’s focus on secure deployment.

The platform has incorporated security in its already loaded devops arsenal. Developers can focus on coding while being confident that any security vulnerability will quickly be detected. This makes it very pleasant to use, as no additional tool or integration is necessary.

It employs what it calls the Secure Stage where all the security parts of devops are performed. This “stage” has a goal of identifying proactively any vulnerabilities before they can be exploited in production code.

Conclusion

Each tool has its own pros and cons and the choice to use one over the other depends on the particular taste of the developer. Often, some tools can even be used together.

The bottom line is that nowadays we are more equipped to handle security issues before they become big problems in our application projects.

Especially in a software market where shipping new apps seems more like a race for reputation than a well-considered process, one of the most important questions often falls to the bottom of the “Urgent” column: how will our product be secured?

If you’re using a robust, open-source framework for building your product (and if one is applicable and available, why wouldn’t you?) then some basic security concerns, like CSRF tokens and password encryption, may already be handled for you.

Still, fast-moving developers would be well served to brush up on their knowledge of common threats and pitfalls, if only to avoid some embarrassing rookie mistakes. Usually, the weakest point in the security of your software is you.

I’ve recently become more interested in information security in general, and practicing ethical hacking in particular. An ethical hacker, sometimes called a “white hat” hacker, and sometimes just a “hacker,” is someone who searches for possible security vulnerabilities and responsibly (privately) reports them to project owners.

By contrast, a malicious or “black hat” hacker, also called a “cracker,” is someone who exploits these vulnerabilities for amusement or personal gain.

Both white hat and black hat hackers might use the same tools and resources, and generally try to get into places they aren’t supposed to be. But white hats do this with permission, and with the intention of fortifying defences instead of destroying them. Black hats are the bad guys.

When it comes to learning how to find security vulnerabilities, it should come as no surprise that I’ve been devouring whatever information I can get my hands on. This post is a distillation of some key areas that are specifically helpful to developers when handling user input. These lessons have been collectively gleaned from these excellent resources:

• The Open Web Application Security Project guides
• The Hacker101 playlist from HackerOne’s YouTube channel
• Web Hacking 101 by Peter Yaworski
• Brute Logic’s blog
• The Computerphile YouTube channel
• Videos featuring Jason Haddix (@jhaddix) and Tom Hudson (@tomnomnom) (two accomplished ethical hackers with different, but both effective, methodologies)

You may be familiar with the catchphrase, “sanitize your inputs!” However, as I hope this post demonstrates, developing an application with robust security isn’t quite so straightforward.

I suggest an alternate phrase: pay attention to your inputs. Let’s elaborate by examining the most common attacks that take advantage of vulnerabilities in this area: SQL injection and cross site scripting.

SQL injection attacks

If you’re not yet familiar with SQL (Structured Query Language) injection attacks, or SQLi, here is a great explain-like-I’m-five video on SQLi. You may already know of this attack from xkcd’s Little Bobby Tables.

Essentially, malicious actors may be able to send SQL commands that affect your application through some input on your site, like a search box that pulls results from your database. Sites coded in PHP can be especially susceptible to these, and a successful SQL attack can be devastating for software that relies on a database (as in, your Users table is now a pot of petunias).

You have no chance to survive make your time.

You can test your own site to see if you’re susceptible to this kind of attack. (Please only test sites that you own, since running SQL injections where you don’t have permission to be doing so is, possibly, illegal in your locality; and definitely, universally, not very funny.) The following payloads can be used to test inputs:

• ' OR 1='1 evaluates to a constant true, and when successful, returns all rows in the table.
• ' AND 0='1 evaluates to a constant false, and when successful, returns no rows.

This video demonstrates the above tests, and does a great job of showing how impactful an SQL injection attack can be.

Thankfully, there are ways to mitigate SQL injection attacks, and they all boil down to one basic concept: don’t trust user input.

SQL injection mitigation

In order to effectively mitigate SQL injections, developers must prevent users from being able to successfully submit raw SQL commands to any part of the site.

Some frameworks will do most of the heavy lifting for you. For example, Django implements the concept of Object-Relational Mapping, or ORM, with its use of QuerySets. We can think of these as wrapper functions that help your application query the database using pre-defined methods that avoid the use of raw SQL.

Being able to use a framework, however, is never a guarantee. When dealing directly with a database, there are other methods we can use to safely abstract our SQL queries from user input, though they vary in efficacy. These are, by order of most to least preferred, and with links to relevant examples:

1. Prepared statements with variable binding (or parameterized queries),
2. Stored procedures; and
3. Whitelisting or escaping user input.

If you want to implement the above techniques, the linked cheatsheets are a great starting point for digging deeper. Suffice to say, the use of these techniques to obtain data instead of using raw SQL queries helps to minimize the chances that SQL will be processed by any part of your application that takes input from users, thus mitigating SQL injection attacks.

The battle, however, is only half won…

Cross Site Scripting (XSS) attacks

If you’re a malicious coder, JavaScript is pretty much your best friend. The right commands will do anything a legitimate user could do (and even some things they aren’t supposed to be able to) on a web page, sometimes without any interaction on the part of an actual user.

Cross Site Scripting attacks, or XSS, occur when JavaScript code is injected into a web page and changes that page’s behavior. Its effects can range from prank nuisance occurrences to more severe authentication bypasses or credential stealing. This incident report from Apache in 2010 is a good example of how XSS can be chained in a larger attack to take over accounts and machines.

The annual DOM dance-off receives an unexpected guest

XSS can occur on the server or on the client side, and generally comes in three flavors: DOM (Document Object Model) based, stored, and reflected XSS. The differences amount to where the attack payload is injected into the application.

DOM based XSS

DOM based XSS occurs when a JavaScript payload affects the structure, behavior, or content of the web page the user has loaded in their browser. These are most commonly executed through modified URLs, such as in phishing.

To see how easy it would be for injected JavaScript to manipulate a page, we can create a working example with an HTML web page. Try creating a file on your local system called xss-test.html (or whatever you like) with the following HTML and JavaScript code:

<html>
    <head>
        <title>My XSS Example</title>
    </head>
    <body>
        <h1 id="greeting">Hello there!</h1>
            <script>
                var name = new URLSearchParams(document.location.search).get('name');
                if (name !== 'null') {
                    document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';
                }
            </script>
        </h1>
</html>

This web page will display the title “Hello there!” unless it receives a URL parameter from a query string with a value for name. To see the script work, open the page in a browser with an appended URL parameter, like so:

file:///path/to/file/xss-test.html?name=Victoria

Fun, right? Our insecure (in the safety sense, not the emotional one) page takes the URL parameter value for name and displays it in the DOM. The page is expecting the value to be a nice friendly string, but what if we change it to something else? Since the page is owned by us and only exists on our local system, we can test it all we like. What happens if we change the name parameter to, say, <img+src+onerror=alert("pwned")>?

This is just one example, largely based on one from Brute’s post, that demonstrates how an XSS attack could be executed. Funny pop-up alerts may be amusing, but JavaScript can do a lot of harm, including helping malicious attackers steal passwords and personal information.

Stored and reflected XSS

Stored XSS occurs when the attack payload is stored on the server, such as in a database. The attack affects a victim whenever that stored data is retrieved and rendered in the browser. For example, instead of using a URL query string, an attacker might update their profile page on a social site to include a hidden script in, say, their “About Me” section. The script, improperly stored on the site’s server, would successfully execute at a later time when another user views the attacker’s profile.

One of the most famous examples of this is the Samy worm that all but took over MySpace in 2005. It propogated by sending HTTP requests that replicated it onto a victim’s profile page whenever an infected profile was viewed. Within just 20 hours, it had spread to over a million users.

Reflected XSS similarly occurs when the injected payload travels to the server, however, the malicious code does not end up stored in a database. It is instead immediately returned to the browser by the web application.

An attack like this might be executed by luring the victim to click a malicious link that sends a request to the vulnerable website’s server. The server would then send a response to the attacker as well as the victim, which may result in the attacker being able to obtain passwords, or perpetrate actions that appear to originate from the victim.

XSS attack mitigation

In all of these cases, XSS attacks can be mitigated with two key strategies: validating form fields, and avoiding the direct injection of user input on the web page.

Validating form fields

Frameworks can again help us out when it comes to making sure that user-submitted forms are on the up-and-up. One example is Django’s built-in Field classes, which provide fields that validate to some commonly used types and also specify sane defaults. Django’s EmailField, for instance, uses a set of rules to determine if the input provided is a valid email. If the submitted string has characters in it that are not typically present in email addresses, or if it doesn’t imitate the common format of an email address, then Django won’t consider the field valid and the form will not be submitted.

If relying on a framework isn’t an option, we can implement our own input validation. This can be accomplished with a few different techniques, including type conversion, for example, ensuring that a number is of type int(); checking minimum and maximum range values for numbers and lengths for strings; using a pre-defined array of choices that avoids arbitrary input, for example, months of the year; and checking data against strict regular expressions.

Thankfully, we needn’t start from scratch. Open source resources are available to help, such as the OWASP Validation Regex Repository, which provides patterns to match against for some common forms of data. Many programming languages offer validation libraries specific to their syntax, and we can find plenty of these on GitHub. Additionally, the XSS Filter Evasion Cheat Sheet has a couple suggestions for test payloads we can use to test our existing applications.

While it may seem tedious, properly implemented input validation can protect our application from being susceptible to XSS.

Avoiding direct injection

Elements of an application that directly return user input to the browser may not, on a casual inspection, be obvious. We can determine areas of our application that may be at risk by exploring a few questions:

• How does data flow through our application?
• What does a user expect to happen when they interact with this input?
• Where on our page does data appear? Does it become embedded in a string or an attribute?

Here are some sample payloads that we can play with in order to test inputs on our site (again, only our own site!) courtesy of Hacker101. The successful execution of any of these samples can indicate a possible XSS vulnerability due to direct injection.

• "><h1>test</h1>
• '+alert(1)+'
• "onmouserover="alert(1)
• http://"onmouseover="alert(1)

As a general rule, if you are able to design around directly injecting input, do so. Alternatively, be sure to completely understand the effect of the methods you choose; for example, using innerText instead of innerHTML in JavaScript will ensure that content will be set as plain text instead of (potentially vulnerable) HTML.

Pay attention to your inputs

Software developers are at a marked disadvantage when it comes to competing with black hat, or malicious, hackers. For all the work we do to secure each and every input that could potentially compromise our application, an attacker need only find the one we missed. It’s like installing deadbolts on all the doors, but leaving a window open!

By learning to think along the same lines as an attacker, however, we can better prepare our software to stand up against bad actors. Exciting as it may be to ship features as quickly as possible, we’ll avoid racking up a lot of security debt if we take the time beforehand to think through our application’s flow, follow the data, and pay attention to our inputs.

The story of requesting twice, allow me to explain how it all began.

While working on a feature, I decided to look at the network tab and observed that the first request was sent with method OPTIONS, and the following request after it was the request with the correct method eg GET, POST etc, which is returning the expected payload. Basically two calls for the same request.

Here take a look at the screen shots below

Request with OPTIONS method

Request with GET method

After digging few docs, I realised it was an expected behaviour. It is related to the concept of HTTP access control (CORS).

To understand it better, let me explain a bit about CORS and requests.

HTTP access control (CORS)

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use.

Cross-Origin Resource Sharing (CORS)

Let us understand the above image above to get a better understanding of CORS.

1. Same Origin Request: We have opened domain-a.com, where we are requesting a blue image hosted in web server domain-a.com. Since we are performing our requests in the same domain, it is called a Same-origin request.

2. Cross Origin Request: We have opened domain-a.com, where we are requesting a red image hosted in web server domain-b.com. Since we are performing our requests in different domains, it is called a Cross-origin Request.

Simple requests

These are requests that doesn't send it’s first request as method OPTIONS. It is fired only once.

Surely it begs the question, why will the first request have method OPTIONS if we are not sending it, please have patience it will be explained below in preflight section ☺

But before that let us understand what are the points that make request simple.

1. The only allowed methods in simple request are:

• GET

• HEAD

• POST

2. Apart from the headers set automatically by the user agent (for example, connection , User-Agent, or any of the other headers with names defined in the Fetch spec as a “forbidden header name”), the only headers which are allowed to be manually set are those which the Fetch spec defines as being a “CORS-safelisted request-header”, which are:

• Accept

• Accept-Language

• Content-Language

• Content-Type

• DPR

• Downlink

• Save-Data

• Viewport-Width

• Width

3. The only allowed values for the Content-Type header are:

• application/x-www-form-urlencoded

• multipart/form-data

• text/plain

4. No event listeners are registered on any XMLHttpRequestUpload object used in the request.

5. No ReadableStream object is used in the request.

Preflighted requests

Preflighted request is a type of request which sends an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data. It is evident from the screenshots above.

For requests like PUT, DELETE, PATCH etc, preflight requests are sent.

Below flowchart summarises really well how it works.

Image Courtesy html5rocks

This flowchart opens up a door to a whole new knowledge. Couldn’t help but appreciate how good it is!

Strangely enough even GET request was observed to have preflights which for my case was due to presence of custom header Authorization, which can be seen from the screenshot below

Is Preflight request bad?

It is a small request without a body, but I always felt it as a bother. It is still a request, and each request is a cost, no matter how small that request is, so I definitely recommend to try and avoid having such cases.

How do we avoid it?

Well the easiest solution is avoid CORS, try to keep our resources and APIs in the same domain. It is really that simple.

Conclusion

It is always good to be armed with knowledge of how requests work. Even if the cost is very low, it still matters. Saving small requests can make our application really fast in the long run. Well I believe in the future, which is fast and furious.

Follow me on twitter to get more updates regarding new articles and to stay updated in latest frontend developments. Also share this article on twitter to help others know about it. Sharing is caring ^_^

Some helpful resources

Below are some of the links that inspired this article

1. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

2. https://stackoverflow.com/questions/24704638/options-request-makes-application-2x-slower

3. https://stackoverflow.com/questions/29954037/why-is-an-options-request-sent-and-can-i-disable-it/29954326

4. https://www.html5rocks.com/en/tutorials/cors/

Summary

This post is about a critical bug on Uber which could have been used by hackers to get unlimited free Uber rides anywhere in the world. This post also explains few best practices while integrating payment gateways.

Description

Uber Technologies Inc. is an online transportation network company, headquartered in San Francisco, California, with operations in 528 cities worldwide. Users can create their account on Uber.com and book a ride. When the ride is completed a user can either pay cash or charge it to their credit/debit card.

But, by specifying an invalid payment method (for example, abc, xyz, and so on), I was able to ride Uber for free.

To demonstrate the bug, I got permission from the Uber Team and took a free ride in India. I wasn’t charged for any of my rides, using the invalid payment method.

Vulnerable request:

POST /api/dial/v2/requests HTTP/1.1 Host: dial.uber.com {“start_latitude”:12.925151699999999,”start_longitude”:77.6657536,
“product_id”:”db6779d6-d8da-479f-8ac7–8068f4dade6f”,”payment_method_id”:”xyz”}

Steps to reproduce:

1. Replayed the above request with random characters as payment_method_id.
2. Ride was free.

Video POC:

Thanks to Uber Security team for fixing this quickly.

The timeline

Aug 22nd 2016: Vulnerability Report to Uber.

Aug 26th 2016: Uber requested more information about the bug.

Aug 26th 2016: Took a free ride and replied with ride details

Aug 27th 2016: Vulnerability fixed by Uber.

Sep 10th 2016: Rewarded with $5000 bounty by Uber.

Takeaways

As a developer, you should always take care of the below test cases when integrating payments:

a) Verify if the payment was success or failure by doing a server to server request to payment gateway or verifying checksum to the payment gateway provider.

b) Always validate the amount of the item with the amount which was paid by the user to the payment gateway.

c) Validate currency in the payment API calls. For example, the attacker can pay 50 IDR for a 50 USD item.

d) If you are storing credit cards/debit card information, then always check for authorisation if an identifier is being passed in one of the API requests.

AppSecure is a specialised cyber security company with years of skill acquired and meticulous expertise. We are here to safeguard your business and critical data from online and offline threats or vulnerabilities.

Contact us: hello@appsecure.in