|
|
|
|
@ -11,16 +11,17 @@ date: November 21, 2018
|
|
|
|
|
## Security holes are bugs |
|
|
|
|
1. Programmer writes some code |
|
|
|
|
2. Programmer makes a mistake! |
|
|
|
|
- Forgot to check permissions |
|
|
|
|
- Mixed private and public data |
|
|
|
|
- Didn't allocate enough space |
|
|
|
|
- Forgets to check permissions |
|
|
|
|
- Mixes private and public data |
|
|
|
|
- Doesn't allocate enough space |
|
|
|
|
- Reads from malicious input |
|
|
|
|
- ... |
|
|
|
|
3. Attacker exploits the security flaw |
|
|
|
|
|
|
|
|
|
## Programming languages: <br> first line of defense |
|
|
|
|
- Catching errors earlier is better |
|
|
|
|
- Earliest possible time: when program is written |
|
|
|
|
- Easier to reject program than try to protect against it |
|
|
|
|
- Easier to reject program than try to defend against it |
|
|
|
|
|
|
|
|
|
## Design languages <br> to reduce security flaws |
|
|
|
|
- Make it easier for programmer to do right thing |
|
|
|
|
@ -53,7 +54,7 @@ date: November 21, 2018
|
|
|
|
|
- Describe how program "steps" |
|
|
|
|
|
|
|
|
|
## 3. Describe how to check <br> a given program |
|
|
|
|
- Must work *without* running the program |
|
|
|
|
- Ideally: works *without* running the program |
|
|
|
|
- Other desirable features: |
|
|
|
|
- Scales up to large programs |
|
|
|
|
- Runs in a reasonable amount of time |
|
|
|
|
|
