Skip to content

Commit d396bcf

Browse files
Add more labs, move them after quizzes
This adds more of the labs. Also, I realized that the labs should be *after* the quizzes. The quizzes focus on *recognizing* correct answers, which is easier than *creating* your own. So the more logical order in general is to do a quiz first, then note lab(s), in cases where both are present. Signed-off-by: David A. Wheeler <[email protected]>
1 parent 36bdf1f commit d396bcf

File tree

1 file changed

+55
-9
lines changed

1 file changed

+55
-9
lines changed

secure_software_development_fundamentals.md

Lines changed: 55 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1369,7 +1369,15 @@ First, make sure that you identify all inputs from potentially untrusted users,
13691369

13701370
At each remaining input from potentially untrusted users you need to validate the data that comes in. These input validation checks are a kind of security check, so you need to make sure that these input validation checks are non-bypassable, as we discussed earlier in the design principle *non-bypassability*. **As a reminder:** only trust security checks (including input validation) when they run on an environment you trust. This is especially important for JavaScript programs - since JavaScript can run on web browsers, it is easy to send security checks to the web browser and forget that *attackers* can control their own web browsers. Any input validation checks you do in an untrusted environment cannot be trusted. If you trust your server environment and not the client environment, then all security-relevant checks must be done in the server environment. We discussed this already, but it is important to emphasize because it is such a common and serious problem. Now let’s move on to how to actually validate input.
13711371

1372-
🧪 LAB: This course includes some labs. They're optional, but you're *strongly* encouraged to try them! Please try lab [hello](https://best.openssf.org/labs/hello.html) to see how our labs work.
1372+
### Input Validation Basics Introduction
1373+
1374+
🧪 LAB: This course includes some labs. Labs are optional, but you're *strongly* encouraged to try them! Please try lab [hello](https://best.openssf.org/labs/hello.html) to see how the labs work in this course.
1375+
1376+
IF a section has a quiz and one or more labs, we'll present the
1377+
quiz first. This order is intentional.
1378+
Quizzes help make sure you can *recognize* a correct answer,
1379+
while labs help you *create* a correct answer. Recognizing a correct answer
1380+
can be a first step towards creating your own.
13731381

13741382
### How Do You Validate Input?
13751383

@@ -1423,8 +1431,6 @@ Some input formats are composite structures of a lot of other data. For example,
14231431

14241432
Many programs need to validate text fields, but those fields’ rules are not defined in a pre-existing library. Some tools allow us to easily handle them, but to use them, we need to understand some background. We will first need to discuss more about text, unicode, and locales in general. Then we will discuss text validation in general and the common way of doing so - regular expressions.
14251433

1426-
🧪 LAB: Please try lab [input1](https://best.openssf.org/labs/input1.html).
1427-
14281434
#### Quiz 1.2: Input Validation: A Few Simple Data Types
14291435

14301436
\>\>Select all the good practices for validating an input number from an untrusted source:<<
@@ -1437,6 +1443,11 @@ Many programs need to validate text fields, but those fields’ rules are not de
14371443

14381444
[x] Require that the number be an integer if that is the only expected kind of number.
14391445

1446+
#### Lab: Input Validation: A Few Simple Data Types
1447+
1448+
🧪 LAB: Please try lab [input1](https://best.openssf.org/labs/input1.html).
1449+
Labs are optional, but we encourage you to try them.
1450+
14401451
### Sidequest: Text, Unicode, and Locales
14411452

14421453
[[OPTIONAL]]
@@ -1565,7 +1576,10 @@ You can usually do a case-insensitive match through some option. Make sure you s
15651576

15661577
There is far more to regexes. In fact, there is a whole book on just regular expressions, [*Mastering Regular Expressions, 3rd Edition*](https://www.oreilly.com/library/view/mastering-regular-expressions/0596528124/), by Jeffrey Friedl (2006), and there are many tutorials on regexes such as the [Regular Expressions for Regular Folk](https://refrf.shreyasminocha.me/) tutorial by Shreyas Minocha. But that introduction will get us started, because we are now going to discuss how regexes can be used for input validation.
15671578

1579+
#### Lab: Introduction to Regular Expressions
1580+
15681581
🧪 LAB: Please try lab [regex0](https://best.openssf.org/labs/regex0.html), which lets you experiment with simple regex notation.
1582+
Labs are optional, but we encourage you to try them.
15691583

15701584
### Using Regular Expressions for Text Input Validation
15711585

@@ -1625,10 +1639,6 @@ Almost all regex implementations support *branches* - that is, “**aa|bb|cc**
16251639

16261640
Again, you should know what your software should not accept, and use some of those examples as automated test cases to ensure that your software will correctly reject them. This is especially important with regexes, because it is easy to write a regex that looks fine but allows inputs it wasn’t intended to. This can help you catch, for example, missing anchors or failures to surround branches with parentheses.
16271641

1628-
🧪 LAB: Please try lab [regex1](https://best.openssf.org/labs/regex1.html), which lets you experiment using regex notation to validate strings.
1629-
1630-
🧪 LAB: Please try lab [input2](https://best.openssf.org/labs/input2.html), which lets you experiment in how to use a regex in a real program.
1631-
16321642
#### Quiz 1.4: Using Regular Expressions for Text Input Validation
16331643

16341644
\>\>Which of the following matches only “1 or more lowercase Latin letters” using an extended regular expression (given the POSIX locale)?<<
@@ -1647,6 +1657,14 @@ Remember, **^...$** are required to make this an allowlist (the text *must* matc
16471657

16481658
[Explanation]
16491659

1660+
#### Lab: Using Regular Expressions for Text Input Validation
1661+
1662+
🧪 LAB: Please try lab [regex1](https://best.openssf.org/labs/regex1.html), which lets you experiment using regex notation to validate strings.
1663+
1664+
🧪 LAB: Please try lab [input2](https://best.openssf.org/labs/input2.html), which lets you experiment in how to use a regex in a real program.
1665+
1666+
Labs are optional, but we encourage you to try them.
1667+
16501668
### Countering ReDoS Attacks on Regular Expressions
16511669

16521670
When you add code, there is a risk that the added code has a vulnerability. This is especially true when you add code that is supposed to help keep your software secure, since by definition, problems in that code could lead to a security problem.
@@ -1702,6 +1720,11 @@ Note: ReDoS is often *not* a real vulnerability. Such regexes can *only* be a vu
17021720

17031721
[ ] None of the above
17041722

1723+
#### Lab: Countering ReDoS Attacks on Regular Expressions
1724+
1725+
🧪 LAB: Please try lab [redos](https://best.openssf.org/labs/redos.html), which lets you experiment in how to counter redos attacks in a real program.
1726+
Labs are optional, but we encourage you to try them.
1727+
17051728
## Input Validation: Beyond Numbers and Text
17061729

17071730
### Insecure Deserialization
@@ -2080,6 +2103,11 @@ A cast changes a value’s type (that is what it is *for*), so by itself that is
20802103

20812104
[Explanation]
20822105

2106+
#### Lab: Avoid Incorrect Conversion or Cast
2107+
2108+
🧪 LAB: Please try lab [conversion](https://best.openssf.org/labs/conversion.html), which lets you experiment in how to counter improper conversion.
2109+
Labs are optional, but we encourage you to try them.
2110+
20832111
## Processing Data Securely: Undefined Behavior / Memory Safety
20842112

20852113
### Countering Out-of-Bounds Reads and Writes (Buffer Overflow)
@@ -2194,6 +2222,11 @@ Correct. Of course, it is safer to not use memory-unsafe languages in the first
21942222

21952223
[Explanation]
21962224

2225+
#### Lab: Countering Out-of-Bounds Reads and Writes (Buffer Overflow)
2226+
2227+
🧪 LAB: Please try lab [oob1](https://best.openssf.org/labs/oob1.html), which lets you experiment in how to counter an out-of-bounds vulnerability.
2228+
Labs are optional, but we encourage you to try them.
2229+
21972230
### Double-free, Use-after-free, and Missing Release
21982231

21992232
[Memory-unsafe code]
@@ -2775,6 +2808,11 @@ This is true. Not only is it more efficient, but the operating system shell usua
27752808

27762809
[Explanation]
27772810

2811+
#### Lab: OS Command (Shell) injection
2812+
2813+
🧪 LAB: Please try lab [shell-injection](https://best.openssf.org/labs/shell-injection.html), which lets you experiment in how to counter an OS shell (injection) vulnerability.
2814+
Labs are optional, but we encourage you to try them.
2815+
27782816
### Other Injection Attacks
27792817

27802818
There are many other kinds of injection attacks beyond SQL injection and operating system command injection. There may be a risk of an injection attack any time you are sending data partly controlled by an untrusted user in a format that has metacharacters, is defined as a language, and/or is processed by an interpreter.
@@ -2984,6 +3022,11 @@ Error-handling is a fact of life, but you need to make sure your error handling
29843022

29853023
[x] If an exception is raised all the way to the “top” of a program (e.g., its event loop), you should typically log that exception, and then decide if the program will halt or continue.
29863024

3025+
#### Lab: Handling Errors
3026+
3027+
🧪 LAB: Please try lab [handling-errors](https://best.openssf.org/labs/handing-errors.html), which lets you experiment in how to counter an OS shell (injection) vulnerability.
3028+
Labs are optional, but we encourage you to try them.
3029+
29873030
### Logging
29883031

29893032
The best way to deal with attacks is to prevent them from having any effect. Sadly, as we noted earlier, sometimes attackers get through our prevention measures. In those cases, we need to detect the attack and then recover from it. Detection is vital, because we often won’t know to trigger recovery until we detect a problem.
@@ -3300,8 +3343,6 @@ CSP has various other mechanisms to limit privileges. Another CSP parameter that
33003343

33013344
When you are developing a site it might be wise to go through the CSP specification and try to maximally limit what you ask web browsers to allow. The less you allow, the less attackers can do if you make a mistake. There are other HTTP headers that can help harden a site against attack; in the next unit we will look at a few.
33023345

3303-
🧪 LAB: Please try lab [csp1](https://best.openssf.org/labs/csp1.html).
3304-
33053346
#### Quiz 4.3: Content Security Policy (CSP)
33063347

33073348
\>\>Using a CSP setting that forbids inline scripts, requires that JavaScript only be executed from specific trusted locations, and moving all JavaScript to separate files into those locations can reduce the impact of cross-site scripting (XSS) attacks. True or False?<<
@@ -3316,6 +3357,11 @@ This is true. CSP does not eliminate all problems, but CSP does let you forbid i
33163357

33173358
[Explanation]
33183359

3360+
#### Lab: Content Security Policy (CSP)
3361+
3362+
🧪 LAB: Please try lab [csp1](https://best.openssf.org/labs/csp1.html).
3363+
Labs are optional, but we encourage you to try them.
3364+
33193365
### Other HTTP Hardening Headers
33203366

33213367
[Web application]

0 commit comments

Comments
 (0)