Tidy up

docs/lectures/security/13_internet_security.md

@@ -1,10 +1,10 @@
 # Internet Security
 
-#### Internet Treat Models
+#### Internet Threat Models
 
-- Different to other treat models:
-  - The attacker isn’t in control of the network
-  - The attacker hasn’t got access to the target’s OS
+- Different to other threat models:
+    - The attacker isn’t in control of the network
+    - The attacker hasn’t got access to the target’s OS
 
 ## Cookies
 
@@ -22,79 +22,81 @@
 - **Persistent** - Expire at a given time
 - **Secure** - Can only be used over `HTTPS`
 - `HTTPOnly` - Inaccessible to `js`
-  - Makes it harder to steal
+    - Makes it harder to steal
 
 ##### Third Party Cookies
 
 - Cookies are associated with the domains that produced them
-  - `amazon.com` cookies don’t go to `google.com`
-- Some websites include request to other domains, such as 3rd party advertisers
-  - These serve cookies *a lot*
-  - This is how advertiser companies know what ads you’ve been served and what adverts you’ve clicked on
+    - `amazon.com` cookies don’t go to `google.com`
+- Some websites include requests to other domains, such as 3rd party advertisers
+    - These serve cookies *a lot*
+    - This is how advertiser companies know what ads you’ve been served and what adverts you’ve clicked on
 
 ### Cookie Vulnerabilities
 
-- How a website uses a cookies is up to the server
+- How a website uses a cookie is up to the server
 - Many create a `SID` to authenticate users, for example to *keep me logged on*
 - Obtaining this cookie - *cookie stealing* - lets you **hijack** their session
-  - `HTTP` Cookies can be stolen simply by monitoring
-  - `HTTPS` will require cross-site scripting attacks or DNS poisoning
+    - `HTTP` Cookies can be stolen simply by monitoring
+    - `HTTPS` will require cross-site scripting attacks or DNS poisoning
 
 #### Cross-site Scripting (XSS)
 
 - A type of *injection attack*, similar in many ways to an SQL injection
 - HTML is read by a browser and is a combination of content and structure
-- If we can inject `html` structures into the content of a website, the browser will simply execute these 
-  - e.g. a `<script>` tag
+- If we can inject `html` structures into the content of a website, the browser will simply execute these
+    - e.g. a `<script>` tag
 
 ##### Reflected XSS
 
 - A malicious URL that inserts an exploit directly into the page returned by a server
 - Consider a 404 page at some address
 - If we embed code into the url
-  - ![1647532522.png](img/1647532522.png)
-  - Modern browsers will throw up a warning
+
+    - ![1647532522.png](img/1647532522.png)
+
+    - Modern browsers will throw up a warning
 
 ##### Persistent XSS
 
 - Even worse, no need to trick people into clicking links
 - Any website that doesn’t properly sanitise `html` tags from user input is vulnerable
 - Blog posts with comment sections are obvious targets
-  - Forums, web comments, shopping reviews
+    - Forums, web comments, shopping reviews
 
 ###### The Samy Worm
 
 - In 2005 Samy Kamkar wrote an XSS-based attack on MySpace
-  - ![1647532776.png](img/1647532776.png)
-  - Fastest spreading virus of all time
+
+    - ![1647532776.png](img/1647532776.png)
+
+    - Fastest spreading virus of all time
 
 ### Preventing XSS
 
-- Wesbites must aggressively escape html characters from *any* user input / output
-  1. Locate all positions in which a website handles untrusted data
-  2. Escape appropriately depending on type of input
-- When you consider all of the things people input on interactive websites, this can be a rela problem
+- Websites must aggressively escape HTML characters from *any* user input / output
+    1. Locate all positions in which a website handles untrusted data
+    2. Escape appropriately depending on type of input
+- When you consider all of the things people input on interactive websites, this can be a real problem
 - You also need to find all of the bizarre obfuscated versions of XSS
 - Use an encoding library, which will handle all of these edge cases
 
 ### Cross site Request Forgery (XSRF)
 
 - When a user puts in a `HTTP` request, they will also send any relevant session cookies
-  - e.g. an `SID` from having logged in
-- If the user has already authenticated, a malicious URl can then perform some action on their account
-  - `http://shop.com/account.php?act=editemail&e=attacker@mail.com`
+    - e.g. an `SID` from having logged in
+- If the user has already authenticated, a malicious URL can then perform some action on their account
+    - `http://shop.com/account.php?act=editemail&e=attacker@mail.com`
 
 #### XSRF in POST
 
 - Most websites use POST, this is little defence
 - The phishing email just points to a convincing website with a malicious form on it
-  - ![1647534757.png](img/1647534757.png)
+
+    - ![1647534757.png](img/1647534757.png)
 
 #### Preventing XSRF
 
-- XSS vulenerabilties make XSRF a lot easier
+- XSS vulnerabilities make XSRF a lot easier
 - Use **synchroniser tokens**
-  - Each website form has a one-time token that the server validates when the form is submitted
-
-
-
+    - Each website form has a one-time token that the server validates when the form is submitted