mobile inception - web api security

W E B A P I S E C U R I T Y

M I C M O N S - D E V F M # 1 3 F E B R U A R Y 2 , 2 0 1 5

S T E V E D E G O S S E R I EM O B I L E I N C E P T I O N

M O B I L E I N C E P T I O N

Founded in May 2013 Based near LLN

“Enabling the mobile enterprise”

#Mobile #Cloud #UX #Analytics #Security

Growing number of clients in Belgium

Stéphane Delcroix, Open Source Veteran

Former Tech Expert at McKinsey Solutions

Xamarin Technology & Mobile UX Expert

Steve Degosserie, MBA

Former Tech Expert at McKinsey Solutions

Cloud & Mobile Enterprise Architecture Expert

Who are we ?


– G A R T N E R ( A N D P R E T T Y M U C H E V E R Y O N E E L S E )

“Every company is a software company.”

– A N D R E E S S E N H O R O W I T Z , V C F I R M“Mobile is eating the world.”

B R U C E S C H N E I E R , S E C U R I T Y E X P E R T, C R Y P T O G R A P H E R

On the HeartBleed SSL vulnerability "Catastrophic" is the right word. On

the scale of 1 to 10, this is an 11. Half a million sites are vulnerable.

2014 - “Year of the Breach”

K E V I N M I T N I C K , S E C U R I T Y E X P E R T, “ W O R L D ’ S M O S T

FA M O U S H A C K E R "

“Sony was likely hacked because they don't follow best practices, even after being hacked several

times before. Lessons not learned.”

W E B A P I S E C U R I T Y - W H Y ?

• Growing number of APIs exposed on public & private networks. APIs are the entry door to a company’s data.

• Attacks & vulnerabilities are becoming worse & more frequent, and even … sponsored by governments.

• As software developers, API producers or consumers, we have the duty to ensure relevant security measures are in use to protect our clients interests.

W E B A P I S E C U R I T Y - G O A L S

• This session serves as a “gentle” introduction to basic security concepts and how they apply to REST APIs.

• Armed with foundational knowledge of security concepts & protocols, developers should be able to better assess the security level of an API.

• Software security like software is an ever-evolving field of study, and as such, requires continuous learning.

> Security 101

HTTP Basic / Digest

TLS & Mutual Auth

Identity Delegation

OAuth 2.0

OpenID Connect 1.0

A G E N D AM I C M O N S - D E V F M # 1 3 - W E B A P I S E C U R I T Y

S E C U R I T Y 1 0 1

M I C M O N S - D E V F M # 1 3 - W E B A P I S E C U R I T Y


S E C U R I T Y 1 0 1 - C I A

C Confidentiality

I Integrity

A Availability

S E C U R I T Y 1 0 1 - C I AM I C M O N S - D E V F M # 1 3 - W E B A P I S E C U R I T Y


S E C U R I T Y 1 0 1 - S E C U R I T Y C O N T R O L S

> Authentication

Authorization

Non-repudiation

Auditing

S E C U R I T Y 1 0 1 - S E C U R I T Y C O N T R O L SM I C M O N S - D E V F M # 1 3 - W E B A P I S E C U R I T Y

S E C U R I T Y 1 0 1 - S E C U R I T Y C O N T R O L S > A U T H E N T I C AT I O N

Something You Know

Something You Have

Something You Are


Authentication

> Authorization

Non-repudiation

Auditing


S E C U R I T Y 1 0 1 - S E C U R I T Y C O N T R O L S > A U T H O R I Z AT I O N

Discretionary Access Control (DAC)

Mandatory Access Control (MAC)

Role-Based Access Control (RBAC)


Authentication

Authorization

> Non-repudiation

Auditing


Authentication

Authorization

Non-repudiation

> Auditing


Security 101

> HTTP Basic / Digest

TLS & Mutual Auth

Identity Delegation

OAuth 2.0

OpenID Connect 1.0


H T T P B A S I C / D I G E S T


H T T P B A S I C / D I G E S TM I C M O N S - D E V F M # 1 3 - W E B A P I S E C U R I T Y

“The HTTP protocol supports authentication as a means of negotiating access to a secure resource.”

1. Client sens an initial anonymous request to a protected resource

2. Server responds with a “challenge” (401 Not Authorized + WWW-Authenticate header, authentication scheme & realm)

3. Client sends credentials in the Authorization header

4. Server allows or forbids access to the requested resource based on the info in the Authorization header

H T T P B A S I C / D I G E S T > H T T P B A S I C A U T H E N T I C AT I O N


H T T P B A S I C / D I G E S T > H T T P B A S I C A U T H E N T I C AT I O N


Advantages

• Internet standard, supported by all major browsers / web client libraries

