This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Architectural Design Patterns for SSO (Single Sign On) Design and Use Cases for Financial Web Applications
Wei Zhang & Marco MoranaOWASP Cincinnati, U.S.A.
OWASP 2
Presentation outline
Description of the challenges for securing SSO architectures in financial web applications Multiple systems require integration. Each system supports stand alone sign on and multiple
business units SSO and federation use cases Security and functional requirements for SSO Secure architecture principles Architectural diagrams Data flow diagrams Sequence diagrams Threat models of SSO architectures Attack trees and misuse cases Security risk framework for secure design of SSO
architectures
OWASP 3
SSO need for financial web system
Different systems serving different functions ATM cash withdraw Branch deposit Monthly statements Make a payment with a check Wire transfer
Different systems have different user information Personal information Transaction journal Statements
Different systems have different products Saving/checking accounts Credit card accounts Mortgage applications or loans Cash rewards Mileage rewards
OWASP 4
Business value
User friendly is the key Single view is the goal Eliminate additional sign on is the
approach Security is the fundation
OWASP 5
Business use case
User can sign on site A to do function B about product C
User can sign on site X to do function Y about product Z.
User should be able to sign on from Site A to access function B and function Y without additional authentication.
Site X will not be sunset
OWASP 6
Design options
Duplicate function Y on site A and access information on site X Pros:
Make it possible to sunset site X Cons:
Introduce duplicated function on two sites Needs to maintain the function and processing rules on two sites.
Build SSO for user to access function Y on site X Pros:
No need to maintain two sets of function and processing rules on two sites
Enable the possibility to fully leverage functions on site X Cons:
Make site A depends on site X Introduce security complexity:
Introduces additional internet hop for communication
OWASP 10
SSO STS: Central Security Token Service to respond with SAML token to federated sites upon request.
Application Server
Key store
Internet
Site A
Application Server
Site X
SSO withSAML token
Citi Customer
`
Key store
credential store
User information
SA
ML
toke
nfo
r S
SO
Sig
n o
n
STS
Key store
SAML token
Varify SAML token/authenticate
OWASP 11
Design and security consideration
Authentication and authorizationSecure tokenSTS
Session management: one dies, both dieSession initiationSession terminationSession recoveryKeep alive
Branding: look and feel of the site iFrameWrapped
OWASP 12
Potential Security Issues with SSO Design In-Secure Session Management:
Sessions are not sync: one dies, one left openSession ReplaySession Riding (CSRF)Session hijackingSessions un-protected iand n clear, cached, logged
Malicious Data Injections: XSS, SQL Injection
Elevation of Privileges, Bypass of AuthenticationBypass authorizationsForceful browsing
OWASP
Secure Architecture Design
General Security Design Principles1. Implement Authentication With Adequate Strength2. Enforce Least Privilege3. Protect Data In Storage, Transit And Display4. Enforce Minimal Trust5. Trace and Log User Actions And Security Events6. Fail Securely And Gracefully7. Apply Defense in Depth8. Apply Security By Default9. Design For Simplicity, KISS Principle10.Secure By Design, Development and Deployment11.Secure As The Weakest Link12.Avoid Security By Obscurity
13
OWASP 14
Security Controls Design Guidelines: Authentication and Authorization
Authentication, What, Where and HowMandatory to restrict access to validated usersStrength depends on application risk/data
classificationCompliant with regulations/standardsProvide for secure password and account
managementMitigates brute forcing and credentials harvestingMitigates Man In The Middle Attacks (MiTM)Provides for user and host to host authentication
Authorization Most Common FlawsFlaws in Role Base Access Controls (RBAC)Flaws allow for horizontal and vertical privilege
What and where to validateType, format, range and length of input dataWherever data crosses system or trust
boundaries Input and outputWherever data crosses system or trust boundarieClient validation vs. server validation
How to validateConstraint, Reject, SanitizeCanonical ValidationEncoding Integrity Checks
OWASP
Architectural Diagram Of Web Applications
17
OWASP
Data flow diagram-Online Banking Application
18
User/Browser
HTTPsRequest
HTTPsResponses
DM
Z (U
ser/Web
Serve
r Bo
un
dary)
Message XML/JMS
Web Server
ApplicationServer
Application Calls (.do)
Messaging Bus
Authentication Credential
Store
Restricte
d N
etwo
rk(A
pp
& D
B S
erver/F
inan
cial S
erver Bo
un
dary
)Application Responses
Auth Data
ServiceMessage
Response
SQL Query Call/JDBC
Intern
al (Web
Serve
r/ Ap
p &
DB
Serve
r Bo
un
dary)
Financial Transaction Processing MainFrame
Financial Transactions (ACH, wires
external transfer)
MFA RBA/Fraud
DetectionXML/HTTPS
XML/HTTPS
OWASP
Sequence diagram of SAML SSO
19
OWASP
Threat Modeling Web Applications
20From Improving Web Application Security: Threats and Countermeasures http://msdn.microsoft.com/en-us/library/ms994921.aspx
OWASP
Attack Trees-Online Banking Applications
21Analyzing the Security of Internet Banking Authentication Mechanisms : http://www.itgi.org/Template.cfm?Section=Home&CONTENTID=35743&TEMPLATE=/ContentManagement/ContentDisplay.cfm
OWASP
Use and Misuse Case of Authentication
22
User
Hacker/Malicious User
Brure ForceAuthentication
Enter Username andpassword
Validate PasswordMinimum Length and
ComplexityApplication/Server
Includes
Mitigates
User Authentication
Includes
Includes
Includes
Mitigates
Threatens
Show Generic ErrorMessage
Includes
Includes
Lock Account After N.Failed Login Attempts
Harverst (e.g. guess)Valid User Accounts
Dictionary Attack
Mitigates
Mitigates
From OWASP Security Testing Guide https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation
OWASP
Security risk framework for secure design of SSO architectures
23
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
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