[Intro. to Computer Security Course Note] Ch 11

Posted on 2019-06-24 Edited on 2020-02-25 Views: Word count in article: 5.9k Reading time ≈ 5 mins.

Ch11. Software Security

Many vulnerabilities result from poor programming practices
Consequences from insufficient checking/validation of data and error codes in programs

Insecure interaction between components
- SQL injection
- Cross-site scripting
- Open redirect
Risky resource management
- Classical buffer overflow
- Path traversal
- DOwnload of code without integrity check
Porous(多孔的) defenses
- Missing authentication for critical function
- Missing authorization
- Missing encryption of sensitive data

Software Quality and Reliability
- Concern: accidental failure of a program
- Not the total number of bugs, but how often they are triggered
- Improvement: structured design and testing to identity and eliminate bugs
Software Security
- Attacker targets specific bugs that result in a failure that can be exploited
- Triggered by inputs that differ dramatically from what is usually expected
- Unlikely to be identified by common testing approaches

The process of designing and implementing software: continue to function even when under attack
Software written using this process
- Detect erroneous conditions resulting from some attack
- Either continue executing safety, or fail gracefully
Key rule: never assume anything
- Check all assumptions and handle any possible error states

Typical programmers	Defensive Programming
Attention on the steps needed for success - Follow the normal flow of execution of the program - But __not consider every potential point of failure__ Often make assumptions: type of inputs and environment	The assumptions need to be validated by the program __All potential failures handled gracefully and safely__ But, increase codes and time spent
When changes are required - Focus on the cahnges required and __what needs to be achieved__	Must carefully check any assumptions made Check and handle all possible errors Carefully check any interactions with existing code

Recent years have been increasing efforts to improve secure software development process
- Software Assurance Forum for Excellence in Code (SAFECode)
  - Outlining industry best practices for software assurance
  - Providing practical advice for secure software development

Incorrect handling is one of the most common failings
Input is any source of data from outside and whose value is not explicitly known by the programmer
All sources of input data must be identified
Explicitly validate assumptions on size and type of values before use
Two key areas of concern: size and interpretation

Programmers often make assumptions: maximum expected size of input
- 有可能會導致 buffer overflows
Testing may not identify the vulnerability
- 測資不夠完整
Safe programming practices
Safe coding regards any input as dangerous

Program input may be binary or textual
- Binary data: depends on encoding and is usually app-specific
Failure to validate may result in an exploitable vulnerability

Input provided to a program by one user that is subsequently output to another user
- Assumption: all content from one site is equally trusted and hence is permitted to interact with other content from that site
- Attacks exploit this assumption and attempt to bypass the browser’s security checks
Most common variant: XSS reflection

Input data should be compared against what is wanted
- using regular expression
- Whitelisting (more secure)
Alternative is to compare the input data with known dangerous values
- Blacklisting

Canonicalization: transforming input data into a single, standard, minimal representation
- Once this is done the input data can be compared with a single representation of acceptable input values

Major issue of input texting: very large range of inputs
Fuzzing: a software testing technique: using randomly generated data as inputs to a program
- Simplicity and freedom from assumption
- Very low cost of generating large numbers of tests
Input can be randomly generated
Conceptually very simple, but identifying only simple types of faults
- Only triggered by a small number of very specific input values

Key issues
- Correct algorithm implementation, machine instructions
- Valid manipulate of data

Largely ignored by most programmers
- Assumption: 反正 compiler 會處理好
Malicious compiler programmer
- Including instructions in the compiler to emit additional code
Countermeasure:
- 檢查檢查再檢查(source 跟 machine code)

All data on a computer are stored as groups of binary bits
Different languages provide varying capabilities for restriction and validating interpretation of data in variables
Correct use of memory
- Issue: allocation and management of dynamic memory storage (heap)

In general, programs do not run in isolation on most computer systems

Environment variables
- 沒辦法透過 reset PATH variable 解決
  - PATH="/sib:/bin:/usr/sbin:/usr/bin"
  - 把 IFS environment variable 改調就可以繞過
- Generally, writing secure, privileged shell scripts is very difficult
- Dynamic linking of libraries may be vulnerable
  - Library injection (LD_LIBRARY_PATH)
  - Solution: using a statically linked executable or blocking the use of this env variable when the program executed runs with different privileges
Using appropriate, least privileges
- Root/Administrator privileges
  - Major attack target
  - Good design partitions complex programs in smaller modules with needed privileges
    - A greater degree of isolation between components
    - Fewer consequences of a security breach in one component
    - Easier to test and verify
Systems calls and standard library functions
- The programs may not perform as expected
  - Incorrect assumptions made for the operations of the system calls and standard library functions
Preventing race conditions with shared system resources
- Need suitable synchronization mechanisms
  - e.g., lock
- Lockfile
Safe temporary file use
- Secure temporary file creation and use requires the use of random names and atomic operation
  - :+1: mkstemp()
  - :-1: ~~tmpfile(), tmpnam(), tempnam()~~
Interacting with other programs