Presentation sso design_security

Editor's Notes

• #15: 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.
• #16: 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.
• #17: 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.