Secure Programming

Explain Introduction.

Explain The Secure Software Development Lifecycle (SSDLC).

Explain Threat Modeling.

Explain STRIDE.

Every application that runs on a network, every operating system, every firmware image represents a body of code that was written by human beings who made decisions under the…

Those decisions — some deliberate, many inadvertent — produced vulnerabilities that adversaries exploit every day at scale.

The consequences of insecure software extend far beyond inconvenience.

Every application that runs on a network, every operating system, every firmware image represents a body of code that was written by human beings who made decisions under the…

Those decisions — some deliberate, many inadvertent — produced vulnerabilities that adversaries exploit every day at scale.

The consequences of insecure software extend far beyond inconvenience.

The 2017 Equifax breach, which exposed the sensitive personal data of 147 million Americans, was caused by a failure to patch a known Apache Struts vulnerability (CVE-2017-5638).

The traditional Software Development Lifecycle (SDLC) — requirements, design, implementation, testing, deployment, maintenance — becomes a Secure SDLC by integrating security…

Requirements Phase : Security requirements must be explicitly gathered alongside functional requirements.

What data does the application handle?

What are the regulatory requirements (HIPAA, PCI-DSS, GDPR)?

Threat modeling is a structured approach to identifying security threats, their likelihood and impact, and appropriate countermeasures during the design phase.

It answers the question: "What can go wrong with this system?"

Threat Modeling connects to risk, controls, and evidence.

STRIDE is the most widely used threat categorization framework for software systems, developed by Microsoft.

STRIDE connects to risk, controls, and evidence.

STRIDE connects to risk, controls, and evidence.

The DREAD model provides a risk rating framework for prioritizing identified threats: - D amage: How severe is the damage if exploited?

(1-10) - R eproducibility: How reliably can the attack be reproduced?

(1-10) - E xploitability: How much skill/effort is required to exploit?

(1-10) - A ffected users: What percentage of users would be affected?

A buffer overflow occurs when a program writes more data to a buffer (a contiguous block of memory) than it was allocated to hold, overwriting adjacent memory regions.

When the vulnerable function returns, execution jumps to the attacker's payload.

Heap buffer overflows target memory allocated by malloc/new.

They are more complex to exploit but can corrupt heap metadata structures, function pointers, or vtable entries to achieve code execution.

An integer overflow occurs when an arithmetic operation produces a result outside the range that the integer type can represent.

For example, adding 1 to a uint8 t with value 255 yields 0 (wraps around).

Integer Overflow connects to risk, controls, and evidence.

Format string vulnerabilities arise when user-supplied data is passed directly as the format string argument to functions like printf: An attacker providing format specifiers like…

%n writes the number of bytes printed so far to a memory address, potentially enabling arbitrary memory writes.

Format string bugs can lead to information disclosure and remote code execution.

SQL injection (SQLi) remains one of the most prevalent and impactful web vulnerabilities.

It occurs when user-supplied data is incorporated into a SQL query without proper sanitization.

Vulnerable code (Python): Attack : An attacker enters admin' -- as the username (and anything as the password).

The query becomes: The -- comments out the rest of the query, bypassing the password check entirely.

As covered in Chapter 8 from the attacker's perspective, XSS is fundamentally a failure of output encoding.

Safe: htmlspecialchars encodes , ", and ' as HTML entities, preventing script injection.

Cross-Site Scripting (Revisited from a Developer Perspective) connects to risk, controls, and evidence.

A race condition (or TOCTOU — Time Of Check to Time Of Use) vulnerability occurs when a program's behavior depends on the relative timing of events in a concurrent environment,…

Example: A program checks if a file is writable (check), then opens and writes to it (use).

An attacker using a symlink race can replace the target file with a symlink to a sensitive file (e.g., /etc/passwd) between the check and the use, causing the program to overwrite…

In web applications, race conditions can arise in multi-threaded environments where shared state (e.g., session data, balance checks) is not properly synchronized.

Many languages provide mechanisms to serialize (convert to bytes) and deserialize (reconstruct from bytes) complex objects for storage or transmission.

