DEV Community: нιтєѕн кυмαя

CSRF in Action 🎭

нιтєѕн кυмαя — Mon, 01 Jul 2019 08:54:08 +0000

Originally published on https://smellycode.com/csrf-in-action/

Cross-Site Request Forgery(CSRF/XSRF) is one of the most popular ways of exploiting a server. It attacks the server by forcing the client to perform an unwanted action. This attack targets applications where the client/user is already logged in. It mainly changes the state of the server by making inadvertent updates or transfer of data. For example, updating vital information like emails contact numbers, etc. or transferring data from one entity to another.

This post demonstrates CSRF attack and elaborates concepts linger around it. It uses a simple todo app and an evil client--which updates the state of todos--for demonstration. Technologies used:

ReactJs for client.
ExpressJs and a couple of middlewares(CORS, body-parser, cookie-parser, etc) for server.
MongoDb as database and Mongoose for data modeling.
JWT for stateless session management.
and a few other stuff.

The sample todo app uses JSON Web Token for stateless session management and authentication. It stores the token in a cookie with httpOnly flag to make the token inaccessible to the JavaScript running on the client. Picture below depicts the auth flow of the app.

Let's take a gander at the code organization of the app. The codebase has three actors -- a server, a client, and an evil client.

The server exposes a few endpoints for CRUD operations on both user(/users) and todo(/todos). It uses mongoose to store data in MongoDB. It also supports cross-origin requests from a client running at localhost:3001(middleware cors is used to enable cross-origin resource sharing). The server runs at http://localhost:3000.

The client has a simple login form and a todo list. It uses ReactJs to build the UI and axios for ajax calls. When the client is loaded, it fetches todos(GET, /todos) of the logged in user. If there's an authentication error(status code is 401), it directs the user to login. Todos are successfully fetched only when the user is logged in.

The evil client runs at http://locahost:3002 with the help of the package http-server. It has a plain HTML page and a form. The form opens its action in a hidden iframe for silent submission. The app lures the user to click on a button which stimulates the form submission. Form submission makes a post call to http://localhost:3000/todos/complete which marks todos belonging to the logged in user as complete.

<!DOCTYPE html>
<html>
  <body>
    <h1>Hey There!</h1>
    <p
      >Having a rough day! Don't worry, I have got a picture of a cute cat to
      cheer you up. <button id="btn_cat">Show me 🐱</button>
    </p>
    <iframe style="display:none" name="csrf-frame"></iframe>
    <form
      method="POST"
      action="http://localhost:3000/todos/complete"
      target="csrf-frame"
      id="csrf-form"
    >
    </form>
    <script type="text/javascript">
      document.getElementById('btn_cat').addEventListener('click', () => {
        document.getElementById('csrf-form').submit();
      });
    </script>
  </body>
</html>

Evil client in action:

Let's address questions which create confusion.

Q: Why no authentication error? 🤔

The server does not throw any authentication error cause the request contains a valid JWT token. The request gets the token from cookies.

When receiving an HTTP request, a server can send a Set-Cookie header with the response. The cookie is usually stored by the browser, and then the cookie is sent with requests made to the same server inside a Cookie HTTP header. ~ Mozila

When the user logs in, the JWT is stored in an httpOnly cookie(see auth flow). Cookies are sent with every request to the same server. Because of that, the JWT becomes part of every request 🤖.

Q: Shouldn't the CORS setup help here?

Let's talk about CORS before jumping to the answer. Browsers limit the interaction of scripts or document loaded on one origin(a tuple of protocol, domain, and port) with another origin to avoid Jungle Raj. The mechanism used for imposing such limitations is known as Same Origin Policy. It ensures that applications are running in isolated environments. Sometimes, developers need to relax the same-origin policy so that applications can interact with each other. That's what originates the idea of Cross-Origin Resource Sharing(CORS). CORS allows site-a to interact with site-b only if site-b agrees--by responding with appropriate HTTP headers. To enable CORS, the server needs a tad of work(the sample todo app uses cors middleware for the same).

In the browser world, ajax requests are classified into three categories:

Simple Request
Non-simple request
Preflight request ✈️.

More details on these can be found here.

Whenever a cross-origin resource is requested using a non-simple request, the browser makes a pre-flight OPTIONS request. The server responds to the pre-flight request with appropriate response headers. If the origin and the request method are present in Access-Control-Allow-Origin and Access-Control-Allow-Methods, the browser originates the main request. Otherwise, a cors error is thrown with a pertinent message.