• Simple to use / implement

• Passwords can be stored in salted hash form in backend

Disadvantages

• Credentials are sent as plaintext (Base64) in the request, every time

• Only authenticates, doesn’t guarantee confidentiality / integrity

• Must be used on a secure communication channel

H T T P B A S I C / D I G E S T > H T T P D I G E S T A U T H E N T I C AT I O N


Advantages

• Internet standard, supported by all major browsers / web client libraries

• Credentials are never sent as plaintext, only a digest derived from the password

• Does not require a secure communication channel

Disadvantages

• Requires 2 roundtrips / call making it slower than other auth methods

• Potentially vulnerable to man-in-the-middle attacks

• Passwords cannot be stored in salted hash form in backend (only MD5)

Security 101

HTTP Basic / Digest

> TLS & Mutual Auth

Identity Delegation

OAuth 2.0

OpenID Connect 1.0


T L S & M U T U A L A U T H


T L S & M U T U A L A U T H > E N C R Y P T I O N R E F R E S H


Encryption

• Symmetric : Relatively fast. Same key for encryption & decryption. Key = secret shared by several parties. Typically used for encryption of data.

• Asymmetric : Relatively slow (1000x than symmetric). 2 keys encryption, a public and private keys, mathematically related.

• Encrypt with private key (digital signature) : Encrypt a fixed-length hash == digital signature. Allows for trust & integrity checks.

• Encrypt with public key (public-key encryption) : Confidentiality of message exchanged. Typically used to agree on a symmetric key to be used later to encrypt data. Allows for Confidentiality.

• Hashing : “Irreversible” encryption, produces a fixed-length output from a variable-length input. Used for authenticity check, password storage.

T L S & M U T U A L A U T H > P K I P R I M E R


PKI is a set of hardware, software, people, policies and procedures to create, manager, distribute, use, store and revoke digital certificates.

• Certificate Authorities : trusted independent third-parties that have the authority to issue, validate, revoke digital certificates. Can be public / private (local), different levels of hierarchy (Root, intermediate).

• Digital Certificates : Issued by a Certificate Authority (Issuer) and binds an owner’s identity (Subject) to a set of public/private key pair, as well as a specific purpose (usage), valid for a certain period. Used to establish trust between parties, to validate the identities.

• Trust Chains : “indirect trust” … indirectly trusts a party based on its digital certificate issued by a party that we trust (e.g. a certificate authority).

T L S & M U T U A L A U T H > S S L , T L S & H T T P S D E M Y S T I F I E D


TLS is an evolution of the SSL protocol developed by Netscape: SSL 1.0/2.0 & 3.0 were released in 1995 & 1996. 2014, SSL 3.0 was found to be vulnerable to the POODLE attack which renders it insecure.

TLS is a more modern & safer protocol than SSL (1.0 released in 1999, 1.1 in 2006, 1.2 in 2008, 1.3 TBD).

HTTPS is not a protocol, simply HTTP on top of SSL/TLS.

T L S & M U T U A L A U T H > T R A N S P O R T L AY E R S E C U R I T Y


“Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communication security over a computer network. They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating,[2] and to exchange a symmetric key. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality, and message authentication codes for message integrity and as a by-product, message authentication.”

T L S & M U T U A L A U T H > T R A N S P O R T L AY E R S E C U R I T Y


Note: Default validation of server certificate in .Net verifies chain to a trusted root CA. No online check is performed to see whether the certificate has been revoked.

Server certificate validation can be customised using the ServicePointManager class (Do not bypass validation !!!)

T L S & M U T U A L A U T H > M U T U A L A U T H E N T I C AT I O N


“Mutual SSL provides the same things as SSL, with the addition of authentication and non-repudiation of the client authentication, using digital signatures. When mutual authentication is used the server would request the client to provide a certificate in addition to the server certificate issued to the client. Mutual authentication requires an extra round trip time for client certificate exchange. In addition the client must buy and maintain a digital certificate. Due to these issues with complexity, cost, logistics, and effectiveness, most web applications are designed so they do not require client-side certificates.”

T L S & M U T U A L A U T H > C E R T I F I C AT E P I N N I N G


Problem with TLS : validation of server certificate checks that the certificate matches the hostname, and can linked back to a trusted (root) certificate. It does not check if it’s your own certificate, or a specific one e.g. that you agreed on with a third-party. Also, if a CA is compromised, fraudulent certificates could be emitted that would be automatically trusted (it happened).

Solution : Enforce additional constraints during the server certificate validation to offer extra protection against MITM attacks, fraudulent certificates or social engineering (“Free wifi ! Just add this root cert to your device !”)

Security 101

HTTP Basic / Digest

