.NET Passport Security Framework

Transcription

.NET Passport Security Framework
.NET Passport
Security Framework
CPSC 328
Spring 2009
UDDI Review
 Publish/Find functionality
 Yellow Pages
 businessService
 White Pages
 businessEntity
 Green Pages
 bindingTemplate
 tModel
 publisherAssertion
 operationalInfo
1
Cross Site Request Forgery
(CSRF)
 Quite similar, yet different from XSS
 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
Simple Example
 Code snippet from evil.mel.com
<html>
<body>
<html>
<img
src="http://www.example.com/transfer.do?
<body>
frmAcct=document.form.frmAcct&
<img src=“http://foo.bar.com/logout.php”>
toAcct=4345754&toSWIFTid=434343&amt=3434.43">
</body>
</body>
</html>
</html>
 How can this work?
 Reliant upon browser automatically
sending still-current session data
 GET vs POST
2
Simple Example
 So lets only use POST. Fixed, right?
<html>
<body onload="document.getElementById('f').submit()">
<form id="f" action="http://foo.com/logout" method="post">
<input name="Log Me Out" value="Log Me Out" />
</form>
</body>
</html>
 Not exactly!
 Automatically POSTs form after page loaded
(via javascript)
 Again, cookie sent implicitly by browser
CSRF: Protection
 How can we prevent it?
 Check the referrer
<form action="/transfer.do" method="post">
<input type="hidden" name="8438927730" value="43847384383">
</form>
 Hidden fields
 Hash of timestamp, userID, & nonce
 ASP.NET: ViewStateUserKey
 Double cookies
 Re-authenticate if important
 Don’t use GET
 But don’t rely on POST!
 Clients, don’t use “remember me”
3
.NET & Passport
 MS foray into single sign-on
 Began as MS Passport
 Became MS .NET Passport
 Now Windows Live ID
 Access to federation of sites/services once
authenticated by one member
 Hotmail, MSNBC, Xbox Live, MSN, …
Single Sign-On: Kerberos
 Developed @ MIT
 Distributed authentication system
 Don’t need full
trust in client
 Tickets




TGT
TGS
Finite life
Encrypted
Source: www.xml-dev.com/blog/
4
Passport
 Functions very similar to kerberos
 Authenticate once to server
 Use services of several hosts
 Application & Authentication Servers exchange
secret key (out of band)
 Happens before system can be used
 Keys must be protected (no expiration)
 Once completed, users can log in & use service
Passport Login Process




User visits site
Site redirects user to Passport Server
User authenticates to server
Server returns user to site with cookies
Source: microsoft.com
5
Passport Cookies
 MSPAuth
 Ticket: user ID
 Timestamps
 MSPProf
 User profile information
 MSPSec
 Ticket Granting Cookie
 Cookies support claim of authentication
 Communicated to application server through client
browser
Passport Attacks
 Steal username & password?
 Replay cookies?
 Steal profile info?
 Username/passwd not stored/collected on partner
sites
 Cookies have timestamps
 Cookies are encrypted
 Profile info not enough to gain credentials
 Privacy is still a concern
6
Web Services & .NET
 .NET & CLR provide functionality similar to Java & JVM
 Managed code provides safety features
 Sandboxing execution
 Compiled to MSIL (similar to java bytecode)
 Unmanaged code does not
 Overflows, privilege escalation, etc…
 Security defined in terms of
 Role-based
 Code Access
 Evidence-Based
Role-Based Security
 A.K.A. User-Based Security
 Traditional model
 Permission defined by account or role
 Security Identifier tracks user
 Checked before resource use
7
Code Access Security
 Access permissions assigned based on trust
in code
 Can assign range of trust
 Similar to IE’s trust zones
 Allows finer degree of control than role-based
 Controls assigned at various levels
 Application
 Class
 Module, library, …
Evidence Based
 Trust zones defined based on
 Digital signature
 URL of origin
 Zone
 Notion of code
groups
8
.NET Vulnerabilities
 Standard concerns w/Web Services
 Input validation
 SQL Injection
 Solution?




Stored procedures (good & bad)
Known-good validation only! Discard all else
Minimal error handling
Non-descript error messages
Hardening .NET Server
The standard fare:
 Web root on separate volume (not w/OS)
 Disable unused ISAPI filters
 Don’t allow outbound originating traffic from IIS
 Incoming traffic only on ports 80 & 443
 Penetration testing
 Remove development/installation files!
 Accounts & passwords! (on DB, too)
9