.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