oAuth – Part 2

A practical example of oAuth integration into your system for authentication process.

Hello readers, today we will walk through a practical example about how to implement a simple login using the oAuth concepts described
in the previous post. To accomplish this goal we going to to create a new Erdiko project with three additional package that will help us to interact with Facebook API. Those packages are Erdiko-Authenticate and oauth2-client  and oauth2-facebook from The League of Extraordinary Packages. But before we can start coding we need to create a developer account and register our app.

How to register your app

This is the easy step; let’s demonstrate how to register using Facebook.
The first step is login in the developers site and sign in with a valid Facebook user. The next step is set you as Developer. To do this go to account, click on the button and follow instructions. Easy, right?
And the last step is to complete and submit this form. That’s it! Now you have registered your app to use Facebook API.

Prepare host project for the example

In this step we just need to create a new Erdiko project, for more details please refer to Erdiko

composer create erdiko/erdiko oauth_authenticate_sample

The next step is add the additional libraries.

In both cases, inside the project directory, will add new required packages

composer require erdiko/authenticate
composer require league/oauth2-client
composer require league/oauth2-facebook

setup erdiko-authenticate

Once it’s added we will need to add the config file in app/config/default/authenticate.json this is an example:

{
  "authentication": {
    "available_types": [{
      "name": "mock",
      "namespace": "erdiko_authenticate_Services",
      "classname": "Mock",
      "enabled": true
    }]
  },
  "storage": {
    "selected": "session",
    "storage_types": [{
      "name": "session",
      "namespace": "erdiko_authenticate_Services",
      "classname": "SessionStorage",
      "enabled": true
    }]
  }
}

we will revisit this file in future sections.

SETUP oAuth2 Client (from thephpleague)

This package doesn’t need a special configuration, but let’s take a look at constructor parameters we will user in our extension.

$provider = new \League\OAuth2\Client\Provider\GenericProvider([
    'clientId'                => 'demoapp',    
    'clientSecret'            => 'demopass',   
    'redirectUri'             => 'http://example.com/yourredirecturl/',
    'urlAuthorize'            => 'http://example.com/oauth2/authorize',
    'urlAccessToken'          => 'http://example.com/oauth2/token',
    'urlResourceOwnerDetails' => 'http://example.com/oauth2/resource'
]);

clientId and clientSecret, come from the dashboard of your registered app, in the picture below are App ID and App Secret.

redirectUri, is a public URL in your server where you will be redirected after oAuth server finish the authentication process (Facebook in our example)

The last three keys (urlAuthorize, urlAccessToken and urlResouceOwnerDetails) will change based on which service we are using. In the above block, we assume that the the oAuth server is placed in example.com, maybe our custom implementation.

Create new Service class

We will implements AuthenticationInterface that way we can inject it in our authenticate package thru autenticate.json config file we added previously.

In authentication section you will have to add a new entry in available_types array:

{
      "name": "oauth",
      "namespace": "app_services",
      "classname": "oAuthAuthenticator",
      "enabled": true
}

In the constructor method of this class we will create a provider instance for the client, but we will use the third package (oauth2-facebook) to simplify things:

namespace app\services;


use erdiko\authenticate\AuthenticationInterface;
use \League\OAuth2\Client\Provider\Facebook;

class oAuthAuthenticator  implements AuthenticationInterface
{
    protected $provider;

    public function __construct()
    {
        session_start();

        $this->provider = new Facebook([
            'clientId'          => '1925853064368417',
            'clientSecret'      => '55ea4c1a56ca6d1db485b954ZZZ',
            'redirectUri'       => 'https://example.com/login/setlogin',
            'graphApiVersion'   => 'v2.8',
        ]);
    }

    public function login($credentials)
    {
        if(!$this->checkLoggedUser()) {
           $authorizationUrl = $this->provider->getAuthorizationUrl();
           $_SESSION['oauth2state'] = $this->provider->getState();
           header('Location: ' . $authorizationUrl);
           return;
        }
    }

    protected function checkLoggedUser()
    {
       return (
            isset($_SESSION['code']) 
            && isset($_SESSION['oauth2state'])
       );
    }

    public function verify($credentials)
    {
       return true;
    }
}

 

As you can see in the login method, I’ve added a simplistic check for a logged user, if there’s no record in session will redirect to login popup. Now we’re delegating the authentication process to Facebook, and the result of this process will be finally handled by method getSetLogin in the login controller.

Use new service in a Login Controller

In this example we are using a Login Controller just to keep authentication logic isolated. This is a normal erdiko controller, where we will have three basic actions: getLogin – that will load a basic -authenticator and invoke the login method. This action will be loaded when you click on Login with Facebook buttons that you can find everywhere these days.

public function getLogin()
{
   $authenticator = new BasicAuthenticator(new User);
   
   $authenticator->login(array(),'oauth');
}

getSetLogin – a callback method – is responsible to manage Facebook response and storage user in SESSION.

