Week 5 Internet and Web Security

Question 1

what is symmetric encryption

Answer 1

Symmetric Encryption

.Uses single key for both encryption and decryption
.Both sender and receiver need same key

.Challenge: Securely sharing the key with intended recipient
.Common uses: Encrypting files, secure communication once key is shared

Question 2

REFRESH AND READ 5_9_1 CORS ON IPAD ON GOODNOTES FROM SLIDE 11 ONWARDS

VERY IMPORTANT

Answer 2

asdonasfjsp;

Question 3

what is the 401 status code

Answer 3

UNAUTHORISED

Question 4

why is https more secure than http:

define what http is and talk about why its not secure
define what https and talk about why it is secure

Answer 4

HTTP:

Plain text transmission
Anyone can intercept and read the data
No security protection

HTTPS:

HTTP wrapped in TLS encryption
Creates secure end-to-end connection
Data protected from interception and tampering

This is exactly why modern websites, especially those handling sensitive information like logins or payments, always use HTTPS rather than HTTP.

Question 5

why is http simple access authentication very risky

Answer 5

Credentials (username & password) sent in plain text via HTTP header.
Vulnerable to “man-in-the-middle” attacks due to lack of encryption.
Limitations:

No encryption (unlike HTTPS).
No rate limiting or account lockouts.
High risk if users reuse passwords across services.

Question 6

what do we mean when we say something is cors configured

Answer 6

Flashcard 1: CORS-Configured Server
Definition: A server that enforces Cross-Origin Resource Sharing (CORS) rules by checking the request’s origin and including specific CORS headers in the response.
Behavior:
Accepts or rejects requests based on allowed origins.
Adds headers like Access-Control-Allow-Origin to responses.
Browser enforces CORS policies; unauthorized origins are blocked.

Question 7

What is assymetric encryption

Answer 7

.Each person has their own public-private key pair
.Public key: Used by others to encrypt messages to you (can be freely shared)
.Private key: Only you have it, used to decrypt messages encrypted with your public key
.Sender uses recipient’s public key to encrypt → Only recipient’s private key can decrypt
.Public keys distributed via key servers, certificates, websites, or directories

Challenge: Verifying public key authenticity (solved by certificate authorities)

Example:
Alice sends to Bob → Alice uses Bob’s public key to encrypt → Only Bob’s private key can decrypt

Question 8

Is:
Example:
Alice sends to Bob → Alice uses Bob’s public key to encrypt → Only Bob’s private key can decrypt

An example or symmetric or assymetric encryption

Answer 8

Assymetric :
. pair of public and private keys
. Alice uses bobs public key to encrypt so only he can decrypt

Question 9

end to end encryption

Answer 9

End-to-end encryption flow:

1. Clear message at sender
2. Message encrypted before leaving sender’s device
3. Stays encrypted during transmission
4. Decrypted only on receiver’s device
5. Returns to clear message

Key benefit: Message can’t be read while in transit, even by service providers ( no eavesdroppers , or man in middle)

Common examples: WhatsApp, Signal, ProtonMail

Question 10

TLS aims

Answer 10

What are the 3 TLS aims:
Authenticity, confidentiality , integrity

Question 11

Explain AUTHENTICITY aim of TLS

Answer 11

Authentication:

Server side must be authenticated
Client side optionally authenticated

Question 12

explain CONFIDENTIALITY of TLS

Answer 12

Message only seen at end points ( before encryption on sender side and after decryption on receiver side)

Question 13

explain INTEGRITY of TLS

Answer 13

Data cannot be modified by attackers without detection during transmission

Question 14

whats the difference between authentication and authorisation

Answer 14

Authentication: Confirms the identity of the user (e.g., verifying who they are via username, password, biometrics).

Authorization: Determines what the authenticated user is allowed to do or access.

Question 15

base 64

Answer 15

Explanation for == Padding
If the input had only 1 byte (e.g., M), the binary would be:

01001101

Divided into 6-bit chunks:

010011 01
The last chunk (01) is incomplete, so we add 4 bits of 0 to make it a chunk of 6:

010011 010000

010011 → T [ first chunk of 6]

010000 -> Q

so Far TQ
HOWEVER base 64 output must be a multiple of 4 characters
so we add two == signs

TQ==

Question 16

explain Basic authentication ( probably best to read and recall)

Answer 16

Authorization: Basic dXNlcjpoZWxsbw==
↓
username:password (Base64 encoded)
↓
“user:hello” (when decoded)
Key Points:

