- 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
The following checklist, available as a softcopy in the Security Templates folder in the book’s companion content, is a minimum set of items a tester should ask herself as she is testing the product. Consider this document to be completed as a sign-off requirement for the application design phase.
|
Check |
Category |
Chapter |
|---|---|---|
|
o |
List of attack points derived from threat model decomposition process |
4 |
|
o |
Comprehensive data mutation tests in place |
19 |
|
o |
Comprehensive SQL and XSS tests in place |
12, 19 |
|
o |
Application tested with SafeDllSearchMode registry setting set to 2 on Windows XP or tested on the default install of Microsoft Windows .NET Server 2003 |
11 |
|
o |
Competitor’s vulnerabilities analyzed to determine whether the issues exist in this product |
3 |
|
o |
Past vulnerabilities in previous versions of product analyzed for root cause |
3 |
|
o |
If the application is not an administrative tool, test that it runs correctly when user has no administrative rights |
7 |
|
o |
If the application is an administrative tool, test that it fails gracefully and early if the user is not an admin |
7 |
|
o |
Application attack surface is as small as possible |
3 |
|
o |
Default install is as secure as possible |
3 |
|
o |
Tested all Safe-for-scripting ActiveX controls methods, properties, and events to verify that all such interfaces are indeed safe to call from script |
16 |
|
o |
Sample code tested for security issues |
23 |
If you learn only one thing from this book, it should be this:
There is simply no substitute for applications that employ secure defaults.
This means building secure, quality software that operates with least privilege, has multiple layers of defense, and has the smallest possible attack surface. You must build software this way because you cannot predict how future attacks will occur.
Do not rely on administrators applying security patches or turning off unused features. They will not do it, or they do not know they have to do it, or, often, they are so overworked that they have no time to do it. As for home users, they usually don’t know how to apply patches or turn off features.
Ignore this advice if you want to stay in "security-update hell."
Finally, you cannot abdicate the security of your product to anyone else. Long gone are the days when security was an art understood by a few; it is now part of everyone’s job to deliver secure software. You can no longer stick your head in the sand.
Ignore this advice at your peril.
-
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.