net passport security framework
play

.NET Passport Security Framework CPSC 328 Spring 2009 UDDI Review - PDF document

.NET Passport Security Framework CPSC 328 Spring 2009 UDDI Review Publish/Find functionality Yellow Pages businessService White Pages businessEntity Green Pages bindingTemplate tModel


  1. .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

  2. 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

  3. 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

  4. .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

  5. 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

  6. 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

  7. 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

  8. 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

  9. .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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend