SDD

University of London CM 2010 Software Design and Development

---

Project maintained by ccy05327 Hosted on GitHub Pages — Theme by mattgraham

Topic 3 Defensive coding, debugging and exception handling

Week 9 Assertion and parameter checking

Learning objectives

• Define what an assertion is in a computer program
• Explain the difference between assertions and logical control flow
• Write assertion code and reason about how and when to enable and disable it

Readings

Opinion 1: Always use assertions

• (PDF) Holzmann, G.J. ‘Assertive testing [reliable code]’, IEEE Software 32(3) 2015, pp.12–15.

Opinion 2: In industry, assertions are often removed in release builds

• (PDF) Clarke, L.A. and D.S. Rosenblum ‘A historical perspective on runtime assertion checking in software development’, SIGSOFT Software Engineering Notes 31(3) 2006, pp.25–37.

For a great discussion of various aspects: What are assertions?

• (PDF) Classic paper: Hoare, C.A.R ‘Assertions: a personal perspective’, IEEE Annals of the History of Computing 25(2) 2003, pp.14–25.
• (PDF) Ariane Rocket explosion: Jazequel, J.-M. and B. Meyer, ‘Design by contract: the lessons of Ariane’, Computer 30(1) 1997, pp.129–30.

Assertions

Assume in runtime assertion where the program is running. Other types of assertions: unit tests, compile-time assertions.

An assertion is a check in your code that evaluates a boolean expression. It checks whether the program is in a desirable state.

int gameScore;
...
assert(gameScore >= 0);

An if statement controls the flow of the program; An assertion checks the state.

What should you do if a run-time assertion fails?

• Terminate the program

  We might not want to terminate the whole program if it’s something multiple users are using at once.

• Print an error

  If writing a library, we can’t predict what it’s been used for hence the error message might not make sense.

• Throw an exception

  A pretty good way to deal with assertion failure. The part of the program calling the code might not be able to handle it.

• Carry on regardless

Assertions & SDD lifecycle

Test that the loop has not iterated more than 10,000 times.

Before devision operation, check you are not dividing by zero.

lifecycle (Simplified version)

• Release build: remove all/dmost assertions from debug build to save runtime (opinionated)

• Debug build

Demonstration of Assertions

• Assertion in C++

  #include <cassert>
  
  int main() {
      double sensorReading = 65537;
      unsigned short storedValue = sensorReading;
      assert(storedValue == sensorReading);
      return 0;
  }
  

• Assertion in Python

  sensorReading = 65000
  storedValue = sensorReading+1
  assert(storedValue == sensorReading)
  

• Assertion in JavaScript

  const assert = require("assert");
  
  let sensorReading = 65500;
  let storedValue = sensorReading+1;
  assert(storedValue == sensorReading);
  

---

Week 10 Secure programming

Learning Objectives

• Explain the wider context of secure programing
• Describe and use basic secure programming techniques
• Give real-world industry examples of secure programming workflows

Reading

(PDF) Classic paper from 1975: Saltzer, J.H. and M. D. Schroeder ‘The protection of information in computer systems’, Proceedings of the IEEE 63(9) 1975, pp.1278–308.

(PDF) David Wheeler’s book is a great resource. It is Unix focused but applicable to all platforms: Wheeler, D.A. Secure programming for Linux and Unix HOWTO (1999).

Some interesting articles can be found in Security and Privacy.

(PDF) For an analysis of software companies’ approach to secure software, read Geer, D. ‘Are companies actually using secure development life cycles?’, Computer 43(6) 2010, pp.12–16.

Links:

• Microsoft SDL practices

• (PDF) Software Assurance Maturity Model

• Building Security in Maturity Model

• Comprehensive, Lightweight Application Security Process (CLASP)/Open Source Foundation for Application Security (OWASP): Introduction to the CLASP process

• OWASP: Top 10 issues for web application security

Secure programming overview

Security goals

• Confidentiality: Who can see? «Read access»
• Integrity: Who can modify and how? «Write access»
• Availability: Can they access it?

Sucure Programming Hit List

• Validate All Input

  Ex. Keyboard presses, files read from disk, data passed to a function, data received over a network.

• Restrict Operations to Buffer Bounds

  Ex. Heartbleed causes buffer bounds (overflow), Wannacry from North Korea, The internet worm had a buffer overflow attack component.

• Follow Good Security Design Principles

  From The protection of information in computer systems

  • Least privilege
  • Economy of mechanism/simplicity
  • Open design
  • Complete mediation: check every access
  • Failsafe defaults
  • Separation of privilege
  • Least common mechanism
  • Psychological acceptability/Easy to use