Network logs of the todo app with preflight requests.

For simple requests, the browser doesn't intiate any preflgiht request. The malicious client leverages this fact to bypass the Same Origin Policy with the help of an HTML form. That's why CORS set up doesn't help here 🤯.

Q: What if WebStorage is used to store JWT instead of httpOnly cookie?

Storing JWT in the Web Storage will make the app less vulnerable for CSRF attacks. But it spikes the chances of the token being compromised. That's because any JavaScript running on the client has access to the web storage. It's DANGEROUS 🛑.

Q: How to prevent CSRF?

The challenge for the server is to validate both the token and the source of the request i.e. origin. The token validation is already implemented. The server needs to verify the source of the request for CSRF protection. The source can either be verified with the help of CORS Origin Header or an XSRF Token. Shielding server with XSRF token(CSRF token) is more reliable and popular than CORS Origin Header.

The implementation of the XSRF token is straight forward. When the client represents valid credentials, the server generates a random unguessable unique string named as xsrfToken. It puts the xsrfToken in JWT along with other claims. The server also adds an xsrfToken in a cookie(why cookie? cause cookies are limited by same-origin policy). Here's a sample JWT payload with xsrfToken:

{
  "sub": "hk",
  "xsrfToken": "cjwt3tcmt00056tnvcfvnh4n1",
  "iat": 1560336079
}

The client reads the token from cookies and adds the token to request headers as X-XSRF-TOKEN before making requests. When the server receives a request, it reads xsrfToken from JWT payload and compares with the X-XSRF-TOKEN header. If both are same then the request is further processed otherwise it is terminated with status code 401. This technique is also known as Double Submit Cookies method.

The auth flow with XSRF token:

Code version of the same with express-jwt:

const expressJwt = require('express-jwt');

// Paths without token.
const publicRoutes = ['/users/register', '/users/authenticate'];

const isRevoked = async (req, payload, done) => {
  const { xsrfToken } = payload;
  done(null, xsrfToken !== req.get('X-XSRF-TOKEN'));
};

module.exports = () =>
  expressJwt({
    secret: process.env.JWT_SECRET,

    getToken: req =>
      req.get('X-XSRF-TOKEN') && req.cookies.jwtToken
        ? req.cookies.jwtToken
        : null,
    isRevoked
  }).unless({
    path: publicRoutes
  });

Client side request interceptor with axios:

import axios from 'axios';

const getCookies = () =>
  document.cookie.split(';').reduce((cookies, item) => {
    const [name, value] = item.split('=');
    cookies[name] = value;
    return cookies;
  }, {});

const baseURL = 'http://localhost:3000';

const ajax = axios.create({
  baseURL,
  timeout: 5000,
  withCredentials: true
});

// Add a request interceptor
ajax.interceptors.request.use(function(config) {
  const xsrfToken = getCookies()['xsrfToken'];
  // CSRF Token.
  if (xsrfToken) config.headers['X-XSRF-TOKEN'] = xsrfToken;
  return config;
});

export default ajax;

Note: Real-world applications require a more elegant mechanism for handling CSRF tokens. You may want to use the middleware csurf.

The evil client after CSRF token:

The final code of the sample app is uploaded here. Thanks for reading 🙏🏻.

Component Glossary 📖

нιтєѕн кυмαя — Wed, 26 Jun 2019 06:25:09 +0000

Originally published on https://smellycode.com/component-glossary/

Components are basic building blocks of modern web applications. They help web developers to break complex user interfaces into independent smaller blocks or pieces which can be reused and plugged with other pieces or components as is. In general, a component is

"a part or element of a larger whole, especially a part of a machine or vehicle." ~ Google

This article explains various types of components with words and code.

Function Components

Function Components are JavaScript functions which take inputs known as props and returns a React Element as output. Here's a simple Greetings function component to greet.

function Greetings(props) {
  return <h1>Hello {props.name}</h1>;
}

// With arrow function
// const Greetings = props => <h1>Hello {props.name}</h1>;

People often mix up function components with "Functional Components". Every component is a functional component if it is functioning or working fine. 😀

React does not instantiate function components. It means they can not be accessed with the ref attribute. Lack of instantiation also makes the life-cycle hooks inaccessible to function components.

Function components don't have any state unless they are hooked.

Class Components

Components created with ES6 Classes are known as Class Components. Class components extend the base class React.Component. Unlike function components, class components can have state and access the life-cycle methods. Class Components define a render method which returns a react element as output. Here's a simple Clock component to display time.