TLS & Mutual Auth

> Identity Delegation

OAuth 2.0

OpenID Connect 1.0


I D E N T I T Y D E L E G AT I O NM I C M O N S - D E V F M # 1 3 - W E B A P I S E C U R I T Y

“Classical” client-server authentication model

S E R V E R

C L I E N T A P P A U T H E N T I C AT I O N / A U T H O R I Z AT I O N

W E B S E R V I C E S

C O N T E N T

D BU S E R

authenticates & requests access

authenticates & requests access

“Classical” Web / Web Services architecture

1. User authenticates, via the Client app, directly with the Web app / Web services, typically initialising an authenticated session on the server.

2. User requests, via the Client app, access to resources from the Web app / Web services within the context of the authenticated session.


Problems with the “Classical” approach:

• Server has to store the user’s credentials

• Server must support password authentication (sthg you know -> weak)

• User doesn’t control what the client app has access to, and cannot limit the access in duration

• User cannot easily revoke access to its resources by the client app (must change password)

• If client app is compromised, the user’s credentials & resources are easily compromised



“Modern” Delegated Identity & API access

S E R V E R

C L I E N T A P PA P I

C O N T E N T

D B

U S E RI D E N T I T Y P R O V I D E RA U T H E N T I C AT I O N /

A U T H O R I Z AT I O N

authenticates

trusts

trustsrequests access w/ token

token

requests access w/ token


A trust relationship is established out of band between the Identity Provider, a “Delegate” (Client app) and a “Service Provider” (API).

A “Delegator” (User) owns the resource residing on the server, hence is also know as the “Resource Owner”. The Delegator delegates permissions to the Delegate to access the service offered by the “Service Provider” (aka the “Resource Server”).



1. The Resource Owner authenticates with the Identity Provider and receives an Access Token.

2. The Resource Owner transmis the Access Token to the Client App, effectively granting it to access the Resource on her behalf. The Client App verifies the Access Token authenticity by checking it was issued a trusted Identity Provider.



3. The Client App requests the Resource Server to access the Resource on behalf of the Resource Owner using the Access Token.

4. The Resource Server verifies the Access Token authenticity by checking it was issued a trusted Identity Provider, and grants access to the requested Resource.


How does the “Modern” approach solves the problems of “Classical” approach:

• Separation of the roles of the Client and Resource Owner.

• Client is using a different set of credentials (= Access Token) than the Resource Owner’s.

• Resource Owner does not communicate her credentials to the Resource server.

• The Access Token has restricted usage in terms of scope and lifetime.

• Resource Owner explicitly approves the emission of an Access Token to the Client.


Security 101

HTTP Basic / Digest

TLS & Mutual Auth

Identity Delegation

> OAuth 2.0

OpenID Connect 1.0


“An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.”


O A U T H 2 . 0

“The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.”

OAuth 2.0 defines:

• Roles

• Protocol Flow

• Grant Types

• Token Types

• Client Types

• Extensibility

O A U T H 2 . 0M I C M O N S - D E V F M # 1 3 - W E B A P I S E C U R I T Y

OAuth 2.0 defines four roles:

• Resource owner

• Resource server

• Client

• Authorization server

O A U T H 2 . 0 > R O L E S


O A U T H 2 . 0 > P R O T O C O L F L O W


OAuth 2.0 defines four grant types:

• Authorization Code

• Implicit

• Resource Owner Password Credentials

• Client Credentials

O A U T H 2 . 0 > G R A N T T Y P E S


OAuth 2.0 defines two token types:

• Access Token

• Refresh Token

O A U T H 2 . 0 > T O K E N T Y P E S


OAuth 2.0 defines two client types:

• Confidential client

• Public client

OAuth 2.0 derives three client profiles from the two client types:

• Web applications (server-side) : confidential

• User-agent-based applications (client-side) : public

• Native applications : public

O A U T H 2 . 0 > C L I E N T T Y P E S


OAuth 2.0 defines an extensibility point on token types:

• Bearer tokens : A bearer token is like “cash”, anyone who owns it can pay with it. No need to prove your identity. Mandates the use of TLS.

• MAC tokens (draft RFC): A MAC token is like a credit card. You have to prove your identity to authorize the payment.

O A U T H 2 . 0 > E X T E N S I B I L I T Y


OAuth 2.0 defines an extensibility point on grant types:

• Token Introspection Profile

• Chained API invocation

• Dynamic Client registration

• Token revocation

O A U T H 2 . 0 > E X T E N S I B I L I T Y


Notes

• OAuth 2.0 is an authorisation protocol and offers standard ways to provide delegated access to protected resources.