• Carefully call out to other resources

  Ex. Library routines, databases, external programs.

• Send information back judiciously

  Being careful about what’s been sent back to the users.

  Ex. Passwords being printed out, debug print outs.

The software development lifecycle (SDLC)

…a structure for the various software development activities to be performed within a project.

i.e. test-driven development

Microsoft Security Development Lifecycle (SDL)

…consists of a set of practices that support security assurance and compliance requirements. It helps developers build more secure software by reducing the number and severity of vulnerabilities in software, while reducing development cost.

1. Provide Training
2. Define Security Requirements
3. Define Metrics and Compliance Reporting
4. Perform Threat Modeling
5. Establish Design Requirements
6. Define and Use Cryptography Standards
7. Manage the Security Risk of Using Third-Party Components
1. Inventory
2. Perform security analysis
3. Keep up to date
8. Use Approved Tools
9. Perform Static Analysis Security Testing (SAST)
Looking at the source code (automated tools or human) to evalute problems.
10. Perform Dynamic Analysis Security Testing (DAST)
Test on a running software for security.
11. Perform Penetration Testing
12. Establish a Standard Incident Response Process

Alternatives to MS SDL

• SAMM: an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.

• BSIMM (“bee simm”): a study of existing software security initiatives. By quantifying the practices of many different organizations, we can describe the common ground shared by many as well as the variations that make each unique. It is not a how-to guide, nor a one-size-fits-all prescription, it is a reflection of software security.

• CLASP/OWASP: designed to help software development teams build security into the early stages of existing and new-start software development life cycles in a sturctured, repeatable, and measurable way.

Static analysis in Python (bandit)

• pip install bandit
• Python Script

Testing third-party libraries

1. pip install tornado
2. Locate library
3. Navigate the library location bandit *.py to test all .py files in that library (bandit -r . if the command doesn’t work)
4. bandit -ll *.py to show only medium & high severity (bandit -rll . works)

---

Week 11 Exception handling

Learning Objectives

• Define the terms throw, try and catch
• Differentiate between exceptions, assertions and control flow
• Write exception handling code that can throw and catch exceptions

Different types of errors

• syntax errors
• compile/interpret errors
• link (build) errors (C++): promise a function and called it but didn’t implement it
• non-errors: non-sensical usage i.e. width & height negative inputs
• runtime errors

Exceptions

1. Event that causes suspension of normal program execution

2. Indication that an operation request was not performed successfully

The foundamental idea is to separate detection of an error (which shuold be done in a called function) from the handling of an error (which should be done in the calling function) while ensuring that a detected error cannot be ignored.

Bjarne Stroustrup - Programming: principles and practice using C++, 2014

Assertion

1. logical expression specifying a program state that must exist or a set of conditions that program variables must satisfy at a particular point during program execution.

2. function or macro that complains loudly if a design assumption on which the code is based is not true

Assertion vs. Exception

Exceptions should be used to catch errors, control flow has similar syntax and function, but shouldn’t be used as such.

Try and catch

Try and catch

Try and catch in JavaScript

try {
  verifyUser();
  console.log('After verifyUser');
} catch (ex) {
  console.log('Exception caught');
  console.log('Name: ' + ex.name);
  console.log('Message: ' + ex.message);
}
console.log('I am still running...');

Throw in JavaScript

Exception Handling in JavaScript (code)

Programming exercise

Here is a reference for the built-in errors in JavaScript:

• MDN web docs ‘JavaScript error reference’ (2020)

Can you write an example program that generates one of these errors in JavaScript?

Exercise (code)

---

Week 12 Using a debugger

Learning Objectives

• Explain the key operations that can be carried out with a debugger
• Use debug operations such as stepping and stack tracing to explore a running program
• Use conditional breakpoints and watchpoints to automatically trigger debugger breaks

Intro to Debugger

Debugging is simply the process of removing errors from your code. A debugger is a tool that you can use to inspect your program as it is running.

Using print, console.log, and std::cout are a kind of manual debugger.

Debugger allows dynamic analysis.

Debugging with GDB

• (PDF) The DNU Project Debugger ‘GDB documentation’ (2020)

Debug in C++ (code)

Reading

Here is an advanced article which summarises some of the state of the art work circa 2016 regarding debugging:

(PDF) Wong, W.E., R. Gao, Y. Li, R. Abreu and F. Wotawa ‘A survey on software fault localization’, IEEE Transactions on Software Engineering 42(8) 2016, pp. 707-740.

---