Username and password combined with “:” separator
This string gets Base64 encoded
“Basic” prefix tells server it’s Basic Authentication

Base64 is just encoding (not encryption):
Anyone can decode it to see credentials
Like writing a secret in a different alphabet
Not secure on its own

Security:

Base64 is reversible → easy to decode
Must use HTTPS/TLS to encrypt the actual transmission
TLS prevents eavesdropping/man-in-the-middle attacks

Question 17

can you use basic authentication with HTTP

Answer 17

No basic authentication exposes the username and password as in authorisation header it displays
basic (username:password in base 64)

Therefore we can only use it on secure protocols like HTTPS which use TLS to ensure end to end encryption

Question 18

what is HTTP Digest access authentication

Answer 18

client submits a hash
which is created based on :
username:realm:password

hash is not reversible cant derive username and password from it like you could with basic authentication

However it does have weaknesses:
. vulnarable to dictionary attacks ( attacker uses a list of common passwords to create a list of their own hashes and compares each hash to the intercepted hash - > if match they found out the password

. Should be used over secure channel like HTTPS

Question 19

example and better explanation of HTTP Digest access authentication weaknesses

Answer 19

Dictionary Attack on Digest Authentication:

Attacker intercepts the hash sent during authentication
(hash = H1: username:realm:password)
Attacker’s Process:

Has list of common passwords
For each password in list:

Creates hash using same format (username:realm:commonPassword)
Compares with intercepted hash

If hashes match → Original password found!

That’s why:

Need complex passwords (harder to be in dictionary)
Need HTTPS (prevents hash interception)
Not considered strong despite using hashing

Real example:
Intercepted: hash(“user:realm:password123”)
Attacker tries:

hash(“user:realm:password”) - no match
hash(“user:realm:123456”) - no match
hash(“user:realm:password123”) - MATCH! Password found!

Question 20

long detailed explanation of id token

Answer 20

ID Token Technical Overview:

Fundamental Purpose:

Represents successful authentication only
Digital proof that someone completed a login process
Contains the identity claimed during authentication

Generation Process:

Created after successful login at Identity Provider (e.g., Google)
Contains authenticated user’s details (sub, email, name)
Digitally signed by the Identity Provider
JWT format: header.payload.signature

Security Properties:

Proves WHAT identity was authenticated
Cannot verify WHO is actually behind the keyboard
Only as secure as the login process itself
Compromised credentials = compromised ID Token

Question 21

short explanation of id token

Answer 21

ID Token (JWT) In A Nutshell:

It’s a digital “proof of successful login” - nothing more
Created AFTER someone logs in successfully
Contains WHOEVER’S identity was used to log in

Key Point: If Bob has James’s password, Bob gets an ID Token saying he’s James - the token only knows someone used James’s credentials successfully.

Question 22

Sequence flow of openId connect authentication flow

Answer 22

Initial Connection

User connects to app
App redirects to OpenID Provider (OP) login
User authenticates (directly or via 3rd party like Google)

Token Handoff (Security-focused)

OP issues single usage token
Token returned via callback URL (specific endpoint: app.com/auth/callback)
Browser only sees single usage token
App converts single usage token into:

ID token (invisible to browser, server-side only)
Access token

Token Properties

ID token signed by OP (verifies authenticity)
Access token defines authorized scopes/permissions
Access token determines what resources user can access

Access Flow

App grants access
User makes requests
App validates each request against access token’s defined scopes
(e.g., “read_photos” scope allows viewing but not deleting photos)
OP verifies token signatures

Key Security Points:

Callback URL pre-registered with OP
Sensitive tokens kept server-side
Browser limited to single usage token
OP maintains signature verification authority
Access controlled by token-defined permissions

Question 23

chat gpt generated quiz on openId connect authentication flow

Answer 23

Let’s test your understanding, focusing on previous points of confusion:

In the callback process:

What URL does the user return to after authentication?
What exactly is carried in this callback?

About tokens:

Which token does the browser see?
Where is the ID token stored and why?
Who signs the ID token?

For access validation:

How does the app know what resources a user can access?
What determines these permissions?

In the third-party authentication:

Why might this be used?
What’s its role in the overall flow?

Question 24

What can origin be extracted from

Answer 24

A URI

Question 25

origin definition

Answer 25

Origin Definition: Set of common characteristics of a web resource URI containing:

Scheme (protocol)
Hostname (domain/subdomain)
Port

Key Rule: Resources must match ALL three elements to share same origin.
Quick Check Formula:
schema:hostname:port = same origin
Example Matches:

http://example.com:8080/any/path
http://example.com:8080/different/path
(Same origin because identical scheme, hostname, port)

Question 26

quiz for origin

Answer 26

Multiple Choice:

What defines a web origin?
a) Scheme and hostname only
b) Scheme, hostname, and path
c) Scheme, hostname, and port
d) Hostname and port only