class Clock extends React.Component {
  state = { now: new Date() };

  intervalId = null;

  updateTime = () => this.setState({ now: new Date() });

  componentDidMount() {
    this.intervalId = setInterval(() => this.updateTime(), 1000);
  }

  componentWillUnmount() {
    clearInterval(this.intervalId);
  }

  render() {
    return <p>{this.state.now.toLocaleTimeString({}, { hour12: true })}</p>;
  }
}

Instances of class components can be accessed with the ref attribute.

class App extends React.Component {
  clockRef = React.createRef();

  componentDidMount() {
    // instance of the clock component
    console.log(this.clockRef.current);
  }

  render() {
    return <Clock ref={this.clockRef} />;
  }
}

Pure Components

Let's discuss a simple Greetings React.Component first.

class Greetings extends React.Component {
  render() {
    console.count('Greetings --> render');
    return <p>Hello {this.props.name}!</p>;
  }
}

It greets with a name passed as props. An additional console.count statement is added to render method to count executions.

The App component below takes name from a form input control and passes it to the Greetings component.

class App extends React.Component {
  state = { name: 'Sheldon', text: '' };

  handleChange = event => {
    this.setState({ text: event.target.value });
  };

  handleSubmit = event => {
    event.preventDefault();
    this.setState({ text: '', name: this.state.text });
  };

  render() {
    return (
      <div>
        <form onSubmit={this.handleSubmit}>
          <input
            type="text"
            value={this.state.text}
            required
            onChange={this.handleChange}
          />
          <input type="submit" value="Greet" />
        </form>
        <Greetings name={this.state.name} />
      </div>
    );
  }
}

When a user interacts with the input control, it updates the state of the App component. React invokes the render method--with the updated state and props--of the App component and its children to create a new React Element tree for diffing. Although, the state and props of the Greetings component are not changed, still React calls the render method of the Greetings component.

In large applications, such unnecessary executions of render methods create performance issues and bog down user interfaces. The shouldComponentUpdate life-cycle method is used to avoid these unnecessary re-renderings of the component. By default, shouldComponentUpdate return true, but its implementation can be easily overridden. Let's override shouldComponentUpdate for the Greetings component.

class Greetings extends React.Component {
  shouldComponentUpdate(nextProps) {
    // Re-render only when the `name` prop changes.
    return this.props.name !== nextProps.name;
  }

  render() {
    console.count('Greetings --> render');
    return <p>Hello {this.props.name}!</p>;
  }
}

After the very first render, Greetings component is re-rendered only when the name prop changes.

To solve the same problem, React introduces a variant of React.Component called React.PureComponent which implicitly implements shouldComponentUpdate. The implicit implementation compares props and state by reference(shallow comparison). Let's write the pure version of Greetings.

class PureGreetings extends React.PureComponent {
  render() {
    console.count('Pure Greetings --> render');
    return <span>Hello {this.props.name}!</span>;
  }
}

Here's the pen with full code.

Controlled/Uncontrolled Components

Working with form elements is a tad tedious. It requires a lot of malarky to get data from the form elements. That's because form elements maintain their own state internally. Developers have to throw a few lines to JavaScript to get the job done. Form elements in React are no exception. The way developers deal with a form element determines whether that element is a Controlled or Uncontrolled Element/Component. If the value of a form element is controlled by React then it's called a "Controlled Component" otherwise "Uncontrolled Component".

Controlled Components don't change their state on user interaction. State changes happen only when the parent component decides eg. the SubscriptionForm component below doesn't honor user inputs (Codepen).

class SubscriptionForm extends React.Component {
  handleSubmit = event => {
    event.preventDefault();
  };
  render() {
    return (
      <form onSubmit={this.handleSubmit}>
        <input type="email" value="smelly@smellycode.com" />
        <input type="submit" value="Subscribe" />
      </form>
    );
  }
}

Why changes are not honored? That's because the value attribute for the email input is set to smelly@smellycode.com. When React runs the diffing algorithm on the render tree. It always gets the email input as smelly@smellycode.com so it ends up rendering the same value regardless of inputs entered by the user. Let's fix it by setting up an event listener which will update the state on change event(Codepen).

class SubscriptionForm extends React.Component {
  state = { email: '' };

  handleSubmit = event => {
    event.preventDefault();
    console.log('Values --> ', this.state);
  };

