Central Authentication Service (CAS) Simple, Flexible, Extensible Open Source Web Single Sign-On for the Enterprise ●Alfresco ●Confluence ●DokuWiki ●Drupal ●Google Apps ●JIRA ●Joomla! ●Liferay ●MediaWiki ●Moodle ●OpenCMS ●PeopleAdmin ●Roller ●Sakai ●Twiki ●uPortal ●Wordpress ●Zimbra ●Spring Security ●Apache Shiro ●Java CAS Client ●.Net CAS Client ●php CAS Client ●mod_auth_cas ●ASP to Zope
Hosted by OWASP & the NYC Chapter Central Authentication Service (CAS) ●CAS initially create by Shawn Bayern in 2001 at Yale ●CAS3 jointly designed and developed by Rutgers and Yale in 2005 as Jasig project ●Simple protocol, flexible architecture, wide deployment
Hosted by OWASP & the NYC Chapter Central Authentication Service (CAS) But...is it secure? How do we know? ●Based on Kerberos ●Wide deployment and many eye balls ●Reports of dynamic scans from time to time ●Maybe we should really check?
Hosted by OWASP & the NYC Chapter Central Authentication Service (CAS) CAS AppSec Working Group - Jan 2013 Joachim Fritschi Jérôme Leleu Misagh Moayyed Parker Neff https://wiki.jasig.org/display/CAS/CAS+AppSec+Working+Group David Ohsie Andrew Petro Bill Thompson Aaron Weaver
●Proactively work to improve the security posture ●Respond to potential vulnerabilities ●Produce artifacts that help potential CAS adopters evaluate the security of CAS ●Create and maintain recommendations on good security practices for deployments Hosted by OWASP & the NYC Chapter CAS AppSec Working Group Goals
OSS AppSec Program ●Form a working group ●OWASP Resources ●Meet regularly ●Make it easy to report vulnerabilities ●Threat Analysis with Developers ●Run security tools (ZAP, Static Code)
Hosted by OWASP & the NYC Chapter Contributors ●Use OWASP Resources and Libraries ●Threat Model ●Work with security researchers
Hosted by OWASP & the NYC Chapter Make it easy to report a vulnerability ●Security issue email address ●Provide a PGP Key
Hosted by OWASP & the NYC Chapter Static Code Analysis Issues were found, prioritized and worked through false positives
●What people think/say: “We probably don’t have any major security issues.” ●Threat analysis gives you a way to systematically analyze the possible threats against your system and rank them by potential impact. ●Threat analysis also gives adopters the information they need to analyze the deployment of your system in their environment. Hosted by OWASP & the NYC Chapter Threat analysis: Purpose
●Decompose the application: Draw a dataflow diagram in order to enumerate the attack surfaces. ●For each attack surface, enumerate the threats to the system and rank them. ●For each threat, create a list of possible mitigations. ●More details: https://www.owasp.org/index.php/Application_Threat_M odeling https://www.owasp.org/index.php/Application_Threat_M odeling Hosted by OWASP & the NYC Chapter Threat analysis: Methodology
●Started with whiteboarding session at Apereo conference to produce initial DFD and threats ●Biweekly follow-up meeting via Webex ●Used STRIDE to help identify threats ●Results maintained on wiki page ●https://wiki.jasig.org/display/CAS/CAS+Threat+Modelin ghttps://wiki.jasig.org/display/CAS/CAS+Threat+Modelin g Hosted by OWASP & the NYC Chapter CAS Appsec Experience
Hosted by OWASP & the NYC Chapter CAS Context DFD
Hosted by OWASP & the NYC Chapter CAS Protocol DFD Browser CAS Server CAS Client (Agent) Application Username/Password + Application Service URL SSO Session Cookie (TGT) Application Service Ticket (ST) HTTP(S) Request + ST HTTP(S) + Optional Session Cookie HTTPS
Hosted by OWASP & the NYC Chapter STRIDE ThreatSecurity Control SpoofingAuthentication TamperingIntegrity RepudiationNon-Repudiation Information DisclosureConfidentiality Denial of ServiceAvailability Elevation of PrivelegeAuthorization
●Identifier: PC_3 ●Category: Information Disclosure ●Threat: The pgtIou and pgtId are send as GET parameters, which can be a problem as they might be stored in logs or indexed in internal search engines... ●Mitigation: Never log the GET parameters on the proxy callback url. Though, it might be not sufficient. Should we change the CAS protocol in the next revision (v4.0) to POST these parameters ? Hosted by OWASP & the NYC Chapter CAS Appsec Sample Threat
●Easy: Security Guide Contents ○Disable http ○How to write a safe CAS client/plugin ○Securing the ticket registry ●Harder: Change the code ○Secure-by-default ○Encrypted/signed ticket registry Hosted by OWASP & the NYC Chapter Classifying Remediation
●Classified 19 threat against the system ●Generated 10 proposals ●One proposal (secure-by-default) integrated into CAS 4.0 ●Paraphrase from a CAS committer: ○“I thought when we started that we would not find any problems, but now I see that there are lots of improvements to be made” Hosted by OWASP & the NYC Chapter CAS Threat modeling results
●Even in a security project, features are favored over security! ●Difficult to get consistent participation (although a core of contributors have kept it up; thank you, Jérôme Leleu and co-presenters!) ●Difficult to get changes prioritized and into the project Hosted by OWASP & the NYC Chapter Challenges
Hosted by OWASP & the NYC Chapter Application Security Professionals Find an open source project and volunteer!
Hosted by OWASP & the NYC Chapter Thanks! David Ohsie Bill Thompson, CISSP, CSSLP IAM Practice Director, Unicon email@example.com Aaron Weaver
Your consent to our cookies if you continue to use this website.