- 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
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.