Secure Web Services

Secure Web Services
Rob Daigneau http://ArcSage.com
Copyright © 2013 Rob Daigneau, All rights reserved

Overview
•About me
•Introduction
•The OWASP 2013 Top Ten List and Web Services

About Me
•Independent Consultant, Coach, and Trainer
Systems Integration
REST
Web Service and API Design
SOA
Distributed Systems Engineering
for Mobile Apps, the Cloud, and the API Economy
•Past Positions
•Director of Architecture, Monster.com
•Manager of Application Development, Fidelity.com
•Etc.
•Author of Service Design Patterns
•Microsoft MVP, Systems Integration

Introduction
•Open Web Application Security Project
Annual recommendations for secure web applications
It’s a game of leap frog
•Scope of Talk
Security is a HUGE subject
I’m more interested in Public APIs
Skipping Windows Authentication and Forms Authentication
ASP.NET Web API, not WCF
•Won’t be demonstrating exploits

Assessing Risk
•Complete security is impossible, nor always required
•Assess your risks and spend your limited time and $ appropriately
•OWASP Rankings
•10 = Lower risk, 1 = highest risk
•My Rankings for Web Services
•Risk potential for web services
High
Medium
Low, Indirect

Overview of “OWASP 2013” and Web Services
Impact of Unauthorized Service Invocation  Data modification, Fraud
OWASP recommendations don’t correspond perfectly to web services, but are largely relevant

Trade-offs
Security
Convenience, Productivity

#10 Unvalidated Redirects and Forwards

Unvalidated Redirects and Forwards
•What
Redirections and forwards to untrusted sites, aka Open Redirect
•Risk
Potential to (indirectly) send users to phishing or malware sites or to “resources” they are authorized to use
•Relevance to Web Services
Unintentional forwarding of malicious links
Web Service driven redirects are less common

Unvalidated Redirects and Forwards
•Examples
A web api for a social media site may allow users to post links that point to a “bad” site
The service could return links to resources a client is unauthorized to use
•Counter Measures
APIs SHOULD validate all links received or returned for “safety”
White and black lists
APIs SHOULD check user’s privileges before returning links

#9 Using Known Vulnerable Components

Using Known Vulnerable Components
•What
Hackers are able to exploit known flaws in libraries or frameworks, which often run at “Full Trust”
•Risk
Exposure of “server side” data (e.g. configuration files, other files)
Deployment of “root kits” and “server take-over”
Indirect

Using Known Vulnerable Components
•Counter Measures
ALWAYS Use Windows Update
ALWAYS Use NuGet to keep your packages up to date
CONSIDER SafeNuget
https://www.nuget.org/packages/SafeNuGet/
DO YOUR BEST to stay educated
Microsoft Security Tech Bulletins
–https://technet.microsoft.com/en-us/security/bulletin/

#8 Cross Site Request Forgery

Cross Site Request Forgery (CSRF)
•What
•Risk
Unauthorized service invocation
High, when a web application provides authentication for web services
Client
Web App
Malicious Site
1. Logon
2. Cookie Token
3. Visit Bad Site, Pass token
4. Issue forged request

Cross Site Request Forgery (CSRF)
•Examples
DELETE http://acme.com/Orders
•Counter Measures
ALWAYS Use Anti-Forgery Tokens
Best = in hidden form fields
2nd best = in request header
–Appropriate for web services
Avoid passing tokens in the URI
ALWAYS use SSL (TLS) so tokens can’t be read by sniffers
REMEMBER OData and most APIs are quite predictable and easy to hack …
Consider using URIs that are unpredictable and “time-bombed”
–Side-effect: Helps to prevent “Replay Attacks”
CONSIDER (Re-)Authenticating on each request
CONSIDER authenticating web service access separately from web app access

#7 Missing Functional Level Access Control

Missing Functional Level Access Control
•What
Not checking user credentials and privileges before allowing invocation of web service
Web service(s) may (naively) assume that authorization checks were performed by web app or (JavaScript) client
•Risk
High

Missing Functional Level Access Control
•Counter Measures
ALWAYS Implement authorization checks on every web service operation
Check should be performed regardless of similar checks done by web apps or (JavaScript) clients
… more on Authorization a little later

#6 Sensitive Data Exposure

