Alice and Bob Learn Secure Coding
Description
Unlock the power of secure coding with this straightforward and approachable guide!
Discover a game-changing resource that caters to developers of all levels with Alice and Bob Learn Secure Coding. With a refreshing approach, the book offers analogies, stories of the characters Alice and Bob, real-life examples, technical explanations and diagrams to break down intricate security concepts into digestible insights that you can apply right away. Explore secure coding in popular languages like Python, Java, JavaScript, and more, while gaining expertise in safeguarding frameworks such as Angular, .Net, and React. Uncover the secrets to combatting vulnerabilities by securing your code from the ground up!
Topics include:
- Secure coding in Python, Java, Javascript, C/C++, SQL, C#, PHP, and more
- Security for popular frameworks, including Angular, Express, React, .Net, and Spring
- Security Best Practices for APIs, Mobile, Web Sockets, Serverless, IOT, and Service Mesh
- Major vulnerability categories, how they happen, the risks, and how to avoid them
- The Secure System Development Life Cycle, in depth
- Threat modeling, testing, and code review
- The agnostic fundamentals of creating secure code that apply to any language or framework
Alice and Bob Learn Secure Coding is designed for a diverse audience, including software developers of all levels, budding security engineers, software architects, and application security professionals. Immerse yourself in practical examples and concrete applications that will deepen your understanding and retention of critical security principles.
Alice and Bob Learn Secure Coding illustrates all the included concepts with easy-to-understand examples and concrete practical applications, furthering the reader's ability to grasp and retain the foundational and advanced topics contained within. Don't miss this opportunity to strengthen your knowledge; let Alice and Bob guide you to a secure and successful coding future.
More details
Other editions
Additional editions
Person
Tanya Jance, aka SheHacksPurple, is the best-selling author of Alice and Bon Learn Application Security and Cards Against AppSec. Over her 28-year IT Career she has won countless awards (including OWASP Lifetime Distinguished Member and Hacker of the Year), spoken all over the planet, and is a prolific blogger. Tanya has trained thousands of software developers and IT security professionals, via her online academies (We Hack Purple and Semgrep Academy), and her live training programs. Having performed counter-terrorism, led security for 52nd Canadian general election, developed or secured countless applications, Tanya Janca is widely considered an international authority on the security of software.
Content
Foreword xxvii
Introduction xxix
Part I General Advice 1
Chapter 1 Introductory Security Fundamentals 3
Assume All Other Systems and Data Are Insecure 3
The CIA Triad 4
Least Privilege 6
Secure Defaults/Paved Roads 8
Assume Breach / Plan For Failure 9
Zero Trust 9
Defense in Depth 10
Supply Chain Security 10
Security by Obscurity 11
Attack Surface Reduction 11
Usable Security 12
Fail Closed/Safe, Then Roll Back 12
Compliance, Laws, and Regulations 12
Security Frameworks 14
Learning from Mistakes and Sharing Those Lessons 16
Backward Compatibility (and Potential Risks It Introduces) 16
Threat Modeling 16
The Difficulty of Patching 17
Retesting Fixes for New Security Bugs 18
Chapter Exercises 19
Chapter 2 Beginning 21
Follow a Secure System Development Life Cycle 21
Use a Modern Framework and All Available Security Features Within 22
Input Validation 23
Output Encoding 26
Examples of Output Encoding 27
HTML Context 28
JavaScript Context 28
Parameterized Queries and ORMs 29
Authentication and Identity 31
Authorization and Access Control 32
Access Control Models 33
Logical Access Control Methods (Implementation) 34
Session Management 34
Secret Management 35
Password Management 37
Communication Security (Cryptography and HTTPS Only) 39
Protecting Sensitive Data 40
Security Headers 43
New Security Header Features 43
Fetch Metadata Request Headers 43
Content Security Policy Header 44
Strict-Dynamic 44
Trusted-Types 44
Security Headers Previously Covered 44
Content-Security-Policy Header 45
HTTP Strict-Transport-Security 45
X-Frame-Options 45
X-Content-Type-Options 45
Permissions Policy 46
Expect-CT 46
Referrer-Policy 46
Public Key Pinning Extension for HTTP (HPKP) 46
X-XSS-Protection 46
More New Headers 46
Same-Origin Policy 47
COEP: Cross-Origin Embedder Policy 47
COOP: Cross-Origin Opener Policy 48
CORP: Cross-Origin Resource Policy 48
CORS: Cross-Origin Resource Sharing 48
CORB: Cross-Origin Read Blocking 49
Secure Cookies 50
Error Handling 51
Chapter Exercises 52
Chapter 3 Improving 55
Database Security 56
Four Perspectives for Protecting Databases 56
File Management 59
File Uploads 61
Your Source Code 62
Memory Management (Buffer, Stack, String, and Integer Overflows) 63
How Do We Avoid Overflows? 64
(De)Serialization 66
Privacy (User/Citizen/Customer/Employee) 67
Errors 69
Logging, Monitoring, and Alerting 72
Fail Closed 73
Locking Resources 73
Enabling Password Managers 74
Cryptographic Practices 75
Strongly Typed Languages 76
Strongly Typed Languages 76
Weakly Typed Programming Languages 77
Domain-Driven Development 78
Memory-Safe Languages 79
Chapter Exercises 80
Chapter 4 Achieving 81
Secure Design 82
How much is "enough" (design) security? 84
Dependency Management and Supply Chain Security 85
Dependency Security 86
Checking If Dependencies Are Safe to Use 87
Supply Chain Security 87
Secure Defaults 90
Secure Defaults for Users 90
Secure Defaults for Developers 92
Readable and Auditable Code 93
Important Functions Happen on Trusted Systems 96
What Is an "Untrusted" System? 96
What Are "Important Functions"? 97
Putting It Together 97
Allowlists versus Blocklists 97
Why Are Block Lists Bad? 98
How Do We Create an Allowlist? 98
Secure Configurations 99
Hostname Validation 100
Reusable Code 100
Safe System Calls 102
Mitigating Circumstances 102
Commenting and Other Documentation 102
Comments 103
Documentation 104
Verification of User Consent 106
Integrity Checks, Code Signing, and Immutable Builds 107
Immutable Builds 108
Avoiding Brute Force 109
Security Controls 110
Handling Elevated Privileges 111
Security Maintenance 112
Repaying Technical Debt 113
Chapter Exercises 114
Summary of Part I 117
Checklist of General Secure Coding Advice 117
Part II Specific Advice 125
Chapter 5 Technology-Specific 127
API Security Best Practices 127
Mobile Application Security Best Practices 134
WebSocket Security Best Practices 137
Serverless Security Best Practices 138
IoT Security Best Practices 140
Chapter Exercises 141
Chapter 6 Popular Programming Languages 143
JavaScript 143
Html/css 148
HTML5, Specifically 149
Python 151
Sql 154
Node.js 157
Java 160
Serialization in Java 164
TypeScript 165
C# 166
Php 170
C/c++ 175
Conclusion 178
Chapter Exercises 179
Chapter 7 Popular Frameworks 181
Web and JavaScript 181
Express 182
React.js 184
Angular 186
jQuery 190
Vue.js 192
Other Frameworks and Libraries 194
.NET (Core) 194
Ruby on Rails 199
Spring and Spring Boot 204
Flask 207
Chapter Exercises 210
Chapter 8 Vulnerability Categories 211
Design Flaws / Logic Flaws 212
How Does This Happen? 213
The Risk 213
Prevention 214
Code Bugs / Implementation Errors 215
How Does This Happen? 215
The Risk 215
Prevention 215
Overflows and Other Memory Issues 216
Overflows 216
Buffer Overreads 217
Invalid Page Faults 217
Use After Free 218
Uninitialized Variables 218
Memory Leaks 218
How Does This Happen? 219
The Risk 219
Prevention 219
Injection: Interpreter and Compiler Issues 220
How Does This Happen? 221
The Risk 221
Prevention 221
Input Issues 222
How Does This Happen? 223
The Risk 223
Prevention 223
Authentication and Identity Issues 223
How Does This Happen? 224
The Risk 224
Prevention 224
Authorization and Access Issues 225
How Does This Happen? 225
Configuration and Implementation Issues 225
How Does This Happen? 226
The Risk 226
Prevention 226
Fraudulent Transactions 227
How Does This Happen? 227
The Risk 227
Prevention 228
Replay Attacks 228
How Does This Happen? 228
The Risk 229
Prevention 229
Crossing Trust Boundaries 229
How Does This Happen? 230
The Risk 230
Prevention 230
File Handling Issues 230
How Does This Happen? 231
The Risk 231
Prevention 231
Object Handling Issues 232
Prominent Features of OOP 232
Deserialization and Other Object Handling Issues 234
How Does This Happen? 234
The Risk 234
Prevention 234
Secrets Management Issues 235
How Does This Happen? 236
The Risk 236
Prevention 236
Race Conditions and Timing Issues 237
How Does This Happen? 237
The Risk 238
Prevention 238
Resource Issues 240
How Does This Happen? 240
The Risk 241
Prevention 241
Falling into an Unknown State 241
How Does This Happen? 242
The Risk 242
Prevention 242
Chapter Exercises 243
Summary of Part II 245
Checklist of Technology-Specific Secure Coding Advice 245
Checklist of Secure Coding Advice for Languages and Frameworks 246
Summary of Vulnerability Issues to Watch For 248
Part III Secure System Development Life Cycle 251
Chapter 9 Requirements 253
Project Kick-Off: Outline of Your Project's Security Activities 253
Project Scheduling and Planning 254
Security Requirements 255
Chapter Exercises 257
Chapter 10 Design 259
Threat Modeling 260
Secure Design Patterns and Concepts 262
Architecture Whiteboarding 263
Examining Data Flows 263
Security User Stories 264
Chapter Exercises 265
Chapter 11 Coding 267
Training 267
Organizations 269
Individuals 270
Code Review 270
First- and Second-Generation Static Analysis Tools 271
Secure Guardrails 272
IDE Plugins and Other Guidance 273
Verifying That Your Dependencies Are Safe (SCA) 274
How Do You Decide Which Dependencies Are Worth Updating or Changing? 274
Finding and Managing Secrets 275
Dynamic Testing (DAST) 276
Chapter Exercises 278
Chapter 12 Testing 279
Test Coverage and Timing 280
Depth Versus Coverage 281
Scanning Your Infrastructure 281
Production or Lower-Level Environments 281
Scoping 282
Timing 282
Manual Testing 284
Automated Testing 286
Fuzzing 287
Interactive Application Security Testing (IAST) 288
Bug Bounty Programs 289
Test Results 290
Actioning Test Results 291
Final Thoughts 293
Chapter Exercises 293
Chapter 13 Release/Deployment 295
Security Events Within the CI/CD 296
Breaking the Build 297
Secret Scanning 298
Static Analysis 298
Dynamic Analysis 298
Software Composition Analysis 299
Linting 299
Infrastructure as Code scanners 299
Securing the CI/CD Pipeline Itself 299
Assuring the Integrity of Your Release 302
Security Release Approval 303
Chapter Exercises 304
Chapter 14 Maintenance 305
Monitoring, Alerting, and Observability 306
Blocking/Shielding 308
Web Application Firewalls (WAFs) 309
Content Delivery Networks (CDNs) 309
Runtime Application Self-Protection (RASP) 310
Virtual Patching 310
API Gateways 310
A Special Note for Data Scientists 311
Continuous Testing 312
Security Incidents 313
Business Continuity and Disaster Recovery Planning 315
Chapter Exercises 317
Chapter 15 Conclusion 319
Good Habits 319
Your Responsibility 322
How Much Is Enough? 323
Using Artificial Intelligence Safely 325
Continuous Learning 327
Becoming a Champion 328
Getting Others on Board 330
Transitioning onto the Security Team 330
Applying for Security Jobs Outside of Your Organization 331
Conclusion 335
Summary of Part III 339
Checklist of Security Activities for Each Phase of the SDLC 339
Appendix A Resources 343
Chapter 1: Introductory Security Fundamentals 343
Chapter 2: Beginning 344
Chapter 3: Improving 345
Chapter 4: Achieving 347
Chapter 5: Technology-Specific 349
Chapter 6: Popular Programming Languages 351
Chapter 7: Popular Frameworks 355
Chapter 8: Vulnerability Categories 357
Chapter 10: Design 359
Chapter 11: Coding 359
Chapter 12: Testing 359
Chapter 13: Release/Deployment 360
Chapter 14: Maintenance 360
Appendix B Answer Keys 361
Chapter 1: Introductory Security Fundamentals 361
Chapter 2: Beginning 363
Chapter 3: Improving 364
Chapter 4: Achieving 365
Chapter 5: Technology-Specific 368
Chapter 8: Vulnerability Categories 370
Chapter 9: Requirements 371
Chapter 11: Coding 372
Chapter 12: Testing 373
Chapter 13: Release/Deployment 374
Chapter 14: Maintenance 375
Index 377
CHAPTER 1
Introductory Security Fundamentals
This chapter will focus on fundamental security concepts, the sorts of things that every security person wishes every other IT professional knew. You may not have a chance to apply all of them in your work, but understanding them can help you create more robust and defensible systems.
Assume All Other Systems and Data Are Insecure
Perhaps the most important lesson in this entire book is learning to stop trusting computer systems, data, and users by default. Human beings, in general, are quite trusting as a species.1 For creating a society with laws, safety, and general order, having most people assume trust from the start is a good thing. It's part of what makes our societal fabric work.
As a result of human beings generally assuming trust, when we design computer systems, we tend to design them in such a way that the systems have an implied trust. What this means is that rather than automatically verifying facts, our computer systems assume they must be true. And this can lead to dire consequences.
COLLEGE COPY CAT
When Alice was in college, she used to save her work files to a shared drive on the network for school. In case her computer ever failed, she knew there would be a backup. In her second year of college, she was preparing a presentation for her software engineering course as part of a class team project. During the class, when her team was going to present the project research, a classmate named Eve2 asked if she could present her own project research first. Alice didn't see anything wrong with this, so she agreed. Eve got up and presented all of Alice's findings as though they were her own! She even used Alice's slide deck and changed the name on the front page to her own. Alice thought, "Are you kidding? How could this happen!?!?!" All of their classmates applauded and were very pleased with Eve. Alice had assumed that saving her files on a shared drive at school meant they would be safe. She never thought a classmate would steal her work and present it as their own or that someone would go rifling through Alice's folders on the shared school drive. Alice had assumed trust, and she had gotten burned.
If we are trying to create a secure system, it is of the utmost importance that we never assume trust. This can mean using multifactor authentication to protect against credential stuffing attacks, double-checking data you receive from the database to ensure that it is the correct format and size, or performing authentication and authorization against an application programming interface (API) calling a serverless app, even though they were both built by your company.
Examples of implied trust:
- Zoning in network design: once someone has entered a zone, they are able to access every other system within that zone without having to cross a firewall or reauthenticate.
- Accepting user input, not validating it, and then using that input to create an SQL query, a URL redirect, or another decision within your system.
- Exposing an API to the internet without putting a gateway in front of it or any other mechanism to perform authentication and authorization, allowing anyone to call it-including bots.
If you only learn one thing from this book, I hope it is this: design every system with as little implied trust as possible. Verify everything, including input, decisions, data, and other system integrations. Perform more than one verification if possible and several if the stakes are high (top-secret information, systems requiring high availability, etc.). Always assume that other systems and data are potentially insecure.
The CIA Triad
The CIA triad are the three things that make up the mandate for most IT Security teams around the world. It is a cybersecurity team's job to guard the confidentiality, integrity, and availability of the systems and data they are charged with protecting. Security teams protect more than just the CIA, but those are often considered the core topics. Throughout this book, we will cover much more, including privacy, safety, authenticity, and layering our defenses.
TOP-SECRET WORK
Bob used to work on a top-secret case for the government of Canada. It was about antiterrorism activities, and that's all he was allowed to say about it. Keeping that sensitive data safe was of the utmost importance, and Bob took all of his training on how to protect that data very seriously. When Bob had his training with the Canadian Centre for Cyber Security, he asked what made the data "top secret" rather than secret or some other classification. The response was, "If that data got out, it could potentially harm Canada as a nation. It could potentially result in hundreds of lost lives and cause various other counterterrorism activities to fail. This information could not only harm those working for the government but also block them from uncovering various plots that could lead to the death of citizens or even, in the worst case, a successful government coup. Your most important task, no matter how complex, onerous, or difficult, is to keep this information from falling into the wrong hands. Guard it, literally, with your life." Although Bob rarely spoke about this work assignment with his friends and family, they were all very aware of how Bob felt about the importance of his work for the Department of Justice.
NOTE
- Confidentiality: the state of keeping or being kept secret or private3
- Integrity: internal consistency or lack of corruption in electronic data3
- Availability: the quality of being able to be used or obtained at any time3
WHEN CRITICAL INFRASTRUCTURE GOES DOWN
In 2022, on July 9, the Rogers telecommunications network went down in Canada.4 Canada has only three major telecommunication companies, and the rest share or rent the lines from the main three. Canadians couldn't pay bills, surf the net, or even call 911 in large parts of the country for several days as a result of this outage. Cybersecurity generally focuses on three things: confidentiality, integrity, and availability (CIA). As you can see, when Rogers went down, it caused a lack of availability for much of the country, and therefore the outage was a security issue. If one human error can disable emergency services for a large part of the country for several days, that system is not secure. Although the outage itself was not caused by a cyber attack, it interfered with one of the CIA triad, and therefore was a security issue. The lack of contingency planning around these systems is also a security issue. This note is not meant as a critique against Rogers; it is a real-world example of how security is a part of quality and also the importance of defense in depth, business continuity planning, and disaster recovery.
Although we have seen the definition of integrity, let's talk a little more about the meaning of that word. Often, when we speak of a person who "has integrity," we mean that you can trust that person: you can rely on them and know they will always make the "right" decision. Integrity is similar for computer systems; when a system and its data have integrity, it means we can use that data to make decisions and know they will be good decisions. This data has already been verified; it is trustworthy.
Now imagine that you are a doctor, and you use a computer to calculate a dosage for medicine based on your patient's weight, height, any medical conditions they have, and various other factors. When you give the patient the medication, you assume it's the correct amount-that the information the computer gives you will help the patient, not harm them. When you do this (trust the output of the system), you are assuming that the system and its data have integrity. Imagine the horror for a doctor if the computer got it wrong and their patient was caused harm. For some systems, the integrity of the data is critical (measuring medicine, for instance), and for others, it's not so important (a recipe for a cake that says one egg versus two-it's not the end of the world). When you are creating a system, it's extremely helpful to know which of the CIA is most important and then to design your systems and tests with that in mind.
Least Privilege
The principle of least privilege (PoLP) refers to an information security concept in which a user is given the minimum levels of access - or permissions - needed to perform their job functions.
- CyberArk5
Although this quote implies that least privilege only applies to users, this is not true; it applies to any person or thing who may have access or privileges, including computer systems, like software or an AI. Least privilege also applies to how long the access is given, as it should only be provided during the time it is required and no longer.
NO MORE ADMIN RIGHTS
Alice remembers her first introduction to the concept of least privilege from the security...
