A Primer on Application Security

1. A Primer on Application Security Brandon McMillon brandom@microsoft.com Academic Developer Evangelist Microsoft Corporation

2. Why Security is Hard (For Some) • “Security is boring” • Often seen as something that disables technology or “gets in the way” • Difficult to measure • Not usually the primary skill or interest of the designers and developers • “The Attacker’s Advantage”

3. The Attacker’s Advantage and the Defender’s Dilemma • Principle #1 The Defender must defend all points; the Attacker will choose the weakest point • Principle #2 The Defender must be constantly vigilant; the Attacker will strike at will • Principle #3 The Defender can only defend what he/she knows about; the Attacker will study for vulnerable points

4. Attacker needs to understand only one security issue • Defender needs to secure all entry points • Attacker has unlimited time • Defender works with time and cost constraints Attackers vs. Defenders • Secure systems are more difficult to use • Complex and strong passwords are difficult to remember • Users prefer simple passwords Security vs. Usability • Developers and management think that security does not add any business value • Cost of addressing security issues only increases as software design lifecycle proceeds Security As an Afterthought Do I need security… Challenges When Implementing Security

5. Why Security Matters • Much more expensive to fix later on – Microsoft estimates that each security bulletin costs $100k. For every software company, fixing an issue after release is 50 to 200 times more expensive than fixing it earlier in the cycle • Bad PR – Your face on magazines! • People shy away from your products • Consultants look to build their reputation by “victimizing” easy targets like you

6. Developer Role in Application Security • Developers must: • Work with designers/architects, testers and systems administrators to ensure application security • Contribute to security by: • Adopting good application security development practices • Using secure programming techniques • Knowing where security issues occur and how to avoid them • Have an “organizational awareness” of security processes and the people involved

7. Developer Role in Application Security (cont.) • To develop a secure application: • Need a secure design/architect • Need to be tested for security • Developers need to work with • Designers/architects • Testers

8. Holistic Approach to Security • Security must be considered at: • All stages of a project • Design • Development • Deployment • All layers • Network • Host • Application “Security is only as good as the weakest link”

9. Who is Threat Modeling?

10. Threat Modeling • Principle: Can’t build a secure system until you’ve identified all the threats against it • Provide capability where teams can • Define – information relevant to application security • Model – Threats, Attacks, Vulnerabilities and Mitigations • Measure – Impact, Probability, Cost, Benefit • What does this new capability provide? • Provides a security strategy • Prioritize security features • Understand value of mitigations • Translates technical risk to business impact

11. Areas of Security Concern Authentication 1 Authorization 2 Asset Handling 3 Input Issues 4 Auditing & Logging 5

12. Threat Classification (STRIDE) • Spoofing • Forging an identity of a service or user • Tampering • Compromising integrity of data • Repudiation • Can’t prove an action committed by an entity • Information Disclosure • Unintended disclosure of information • Denial of Service • Compromising availability of a service • Elevation of Privileges • An identity can gain unauthorized privileges

13. Attacker A Few Common Attack Patterns • “Man in the Middle” (MitM) Attack Convince www.IBuySpy.com you are User www.IBuySpy.com User Convince User you are www.IBuySpy.com

14. Request Request Attacker A Few Common Attack Patterns (cont.) • Replay Attack www.IBuySpy.com User Attacker gets hold of the User Request and replays it on the www.IBuySpy.com server

15. A Few Common Attack Patterns (cont.) • Dictionary Attack • Decipher a secret using words from a dictionary • Brute Force Attack • Decipher a secret by enumerating through all possibilities

16. Cryptography • Idea: Make the cost of unauthorized retrieval of a message significantly higher than the value of the message • Encryption is the process of making information unreadable by unauthorized persons • Cryptographic algorithms can be: • Asymmetric • Symmetric • One-way (Hash algorithm)

17. Symmetric Cryptography • Uses one key to: • Encrypt the data • Decrypt the data • Is fast and efficient • Decrypt(Encrypt(“secret”, Key), Key) = “secret” • Decrypt(Encrypt(“secret”, Key), OtherKey) = <garbage>

