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 2
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 3
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 4
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 5
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:
– Authentication
– Authorization
– Session coordination
– UI
OWASP 6
7. SSO – Secure token: use symmetric and public key cryptography
to encrypt the application data, or payload for SSO.
Pros: Cons:
Easy to set up and Not a unified solution
implement Each federated site
Supports PKI and has to manage
SAML cryptographic key
No dependency on
other system.
OWASP 7
8. SSO – Secure token: use symmetric and public key cryptography
to encrypt the application data, or payload for SSO.
SSO with
encrypted token Decrypt token
`
Internet and authenticate
Citi
Customer
Secure token
Sign on
Site X
for SSO
Site A
Application
Application Server
Server
credential User
store information
Key store
Key store
OWASP 8
9. SSO STS: Central Security Token Service to respond with SAML token to
federated sites upon request.
Pros: Cons:
Drives to unified Introduces dependences
solution for both on STS for federated
internal and external sites
communication. Introduces additional
Centralized internet hop for
cryptographic key communication
management
approach.
Supports SAML and
SOAP
OWASP 9
10. SSO STS: Central Security Token Service to respond with SAML token to
federated sites upon request.
SSO with
SAML token
`
Internet
Citi
Customer
SAML token
Sign on
Site X
for SSO
Site A
Varify SAML
Application
token/authenticate
Application Server
STS
Server
SAML token
credential User
store information
Key store Key store
Key store
OWASP 10
11. Design and security consideration
Authentication and authorization
Secure token
STS
Session management: one dies, both die
Session initiation
Session termination
Session recovery
Keep alive
Branding: look and feel of the site
iFrame
Wrapped
OWASP 11
12. Potential Security Issues with SSO Design
In-Secure Session Management:
Sessions are not sync: one dies, one left open
Session Replay
Session Riding (CSRF)
Session hijacking
Sessions un-protected iand n clear, cached, logged
Malicious Data Injections:
XSS, SQL Injection
Elevation of Privileges, Bypass of Authentication
Bypass authorizations
Forceful browsing
OWASP 12
13. Secure Architecture Design
General Security Design Principles
1. Implement Authentication With Adequate Strength
2. Enforce Least Privilege
3. Protect Data In Storage, Transit And Display
4. Enforce Minimal Trust
5. Trace and Log User Actions And Security Events
6. Fail Securely And Gracefully
7. Apply Defense in Depth
8. Apply Security By Default
9. Design For Simplicity, KISS Principle
10. Secure By Design, Development and Deployment
11. Secure As The Weakest Link
12. Avoid Security By Obscurity
OWASP 13
14. Security Controls Design Guidelines: Authentication
and Authorization
Authentication, What, Where and How
Mandatory to restrict access to validated users
Strength depends on application risk/data classification
Compliant with regulations/standards
Provide for secure password and account management
Mitigates brute forcing and credentials harvesting
Mitigates Man In The Middle Attacks (MiTM)
Provides for user and host to host authentication
Authorization Most Common Flaws
Flaws in Role Base Access Controls (RBAC)
Flaws allow for horizontal and vertical privilege escalation
and forceful browsing OWASP 14
15. Security Controls Design Guidelines: Session
Management
Avoid common session management flaws:
Session cookies and authentication tokens
unprotected (e.g. clear text) between client and server
Missing session invalidation at idle-time out and user
logout
Missing re-issuance of new session token to prevent re-
use for authentication
Un-secure storage in a session store in clear text
Lack of strong random generation of session
cookies/identifiers (e.g. >128 bit)
Lack of coordinated session between application tiers
OWASP 15
16. Security Controls Design Guidelines: Input
Validation
What and where to validate
Type, format, range and length of input data
Wherever data crosses system or trust boundaries
Input and output
Wherever data crosses system or trust boundarie
Client validation vs. server validation
How to validate
Constraint, Reject, Sanitize
Canonical Validation
Encoding
Integrity Checks
OWASP 16
20. Threat Modeling Web Applications
From Improving Web Application Security: Threats and Countermeasures http://msdn.microsoft.com/en-us/library/ms994921.aspx
OWASP 20
21. Attack Trees-Online Banking Applications
Analyzing the Security of Internet Banking Authentication Mechanisms : OWASP 21
http://www.itgi.org/Template.cfm?Section=Home&CONTENTID=35743&TEMPLATE=/ContentManagement/ContentDisplay.cfm
22. Use and Misuse Case of Authentication
Enter Username and
password
Includes
User
User Authentication Threatens
Brure Force
Authentication
Includes
Includes
Show Generic Error Mitigates
Message Harverst (e.g. guess)
Valid User Accounts
Includes
Mitigates
Includes
Validate Password
Minimum Length and Mitigates
Application/Server Hacker/Malicious User
Complexity
Dictionary Attack
Includes
Mitigates
Lock Account After N.
Failed Login Attempts
From OWASP Security Testing Guide OWASP 22
https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation
23. Security risk framework for secure design of
SSO architectures
Threat Misuses and Security Security Controls/ Technical Business
Agents Attack Vectors Weaknesses Countermeasures Impacts Impacts
Users, User logs out from one Inherent weaknesses in Single Logout Among Loss of Reputation loss.
Customers/ application and forget to synchronizing sessions Applications, Keep-Alives sensitive/confident Unlawful
Employees log out to another among applications ial data compliance fines
application that SSOs
into it
Malicious Victim is targeted by Social Engineering, Web Consumer Education, Data Execute JS on Fraud, financial
Users, phishing, download of Application Vulnerabilities, Filtering, escape all un- client, install losses,
Fraudsters malware XSS trusted data based on HTML malware reputation
content loss/defacements
Malicious Attacker sends malicious Input Validation Filtering, parameterized API, Loss of data, data Public disclosure
Users, data to the application Vulnerabilities: XSS, SQL ESAPI filtering APIs, white-list alteration, denial of vulnerability
Fraudsters Injection validations of service/access Reputation
damage
Malicious Attacker target design Weak Auth and Session Follow Security Requirements Unauthorized Loss of CIA, legal
Users, flaws in the Mgmt Vulnerabilities For Secure Password Policies, access to data, and financial
Fraudsters SSO/authentication or Implement Account Locking, functions implications
session management Disable “Auto-logons”
functions
Fraudsters Attacker creates forged Cross Site Request Forgery Include the unique token in a Can change data Loss of CIA,
HTTP requests and tricks Vulnerabilities hidden field. and functions on fraud, denial of
a victim into submitting behalf of the user access
them
Automated Attacker uses a bot/script Insufficient Anti- Include CAPTCHA, ESAPI Can overflow/deny Business
Scripts/ to attack the application Automation protection intrusion detection APIs service to process Disruptions/losse
Spam Bots for denial of service and spam data, s, reputational
harvesting harvest accounts./ damage
data
OWASP 23
Editor's Notes
Authentication A system that restricts access to resources can only be regarded secure if its users are authenticated when accessing personal and business sensitive information. Hence, some kind of authentication is mandatory. The methods used for implementing authentication should be properly selected depending on the sensitivity of the information that needs to be accessed. For instance, a simple username / password combination might be sufficient for a free mail application, but definitely not for an on-line banking service. In some cases, compliance with standards and regulations drives the adoption of security controls such as in the case of MFA (Multi Factor Authentication). Some types of web authentications are insecure (e.g. HTTP Basic Authentication) and should be implemented with care depending on the inherent risk of the application and the presence of other compensating controls (e.g. SSL). Moreover, authentication needs to have controls in place to prevent brute forcing of passwords (e.g. password strength and account lockouts) as well as harvesting of credentials (e.g. generic credential validation error messages at logout). When an authentication solution for the application relies on another application such as in the case of SSO potential weakness due to the integration of the authentication system needs to be properly addressed. Authorization . Similar to authentication, authorization is required for systems that restrict access to resources. Not every user in the system whether authenticated or not is equal. Authorization aims to provide a mechanism by which system designers can both define the access control mechanisms and enforce them. For this reason, is critical to follow best practices while designing authorization controls for the application. Issues in this category deal with weak access control for protected resources. For instance, a flawed access control design might allow elevation of privileges through parameter modification and forceful browsing to access functionality and/or data they are not authorized for. Authorization data stored in hidden FORM fields is exposed to modification on the client side to bypass segregation of duties (e.g. vertical and horizontal escalation). Another common problem is that users of the application have excessive rights being granted or that roles are not granular enough as well as the application does not enforce least privilege in the default architecture. Some authorization flaws are also due to vulnerabilities in the web server (e.g. IBM servlet authorization flaws) and need to be properly patched during configuration management before production release.
User and Session Management . Most applications use the concept of sessions to provide stateful interactions to the user despite the fact that protocols like HTTP are inherently stateless. This concept can cause problems if session data is not appropriately protected, either when stored or while in transit. It has to be ensured that session data cannot be altered, or otherwise compromised when the session is active. For instance, using unprotected session cookies could enable an attacker to hijack the session. Other problems refer to the independence of multiple sessions belonging to different users. For example, if two users are logged in at the same time, one as super user and the other as a normal low privileged user and if the sessions are not independent there is a chance that the application might provide administrative functionality to the low privileged user. Provide a security mechanism to maintain session independence between multiple logged on users. Session identification should also be protected with proper design by requiring proper cookie strength (e.g. 128 bit random). Session ID should be re-issued before authentication invalidated at logout and sessions should time-out after some duration of inactivity. Furthermore, it is important that user management is considered as well. This includes avoid to use sensitive information to log-in into the application, password management (Change password resets and password retrieval functions), user enrollment (e.g. the manner new users are added to the system), accounts (e.g. lockout after certain invalid logins), passwords (e.g. password resets) and other user specific issues.
Data Management concerns with the implemented security control to manage data securely during transmission, storage and transit. The requirements for the application data management should be captured in the security requirements of the application depending on the analysis of the sensitivity of the data handled by the application (i.e. data classification) and risk considerations (e.g. dollar amounts in financial transactions to be considered high financial risk).. Data Validation is concerned with problems stemming from assumptions about type, format, range and length of input data. Since there is in general no guarantee that the received data is of the expected form, validation has to be carried out, before further processing that data. If no validation is done, an attacker can inject malicious data into the system, thus causing serious problems. Ineffective data validation is still one of the most common sources for vulnerabilities of applications. For instance, if an input string is expected to be of a certain length but the string received is longer than that, the excess data could overwrite critical information and cause a buffer overflow. Thus an attacker could take over a machine just by crafting a malicious string. It is not only important that thorough data validation takes place, but also where the validation is carried out. A classic candidate for performing data validation is wherever data crosses system or trust boundaries. Client side validation, for instance, is good to avoid unnecessary network traffic and delays, however, the received data must still be validated at the server side, since the data could have been changed in transit e.g. using an HTTP proxy.