DEV Community: Andy

Reflected XSS attack on localStorage

Andy — Thu, 30 Jul 2020 16:18:22 +0000

We've all seen the debates about localStorage vs. cookies when it comes to handling client-side JWTs. You may choose to store your JWTs in one or the other depending on which article you read. But what does an XSS attack actually look like?

XSS Overview

The Open Web Application Security Project (OWASP) defines XSS as:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites.

In other words, attackers can use the features of your site to inject malicious Javascript. It's important to note that any client-side Javascript has access to localStorage, sessionStorage and cookies (non-HttpOnly).

Example

I'm going to use a simple error page that users are redirected to if they encounter an general error. I've seen this used many times (hopefully a little better than what I'm about to show!)

Note: Let's assume that our site authenticates users via JWT and stores them in localStorage.

Here's our beautiful error page:

It accepts code and message parameters to display in the page like so:



.../error.html?code=500&message=Something%20went%20wrong

The code that handles displaying the message looks like:



const params = new URL(document.location).searchParams
const errorCode = parseInt(params.get("code"))
const errorMessage = params.get("message")

document.getElementById("error-code").innerHTML ="Error code: " + errorCode
document.getElementById("error-message").innerHTML = errorMessage

Can you spot the mistake? 😏

We are getting the error message from the URL and placing it into our document HTML... 🤔

What would happen if an attacker was to try to inject some Javascript instead of a message?

Uh-oh! This confirms to the attacker that this page is vulnerable to an attack called Reflected XSS.

With some creativity, it's not a huge leap to get the contents of your local storage (which includes your JWT) and send it off to the attacker... bye bye token!

Once the attacker has your token, it's trivial to reveal all information stored in that token. They are just base64 encoded objects.

Solution

The main issue with our code is that we are getting the message string from the URL and inserting it directly into our document HTML. Instead, we should:

Sanitise anything that could come from the user (including URL parameters).
Use .textContent instead.

A good tip is Don't store anything in the JWT you wouldn't already consider public. This way, even if your site happens to be vulnerable to XSS, the attacker isn't gaining any private information.

Conclusion

There is nothing wrong with storing JWTs in localStorage. The issue is with poor coding practices that have the potential to expose your site and users to attack.

Granted, this was a simple (and contrived) example of reflected XSS, but there are other DOM-based attacks your app may be vulnerable to.

It's fun to break things you're working on and see if you can patch any vulnerabilities before they make it out!

Here are some good places to learn more:

Have fun! Thanks for reading! 😃

Store array data in keyed-objects for better performance

Andy — Mon, 27 Jul 2020 15:18:52 +0000

There are plenty of ways to store client-side data in Javascript and React, not to mention ES6's data structures like Set and Map, but sometimes all you need is a simple object.

I use this pattern almost daily in combination with redux and/or context to streamline data access. I want to demonstrate how we can use a keyed-object to increase performance vs. storing data in a typical array.

Problem Example

Let's say we're fetching an array of people from an API to display a list:

[  
  {
    'id': 1,
    'name': 'Keanu Reeves',
    'bio': 'Bad ass' 
  },
  {
    'id': 2,
    'name': 'Elon Musk',
    'bio': 'Space cowboy' 
  },
  ...
  {
    'id': 20,
    'name': 'Tom Hanks',
    'bio': 'Toy cowboy' 
  },
]

Assuming we store this array somewhere client side, if we wanted to access a particular user by ID, we would need to do something like people.find(x => x.id === 1). This has a time complexity of O(n) and can be expensive if the array is large.

O(n) means the larger the array gets, the longer it can take to find what you're looking for! This is because it has to potentially check every item in the array 👎

Solution Example

By looping through the results in the API response, we can build a keyed-object.

const keyedObject = {};
response.map(person => {
  const {id, ...rest} = person
  keyedObject[id] = rest
});

Added bonus (looping)

If we need to loop through the data to display a list for example, we can create an array to store the IDs.

The final solution might look like this:

const keyedObject = {};
const ids = response.map(person => {
  const {id, ...rest} = person
  keyedObject[id] = rest
  return id
});

Now we can quickly access our data by ID with O(1) time complexity and loop through the data using our ids array.

O(1) is great for performance because no matter how large the array or object is, we can always go straight to the item we want! 👍

const name = keyedObject[personId].name
const allNames = ids.map(id => keyedObject[id].name)

Thanks for reading! 😃

OIDC Authentication with React & Identity Server 4

Andy — Sun, 26 Jul 2020 16:37:34 +0000

I put this small demo together with the following objectives:

Authenticate a React app user via Identity Server 4 using OIDC.
Store authenticated user details in a central store client side.
Have a public and a protected route within the app. Only authenticated users can access protected route.
Fetch data from a protected web API using a JWT. Only authenticated users can access the API.

Basic Architecture

React app will serve as the customer facing site.
Identity Server 4 will implement OpenID Connect and be used to authenticate users.
.NET Core API will have a protected enpoint that will serve some doughnut-y goodness 🍩.

Identity Server 🤖

Starting with one of the .NET templates provided by Identity Server, we need to configure our client, API resource and test user. For the purpose of this demo I will just create a single client, API resource and test user: Peter Parker 🕷️.

The GetClients function of config.cs is configured as follows:



public static IEnumerable<Client> GetClients()
{
    return new[]
    {
        new Client
        {
            // unique ID for this client
            ClientId = "wewantdoughnuts", 
            // human-friendly name displayed in IS
            ClientName = "We Want Doughnuts", 
            // URL of client
            ClientUri = "http://localhost:3000", 
            // how client will interact with our identity server (Implicit is basic flow for web apps)
            AllowedGrantTypes = GrantTypes.Implicit, 
            // don't require client to send secret to token endpoint
            RequireClientSecret = false, 
            RedirectUris =
            {             
                // can redirect here after login                     
                "http://localhost:3000/signin-oidc",            
            },
            // can redirect here after logout
            PostLogoutRedirectUris = { "http://localhost:3000/signout-oidc" }, 
            // builds CORS policy for javascript clients
            AllowedCorsOrigins = { "http://localhost:3000" }, 
            // what resources this client can access
            AllowedScopes = { "openid", "profile", "doughnutapi" }, 
            // client is allowed to receive tokens via browser
            AllowAccessTokensViaBrowser = true 
        }
    };
}

Also in config.cs, we can add our web API as a resource in GetApis:



public static IEnumerable<ApiResource> GetApis()
{
    return new ApiResource[]
    {
        // name and human-friendly name of our API
        new ApiResource("doughnutapi", "Doughnut API") 
    };
}

Web API 🕸️

Our web API will serve up doughnut freshness from behind a protected endpoint. When calling the API from our React app, we will pass a bearer token in the request headers. The API can verify the token and give us what we want.

In the .NET Core Web API template project we can add bearer token authentication by adding the following to the ConfigureServices method in Startup.cs:



services.AddAuthentication("Bearer")
    .AddJwtBearer("Bearer", options =>
    {
        // URL of our identity server
        options.Authority = "https://localhost:5001";
        // HTTPS required for the authority (defaults to true but disabled for development).
        options.RequireHttpsMetadata = false; 
        // the name of this API - note: matches the API resource name configured above
        options.Audience = "doughnutapi"; 
    });

Next, we can add the middleware to the app by adding app.UseAuthentication() to the Configure method of Startup.cs. This allows authentication to be performed on every request.



public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseCors(builder =>
          builder
            .WithOrigins("http://localhost:3000")
            .AllowAnyHeader()
            .AllowAnyMethod()
            .AllowCredentials()
        );

    app.UseAuthentication();
    app.UseMvc();

    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.Run(async (context) =>
    {
        await context.Response.WriteAsync("Doughnut API is running!");
    });
}