  handleChange = event => this.setState({ email: event.target.value });

  render() {
    return (
      <form onSubmit={this.handleSubmit}>
        <input
          type="email"
          value={this.state.email}
          onChange={this.handleChange}
        />
        <input type="submit" value="Subscribe" />
      </form>
    );
  }
}

Everything that goes into the input form elements is controlled by React here. That's why it is called "Controlled Component".

For "Uncontrolled Component", form data is not handled by React. DOM takes care of them. Here's an uncontrolled version of the SubscriptionForm.

class SubscriptionForm extends React.Component {
  inputRef = React.createRef();

  handleSubmit = event => {
    event.preventDefault();
    console.log('Value -->', this.inputRef.current.value);
  };

  render() {
    return (
      <form onSubmit={this.handleSubmit}>
        <input type="email" ref={this.inputRef} />
        <input type="submit" value="Subscribe" />
      </form>
    );
  }
}

For elaborative comparison please refer the article.

Higher Order Components

Suppose there's an application which has a few malformed components--components whose elements/children are invalid react elements. Rendering of these components breaks the user interface.

// A sample malformed component.
class MalformedComponent extends React.Component {
  render() {
    // {new Date()} is not a valid react element. Rendering it will throw an error.
    return <p>Now:{new Date()}</p>;
  }
}

We need to implement an error handling mechanism to avoid crashes. React provides error boundary apis to handle such errors. So we refactor MalformedComponent as:

class MalformedComponent extends React.Component {
  state = {
    error: null
  };

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { error };
  }

  render() {
    if (this.state.error) {
      return (
        <details>
          <summary>Ouch! Things are messed up. We are sorry. 👾</summary>
          <pre style={{ color: `red` }}>{this.state.error.stack}</pre>
        </details>
      );
    }
    return <WrappedComponent {...this.props} />;
  }
}

Adding error boundaries only fixes the MalformedComponent. We need to fix the other components too, means we need to add error boundaries to other components.

How do we do it? Hmm, One way is to add the error handling code in every malformed component the way we did above. But it will make our component a bit cumbersome to maintain and less DRY.

What if we write a function to fill in the error handling code? Well, we can write but we shouldn't because we'll be modifying the existing component which is not recommended and may lead to unexpected behavior.

What if we write a function which takes a malformed component and returns a new component which wraps the malformed component with error boundaries? Interesting! Only thing is, it will add a new wrapper component in our component tree, but we can live with it. Let's code it.

const withErrorBoundaries = WrappedComponent => props => {
  return class extends React.Component {
    state = {
      error: null
    };

    static getDerivedStateFromError(error) {
      // Update state so the next render will show the fallback UI.
      return { error };
    }

    render() {
      if (this.state.error) {
        // Fallback ui.
        return (
          <details>
            <summary>Ouch! Things are messed up. We are sorry. 👾</summary>
            <pre style={{ color: `red` }}>{this.state.error.stack}</pre>
          </details>
        );
      }
      return <WrappedComponent {...this.props} />;
    }
  };
};

withErrorBoundaries can be used with any malformed component.

const SafeComponent = withErrorBoundaries(MalformedComponent);

That's what precisely a higher order component is all about. It's a pattern which facilitates component logic reusability. You can think of a HOC as a function that takes a component and returns a new component. An in-depth explanation of HOCs is available here.

Dumb Components

Dumb components are also known as presentational or stateless components. They mostly contain HTML and styles. The purpose of dumb components is to render the DOM using props. Dumb Components don't load or mutate any data. Data required by dumb components are passed as input/props along with the actions. That's why dumb components don't have any state related to data. It makes them more reusable and manageable. Here is a very basic Greetings dumb component :

function Greetings(props) {
  return <h1>Hello {props.name}</h1>;
}

Smart/Container Components

Smart components are also known as Container Components. Smart Components know how to load and mutate data. Sometimes smart components mere act as a container and pass data to child components as props. Smart Components can also have state and logic to update the state. A simple Clock component with state and logic.

class Clock extends React.Component {
  state = { now: new Date() };

  intervalId = null;

  tick = () => this.setState({ now: new Date() });

  componentDidMount() {
    this.intervalId = setInterval(() => this.tick(), 1000);
  }

  componentWillUnmount() {
    clearInterval(this.intervalId);
  }

  render() {
    return <p>{this.state.now.toLocaleTimeString()}</p>;
  }
}

You can read more about Dumb Components and Smart components on Shade.codes.