You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: secure_software_development_fundamentals.md
+13-12Lines changed: 13 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1369,9 +1369,9 @@ First, make sure that you identify all inputs from potentially untrusted users,
1369
1369
1370
1370
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.
1371
1371
1372
-
### Lab: Input Validation Basics Introduction
1372
+
#### Lab: Input Validation Basics Introduction
1373
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.
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
1375
1376
1376
IF a section has a quiz and one or more labs, we'll present the
1377
1377
quiz first. This order is intentional.
@@ -1445,7 +1445,7 @@ Many programs need to validate text fields, but those fields’ rules are not de
1445
1445
1446
1446
#### Lab: Input Validation: A Few Simple Data Types
Labs are optional, but we encourage you to try them.
1450
1450
1451
1451
### Sidequest: Text, Unicode, and Locales
@@ -1578,7 +1578,7 @@ There is far more to regexes. In fact, there is a whole book on just regular exp
1578
1578
1579
1579
#### Lab: Introduction to Regular Expressions
1580
1580
1581
-
🧪 LAB: Please try lab [regex0](https://best.openssf.org/labs/regex0.html), which lets you experiment with simple regex notation.
1581
+
🧪 Lab: Please try lab [regex0](https://best.openssf.org/labs/regex0.html), which lets you experiment with simple regex notation.
1582
1582
Labs are optional, but we encourage you to try them.
1583
1583
1584
1584
### Using Regular Expressions for Text Input Validation
@@ -1659,9 +1659,9 @@ Remember, **^...$** are required to make this an allowlist (the text *must* matc
1659
1659
1660
1660
#### Lab: Using Regular Expressions for Text Input Validation
1661
1661
1662
-
🧪 LAB: Please try lab [regex1](https://best.openssf.org/labs/regex1.html), which lets you experiment using regex notation to validate strings.
1662
+
🧪 Lab: Please try lab [regex1](https://best.openssf.org/labs/regex1.html), which lets you experiment using regex notation to validate strings.
1663
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.
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
1665
1666
1666
Labs are optional, but we encourage you to try them.
1667
1667
@@ -1722,7 +1722,7 @@ Note: ReDoS is often *not* a real vulnerability. Such regexes can *only* be a vu
1722
1722
1723
1723
#### Lab: Countering ReDoS Attacks on Regular Expressions
1724
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.
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
1726
Labs are optional, but we encourage you to try them.
1727
1727
1728
1728
## Input Validation: Beyond Numbers and Text
@@ -2105,7 +2105,7 @@ A cast changes a value’s type (that is what it is *for*), so by itself that is
2105
2105
2106
2106
#### Lab: Avoid Incorrect Conversion or Cast
2107
2107
2108
-
🧪 LAB: Please try lab [conversion](https://best.openssf.org/labs/conversion.html), which lets you experiment in how to counter improper conversion.
2108
+
🧪 Lab: Please try lab [conversion](https://best.openssf.org/labs/conversion.html), which lets you experiment in how to counter improper conversion.
2109
2109
Labs are optional, but we encourage you to try them.
2110
2110
2111
2111
## Processing Data Securely: Undefined Behavior / Memory Safety
@@ -2224,7 +2224,7 @@ Correct. Of course, it is safer to not use memory-unsafe languages in the first
2224
2224
2225
2225
#### Lab: Countering Out-of-Bounds Reads and Writes (Buffer Overflow)
2226
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.
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
2228
Labs are optional, but we encourage you to try them.
2229
2229
2230
2230
### Double-free, Use-after-free, and Missing Release
@@ -2810,7 +2810,7 @@ This is true. Not only is it more efficient, but the operating system shell usua
2810
2810
2811
2811
#### Lab: OS Command (Shell) injection
2812
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.
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
2814
Labs are optional, but we encourage you to try them.
2815
2815
2816
2816
### Other Injection Attacks
@@ -3024,7 +3024,7 @@ Error-handling is a fact of life, but you need to make sure your error handling
3024
3024
3025
3025
#### Lab: Handling Errors
3026
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.
3027
+
🧪 Lab: Please try lab [handling-errors](https://best.openssf.org/labs/handling-errors.html), which lets you experiment in how to counter an OS shell (injection) vulnerability.
3028
3028
Labs are optional, but we encourage you to try them.
3029
3029
3030
3030
### Logging
@@ -3359,7 +3359,8 @@ This is true. CSP does not eliminate all problems, but CSP does let you forbid i
0 commit comments