React SPA 👾

We can use Create React App to spin up a quick React project. From there, we can add our components and services for authenticating a user.

userService.js

We are using IdentityModel's oidc-client to implement our OIDC flow in React. I've created a userService that will abstract all functionality relating to OIDC and user management. oidc-client exposes a UserManager class that requires a config object:



const config = {
  // the URL of our identity server
  authority: "https://localhost:5001", 
  // this ID maps to the client ID in the identity client configuration
  client_id: "wewantdoughnuts", 
  // URL to redirect to after login
  redirect_uri: "http://localhost:3000/signin-oidc", 
  response_type: "id_token token",
  // the scopes or resources we would like access to
  scope: "openid profile doughnutapi", 
  // URL to redirect to after logout
  post_logout_redirect_uri: "http://localhost:3000/signout-oidc", 
};

// initialise!
const userManager = new UserManager(config)

userService.js exports various functions that use the userManager class created above.

Initiating OIDC flow

Using userService.signinRedirect(), we can initiate the OIDC login flow. This will redirect the user to the login screen of Identity Server, and once authenticated, will redirect them back to the redirect_uri provided when configuring the UserManager class.

Callback Routes

For the simplicity of this demo, 2 callback routes have been configured: /signin-oidc and /signout-oidc.

Once the user has logged in, they are redirected to /signin-oidc on the client. On page load, userService.signinRedirectCallback() will process the response from the OIDC authentication process. Once complete, the user is redirected to the home page and authentication has been successful! Yay!



function SigninOidc() {
  const history = useHistory()
  useEffect(() => {
    async function signinAsync() {
      await signinRedirectCallback()
      // redirect user to home page
      history.push('/')
    }
    signinAsync()
  }, [history])

Similarly, when the user logs out they are redirected to Identity Server to confirm logout then back to /signout-oidc on the client. This is where we can do any further actions such as redirecting the user to a 'Logout Successful!' page.

AuthProvider

Inspired by this Medium article on implementing OIDC in React, I used React Context to create an AuthProvider to wrap all components of the app. I'm only using this to handle events triggered in our userManager class:



userManager.current.events.addUserLoaded(onUserLoaded)
userManager.current.events.addUserUnloaded(onUserUnloaded)
userManager.current.events.addAccessTokenExpiring(onAccessTokenExpiring)
userManager.current.events.addAccessTokenExpired(onAccessTokenExpired)
userManager.current.events.addUserSignedOut(onUserSignedOut)

The UserLoaded event is used to store the user object from Identity Server in Redux. This user object includes an access token which is added to the authorization header in axios.

We're done! 👊

A user of our React app can successfully authenticate via Identity Server and call our web API to get some doughnut-y goodness!

This doesn't implement more advanced features such as silently renewing tokens but it does serve as a demonstration of adding OIDC to a React app.

Feel free to clone the Github repo and have a poke around the demo and source code. PRs also welcome!