London Adapt or Die: Securing your APIs the Right Way!

©2016 Apigee Corp. All Rights Reserved.
Securing APIs the Right Way
Nandan Sridhar

The views expressed in this presentation are those of
the presenter, and not necessarily those of Apigee
Corporation.
2

All security presentations begin with some
scary stories…
3

Snapchat
4
• No rate limit on request to get friends by phone
number
• Hard-coded encryption key
• Weak cipher
• http://gibsonsec.org/snapchat/

Nissan Leaf
5
• http://www.troyhunt.com/2016/02/controlling-vehicle-features-of-nissan.html
• No authentication on some APIs
– Climate control, battery status
– Only VIN number required
• User ID leaked by some of those APIs

Some API Security Breaches
6©2016 Apigee Corp. All rights reserved.
Breach Reason Source
Buffer Compromised third-party admin password; OAuth
secret in GitHub
ProgrammableWeb
Multiple Kardashian
Apps
No authentication or authorization Wired
MoonPig No authentication or authorization www.ifc0nfig.com
Facebook Graph API Users can delete other users’ photos; Improper
authorization check
ProgrammableWeb
IRS GetTranscript
Application
Password reset mechanism relied on personal data IRS
Tesla Model S Six-character password that’s easily guessable Security Affairs,
Elsewhere

…they don’t necessarily apply to you.
7

Enterprises & API Security
• Large enterprises start with API Security in one of two ways:
– They have an existing web architecture (web servers, cookie based, etc.). Build on
top of it; build something that works with existing security
– “Wikitecture”: They start with Wikipedia, look at the latest trends, specs in the
space. Most settle on OAuth.
8
Neither approach is entirely wrong!

Use Cases
Broadly speaking we can classify (for the purposes of security) APIs into two
categories:
• Internal APIs
– Application-to-application communication
– Traffic never leaves your data center
• External APIs
– Any internet facing API
9

Layers
Security will always require multiple layers, all working in
conjunction to provide sufficient security. We will focus on the
security that can be implemented in the API Management
Layer (the API Gateway)
10

Security is embedded into Apigee API Management
11
Back-end
RBAC management
IDM Integration
Global Policies
User Provisioning
AD / LDAP
Groups
Quota/Spike Arrest
SQL threat protection
JSON bomb protection
IP based restrictions
Bot Detection
Data
Privacy
Two way TLS
API key
OAuth2
Threat Protection
Identity Mgmt & Governance
Manageme
nt Server
Portal Analytics
API
MANAGEMENT
Data Privacy
Two-way TLS
Southbound VPN
IP Access Control
Logging & Auditing
Data Privacy
Org Boundaries
Encryption
SOC 2, PCI-DSS,
HIPAA
Access Control
OAuth2
API Key Verification
IP Access Control
Logging & Auditing
Apps

Let’s get basics right first
• Don’t underestimate the value of mutual TLS
• IP Whitelist/Blacklist
• Analytics & Logging
• Validate messages (at least in the test environments)
– JSON/XML Schemas
– Open API Specs
• Pass context around, use a standard
– JWT (RFC 7519)
– JWT can be signed (JWS) or encrypted (JWE)
– Great support for libraries (JavaScript,
Java, .Net etc.)
12

External APIs need more care
13

Don’t JWTs Fix Everything?
Signed tokens will not work for everyone:
• Tokens cannot be revoked before their expiration time without a central
store of revoked tokens. (However there may be a smaller number of
these)
• JWT based signed tokens are very large - sometimes larger than the
API payload
• Custom attributes must go in the token (making it larger)
• Sometimes people have many scopes
• What if some custom attributes are very sensitive and should not be
there at all, even if encrypted?
14

OAuth 2.0 – most popular; a good place to start
• Application Authorization is a fundamental part of API
security
– Best way to stop runaway applications
– Only options for certain types of apps (anonymous
API access)
– Requirement for all forms of OAuth
• Best practices
– Use different credentials for each version of each
app
– Makes it easier to pull a bad version
– Hide the app credentials as best you can
– Realize that they still can be stolen
– Have an approval process for apps
15

Prevent Excessive Traffic
• Protect APIs that are vulnerable to brute force
– Validating password
– Validating anything
– Anything where the only ID is in a small space
• Protect from runaway applications
– Denial of service is also an attack
– Excessive usage may mean data is being harvested
– Not always an attack – developers make mistakes
16
/api
Good Guys Backend Systems
Allow

Prevent Content Attacks
• Accepting JSON over the Internet?
– Excessive identifier length
– Excessive nesting
– Large arrays and elements
• Accepting XML over the Internet?
– All that and more
• Are you sure there can’t be SQL injection?
– Regular expression checks
17

