Week 5 Internet and Web Security Flashcards
what is symmetric encryption
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
REFRESH AND READ 5_9_1 CORS ON IPAD ON GOODNOTES FROM SLIDE 11 ONWARDS
VERY IMPORTANT
asdonasfjsp;
what is the 401 status code
UNAUTHORISED
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
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.
why is http simple access authentication very risky
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.
what do we mean when we say something is cors configured
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.
What is assymetric encryption
.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
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
Assymetric :
. pair of public and private keys
. Alice uses bobs public key to encrypt so only he can decrypt
end to end encryption
End-to-end encryption flow:
- Clear message at sender
- Message encrypted before leaving sender’s device
- Stays encrypted during transmission
- Decrypted only on receiver’s device
- 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
TLS aims
What are the 3 TLS aims:
Authenticity, confidentiality , integrity
Explain AUTHENTICITY aim of TLS
Authentication:
Server side must be authenticated
Client side optionally authenticated
explain CONFIDENTIALITY of TLS
Message only seen at end points ( before encryption on sender side and after decryption on receiver side)
explain INTEGRITY of TLS
Data cannot be modified by attackers without detection during transmission
whats the difference between authentication and authorisation
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.
base 64
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==
explain Basic authentication ( probably best to read and recall)
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
can you use basic authentication with HTTP
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
what is HTTP Digest access authentication
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
example and better explanation of HTTP Digest access authentication weaknesses
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!
long detailed explanation of id token
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
short explanation of id token
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.
Sequence flow of openId connect authentication flow
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
chat gpt generated quiz on openId connect authentication flow
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?
What can origin be extracted from
A URI
origin definition
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)
quiz for origin
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
Same Origin or Not
http://example.com/path1
http://example.com/path2
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.
Same Origin or Not
Compare each URL with: http://example.com:8080/index.html
http://example.com:8080/about
Yes (identical scheme, hostname, port)
Same Origin or Not
Compare each URL with: http://example.com:8080/index.html
https://example.com:8080/index.html
No (different scheme)
Same Origin or Not
Compare each URL with: http://example.com:8080/index.html
http://example.com/index.html
No (different implicit port)
Same Origin or Not
Compare each URL with: http://example.com:8080/index.html
http://sub.example.com:8080/index.html
No (different hostname)
Same Origin or Not
Compare each URL with: http://example.com:8080/index.html
http://example.com:3000/index.html
No (different port)
default http
80
default https
443
How same origin policy protects you rundown
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
Intro to CORS( Cross - orgin Resource Sharing)
Same origin request blocks all requests of different origins
However there are scenarios where we want cross origin access
We use Cors
What is CORS
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 )
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
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
CORS is BROWSER side SECURITY
. Browser makes final decisions on whether to accept or block stuff