Insecure deserialization occurs when untrusted data is deserialized without validation.

Depending on the language and libraries involved, this can lead to remote code execution, object injection, or data tampering.

Java's native serialization mechanism is particularly notorious — the readObject method can trigger arbitrary code execution if an attacker can supply crafted serialized data.

A use-after-free vulnerability occurs when a program continues to use a memory pointer after the memory it points to has been freed (deallocated).

If an attacker can control what data is placed in the reallocated memory region, they may be able to redirect program execution.

Use-after-free vulnerabilities are among the most common critical memory safety vulnerabilities in C/C++ code and are a primary motivation for the adoption of memory-safe…

All data entering a program from external sources — web forms, API parameters, URL parameters, HTTP headers, file uploads, database data, environment variables — must be treated…

Validation checks that input conforms to the expected format, type, length, and range.

Prefer whitelist (allowlist) validation over blacklist validation: define what is acceptable and reject everything else, rather than trying to enumerate all possible malicious…

Blacklists are almost always incomplete.

As demonstrated in the SQL injection section, parameterized queries (also called prepared statements) prevent SQL injection by separating code from data.

Every modern database library supports them.

There is no legitimate reason to use string concatenation to build SQL queries with user input.

Similarly, use ORM frameworks that handle parameterization automatically, but be aware of their configuration — many ORMs support raw query modes that can reintroduce SQLi if…

Output encoding is the complement to input validation: before including any data in output (HTML, JavaScript, CSS, URL, XML, JSON), encode it appropriately for the output context.

HTML encoding, JavaScript encoding, URL encoding, and CSS encoding all use different character escapes and must be applied contextually.

A string that is safe in an HTML body context may be dangerous in an HTML attribute, JavaScript string, or URL.

Security-sensitive applications must handle errors carefully: - Do not expose internal details (stack traces, database error messages, file paths) to end users in production.

These help attackers understand the system's internals.

- Log sufficient information for forensic investigation (who did what, when, and from where) but do not log sensitive data (passwords, credit card numbers, health information,…

- Use structured logging that can be analyzed by SIEM systems.

A recurring theme in software security: never roll your own cryptography .

Cryptographic implementation is extraordinarily subtle — timing side channels, improper IV handling, padding oracle vulnerabilities, and subtle mathematical errors can completely…

Even expert cryptographers discover implementation flaws in their own code.

Use well-established, actively maintained cryptographic libraries: OpenSSL/BoringSSL/LibreSSL (C), Bouncy Castle (Java), Python's cryptography package (which wraps libsodium or…

Modern applications depend on dozens or hundreds of third-party libraries.

These dependencies have their own vulnerabilities.

Tools include Snyk, OWASP Dependency-Check, GitHub's Dependabot, and Google's OSV-Scanner.

Incorporate SCA into the CI/CD pipeline to catch new vulnerabilities as they are disclosed.

Static Application Security Testing (SAST) tools analyze source code (or compiled bytecode) without executing the program, looking for patterns that indicate security…

They can detect common vulnerabilities like SQL injection, XSS, buffer overflows, use of deprecated functions, and hard-coded credentials.

SAST tools include Semgrep (multi-language, rule-based), Checkmarx, Veracode, SonarQube (open-source tier available), Bandit (Python), and Brakeman (Ruby on Rails).

SAST should be integrated into the IDE (developer gets immediate feedback) and CI/CD pipeline (gates build/merge on security findings).

Introduction

The Secure Software Development Lifecycle (SSDLC)

Threat Modeling

STRIDE

Where Introduction applies.

Where The Secure Software Development Lifecycle (SSDLC) applies.

How the difference changes the security decision.

Identify the asset or process at risk.

Choose a preventive, detective, or corrective control.

Explain what evidence would prove the control is working.

Define one core concept in plain language.

Compare two controls or threats from the week.

Apply one idea to a campus or business system.

Evaluate why a solution might fail in practice.

Collect evidence, not just screenshots.

Explain what the artifact proves.

Connect the proof back to risk and control selection.

Secure Programming

Security is a decision process, not just a tool list.

Use the reading to justify practical choices.