Sensitive Data Exposure
•What
Many web services do not properly protect sensitive data
e.g. Credit card info, Tax IDs, User credentials, etc.
•Risk
High

Sensitive Data Exposure
•Counter Measures
ALWAYS Use Transport Layer Security (TLS, SSL) when sending or receiving sensitive data (including session tokens)
ALWAYS Implement “Functional Level Access Controls” at the web service
CONSIDER encrypting especially sensitive data (in transit), e.g. …
User credentials …
–SHA hash
Credit card data and Personally Identifiable Information (PII) …
–Asymmetric encryption
NEVER store sensitive data if you don’t have to (e.g. credit card data)
WATCH OUT for accidental transfer of sensitive data buried in “deep object hierarchies”
NEVER convey Exception details in any HTTP Response
Beware of HTTP 500 status

#5 Security Misconfiguration

Security Misconfiguration
•What
Leaving default accounts active and “back-doors” open (e.g. admin services)
•Risk
Indirect

Security Misconfiguration
•Counter Measures
ALWAYS Disable/inactivate default accounts, change passwords
ALWAYS Make sure your SSL certificates haven’t expired
NEVER use custom certificates (makecert tool) in production
CONSIDER creating fine-grained database roles for access to different tables, views, and stored procedures
CONSIDER locking down configuration files and removing unused portions.
CONSIDER Encryption of sensitive portions of configuration file
ALWAYS Disable unnecessary services and features across the platform stack
CAREFUL with Windows Update
ALWAYS Use NuGet to keep your packages up to date

#4 Insecure Direct Object References

Insecure Direct Object Reference
•What
An authenticated user changes the value of a URI segment, query string parameter, or request body content in order to gain unauthorized access
•Risk
High

Insecure Direct Object Reference
•Counter Measures
ALWAYS Authenticate and Authorize user on each access
Easy to validate user’s access to general logical areas
More difficult to authorize access to individual entities/records
NEVER expose auto-generated (integer) IDs in the URI or request body when creating Public/Internet APIs
Consider using surrogate keys
REMEMBER that predictable URIs (e.g. OData) are easy to hack, … consider using random “time-bombed” URIs and Surrogate Keys (i.e. Reference Maps)
Side effect  Helps prevent “Replay Attacks”
ALWAYS be on the look-out for accidental transfer of sensitive data buried in “deep object hierarchies”

#3 Cross Site Scripting (XSS)

Cross Site Scripting (XSS)
•What
Service receives and stores untrusted data (i.e. executable scripts)
Scripts are later received by web apps, including mobile web apps and executed by browser
•Risk
Potential to hijack user’s session  unauthorized service invocation
Potential to send users to maliscious sites
Indirect
A very common attack against web applications

Cross Site Scripting (XSS)
•Counter Measures
CONSIDER if service should accept scripts from clients and return scripts to clients?
ALWAYS validate input received by web service
URIs, query string parameters, request body, cookies
–E.g. Regex for URIs, RFC 3986
REMEMBER that web applications SHOULD use HTML output encoding to ensure scripts are properly “escaped” preventing execution in the browse

#2 Broken Authentication & Session Management

Broken Authentication & Session Management
•What
Authentication or Session information is leaked
Client credentials, Session IDs
A common concern with custom authentication or session management schemes
•Risk
Compromised passwords, keys, or session tokens
Provides ability for attacker to impersonate valid users
High – information leakage
Indirect – credential management, logout logic, account management

Broken Authentication & Session Management
•Counter Measures
ALWAYS use SSL when using Basic or Forms Authentication
Credentials are passed in clear text, Base-64 encoded
ALWAYS keep sessions “short-lived”, enforce time-outs
NEVER pass tokens in URI, they can be easily stolen (if not using SSL)
Instead, pass in HTTP request headers or body

The ASP.NET Web API and Authentication
•IIS Authentication
Basic, Digest, Windows
•Forms Authentication
User credentials are acquired through a custom login form
Once user authenticated, server issues a “ticket” (i.e. token/cookie) that’s passed in subsequent requests
Relevant only to Web APIs that are called from a web application in same logical domain

The ASP.NET Web API and Authentication
•Custom Authentication
Good for public, Internet APIs
May leverage Basic or Digest Authentication, or even Client Certificates
Service may check for user credentials or client certificates in Message Handlers

