Add the rest of university notes

docs/lectures/security/13_internet_security.md

@@ -0,0 +1,100 @@
+# Internet Security
+
+#### Internet Treat 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
+
+## Cookies
+
+- `HTTP` is a **stateless** protocol
+- Most of what we do online is **stateful**
+- Cookies are small text files used to provide *persistence*
+- Servers can provide cookies during HTTP responses, using `Set-Cookie`
+- Browsers will return any cookies for a given domain in `GET` and `POST` requests
+
+![1647531804.png](img/1647531804.png)
+
+### Types of Cookie
+
+- **Session** - Deleted when the browser exits, contain no expiration date
+- **Persistent** - Expire at a given time
+- **Secure** - Can only be used over `HTTPS`
+- `HTTPOnly` - Inaccessible to `js`
+  - 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
+
+### Cookie Vulnerabilities
+
+- How a website uses a cookies 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
+
+#### 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
+
+##### 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
+
+##### 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
+
+###### 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
+
+### 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
+- 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`
+
+#### 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)
+
+#### Preventing XSRF
+
+- XSS vulenerabilties 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
+
+
+