Which component is NOT part of origin?
a) Path
b) Scheme
c) Port
d) Hostname

Same Origin or Not?
Compare each URL with: http://example.com:8080/index.html

http://example.com:8080/about
https://example.com:8080/index.html
http://example.com/index.html
http://sub.example.com:8080/index.html
http://example.com:3000/index.html

Question 27

Same Origin or Not

http://example.com/path1
http://example.com/path2

Answer 27

Hint: check scheme , hostname , port if they match
http://example.com/path1
http://example.com/path2

Answer: Same Origin ✅
Explanation: Both share identical scheme (http) and hostname (example.com). Since no port is specified, they default to port 80, making these URIs share the same origin despite different paths.

Question 28

Same Origin or Not
Compare each URL with: http://example.com:8080/index.html

http://example.com:8080/about

Answer 28

Yes (identical scheme, hostname, port)

Question 29

Same Origin or Not
Compare each URL with: http://example.com:8080/index.html

https://example.com:8080/index.html

Answer 29

No (different scheme)

Question 30

Same Origin or Not
Compare each URL with: http://example.com:8080/index.html

http://example.com/index.html

Answer 30

No (different implicit port)

Question 31

Same Origin or Not
Compare each URL with: http://example.com:8080/index.html

http://sub.example.com:8080/index.html

Answer 31

No (different hostname)

Question 32

Same Origin or Not
Compare each URL with: http://example.com:8080/index.html

http://example.com:3000/index.html

Answer 32

No (different port)

Question 33

default http

Answer 33

80

Question 34

default https

Answer 34

443

Question 35

How same origin policy protects you rundown

Answer 35

SUMMARY: Same-Origin Policy Complete Guide

Types of Requests:

A. Direct Browser Requests (User Actions):

ALL HTTP methods allowed (GET, POST, PUT, DELETE)
No origin check needed
Example: Typing URL, clicking links, submitting forms

B. Script-Initiated Requests:

ALL requests must pass Same-Origin check
Includes: XMLHttpRequest, Fetch API, Iframe access
Origin check required regardless of HTTP method

Attack Prevention Example:

Initial Visit:

User on malicious site (www.your-bank.bad-site.com)
Site embeds legitimate bank (www.your-bank.com) in iframe

Attack Attempt:

Script from bad-site.com tries to access iframe content:

javascriptCopyframes.bank_frame.document.getElementById(“balance”).value

Protection:

Browser checks origins
Different origins = Access blocked
Security error returned

Origin Check Process:

Compare script’s location vs target location
Must match: scheme:hostname:port
Any difference = blocked

Question 36

Intro to CORS( Cross - orgin Resource Sharing)

Answer 36

Same origin request blocks all requests of different origins

However there are scenarios where we want cross origin access

We use Cors

Question 37

What is CORS

Answer 37

Cross origin resource sharing -> defines a way browser and server determine if its safe to allow a cross origin request

more secure than purely letting all cross origin requests (for reasons we have discussed previously look at previous flashcards in same origin section )

Question 38

The actual flow of Cors Request and Response and Headers

this is actually a complex request as options is sent first to see if permissions

And then only if permissions allowed we send the actual request

Answer 38

CORS Flow Summary:

Script initiates a request

javascript
// Developer only writes this

fetch(‘https://api.example.com/data’, {
method: ‘POST’,
body: JSON.stringify({data: ‘example’})
})

// behind the scenes starts here

Browser automatically:

Detects it’s cross-origin
Sends OPTIONS request with Origin header
Developer doesn’t write any OPTIONS code
Origin header is automatically set eg : http://origin1.com

Server response includes:

Access-Control-Allow-Origin: http://origin1.com
Confirms if cross-origin request allowed

Only then:

Original POST request is sent
All this security flow happens behind the scenes
Developers only write the actual request code

Question 39

CORS is BROWSER side SECURITY
. Browser makes final decisions on whether to accept or block stuff