18. Asymmetric Cryptography • Uses two mathematically related keys: • When one key encrypts the data… • Only other key can decrypt the data • Is slower than symmetric encryption • Separation of keys facilitates better management and exchange of keys • Decrypt(Encrypt(“secret”, publicKey), privateKey) = “secret” • Decrypt(Encrypt(“secret”, privateKey), publicKey) = “secret” • Decrypt(Encrypt(“secret”, publicKey), publicKey) = <garbage> • Decrypt(Encrypt(“secret”, privateKey), privateKey) = <garbage>

19. The Untrustworthy Courier • You want to send a diamond to your friend • You have a lock and a key • Your friend has a lock and a key • You can only use an untrustworthy courier who will provide you a box into which you can place your diamond • Fact: if the box is not locked, the courier will run off with its contents! • How do you transfer the diamond?

20. The Untrustworthy Courier (cont.)

21. Sharing a Secret using Asymmetric Encryption Encrypt(“secret”, PublicKey) = <EncryptedBlob> <EncryptedBlob> Decrypt(<EncryptedBlob>, PrivateKey) = “secret” “secret” Symmetric Key Symmetric Key “secret” Private Key Private/Public Key Pair Public Key

22. Cryptographic Hash Algorithm • Uses no keys at all • Generates a fixed-size output (“hash value” or “message digest”) • …and is therefore not reversible • The hash values should also be collision-free • It should be (practically) impossible to discover another input that maps to the same output

23. Areas of Security Concern Fundamental 0 Authentication 1 Authorization 2 Asset Handling 3 Input Issues 4 Auditing & Logging 5

24. Authentication & Authorization • Authentication • Verifies the identity of a principal • “Who’s There?” • Authorization • Confirms that an authenticated principal is allowed access to specific resources or carry out a specific action • “What would you like?”

25. Authentication – Authentication Methods • Basic • Digest • Integrated • Kerberos v5 • NTLM • Digital signatures and digital certificates • Microsoft .NET Passport • ASP.NET Forms Authentication • Biometrics • Smart Cards

26. Basic Authentication • Is simple… • …and also insecure • Is supported by all majorbrowsers and servers • Is easy to program andset up • Manages user credentials

27. How Basic Authentication Works • Username and password encoded using Base64 encoding and sent to server • YWxpY2U6UGFzc3dvcmQxMjM=alice:Password123 GET /SomeBasicSite/ HTTP/1.0 Accept: image/gif, image/jpeg, image/pjpeg, */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Host: SomeBasicSite If-None-Match: "39d041a8ae3fc51:a28" Authorization: Basic YWxpY2U6UGFzc3dvcmQxMjM= Connection: Keep-Alive

28. Base64 Encoding • Encode a message of n bytes Byte 1 Byte 2 Byte 3 Bit 7 - 12 Bit 13 - 18 Bit 19 - 24 Bit 1 - 6 Each block of 6 bits gets mapped to one of the possible 26 = 64 values from {A, B, …, Y, Z, a, b, …, y, z, 0, 1, …, 8, 9, +, /} If n mod 3 = 2 then “=” is used to pad the encoded message If n mod 3 = 1 then “==” is used to pad the encoded message

29. Request Challenge (nonce) Password How Digest Authentication Works 5 Account Store Server Password + nonce 1 6 2 X$!87ghy5 4 If values match, the user is authenticated Password + nonce Client X$!87ghy5 3 Hash Algorithm

30. Using Basic & Digest Authentication • Don’t use Basic Authentication! • If using Digest, couple with a secure 128-bit SSL channel • If using with IIS (6.0): • Clients need IE 5.0 or later • Users must have a valid Windows user account stored in AD on the DC • Requires “reversibly encrypted” (clear text) password in AD

31. Service Request ST KDC KDC TGT ST 1 2 2 1 Target Service TGT 3 3 4 TGT cached locally Session established Client Client ST Service Ticket TGT Authentication – Kerberos v5 Initial Logon Ticket-Granting Ticket

32. Why Kerberos v5 Works? • Built around symmetric encryption • Every service and identity on a domain has a unique key that is shared with the KDC (KDC has its own key that is not shared) • Uses the concept of “service tickets” • “Service tickets” bind authentication of clients to a specific service (mutual authentication) • Assumptions: • Since the target service can read the service ticket presented by a client, it could have only been created by the KDC • The KDC will only give out service tickets to those clients that have been authenticated

