Presentation sso design_security
•Download as PPT, PDF•
8 likes•9,506 views
OWASP Appsec ASIA, 2011 presentation
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Presentation sso design_security
Similar to Presentation sso design_security (20)
More from Marco Morana
More from Marco Morana (20)
Recently uploaded
Recently uploaded (20)
Presentation sso design_security
- 1. Architectural Design Patterns for SSO (Single Sign On) Design and Use Cases for Financial Web Applications Wei Zhang & Marco Morana OWASP Cincinnati, U.S.A. OWASP Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation http://www.owasp.org
- 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
- 17. Architectural Diagram Of Web Applications OWASP 17
- 18. Data flow diagram-Online Banking Application MFA RBA/ Application Fraud HTTPs Calls (.do) Detection User/ Request XML/HTTPS Browser Web Server Financial Application XML/HTTPS HTTPs Responses Transactions (ACH, wires external transfer ) (App & DB Server/Financial Server Boundary) Responses Messaging Internal (Web Server/ App & DB Server Boundary) Message Bus XML/JMS Application DMZ (User/Web Server Boundary) Server Service Message Response Restricted Network SQL Query Call/ Auth Data JDBC Financial Transaction Processing MainFrame Authentication Credential Store OWASP 18
- 19. Sequence diagram of SAML SSO OWASP 19
- 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.