• OAuth 2.0 is not an authentication protocol, it doesn’t bring any answer as to what is the Resource Owner’s identity.

• OAuth 2.0 does not define the interactions between the resource server and the authorization server (e.g. token validation, introspection).

• OAuth 2.0 does not mandate the user of any specific token type. Bearer tokens are the most typical ones though.

O A U T H 2 . 0M I C M O N S - D E V F M # 1 3 - W E B A P I S E C U R I T Y

Security 101

HTTP Basic / Digest

TLS & Mutual Auth

Identity Delegation

OAuth 2.0

> OpenID Connect 1.0


“OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol.”


O P E N I D C O N N E C T 1 . 0

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol:

• Identity Token

• Authentication Flow

• Standard Flows

• Standard Scopes

• Standard Endpoints

• Discovery & Dynamic Client Registration

O P E N I D C O N N E C T 1 . 0M I C M O N S - D E V F M # 1 3 - W E B A P I S E C U R I T Y

The Identity Token (ID Token) is a JSON Web Token (JWT) containing authenticated user information (claims) from the authorization server to the client application. The structure of the ID Token is defined in the Open ID Connect specification:

• Header

• Body - Claimset

• Signature

O P E N I D C O N N E C T 1 . 0 > I D E N T I T Y T O K E N


O P E N I D C O N N E C T 1 . 0 > A U T H E N T I C AT I O N F L O W


In a nutshell, the OpenID Connect 1.0 authentication flow defines the interaction between a Relying Party (RP) requiring End-User Authentication and Claims from an OpenID Provider (OP).

Terminology mapping between Open ID Connect & OAuth 2.0:

Open ID Connect Relying Party == OAuth 2.0 Client app

Open ID Connect Provider == OAuth 2.0 Authorisation server

O P E N I D C O N N E C T 1 . 0 > A U T H E N T I C AT I O N F L O W


OpenID Connect defines standard flows:

• Implicit Flow (client-side)

• Authorization Code Flow (server-side)

• Hybrid Flow

O P E N I D C O N N E C T 1 . 0 > S TA N D A R D F L O W S


OpenID Connect defines standard scopes & associated claims:

• profile : name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at

• email : email, email_verified

• address : address

• phone : phone_number, phone_number_verified

• offline_access : requests a refresh token

O P E N I D C O N N E C T 1 . 0 > S TA N D A R D S C O P E S


OpenID Connect defines standard endpoints:

• Authorize endpoint

• Token endpoint

• Introspection endpoint

• UserInfo endpoint

O P E N I D C O N N E C T 1 . 0 > S TA N D A R D E N D P O I N T S


While most client applications / APIs will use a “pre-registration” mechanism (with the Open ID Provider) to obtain a client key / client secret pair, OpenID Connect defines standard API endpoints that allow a Discovery mechanism of an Open ID Provider’s metadata, and Dynamic Registration of Client applications to it.

O P E N I D C O N N E C T 1 . 0 > D I S C O V E R Y & D Y N A M I C C L I E N T R E G I S T R AT I O N S


(for those still awake and following …)

While the Open ID Connect protocol is concerned with Authentication, it is possible to envisage using the ID Token as an Access Token, and therefore performs authentication and authorization decisions in the Resource Server based on a single ID token.

Other option is to include a different set of claims into a JWT Access Token than those included in the ID Token to separately perform identity & access control decisions.

O P E N I D C O N N E C T 1 . 0 > I D T O K E N A S A C C E S S T O K E N ?


Q & A


C R E AT I V E C O M M O N S P I C T U R E S

• Enough already! - Es reicht! by Daniela Hartmann, on Flickr : https://flic.kr/p/bth8sR |

Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0)

• The Inception bridge by Miroslav Petrasko, on Flickr : https://flic.kr/p/i7GhtL | Attribution-

NonCommercial-NoDerivs 2.0 Generic (CC BY-NC-ND 2.0)

• Server room with grass! by Tom Raftery, on Flickr : https://flic.kr/p/8gPdHt | Attribution-

NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0)

• XKCD http://xkcd.com/1354/ | Creative Commons Attribution-NonCommercial 2.5 License

• Gate Detail by floodllama, on Flickr : https://flic.kr/p/duUz65 | Attribution 2.0 Generic (CC

BY 2.0)

https://flic.kr/p/bth8sR

https://flic.kr/p/i7GhtL

https://flic.kr/p/8gPdHt

http://xkcd.com/1354/

https://flic.kr/p/duUz65

mobile inception - web api security

Technology

r t n e r

b r u c e s c h n e

s e c u r i t y e x

e i n c e p t i o nfounded

u c h e v e r y o n

e i n c e p t i o n

p i s e c u r i t ym

s e c u r i t y c o