# 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