CSRF Review
 Quite similar, yet different from XSS
Liberty Alliance
CPSC 328
Spring 2009
 Malicious script or link involved
 Exploits trust
 XSS - exploit user’s trust in the site
 CSRF - exploit site’s trust in the user’s browser
 CSRF relies on browser automatically sending
authentication/session data
 Very difficult to detect
 Server side: looks like legitimate request from user
 Client side: never know you just sent something
Kerberos Review
 Developed @ MIT
 Distributed authentication system
 Don’t need full
trust in client
 Tickets




.NET Passport Review
 Windows Live ID (Single Sign-On)
 Functions very similar to kerberos
 Authenticate once to server
 Use services of several hosts
 Cookies:
 MSPAuth
 MSPProf
 MSPSec
TGT
TGS
Finite life
Encrypted
Source: www.xml-dev.com/blog/
Source: microsoft.com
1
OWASP A4: Insecure Direct
Object Reference
 Expose internal implementation object
 DB, file, directory
 Account #’s, ID #’s, etc…
 Exposure creates potential attack vector
 Manually change URL parameters
 Hand craft SQL statements
 URL Jumping Directory Traversal
Insecure Direct Object Reference
 Consider form code snippet:
<select name="language">
<option value=”en">English</option>
</select>
…
require_once ($_REQUEST['language’]."lang.php");
 Manually set value of language:
../../../../etc/passwd%00
 This example relies on?
 Null exploit
 No root jail
Another Example
 Consider backend code for form:
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
String query = "SELECT * FROM table WHERE cartID=" + cartID;
 Evil Mel free to change cartID to any
value he wants…
Direct Object Reference
Protection
 Don’t “spill” private object references to
public
 Account/ID numbers, primary keys, etc…
 Filter input
 Accept known-good
 Verify authorization to referenced objects
2
Protection Example
Liberty Alliance

Started 2001 by Sun Microsystems
 Open standards for Federated Identity Management
 Repaired cartID example:
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
User user = (User)request.getSession().getAttribute( "user" );
String query = "SELECT * FROM table WHERE
cartID=" + cartID + " AND userID=" + user.getID();

Handles Single Sign-On (Simplified Sign-On)
 Human Principals
 Automated Principals

Governance
 Management Board
 3 Expert Groups
 Check authorization for access
 Business
 Technology
 Public Policy
 Repaired file example:
http://www.example.com/application?file=1
 Backend code maps value to file name
Liberty Alliance & Web Services
 Web Services goal:
simplify linking of business systems

Interacts closely with standards bodies




IETF
OASIS
W3C
OMA
Who is Liberty Alliance?
 160+ Organizations
 Profit, Non-Profit, Government
 Liberty Alliance goal:
simplify authentication management
 Provide seamless web experience
 User based
 Organization/host based
Source: projectliberty.org
3
Key Components
Circles of Trust
 Principal
 Any entity that can acquire an ID and perform actions
 Identity Provider
 Protect privacy of Principals
 Define/Manage trust relationships
 Entity that creates, maintains, manages Principal IDs
 Service Provider
 Defined by agreements
 Entity that provides services to Principals
 Circle of Trust
 Liberty Architecture
 Operational Agreements
 Federation of Service & Identity Providers
 Local Identity
 Enables business transactions
 Principal’s identity with a specific provider
 Federated Identity
 Set of local identities that provide simplified sign-on through
liberty protocols
 In secure environment
 In seamless environment
Single (Simplified) Sign-On
 User authenticates to Liberty enabled site
 User seamlessly signed-on to all sites within
circle of trust (no need to re-authenticate)
 Can be extended to sites in other circles of
trust
Source: projectliberty.org
4
Identity Federation
Identity Federation
 Principal wants to enable local account for
access to federated sites in circle of trust
 Enables Single Sign-On
 Links account with other accounts via
Liberty protocol
 SAML provides account authentication
decisions to circle of trust
Source: projectliberty.org
Identity Federation (1)
Identity Federation (2)
 User connects to IdP & authenticates
Source: projectliberty.org
 User chooses which accounts to federate
Source: projectliberty.org
5
Account Federation (3)
Name Registration
 Federation initiated at the IdP
 When federating IDs, SPs specify how they will
refer to a Principal
 SP naming convention may differ from IdP
convention
 Protects Principal
 Does not force particular schema on IdPs or SPs
 Registration is required for SSO to function
Source: projectliberty.org
Federation
 Initiated by Principal
 Can be retracted by
 Principal
 IdP
 SP
 Terminate
 Identity Federation
 Federation
Source: projectliberty.org
6
Single Sign-On
Single Sign-On (1)
Instead of the SP directly authenticating
the user, the SP queries the IdP and the
IdP issues an authentication assertion
 User connects to IdP & Authenticates
Source: projectliberty.org
Source: projectliberty.org
Single Sign-On (3)
Single Sign-On (2)
 User redirected to IdP based on
authentication request from SP
 User chooses an SP
Source: projectliberty.org
Source: projectliberty.org
7
Single Sign-On (4)
Single Sign-On (5)
 IdP issues an authentication assertion
Source: projectliberty.org
Single Sign-On (6)
 SP checks the authentication assertion
and allows access to service
 Authentication assertion sent from IdP to Sp
Source: projectliberty.org
Single Log-Out
 Log out from SP, log out from circle of trust
 Notice sent to all SPs in federation
 Log out from IdP
 Notice sent to all SPs
 Log out from SP
 Notice sent from SP to IdP
 Notice sent from IdP to all other SPs
Source: projectliberty.org
8
Single Log-Out
 Initiated at IdP
Liberty Security




XML Signature
XML Encryption
SAML
No secret sharing on Principal between sites
 Authentication assertions
 Distributed Federation of IdPs
 SPs can specify authentication context
 Password
 Smart Card
 Certificate
 IdPs can provide authentication context
 Principal physically present @ registration
9