architectural design patterns for sso (single sign on) for sso
TRANSCRIPT
Architectural Design Patterns for SSO (Single Sign On)for SSO (Single Sign On) Design and Use Cases for Fi i l W b A li tiFinancial Web Applications
Wei Zhang & Marco MoranaOWASP Cincinnati, U.S.A.
OWASP
Copyright © The OWASP Foundation
OWASP
Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
Th OWASP F d tiThe OWASP Foundationhttp://www.owasp.org
Presentation outlinePresentation outline
The needs/challenges for securing SSO architectures inThe needs/challenges for securing SSO architectures in financial web applications Secure SSO design patternsSecure SSO design patterns Security consideration and risk for SSO designSecure architecture principlesSecure architecture principlesArchitectural diagramsData flow diagramsData flow diagramsSequence diagramsTh t d l f SSO hit tThreat models of SSO architecturesAttack trees and misuse cases
k f k f d fSecurity risk framework for secure design of SSO architectures
OWASP 2
Single Sign On (SSO) needs for financial web systems
Different systems serving different functionsDifferent systems serving different functionsATM cash withdrawBranch deposit Monthly statementsMonthly statementsMake a payment with a checkWire transfer
Different systems have different type of user’s informationPersonal and sensitive informationFinancial transactionsBank statements
Different business features are available for each systemSaving/checking accountsCredit card accountsCredit card accountsMortgage applications or loansCash rewards
l dOWASP 3
Mileage rewards
Requirements for SSORequirements for SSO
User friendly is the keyUser friendly is the keySingle view is the goalEliminate additional sign on is the approachSecurity is the foundationSecurity is the foundation
OWASP 4
SSO Use CaseSSO Use Case
User can sign on site A to do function B aboutUser can sign on site A to do function B about product CUser can sign on site X to do function Y about product Z.product Z.For users with both product C and Z, user should be able to sign on from Site A to accessshould be able to sign on from Site A to access function B and function Y without additional authentication.Site X will not be sunset to support users withSite X will not be sunset to support users with only product Z.
OWASP 5
Design options for SSODesign options for SSO
Duplicate function Y on site A and access information on site XDuplicate function Y on site A and access information on site XPros:
Make it possible to sunset site XCCons:
Introduce duplicated function on two sitesNeeds to maintain the function and processing rules on two sites.
Build SSO for user to access function Y on site XPros:
No need to maintain two sets of function and processing rules on two sitesNo need to maintain two sets of function and processing rules on two sitesEnable the possibility to fully leverage functions on site X
Cons:Make site A depends on site XIntroduce security complexity:
– Authentication– Authorization– Session coordination– UI
OWASP 6
SSO Design PatternsSSO Design Patterns
Ad hoc Encrypted Token:Ad-hoc Encrypted Token:Use symmetric and public key cryptography to y p y yp g p yencrypt the application data that used for SSO
St d d S T k S iStandard Secure Token Service (STS):(STS):
Central Security Token Service to respond ith t d d SAML t k th t twith standard SAML token that supports
federation across different sites upon request.
OWASP
SSO – Ad-Hoc Encrypted TokenSSO Ad Hoc Encrypted Token
Pros:Easy to set up and
Cons:Not a unified solutionEasy to set up and
implementS t PKI d
Not a unified solutionEach federated site has to manageSupports PKI and
SAMLhas to manage cryptographic key
No dependency on other system.
OWASP 8
SSO – Ad-hoc encrypted tokenSSO Ad hoc encrypted token
SSO ith
InternetSSO withencrypted token
Customer
`
Decrypt token and authenticate
Site ASite X
ure
toke
nSS
O
Sign
on
Application
Site AApplication
ServerS
ecfo
r SS
Server
Key storeKey store
credential store
User information
ey sto e
OWASP 9
SSO – STSSSO STS
CPros:Drives to unified
Cons:Introduces dependences
solution for both internal and external
on STS for federated sites
communication.Centralized
Introduces additional internet hop for
cryptographic key management approach.
pcommunication
g ppSupports SAML and SOAP
OWASP 10
SSO – STSSSO STS
SSO ith
InternetSSO withSAML token
Customer
`
Site ASite X
ML
toke
nSS
OSig
n on
Application
Site AApplication
ServerSA
Mfo
r SSTS
Varify SAML token/authenticate
Server STSSAML token
Key storeKey store
credential store
User information
Key storeey sto e
OWASP 11
SSO design and security considerationsSSO design and security considerations
Secure authentication and authorizationSecure authentication and authorizationAd-hoc encrypted tokenSTSSTS
Secure session management: one dies, both dieSession initiationSession terminationSession recoveryyKeep alive
Secure web page wrapping: look and feel of the siteiFrames
OWASP 12
iFrames
Potential Security Issues with SSO DesignPotential Security Issues with SSO Design
In-Secure Session Management:In Secure Session Management:Sessions are not sync: one dies, one left openSession ReplaySession ReplaySession Riding (CSRF)Session hijackingSessions un-protected/in clear, cached, loggedp gg
Malicious Data Injections: XSS SQL InjectionXSS, SQL Injection
Elevation of Privileges, Bypass of AuthenticationBypass authorizationsForceful browsing
OWASP 13
o ce u b o s g
Secure Architecture DesignSecure Architecture Design
General Security Design Principles1. Implement Authentication With Adequate Strength2. Enforce Least Privilegeg3. Protect Data In Storage, Transit And Display4. Enforce Minimal Trusto ce a ust5. Trace and Log User Actions And Security Events6. Fail Securely And Gracefully6. Fail Securely And Gracefully7. Apply Defense in Depth8 Apply Security By Default8. Apply Security By Default9. Design For Simplicity, KISS Principle10 Secure By Design Development and Deployment10.Secure By Design, Development and Deployment11.Secure As The Weakest Link12 A oid Sec it B Obsc it
OWASP12.Avoid Security By Obscurity
14
Security Controls Design Guidelines: Authentication d A th i tiand Authorization
Authentication, What, Where and HowAuthentication, What, Where and HowMandatory to restrict access to validated usersStrength depends on application risk/data classificationStrength depends on application risk/data classificationCompliant with regulations/standardsProvide for secure password and account managementMitigates brute forcing and credentials harvestingg g gMitigates Man In The Middle Attacks (MiTM)Provides for user and host to host authenticationProvides for user and host to host authentication
Authorization Most Common FlawsFlaws in Role Base Access Controls (RBAC)Flaws allow for horizontal and vertical privilege escalation
OWASP 15Forceful browsing
Security Controls Design Guidelines: Session Management
Avoid common session management flaws:gSession cookies and authentication tokens unprotected (e.g. clear text) between client and serveru p otected (e g c ea te t) bet ee c e t a d se eMissing session invalidation at idle-time out and user logoutlogoutMissing re-issuance of new session token to prevent re-use for authenticationuse for authenticationUn-secure storage in a session store in clear text L k f t d ti f iLack of strong random generation of session cookies/identifiers (e.g. >128 bit)Lack of coordinated session between application tiers
OWASP 16
Security Controls Design Guidelines: Input lid iValidation
What and where to validateWhat and where to validateType, format, range and length of input dataWherever data crosses system or trust boundariesInput and outputp pClient validation vs. server validation
How to validateHow to validateConstraint, Reject, SanitizeCanonical ValidationEncodinggIntegrity Checks
OWASP 17
Architecture of Financial Web ApplicationsArchitecture of Financial Web Applications
OWASP 18
Data flow diagram-Online Banking ApplicationData flow diagram Online Banking Application
DM
Z
(App &
DB
Internal (Z (User/W
e
Restrict
B Server/Fin
(Web Serveeb Server B
ted Netw
ornancial Ser
er/ App &
DBoundary)
rkrver Bound
DB
Server B dary)
Boundary)
OWASP 19
Sequence diagram of SAML SSOSequence diagram of SAML SSO
OWASP 20
Threat Modeling Web ApplicationsThreat Modeling Web Applications
OWASP 21From Improving Web Application Security: Threats and Countermeasures http://msdn.microsoft.com/en-us/library/ms994921.aspx
Attack Trees-Online Banking ApplicationsAttack Trees Online Banking Applications
OWASP 22Analyzing the Security of Internet Banking Authentication Mechanisms : http://www.itgi.org/Template.cfm?Section=Home&CONTENTID=35743&TEMPLATE=/ContentManagement/ContentDisplay.cfm
Use and Misuse Case of AuthenticationUse and Misuse Case of Authentication
OWASP 23From OWASP Security Testing Guidehttps://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation
Security risk framework for secure design of SSO architecturesSSO architectures
Threat Agents
Misuses and Attack Vectors
Security Weaknesses
Security Controls/Countermeasures
Technical Impacts
Business Impacts
Users, Customers/Employees
User logs out from one application and forget to log out to another application that SSOs into it
Inherent weaknesses in synchronizing sessions among applications
Single Logout Among Applications, Keep-alives
Loss of sensitive/confidential data
Reputation loss. Unlawful compliance fines
into it
Malicious Users, Fraudsters
Victim is targeted by phishing, download of malware
Social Engineering, Web Application Vulnerabilities, XSS
Consumer Education, Data Filtering, escape all un-trusted data based on HTML content
Execute JS on client, install malware
Fraud, financial losses, reputation loss/defacementsco e oss/de ace e s
Malicious Users, Fraudsters
Attacker sends malicious data to the application
Input Validation Vulnerabilities: XSS, SQL Injection
Filtering, parameterized API, ESAPI filtering APIs, white-list validations
Loss of data, data alteration, denial of service/access
Public disclosure of vulnerabilityReputation damageg
Malicious Users, Fraudsters
Attacker target design flaws in the SSO/authentication or session management f ti
Weak Auth and Session Mgmt Vulnerabilities
Follow Security Requirements For Secure Password Policies, Implement Account Locking, Disable “Auto-logons”
Unauthorized access to data, functions
Legal and financial implications
functions
Fraudsters Attacker creates forged HTTP requests and tricks a victim into submitting
Cross Site Request Forgery Vulnerabilities
Include the unique token in a hidden field.
Can change data and functions on behalf of the user
Fraud, revenue loss because of denial of accessa victim into submitting
thembehalf of the user denial of access
Automated Scripts/Spam Bots
Attacker uses a bot/script to attack the application for denial of
Insufficient Anti-Automation protection
Include CAPTCHA, ESAPI intrusion detection APIs
Can overflow/deny service to process spam data,
Loss due to business Disruptions/losse
OWASP 24
Spam Bots ppservice and harvesting
p ,harvest accounts./data
p /s, reputational damage
ReferencesReferences
OpenSAML：OpenSAML：https://spaces.internet2.edu/display/OpenSAML/Home
ESAPI:ESAPI:https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
Improving Web Application Security: Threats and Countermeasureshttp://msdn.microsoft.com/en-us/library/ms994921.aspxA l i h S i f I B ki A h i iAnalyzing the Security of Internet Banking Authentication Mechanismshttp://www itgi org/Template cfm?Section=Home&CONTENTID=35743&Thttp://www.itgi.org/Template.cfm?Section=Home&CONTENTID=35743&T
EMPLATE=/ContentManagement/ContentDisplay.cfm
OWASP Security Testing Guidehttps://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation
OWASP
