Secure App 6

Here is your Teaching Note, Quiz, and Answer Key for Section 6: Writing Secure Code from the Fundamentals of Secure Application Development course.

🧑‍🏫 Teaching Note – Section 6: Writing Secure Code

🎯 Learning Objectives

By the end of this section, students should be able to:

• Recognize common coding practices that lead to security vulnerabilities.
• Understand and apply language-specific secure coding standards.
• Identify and avoid critical issues like buffer overflows, insecure functions, and race conditions.
• Use compiler warnings and runtime checks effectively.
• Adopt engineering practices like pair programming and TDD for secure code.

🧭 Lesson Plan Outline (60–75 minutes)

1. Warm-Up: Why Coding Errors Are Dangerous (5 min)

• Pose this question: “What’s the most common cause of software security issues?”

  • Expected answer: Coding mistakes.

2. Common Vulnerabilities in Code (15 min)

• Based on the "19 Deadly Sins of Software Security":

  • Buffer Overflows
  • SQL/Command Injection
  • XSS
  • Race Conditions
  • Failing to handle errors

• Use real-world examples (e.g., Heartbleed, Equifax breach).

3. Language-Specific Coding Standards (10 min)

• Introduce:

  • CERT (for C, C++, Java, Perl)
  • OWASP Secure Coding Checklist
  • Microsoft Secure Coding Guidelines

• Emphasize the need for different rules per language.

4. Compiler Warnings & Runtime Checks (10 min)

• Teach why warnings should not be ignored.
• Discuss deprecated functions, unchecked memory allocations, pointer handling.

5. Secure Coding in C/C++ (10 min)

• Stack canaries, memory initialization, integer range checks, function pointer encryption.

6. Secure Engineering Practices (10–15 min)

• Pair programming
• Test-driven development
• Static & dynamic analysis tools
• Emphasize disciplined coding with review checkpoints.

📝 Quiz – Section 6: Writing Secure Code

🧠 Multiple Choice

1. What is the most common cause of software vulnerabilities? A. Poor project management B. Insecure hosting providers C. Coding errors D. Lack of UI validation

2. Which of the following is a secure coding practice in C/C++? A. Ignoring pointer warnings B. Using deprecated gets() function C. Using stack canaries to detect overflows D. Skipping compiler warnings

3. What is the advantage of pair programming in secure coding? A. Faster code compilation B. Real-time peer review reduces bugs C. Less memory usage D. Easier documentation

4. Which of the following is a vulnerability from the “19 Deadly Sins” list? A. Input beautification B. Buffer overflow C. Use of API keys D. Server-side rendering

5. What’s the key benefit of enabling runtime checks in compilers? A. Makes code shorter B. Helps spot bugs during execution C. Speeds up application performance D. Removes the need for QA testing

✅ True/False

1. ___ All compiler warnings can be safely ignored if the code works.
2. ___ Secure coding practices are different for each programming language.
3. ___ Race conditions can be caused by multi-threaded access to shared resources.
4. ___ Stack canaries help detect memory corruption.
5. ___ Using secure functions like fgets() instead of gets() helps prevent vulnerabilities.

✏️ Short Answer

1. Name two coding flaws that cause security vulnerabilities.
2. Why should deprecated functions be avoided?
3. What is a stack canary and how does it help?
4. Why is input validation not enough on its own to ensure secure code?
5. List two engineering practices that help reduce coding-related vulnerabilities.

✅ Answer Key – Section 6 Quiz

Multiple Choice

1. C
2. C
3. B
4. B
5. B

True/False

1. False
2. True
3. True
4. True
5. True

Short Answer – Sample Responses

11.

• Buffer overflow
• SQL injection
• Race condition
• Cross-site scripting (XSS)

12.

They are insecure, not maintained, and often known to be exploitable.

13.

A stack canary is a known value placed between buffer and return address. If overwritten, it signals a buffer overflow attack.

14.

Because attackers may bypass front-end validations—secure code must still validate and sanitize inputs at the back end.

15.

• Test-driven development (TDD)
• Pair programming
• Peer code reviews
• Static analysis tools