Watch for trouble
• Monitor the API
– Usage patterns, anomalies
– Usage patterns by application
– Latency
– Error rate
• Monitor the world too
– Unusual tweets?
– Other social media?
18

Governance
©2016 Apigee Corp. All Rights Reserved. 19

Flow Hook Location Description
Pre-proxy Flow Hook BEFORE a proxy
endpoint executes
Pre-target Flow Hook BEFORE a target
endpoint executes
Post-target Flow Hook AFTER the target
response executes
Post-proxy Flow Hook AFTER the proxy
endpoint and right
before the response is
sent out to the client
Security is not voluntary!
20
With a flow hook, you attach a shared flow
so that it executes at the same place for all
API proxies deployed to a specific
environment

LIVE
DEMO

Multi-Dimensional Threat Protection

BOT Detection

/api
BOTs
Backend Systems
Block

API threats faced by customers today
• Threats are Adaptive – Blend with human behavior
• Bots can probe for API security weakness
• Competitors can scrape your price data
• Bots can be programmed for Bruteforce attacks (DDoS)
• Bots can abuse guest accounts
• Bot traffic skews analytics and KPIs
• Bots create performance overhead on Web Operations
• Bots can use your API keys to access private APIs
25

What is Apigee Sense?
• An adaptive API security product to
prevent sophisticated bot attacks
• Detects threat patterns at the API
layer, including bot attacks
• Enables you to take actions on bots
you find
26

Apigee Sense: Adaptive Threat Protection
• Deep Data Analysis
– Dashboard for learning/reporting
– Threat Alerts (Periodic summary
reports)
• Mitigation Actions
– Block, Tag, Limit, Divert
27

Closed Loop Protection – Analyze, Detect, Protect
29
API
clients
Target
Services
AP
I
Dashboard
Machine
Learning
Models and
Rules
Action
(Block/Throttle/Alert)
Blacklist
Your Traffic
System-wide
Purchased

LIVE
DEMO

Proof of Work

/api
Spammers Backend Systems
Proof of Work
§
Throttle

What is Proof of work?
• A Proof of Work algorithm is an algorithm that takes a lot of computational power to
generate, and provides a quick way to ensure that the work was actually done
• BitCoin (blockchain process) uses an algorithm called “HashCash”. The effort in
HashCash isn’t always constant effort
• Merkle Trees is An (Almost) Constant-Effort Solution-Verification Proof-of-Work
Protocol
• This makes it computationally expensive for unwanted traffic (such as bot attacks) to
hit the API while ensuring that there is minimal impact on legitimate API clients
33

LIVE
DEMO

Combine Proof of Work with Apigee Sense
35

Extend OAuth

Sometimes OAuth 2.0 isn’t good enough…
37

• Provides strong client authentication
• This specification enables OAuth 2.0
implementations to apply Token Binding
to Access Tokens and Refresh Tokens.
• This cryptographically binds these
tokens to the TLS connections over
which they are intended to be used
• This use of Token Binding protects these
tokens from man-in-the-middle and
token export and replay attacks
OAuth 2.0 Token Binding
38
Browser/
Client
Apigee
Edge
GET /api HTTP/1.1
Host: apigee.com
Sec-Token-Binding: {nonce}signed

LIVE
DEMO

• This specification defines how to declare
in a JSON Web Token (JWT) that the
presenter of the JWT possesses a
particular proof-of-possession key and
that the recipient can cryptographically
confirm proof-of-possession of the key
by the presenter.
• Being able to prove possession of a key
is also sometimes described as the
presenter being a holder-of-key
Proof of Key for JWT
40
Browser/
Client
Relying
Party
GET /? {id=bob&key=K2} HTTP/1.1
Host: rp.com
Sec-Token-Binding: {nonce}signed
302 Found
Location: rp.com?{id=bob&key=K2}
Identity
Provider
Browser/
Client
Relying
Party
GET /issue-token HTTP/1.1
Host: idp.com
Sec-Token-Binding: {nonce}signed K1 &
{nonce}signed K2
Identity
Provider
TLS

Icon Library
43

London Adapt or Die: Securing your APIs the Right Way!

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (16)

Semelhante a London Adapt or Die: Securing your APIs the Right Way!

Semelhante a London Adapt or Die: Securing your APIs the Right Way! (20)

Mais de Apigee | Google Cloud

Mais de Apigee | Google Cloud (7)

Último

Último (20)

London Adapt or Die: Securing your APIs the Right Way!