public function getSetLogin()
{
    $authenticator = new BasicAuthenticator(new User());
    if (empty($_GET['state']) || ($_GET['state'] !== $_SESSION['oauth2state'])) {

        unset($_SESSION['oauth2state']);
        throw new \Exception('Invalid state.');
    }
    $token = $this->provider->getAccessToken('authorization_code', [
        'code' => $_GET['code']
    ]);
    try{
        $user = $this->provider->getResourceOwner($token);
        $authenticator->persistUser($user);
    } catch (\Exception $e) {
        throw new \Exception($e->getMessage());
    }
}

Finally, we have the getLogout action, that will destroy the SESSION and user won’t be longer authenticated.

public function getLogout()
{
   $authenticator = new BasicAuthenticator(new User());
   $authenticator->logout();
   \erdiko\core\helpers\FlashMessages::set("Good bye, ".$authenticator->currentUser()->getUsername(), "success");
   $this->getLogin();
}

Conclusion

It’s pretty easy to add oAuth features on your system as you can see. Delegating the authentication process to a trusted server, providing users with the ability to use existing trusted accounts is a clear win.

Hope you enjoy this small example! Thanks for reading and hope to see you in my next post!

Security in Web-apps: Overview

Introduction

This blog entry intends to bring an overview about security and an introduction of usual mistakes and some tips.

Overview

What does Web application security means?

There are several definitions for this questions, but we can shorten them like:

A process that aims to address and fulfill the four principles of security:

  • Confidentiality: States that the sensitive data stored in the Web application should not be exposed under any circumstances.
  • Integrity: States that the data contained in the Web application is consistent and is not modified by an unauthorized user.
  • Availability: States that the Web application should be accessible to the genuine user within a specified period of time depending on the request.
  • Nonrepudiation: States that the genuine user cannot deny modifying the data contained in the Web application and that the Web application can prove its identity to the genuine user.

How to start working on this

As I mentioned before, security is process not just a patch that we can apply at the end of the project. This process should be transversal to the project, starting on the design phase and following, develop, tests and enhancements.

There’s an international non-profit organization that focus on software security improvements, Open Web Application Security Project (OWASP) that has identified the top 10 vulnerabilities:

  • Injection flaws
    • Injection is an entire class of attacks that rely on injecting data into a web application in order to facilitate the execution or interpretation of malicious data in an unexpected manner.
  • Broken authentication and Session Management
    • This is a vulnerability associated with the complex process of User’s authentication. This can happens in all web servers, application servers, and web application environments.
  • Cross Site Scripting (XSS)
    • XSS occurs when an attacker is capable of injecting a script, often Javascript, into the output of a web application in such a way that it is executed in the client browser.
  • Insecure direct object references
    • Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
  • Security misconfiguration
    • This is a set of potential flaws can be caused by a wrong configuration of web server or application server. There are a wide variety of server configuration problems that can plague the security of a site.
  • Sensitive data exposure
    • This web security vulnerability is about crypto and resource protection. Sensitive data should be encrypted at all times, including in transit and at rest. No exceptions.
  • Missing function level access control
    • This is simply an authorization failure. It means that when a function is called on the server, proper authorization was not performed.
  • Cross site request forgery (CSRF)
    • This is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.
  • Using components with known vulnerabilities
    • This flaws usually happens when 3rd party pieces of code are included in a system even when there are some vulnerabilities reported by the developers or any community.
  • Unvalidated redirects and forwards
    • We will talk about each item in later posts.

Basic Tips

A common expression between experts is “Never blindly trust the user! they don’t care about the problems can be caused to the system after an invalid input”. To avoid accidental or malicious issues caused by input, always sanitize data that will be used by your system.

Is very important you validate not only the inbound data, but also the output one. There are some threads used by hackers that try to inject redirections in large inputs the can be executed by client on output.

Here’s a small snippet that can show how to validate inputs:

...
require_once(dirname(__FILE__).’/<path_to_classes>/PHPSanitizer.php’);
$sanitizer = PHPSanitizer::getInstance();
$sanitizer->setType(PHPSanitizer::PARANOID);
$sanitizer->validate($string); //return a boolean
$sanitizer->cleanup($string); //returns an string with all invalid characters removed
...

Implementation of PARANOID type:

require_once(dirname(__FILE__).'/AbstractSanitizer.php');
require_once(dirname(__FILE__).'/ISanitizer.php');


class SanitizerParanoid extends AbstractSanitizer implements ISanitizer{
   private $pattern = "/[^a-zA-Z0-9]/";
   private $replacement = "";


   public function validate($string){
       return (preg_match_all($this->pattern, $string)===0);
   }


   public function cleanup($string){
       return preg_replace($this->pattern, $this->replacement, $string);
   }
}

Full code can be forked on  PHPSanitizer

Use prepared SQL statement every time you can, this way RDBMS will compile the query and reject invalid type parameters.

Also take care about your server hardening.

  • Avoid list directories on your server
  • Remove banners of your server
  • Add authentications methods
  • Use SSL across all your sensitive URLs