Minor tweaks

Signed-off-by: David A. Wheeler <[email protected]>

Author: david-a-wheeler

secure_software_development_fundamentals.md

@@ -2019,7 +2019,7 @@ Sometimes it is necessary to convert or cast a data value from one type to anoth
 
 A special case, which can happen in some programming languages, is called “type confusion”. Type confusion occurs when the access to a resource occurs using a type that’s incompatible with its original type. This could be considered a silent incorrect conversion. This is easily done in languages like C and C++ using union types, where the same memory region can be expressly defined as allowing multiple types. When using union types, the developer must ensure that only the correct type is used for a given access (read or write).
 
-Type confusion isn’t limited to C and C++, however. Type confusion can happen in any language where the same variable or memory location can be interpreted in more than one way. As noted by MITRE CWE-843, “errors in PHP applications can be triggered by providing array parameters when scalars are expected, or vice versa. Languages such as Perl, which perform automatic conversion of a variable of one type when it is accessed as if it were another type, can also contain these issues.”
+Type confusion isn’t limited to C and C++, however. Type confusion can happen in any language where the same variable or memory location can be interpreted in more than one way. As noted by MITRE for [CWE-843](https://cwe.mitre.org/data/definitions/843.html), “errors in PHP applications can be triggered by providing array parameters when scalars are expected, or vice versa. Languages such as Perl, which perform automatic conversion of a variable of one type when it is accessed as if it were another type, can also contain these issues.”
 
 For our purposes, conversions do not include determining if a value is truthy. In general, programming languages have conditional constructs (such as **if** and **while**) that will produce different results depending on whether or not a condition’s value is truthy. What is truthy is a key design decision when creating a programming language. For example, every value in JavaScript is considered truthy except for a specific list of falsy values (currently **false**, **0**, **-0**, **0n**, **“”**, **null**, **undefined**, and **NaN**). In such languages, **if p** and similar are a shorthand for checking if a value is truthy. This interpretation in conditionals might be considered a conversion from some other type into a boolean type, but such constructs are really just an abbreviated way to determine if a value is truthy, and that is not what we are concerned with here.
 
@@ -3109,7 +3109,7 @@ In some ways, a CSRF attack is the opposite of an XSS attack. XSS exploits the u
 
 A common countermeasure used today in most widely-used web application frameworks is to send a secret user-specific CSRF token in all forms and any other URLs with side-effects, and then check to ensure that the correct secret is included with any request with a side-effect. Since attackers will not know the secret value, the attacker cannot insert a matching CSRF token. Since this is built into almost all widely-used web frameworks today, many applications are automatically protected from CSRF (unless they disable the protection or don't use the framework correctly). You should prefer a web application framework that has a CSRF token mechanism.
 
-Another common countermeasure used today is what are called **SameSite** cookies. Historically, all cookies were sent to a server whenever the user had matching cookies for that server, even when the primary page being displayed is from a different server. For example, a web page on site BB might include a reference to an image on site CC; when the web browser downloaded the image from CC it would send all related cookies. However, this does not really make much sense; in many cases cookies should not be sent if the interaction was caused by an unrelated server. So modern browsers have an optional **SameSite** setting on cookies. If the setting is **Lax** or **Strict**,  a request caused by an attacker on a different server will not cause the cookie (like a session) to be sent. So as long as your session cookies have a **SameSite** setting of **Lax** or **Strict**, CSRF attacks generally don’t work. Even better, modern browsers are working to make **SameSite=Lax** the default. It is best to set **SameSite** to **Lax** or **Strict** yourself, but a secure default is still a good thing.
+Another common countermeasure used today is what are called **SameSite** cookies. Historically, all cookies were sent to a server whenever the user had matching cookies for that server, even when the primary page being displayed was from a different server. For example, a web page on site BB might include a reference to an image on site CC; when the web browser downloaded the image from CC it would send all related cookies. However, this does not really make much sense; in many cases cookies should not be sent if the interaction was caused by an unrelated server. So modern browsers have an optional **SameSite** setting on cookies. If the setting is **Lax** or **Strict**,  a request caused by an attacker on a different server will not cause the cookie (like a session) to be sent. So as long as your session cookies have a **SameSite** setting of **Lax** or **Strict**, CSRF attacks generally don’t work. Even better, modern browsers are working to make **SameSite=Lax** the default. It is best to set **SameSite** to **Lax** or **Strict** yourself, but a secure default is still a good thing.
 
 In short, CSRF vulnerabilities are becoming less common because the industry is moving towards safe defaults. This shows it is *possible* to reduce the likelihood of entire classes of vulnerabilities by designing or modifying systems so that the default is secure. Where possible, build countermeasures into your tools/standards/system so the problem won’t occur. If you are building a new web application, it is much less likely to be a problem, but make sure that your web framework counters it and that you use its mechanisms correctly.
 
@@ -3197,7 +3197,7 @@ The same kind of problem can happen in JavaScript. JavaScript’s “**window.op
 
 Of course, if you can trust that other page, that is not a security problem. So using a target value is often not a problem as long as you are referring to your *own* site. But if you are referring to another site, this may be more of a concern - are you sure you can trust it? Even if you trust your own or another site, it might be unwise to allow this - what happens if someone breaks into that part or that other site? Again, there is the principle of least privilege - we don’t want to give privileges if we don’t need to. This can also be a minor performance problem; page performance may suffer due to use of a shared process.
 
-The simplest solution is to avoid using **target=...** in HTML, and always set **target="_self”** when calling JavaScript **window.open()...** especially for links to user-generated content and external domains. If you decide to use HTML **target=**, also use **rel="noopener noreferrer”**. The “**noopener**” tells the web browser to *not* allow the JavaScript to gain control over the referring window (so **window.opener** won’t give access to it). The ”**noreferrer**” prevents passing on the referrer information to the new tab/window ([*Security Vulnerability and Browser Performance Impact of Target=”_blank”*](https://medium.com/@darrensimio/security-vulnerability-and-browser-performance-impact-of-target-blank-80e5e67db547) by Darren Sim, 2019).
+The simplest solution is to avoid using **target=...** in HTML, and always set **target="_self"** when calling JavaScript **window.open()...** especially for links to user-generated content and external domains. If you decide to use HTML **target=**, also use **rel="noopener noreferrer"**. The “**noopener**” tells the web browser to *not* allow the JavaScript to gain control over the referring window (so **window.opener** won’t give access to it). The ”**noreferrer**” prevents passing on the referrer information to the new tab/window ([*Security Vulnerability and Browser Performance Impact of Target=”_blank”*](https://medium.com/@darrensimio/security-vulnerability-and-browser-performance-impact-of-target-blank-80e5e67db547) by Darren Sim, 2019).
 
 ### Quiz 4.8
 
@@ -4809,7 +4809,7 @@ This means you can use expressions like “∀ X (valid(X) → well_formed(X))
 
 Mathematical statements can be used to model the real world, but do not confuse mathematical statements as being the same as the real world!
 
-In particular, you can easily create mathematical statements that are not what you really mean. For example, natural languages sometimes use “and” and “or” in a way different than what we defined above. This is especially a problem for “or”, which in mathematics and computing is true when both sides are true (aka “inclusive or”), but in natural language it is sometimes implied that only one will be true (aka “exclusive or”). For example, in the phrase “we will go to the movies or a play tonight”, the speaker probably does not mean that we could do *both*. Using mathematics can remove many ambiguities like this, but you will have to decide if that expression is what you *mean*. The time-tested way to counter this problem is to have others review your statements and discuss if that is what was intended.
+In particular, you can easily create mathematical statements that are not what you really mean. For example, natural languages sometimes use “and” and “or” in a way different from what we defined above. This is especially a problem for “or”, which in mathematics and computing is true when both sides are true (aka “inclusive or”), but in natural language it is sometimes implied that only one will be true (aka “exclusive or”). For example, in the phrase “we will go to the movies or a play tonight”, the speaker probably does not mean that we could do *both*. Using mathematics can remove many ambiguities like this, but you will have to decide if that expression is what you *mean*. The time-tested way to counter this problem is to have others review your statements and discuss if that is what was intended.
 
 #### Formal Methods Tools