Authorization and Session magic
COMP6443 : Topic 2(Week 3)
COMP6443 – Week 3 – Injection
A NOTE ON ETHICS / LEGALITY
UNSW hosting this course is an extremely important step forward.
We expect a high standard of professionalism from you, meaning:
Respect the property of others and the university
Always abide by the law and university regulations
Be considerate of others to ensure everyone has an equal learning experience
Always check that you have written permission before performing a security test on a system
Always err on the side of caution. If you are unsure about anything ask one of the course staff!
COMP6443 – Week 3 – Injection
“NOT-A-HOMEWORK”
5f4dcc3b5aa765d61d8327deb882cf99
COMP6443 – Week 3 – Injection
HTTP vs HTTPs
COMP6443 – Week 3 – Injection
HTTP
Client opens a TCP connection to the Server
Client and server now have a bidirectional communication stream
Requests and responses sent over this channel
Server
Client
TCP Connection
COMP6443 – Week 3 – Injection
The Problem with HTTP
The requests and responses are sent in cleartext
A malicious party (Man in the Middle) in the path of the requests/responses can read and even modify them
This could be:
A router routing the packet
An attacker on the client’s local network
Server
Client
COMP6443 – Week 3 – Injection
HTTPS
Transport Layer Security (TLS) implemented on top of TCP connection
Client and server now have an encrypted communication stream
TLS was previously known as Secure Sockets Layer (SSL)
Server
Client
TLS
TCP Connection
COMP6443 – Week 3 – Injection
HTTPS
But how do we know the server is the one we intend to connect to?
During the TLS Handshake, the server sends a certificate indicating that it has control of the intended domain
The browser (client) verifies the certificate, showing a privacy warning if it looks sus
COMP6443 – Week 3 – Injection
How do certificates work?
A certificate authority verifies that a server has control of a domain
The CA issues the server a public key certificate and corresponding private key
CAs themselves may be signed by another CA, resulting in a “certificate chain” with the root certificate authority at the top
Operating Systems come loaded with a set of trusted root CAs
COMP6443 – Week 3 – Injection
Can HTTPS be MiTM’d?
A malicious attacker can sit between client/server as a proxy
However, it will not be able to present a certificate signed by a trusted CA
Best it can do is present a “self-signed” certificate, which will result in a privacy warning
Server
Proxy
TLS
TCP Connection
Client
TLS
TCP Connection
COMP6443 – Week 3 – Injection
COMP6443 – Week 3 – Injection
How to be secure?
Don’t serve any content over HTTP, redirect to HTTPs
HOWEVER, this is still problematic as the initial HTTP request is still susceptible to MiTM
Server
Proxy
TLS
TCP Connection
Client
TCP Connection
COMP6443 – Week 3 – Injection
OVERVIEW
Authentication → Session Management → Access Control
(Authorisation)
Is the user
who they claim
to be? Is it still
that user? Is the user
allowed to access this thing?
COMP6443 – Week 3 – Injection
SESSION MANAGEMENT in 1999
GET /bestcms.php?page=supersecretpls&sessionid=123 HTTP/1.0
Host: www.lol.com
Cookie: username=uid0123456
Cookie: usertype=admin
CLIENT
COMP6443 – Week 3 – Injection
SESSION MANAGEMENT in 2021
GET /1 HTTP/1.1
Host: www.lol.com
Cookie: SESSIONID=1234567890
I recognize this SESSIONID. You are user ABCD
You have 1 item in your cart, item XYZ
You are not currently logged in.
SERVER
CLIENT
COMP6443 – Week 3 – Injection
ANATOMY OF A COOKIE
The main way we store session information is in a cookie.
Server → Client
Set-Cookie: SSID=abcdef; Domain=lol.com; Expires=Mon, 20 Jan 2020 20:20:20 GMT; Secure; HttpOnly
name=value the data to store
Domain specifies the (sub)domain that the cookie belongs to
Expires date when the cookie should be deleted
Secure only send the cookie over secure connections (i.e. HTTPS)
HttpOnly disable access to the cookie from JavaScript
Client → Server
Cookie: country=aus; SSID=abcdef
COMP6443 – Week 3 – Injection
ATTACKING SESSIONS
Session Creation
How are sessions created? Can I fake my own session?
Can I attack the PRNG, and generate my own cookie?
Can I “fixate” a session?
Session Handling / Transfer / Usage
Can I steal the cookie through XSS (No “HttpOnly” flag?)
Can I steal the cookie through redirecting to HTTPS.
What information does the site trust the user to provide?
Session Cleanup
What happens when I click “log out”?
Under what conditions is a session actually destroyed? What happens then?
Do sessions time out correctly?
COMP6443 – Week 3 – Injection
Authentication → Session Management → Access Control(Authorization)
Is the user
who they claim
to be? Is it still
that user? Is the user
allowed to access this thing?
COMP6443 – Week 3 – Injection
ACCESS CONTROL TYPES
DAC (NTFS)
RuleBAC and RoleBAC (Attribute)
Parameter-based
COMP6443 – Week 3 – Injection
ON /admin AND OTHER THINGS…
Your user context is enough to get your ssh privkey.
COMP6443 – Week 3 – Injection
TYPES OF (WEB) ACCESS CONTROL
Security through obscurity
One-off access control
Rule-based access control
COMP6443 – Week 3 – Injection
RBAC: HORIZONTAL vs VERTICAL
Horizontal access control is making sure one user can’t access a different user’s data without permission
http://bank.com/statement.php?user_id=12078
Vertical access control is making sure only administrative users can access administrative content
Attacking vertical access control is commonly known as privilege escalation
http://bank.com/admin.php
COMP6443 – Week 3 – Injection
DEMO ROLE BASED ACCESS CONTROL DEMO
ATTACKING ACCESS CONTROL
METHOD 1: BYPASS ENTIRELY
www.website.com
shop.website.com
blog.website.com
stage.website.com
db.website.com
api.website.com
dev.website.com
backup-syd.website.com
archive.website.com
s3 Buckets
github
pastebin
third party providers
mobile applications
analytics
etc etc…
COMP6443 – Week 3 – Injection
ATTACKING ACCESS CONTROL
METHOD 1.5: ROBOTS.TXT
COMP6443 – Week 3 – Injection
ATTACKING ACCESS CONTROL
METHOD 2: COPY LEGITIMATE USERS
COMP6443 – Week 3 – Injection
ATTACKING ACCESS CONTROL
METHOD 3: ACTUAL TESTING
How does the application know what user role I am?
Are checks applied consistently throughout the application?
When a check fails, what happens?
What aspects of this information can I control?
Can I impersonate another user, or role?
What about content which has zero access control?
CYBER SUCCESS
COMP6443 – Week 3 – Injection
TOWARDS BETTER ACCESS CONTROL
GET /statement.php?user_id=12078 HTTP/1.1
Host: www.bank.com
Cookie: SESSIONID=…
CLIENT
Is this a valid, authenticated session?
Does this type of user have to access the ‘view statement’ functionality?
Does this user have permission to view user 12078’s bank statement?
SERVER
HTTP/1.1 302 Found
Location: /login.php
NO
HTTP/1.1 403 Forbidden
HTTP/1.1 200 OK
…
YES
COMP6443 – Week 3 – Injection
CLIENT-SIDE ACCESS CONTROL
User Identity & Trust
Cookies
Content Integrity
HTTP/HTTPS
Mixed Content
HTTPS Downgrade
XSS
Phishing Websites
Phishing / CSRF
Insecure Sites
Plugins
Compromises of Privacy
(e.g. friends list)
COMP6443 – Week 3 – Injection
DEMO ACCESS CONTROL DEMO
THE WEAKEST LINK
COMP6443 – Week 3 – Injection
HOW TO PROTECT?
2FA
COMP6443 – Week 3 – Injection
2FA
SMS
Mobile app
Key generator
Fingerprint
Channel-based
Location-based
Biometric
COMP6443 – Week 3 – Injection
OAUTH
Open id – Authentication Protocol
Oauth – Authorization Framework(Oauth 1.0 & 2.0)
OpenID Connect – built on top of Oauth 2.0
4 Types of Oauth grants:
Authorization Grant
Implicit Grant
Resource Owner Credentials
Client Credentials
COMP6443 – Week 3 – Injection
OAUTH
https://www.oauth.com/playground/index.html
COMP6443 – Week 3 – Injection
DEMO
OAUTH
https://oauth.tools/
COMP6443 – Week 3 – Injection
[DEFENSIVE] SECURING YOUR SESSIONS
Minimize your attack surface
Your session should be managed on the server side where possible, using a single session token.
Mostly mechanical fixes
Don’t let people steal your tokens (URLs, HTTP, etc)
Don’t let people re-use tokens (expire them properly, log out)
Don’t let people generate tokens (secure PRNG, avoid rolling your own crypto, don’t allow users to supply tokens).
Attention to detail is key.
COMP6443 – Week 3 – Injection
READING MATERIAL (REFERENCE)
OAuth2 Simplified
https://aaronparecki.com/oauth-2-simplified/
What the heck is Oauth
How Anand hacked Tinder
https://medium.com/free-code-camp/hacking-tinder-accounts-using-facebook-accountkit-d5cc813340d1
COMP6443 – Week 3 – Injection
WEEK 2-3 ASSESSMENT
Hash collisions
Don’t forget about automation!
Don’t forget about writing a report!!
Please call out if you get stuck.
Support one another, your tutors are here to help!
COMP6443 – Week 3 – Injection
questions? slack / email / come talk to us
THANKS FOR LISTENING TO US RANT!
COMP6443 – Week 3 – Injection