33. Kerberos PKINIT • Extension to Kerberos that allows the use of public key cryptography for authentication • Use with Kerberos protocol • Instead of symmetric key that is derived from user’s password, the user supplies a public key • Allows for smartcard authentication implementation

34. Data Data Verifying Data Integrity with Hashes User A User B Hash Value If hash values match, data is valid Hash Algorithm Hash Algorithm Hash Value Hash Value User A sends data and hash value to User B

35. User B Hash Algorithm Data Data Hash Algorithm User A Public Key Hash Value Hash Value Hash Value User A Private Key Digital Signatures User A If hash values match, data came from the owner of the private key and is valid

36. How Digital Certificates Work Private Key User Private/Public Key Pair Computer Public Key Service Application Certification Authority Certified Administrator

37. Authentication – Client Digital Certificates • Used in Web applications • Server secures communications using SSL/TLS with a X.509 server certificate • Server authenticates clients using data in client X.509 certificate, if required • Certificate authority issues a certificate for which the server holds a root certificate • Used in distributed applications • Application uses SSL/TLS communication channel • Client and server applications authenticate using certificates • Can be deployed on smart cards

38. Authentication – What to use? • Don’t re-invent the wheel • Use Integrated Authentication (Kerberos, NTLM) if possible • Use digital certificates if feasible • If implementing custom authentication • Keep logs • Implement a lockout policy • Enforce strong passwords • Handle account/password store appropriately

39. Areas of Security Concern Fundamental 0 Authentication 1 Authorization 2 Asset Handling 3 Input Issues 4 Auditing & Logging 5

40. Authorization Models • Role Based • Custom (“Roll Your Own”) • Resource Based • Trusted Subsystem Model • Impersonation/Delegation Model

41. Authorization – “Roll Your Own” • All client requests are serviced by one account / role

42. Pros & Cons of “Roll Your Own” model • Pros • Complete control / flexible • Connection pooling • Cons • One account has complete access to data - high risk from server compromise • Auditing • Administration challenges • Lots of code

43. Trusted Subsystem Model • Can Use AD roles to create trust levels • Can maintain user-trust level relationship as part of application • Can map users to different components • Can map users to different SQL connection strings • Can use ASP.NET URL authorization

44. Implementing Trusted Subsystem Model • Web services running under different identities • Using different SQL connection strings • Will need to use SQL authentication • Use .NET serviced components

45. Pros & Cons of Trusted Subsystem Model • Pros • Scalability (DB connection pooling) • Single tier administration • Less code than “Roll Your Own” • Cons • Auditing • High risk from server compromise (depending on setup)

46. Impersonation vs. Delegation • Impersonation is the ability of a thread to execute in a security context different from that of the process owning the thread • Alternate ID accesses local resources only • Delegationis the impersonation of clients over the network • Alternate ID accesses remote resources

47. Constrained Delegation • Trusted for Delegation • Assert the identity of any user across entire enterprise • Domain Controllers should be the only systems Trusted for Delegation • Constrained Delegation • Assert the identity of: • Specific users… • To specific machines… • For specific services • A new extension in the implementation of the Kerberos protocol in Windows Server 2003 • Allows a service to obtain service tickets (under the delegated users identity) to a subset of other services • To enable Constrained Delegation, contact your AD administrator

48. Pros & Cons of Impersonation/Delegation Model • Pros • Less code! • Precision logging • Cons • Administrative challenges • Heavily technology dependent (e.g., Kerberos) • Reduced scalability (no DB connection pooling) • Users have direct access to all tiers (including data)

49. Principle of Least Privilege • Provide users the minimum set of privileges to get the job done • Use service accounts with minimum set of privilege on required resources needed for the task • If privileges vary across your code, modularize your code and run under the required context for that module

50. Thick-client Authentication & Authorization • Don’t trust the client! • Server should do it’s own authentication • If NTLM/Kerberos, can pass on authenticated identity token: • myWSProxy.Credentials = System.Net.CredentialCache.DefaultCredentials; • Don’t let the client filter data based on authorization level it establishes for the user • Server should send only the data authorized for the authenticated user