- Writing Secure Code
- A Note Regarding Supplemental Files
- Copyright
- Dedication
- Introduction
- I. Contemporary Security
- 1. The Need for Secure Systems
- Applications on the Wild Wild Web
- The Need for Trustworthy Computing
- Getting Everyone’s Head in the Game
- Some Ideas for Instilling a Security Culture
- The Attacker’s Advantage and the Defender’s Dilemma
- Principle #1: The defender must defend all points; the attacker can choose the weakest point.
- Principle #2: The defender can defend only against known attacks; the attacker can probe for unknown vulnerabilities.
- Principle #3: The defender must be constantly vigilant; the attacker can strike at will.
- Principle #4: The defender must play by the rules; the attacker can play dirty.
- Summary
- 2. The Proactive Security Development Process
- 3. Security Principles to Live By
- SD3: Secure by Design, by Default, and in Deployment
- Security Principles
- Learn from Mistakes
- Minimize Your Attack Surface
- Employ Secure Defaults
- Use Defense in Depth
- Use Least Privilege
- Backward Compatibility Will Always Give You Grief
- Assume External Systems Are Insecure
- Plan on Failure
- Fail to a Secure Mode
- Remember That Security Features != Secure Features
- Never Depend on Security Through Obscurity Alone
- Don’t Mix Code and Data
- Fix Security Issues Correctly
- Summary
- 4. Threat Modeling
- Secure Design Through Threat Modeling
- Security Techniques
- Mitigating the Sample Payroll Application Threats
- A Cornucopia of Threats and Solutions
- Summary
- 1. The Need for Secure Systems
- II. Secure Coding Techniques
- 5. Public Enemy #1: The Buffer Overrun
- 6. Determining Appropriate Access Control
- 7. Running with Least Privilege
- Least Privilege in the Real World
- Brief Overview of Access Control
- Brief Overview of Privileges
- Brief Overview of Tokens
- How Tokens, Privileges, SIDs, ACLs, and Processes Relate
- Three Reasons Applications Require Elevated Privileges
- Solving the Elevated Privileges Issue
- A Process for Determining Appropriate Privilege
- Step 1: Find Resources Used by the Application
- Step 2: Find Privileged APIs Used by the Application
- Step 3: Which Account Is Required?
- Step 4: Get the Token Contents
- Step 5: Are All the SIDs and Privileges Required?
- Step 6: Adjust the Token
- Low-Privilege Service Accounts in Windows XP and Windows .NET Server 2003
- The Impersonate Privilege and Windows .NET Server 2003
- Debugging Least-Privilege Issues
- Summary
- 8. Cryptographic Foibles
- Using Poor Random Numbers
- Using Passwords to Derive Cryptographic Keys
- Key Management Issues
- Key Exchange Issues
- Creating Your Own Cryptographic Functions
- Using the Same Stream-Cipher Encryption Key
- Bit-Flipping Attacks Against Stream Ciphers
- Reusing a Buffer for Plaintext and Ciphertext
- Using Crypto to Mitigate Threats
- Document Your Use of Cryptography
- Summary
- 9. Protecting Secret Data
- Attacking Secret Data
- Sometimes You Don’t Need to Store a Secret
- Getting the Secret from the User
- Protecting Secrets in Windows 2000 and Later
- Protecting Secrets in Windows NT 4
- Protecting Secrets in Windows 95, Windows 98, Windows Me, and Windows CE
- Not Opting for a Least Common Denominator Solution
- Managing Secrets in Memory
- Locking Memory to Prevent Paging Sensitive Data
- Protecting Secret Data in Managed Code
- Raising the Security Bar
- Storing the Data in a File on a FAT File System
- Using an Embedded Key and XOR to Encode the Data
- Using an Embedded Key and 3DES to Encrypt the Data
- Using 3DES to Encrypt the Data and Storing a Password in the Registry
- Using 3DES to Encrypt the Data and Storing a Strong Key in the Registry
- Using 3DES to Encrypt the Data, Storing a Strong Key in the Registry, and ACLing the File and the Registry Key
- Using 3DES to Encrypt the Data, Storing a Strong Key in the Registry, Requiring the User to Enter a Password, and ACLing the File and the Registry Key
- Trade-Offs When Protecting Secret Data
- Summary
- 10. All Input Is Evil!
- 11. Canonical Representation Issues
- What Does Canonical Mean, and Why Is It a Problem?
- Canonical Filename Issues
- Bypassing Napster Name Filtering
- Vulnerability in Apple Mac OS X and Apache
- DOS Device Names Vulnerability
- Sun Microsystems StarOffice /tmp Directory Symbolic-Link Vulnerability
- Common Windows Canonical Filename Mistakes
- 8.3 Representation of Long Filenames
- NTFS Alternate Data Streams
- Trailing Characters
- \? Format
- Directory Traversal and Using Parent Paths (..)
- Absolute vs. Relative Filenames
- Case-Insensitive Filenames
- UNC Shares
- When Is a File Not a File? Mailslots and Named Pipes
- When Is a File Not a File? Device Names and Reserved Names
- Canonical Web-Based Issues
- Visual Equivalence Attacks and the Homograph Attack
- Preventing Canonicalization Mistakes
- Web-Based Canonicalization Remedies
- A Final Thought: Non-File-Based Canonicalization Issues
- Summary
- 12. Database Input Issues
- 13. Web-Specific Input Issues
- Cross-Site Scripting: When Output Turns Bad
- Other XSS-Related Attacks
- XSS Remedies
- Encoding Output
- Adding Double Quotes Around All Tag Properties
- Inserting Data in the innerText Property
- Forcing the Codepage
- The Internet Explorer 6.0 SP1 HttpOnly Cookie Option
- Internet Explorer "Mark of the Web"
- Internet Explorer <FRAME SECURITY> Attribute
- ASP.NET 1.1 ValidateRequest configuration option
- Don’t Look for Insecure Constructs
- But I Want Users to Post HTML to My Web Site!
- How to Review Code for XSS Bugs
- Other Web-Based Security Topics
- Summary
- 14. Internationalization Issues
- The Golden I18N Security Rules
- Use Unicode in Your Application
- Prevent I18N Buffer Overruns
- Validate I18N
- Character Set Conversion Issues
- Use MultiByteToWideChar with MB_PRECOMPOSED and MB_ERR_INVALID_CHARS
- Use WideCharToMultiByte with WC_NO_BEST_FIT_CHARS
- Comparison and Sorting
- Unicode Character Properties
- Normalization
- Summary
- III. Even More Secure Coding Techniques
- 15. Socket Security
- 16. Securing RPC, ActiveX Controls, and DCOM
- An RPC Primer
- Secure RPC Best Practices
- Use the /robust MIDL Switch
- Use the [range] Attribute
- Require Authenticated Connections
- Use Packet Privacy and Integrity
- Use Strict Context Handles
- Don’t Rely on Context Handles for Access Checks
- Be Wary of NULL Context Handles
- Don’t Trust Your Peer
- Use Security Callbacks
- Implications of Multiple RPC Servers in a Single Process
- Use Mainstream Protocols
- Secure DCOM Best Practices
- An ActiveX Primer
- Secure ActiveX Best Practices
- Summary
- 17. Protecting Against Denial of Service Attacks
- 18. Writing Secure .NET Code
- Code Access Security: In Pictures
- FxCop: A "Must-Have" Tool
- Assemblies Should Be Strong-Named
- Specify Assembly Permission Requirements
- Overzealous Use of Assert
- Further Information Regarding Demand and Assert
- Keep the Assertion Window Small
- Demands and Link Demands
- Use SuppressUnmanagedCodeSecurityAttribute with Caution
- Remoting Demands
- Limit Who Uses Your Code
- No Sensitive Data in XML or Configuration Files
- Review Assemblies That Allow Partial Trust
- Check Managed Wrappers to Unmanaged Code for Correctness
- Issues with Delegates
- Issues with Serialization
- The Role of Isolated Storage
- Disable Tracing and Debugging Before Deploying ASP.NET Applications
- Do Not Issue Verbose Error Information Remotely
- Deserializing Data from Untrusted Sources
- Don’t Tell the Attacker Too Much When You Fail
- Summary
- IV. Special Topics
- 19. Security Testing
- The Role of the Security Tester
- Security Testing Is Different
- Building Security Test Plans from a Threat Model
- Decompose the Application
- Identify the Component Interfaces
- Rank the Interfaces by Potential Vulnerability
- Ascertain the Data Structures Used by Each Interface
- Attacking Applications with STRIDE
- Attacking with Data Mutation
- Before Testing
- Building Tools to Find Flaws
- Testing Sockets-Based Applications
- Testing HTTP-Based Server Applications
- Testing Named Pipes Applications
- Testing COM, DCOM, ActiveX, and RPC Applications
- Testing ActiveX Controls in <OBJECT> tags
- Testing File-Based Applications
- Testing Registry-Based Applications
- Testing Command Line Arguments
- Testing XML Payloads
- Testing SOAP Services
- Testing for Cross-Site Scripting and Script-Injection Bugs
- Testing Clients with Rogue Servers
- Should a User See or Modify That Data?
- Testing with Security Templates
- When You Find a Bug, You’re Not Done!
- Test Code Should Be of Great Quality
- Test the End-to-End Solution
- Determining Attack Surface
- Summary
- 20. Performing a Security Code Review
- 21. Secure Software Installation
- 22. Building Privacy into Your Application
- Malicious vs. Annoying Invasions of Privacy
- Major Privacy Legislation
- Privacy vs. Security
- Building a Privacy Infrastructure
- Designing Privacy-Aware Applications
- Including Privacy in the Development Process
- Exploring Privacy Features
- Summary
- 23. General Good Practices
- Don’t Tell the Attacker Anything
- Service Best Practices
- Don’t Leak Information in Banner Strings
- Be Careful Changing Error Messages in Fixes
- Double-Check Your Error Paths
- Keep It Turned Off!
- Kernel-Mode Mistakes
- Add Security Comments to Code
- Leverage the Operating System
- Don’t Rely on Users Making Good Decisions
- Calling CreateProcess Securely
- Don’t Create Shared/Writable Segments
- Using Impersonation Functions Correctly
- Don’t Write User Files to Program Files
- Don’t Write User Data to HKLM
- Don’t Open Objects for FULL_CONTROL or ALL_ACCESS
- Object Creation Mistakes
- Care and Feeding of CreateFile
- Creating Temporary Files Securely
- Implications of Setup Programs and EFS
- File System Reparse Point Issues
- Client-Side Security Is an Oxymoron
- Samples Are Templates
- Dogfood Your Stuff!
- You Owe It to Your Users If…
- Determining Access Based on an Administrator SID
- Allow Long Passwords
- Be Careful with _alloca
- Don’t Embed Corporate Names
- Move Strings to a Resource DLL
- Application Logging
- Migrate Dangerous C/C++ to Managed Code
- 24. Writing Security Documentation and Error Messages
- 19. Security Testing
- V. Appendixes
- A. Dangerous APIs
- APIs with Buffer Overrun Issues
- strcpy, wcscpy, lstrcpy, _tcscpy, and _mbscpy
- strcat, wcscat, lstrcat, _tcscat, and _mbscat
- strncpy, wcsncpy, _tcsncpy, lstrcpyn, and _mbsnbcpy
- strncat, wcsncat, _tcsncat, and _mbsnbcat
- memcpy and CopyMemory
- sprintf and swprintf
- _snprintf and _snwprintf
- printf family
- strlen, _tcslen, _mbslen, and wcslen
- gets
- scanf("%s",…), _tscanf, and wscanf
- Standard Template Library stream operator (>>)
- MultiByteToWideChar
- _mbsinc, _mbsdec, _mbsncat, _mbsncpy, _mbsnextc, _mbsnset, _mbsrev, _mbsset, _mbsstr, _mbstok, _mbccpy, and _mbslen
- APIs with Name-Squatting Issues
- APIs with Trojaning Issues
- Windows Styles and Control Types
- Impersonation APIs
- APIs with Denial of Service Issues
- Networking API Issues
- Miscellaneous APIs
- APIs with Buffer Overrun Issues
- B. Ridiculous Excuses We’ve Heard
- No one will do that!
- Why would anyone do that?
- We’ve never been attacked.
- We’re secure—we use cryptography.
- We’re secure—we use ACLs.
- We’re secure—we use a firewall.
- We’ve reviewed the code, and there are no security bugs.
- We know it’s the default, but the administrator can turn it off.
- If we don’t run as administrator, stuff breaks.
- But we’ll slip the schedule!
- It’s not exploitable!
- But that’s the way we’ve always done it.
- If only we had better tools….
- C. A Designer’s Security Checklist
- D. A Developer’s Security Checklist
- E. A Tester’s Security Checklist
- F. Annotated Bibliography
- A. Dangerous APIs
- G. About the Author
- About the Authors
- Copyright
About the Authors
Michael Howard, CISSP, is a leading security expert. He is a senior security program manager at Microsoft® and the coauthor of The Software Security Development Lifecycle. Michael has worked on Windows security since 1992 and now focuses on secure design, programming, and testing techniques. He is the consulting editor for the Secure Software Development Series of books by Microsoft Press.
David LeBlanc, Ph.D., is a founding member of the Trustworthy Computing Initiative at Microsoft®. He has been developing solutions for computing security issues since 1992 and has created award-winning tools for assessing network security and uncovering security vulnerabilities. David is a senior developer in the Microsoft Office Trustworthy Computing group.
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.