HTTP Modules
ASP.NET Message Flow
Message Handlers
Authorization Filters
Action Filters
Exception Filters
Controller Action
Message Handler Scopes : Global, Route Authorization Filter Scope : Controller Action Filter Scope : Controller Action

The ASP.NET Web API and OAuth
•Enables a third-party to obtain limited access to a service
3rd party clients obtain “access token” which define scope of resource access, lifetime, etc.
RFC 6749, http://oauth.net/
Third Party Client
Resource Owner
Authorization Server
Resource Server (i.e. the web service)
1. Auth Request
2. Auth Grant
3. Auth Grant
4. Access Token
5. Access Token
6. Protected Resource

#1 Injection

Injection
•What
Occurs when commands or queries are passed through query strings or request body
•Risk
Service executes the command or query causing…
Sensitive data to be revealed
Data corruption
Denial of Service
Medium

Injection
•Counter Measures
CONSIDER validating data input for input that looks like a command
URI segment values, query strings, request body, request headers
ALWAYS use named parameters in ADO.NET queries
Strong data typing helps
CONSIDER using Entity Framework and LINQ
Provides similar protections as parameterized queries
CONSIDER constraining access with different logons for different roles
E.g. Setting privileges on Data Services

Thank you
Rob Daigneau http://ArcSage.com http://ServiceDesignPatterns.com info@ArcSage.com
Harness the power of modern computing platforms

APPENDIX

Principles
•Defense in Depth
https://www.owasp.org/index.php/Defense_in_depth
•Principle of Least Privilege
http://en.wikipedia.org/wiki/Principle_of_least_privilege
•Request Logging
This data can give you info to piece together an attack

IIS Authentication
•http://msdn.microsoft.com/en-us/library/aa292114(v=vs.71).aspx
•Basic and Digest HTTP Authentication
http://www.ietf.org/rfc/rfc2617.txt
Basic : Browser prompts for user name and password, these are transferred in Base64 which is trivial to decode and therefore insecure. TLS should be used with this scheme
Digest : User credentials are concatenated with data known only to client and server. This "digest" (hash) is sent to the server. The server applies same technique and checks to see if results are same. The digest can be stolen and used by an attacker, so TLS is advised.
•Windows Authentication
Leverages Kerberos or NTLM Authentication and symmetric key cryptography (public/private key) when transferring user credentials. Requires an Authentication Server (i.e. An Active Directory Server). Appropriate for Intranet scenarios. Doesn't work through firewalls unless client uses a VPN to connect
Can use the Windows Authentication Provider
http://msdn.microsoft.com/en-us/library/907hb5w9(v=vs.100).aspx

ASP.NET Terminology
•Principal : The security context under which the code is running; accessed via Thread.CurrentPrincipal
•Identity : Contained in the principal; has information about the client

Encryption Terminology
•Encryption : Conversion of text by a cipher (i.e. algorithm) that can only be decoded with the proper key
•Symmetric Encryption : Uses same key and algorithm to encrypt and decrypt data. This is why it’s called 2- way encryption. It’s generally ok to use when data transport occurs only in a logical domain, the encypter and decrypters are under your control, and you don't need to know who encrypted the content. Commonly uses AES
•Asymmetric Encryption : Uses different keys to encrypt and decrypt data. Encryption key is public and may be widely distributed. Decryption key is kept private. Example = TLS. Common for public web services
•TLS : Transport Layer Security. Supersedes SSL. Provides encryption over a channel, thus ensuring data confidentiality. Also ensures identity of the server through certifications (i.e. X509)
•Hash : A type of encryption in which a digest (i.e. hashing algorithm) is applied to text. The resulting fixed- length string cannot be converted back to the original value. A server can validate a hash by comparing it to a hashed value that was created with the same algorithm and salt. Hashed values may be intercepted, so should use in conjunction with TLS
•Salt : A value used by a hashing algorithm to determine the resulting hashed value for a variable input value
•MD5, SHA : Hashing algorithms; MD5 is weak since two different inputs can produce the same hash
•DES : Data Encryption Standard. A symmetric key algorithm considered insecure
•AES : Advanced Encryption Standard, Successor to DES

Secure Web Services

More Related Content

What's hot

Viewers also liked

Similar to Secure Web Services

Secure Web Services