Web security updates

web/cookies.md

@@ -56,3 +56,8 @@ Secure session tokens should be random and unpredictable, so an attacker cannot
 It is easy to confuse session tokens and cookies. Session tokens are the values that the browser sends to the server to associate the request with a logged-in user. Cookies are how the browser stores and sends session tokens to the server. Cookies can also be used to save other state, as discussed earlier. In other words, session tokens are a special type of cookie that keep users logged in over many requests and responses.
 
 [^1]: The lack of restriction on the `Path` attribute has caused problems in the past, as cookies are presented to the server and JavaScript as an unordered set of name/value pairs, but is stored internally as name/path/value tuples, so if two cookies with the same name and host but different path are present, both will be presented to the server in unspecified order.
+
+
+## 20.5 Cookie Policy versus Same-Origin Policy
+
+Cookie polices and the same-origin policies have subtle differences. For example, it is possible for two different origins to share cookies. If a cookie is set for domain `berkeley.edu`, then `eecs.berkeley.edu` and `auth.berkeley.edu` can both read and write that cookie, even if they do not have the same origin. This can be used by an attacker: lets say an attacker controls `eecs.berkeley.edu`. They can then set a cookie for `berkeley.edu`, which will be sent to `auth.berkeley.edu` requests by the browser. 

web/csrf.md

@@ -49,7 +49,7 @@ If an attacker tries the attack in the previous section, the malicious form they
 
 ## 21.3. Defense: Referer Validation
 
-Another way to defend against CSRF tokens is to check the Referer[^1] field in the HTTP header. When a browser issues an HTTP request, it includes a Referer header which indicates which URL the request was made from. For example, if a user fills out a form from a legitimate bank website, the Referer header will be set to `bank.com`, but if the user visits the attacker's website and the attacker fills out a form and submits it, the Referer header will be set to `evil.com`. The server can check the Referer header on each request and reject any requests that have untrusted or suspicious Referer headers.
+Another way to defend against CSRF attacks is to check the Referer[^1] field in the HTTP header. When a browser issues an HTTP request, it includes a Referer header which indicates which URL the request was made from. For example, if a user fills out a form from a legitimate bank website, the Referer header will be set to `bank.com`, but if the user visits the attacker's website and the attacker fills out a form and submits it, the Referer header will be set to `evil.com`. The server can check the Referer header on each request and reject any requests that have untrusted or suspicious Referer headers.
 
 Referer validation is a good defense if it is included on every request, but it poses some problems if someone submits a request with the Referer header left blank. If a server accepts requests with blank Referer headers, it may be vulnerable to CSRF attacks, but if a server rejects requests with blank Referer headers, it may reduce functionality for some users.
 
@@ -58,3 +58,7 @@ In practice, Referer headers may be removed by the browser, the operating system
 _Further reading:_ [OWASP Cheat Sheet on CSRF](https://owasp.org/www-community/attacks/csrf)
 
 [^1]: Yes, the "Referer" field represents a roughly three decade old misspelling of referrer. This is a silly example of how "legacy", that is old design decisions, can impact things decades later because it can be very hard to change things
+
+## 21.4. Defense: SameSite Cookie Attribute
+
+A last way to defend against CSRF attacks is to add a flag to cookies that specifies it should be sent only when the domain of the cookie exactly matches the domain of the origin. For example, with this flag, if `evil.com` causes the browser to make a request to `bank.com`, cookies for `bank.com` will not be sent if because the origin domain (`evil.com`) and cookie domain (`bank.com`) are different. Unfortunately, this browser-side defense is not implemented on all browsers, thus is usually only used as a defense-in-depth strategy.

web/intro.md

@@ -24,9 +24,9 @@ Every resource (webpage, image, PDF, etc.) on the web is identified by a URL (Un
   </code>
 </p>
 
-The first mandatory part is the _protocol_, located before in the URL. In the example above, the protocol is <code class="blue">http</code>. The protocol tells your browser how to retrieve the resource. In this class, the only two protocols you need to know are HTTP, which we will cover in the next section, and HTTPS, which is a secure version of HTTP using TLS (refer to the networking unit for more details). Other protocols include `git+ssh://`, which fetches a git archive over an encrypted tunnel using `ssh`, or `ftp://`, which uses the old FTP (File Transfer Protocol) to fetch data.
+The first mandatory part is the _protocol_, also called _scheme_, located before in the URL. In the example above, the protocol is <code style="color: blue">http</code>. The protocol tells your browser how to retrieve the resource. In this class, the only two protocols you need to know are HTTP, which we will cover in the next section, and HTTPS, which is a secure version of HTTP using TLS (refer to the networking unit for more details). Other protocols include `git+ssh://`, which fetches a git archive over an encrypted tunnel using `ssh`, or `ftp://`, which uses the old FTP (File Transfer Protocol) to fetch data.
 
-The second mandatory part is the _location_, located after but before the next forward slash in the URL. In the example above, the location is <code class="green">www.example.com</code>. This tells your browser which web server to contact to retrieve the resource.
+The second mandatory part is the _location_, also called _domain_, located after but before the next forward slash in the URL. In the example above, the location is <code style="color: green">www.example.com</code>. This tells your browser which web server to contact to retrieve the resource.
 
 Optionally, the location may contain an optional _username_, which is followed by an `@` character if present. For example, <code class="green">[email protected]</code> is a location with a username `evanbot`. All locations must include a computer identifier. This is usually a domain name such as <code class="green">www.example.com</code>. Sometimes the location will also include a port number, such as <code class="green">www.example.com:81</code>, to distinguish between different applications running on the same web server. We will discuss ports a bit more when we talk about TCP during the networking section.
 

web/ui-attacks.md

@@ -36,3 +36,12 @@ There are many ways to defend against clickjacking attacks. The general idea is
 **Direct the user's attention to their click**: This can be done by freezing the rest of the screen besides the area directly around the user's cursor, or by highlighting the user's cursor. This will make the user less likely to be fooled by a fake cursor and force them to focus on where their real cursor is pointing. The user's clicks can also be invalidated if the user tries to click outside of a relevant portion of the screen.
 
 **Delay the click**: Force the user to hover over the desired button for some amount of time before allowing the user to click the button. This forces the user to spend some time looking at where they're clicking before they actually perform the click.
+
+## 23.3 Phishing
+
+Phishing is an attack in which the attacker tricks the victim into sending the attacker personal information. In the context of web pages, the attackers exploit the user's inability to distinguish between a legitimate website and a website impersonating the legitimate website. In order to do this, attackers setup fake websites that mimick the UI of the original website. More sophisticated attacks involve:
+
+* Valid certificate: obtain a valid certificate so the browser displays the green lock icon, giving users a false sense of security.
+* Homograph attack: create a malicious URL that looks similar to the legitimate one, often using non-ascii characters. 
+* Browser-in-browser attack: simulates the entire web browser with JavaScript.
+