Home / MAD1 / Week 9

Week 9 · Security: authentication, sessions, tokens and attacks

The one-minute story

By the end of this week you can:

• explain authentication vs authorisation, and RBAC vs ABAC;
• store and check passwords safely with generate_password_hash and check_password_hash;
• explain and build session-based login with cookies, Flask session and Flask-Login (login_user, @login_required, roles);
• name and prevent CSRF, XSS and SQL injection;
• explain HTTPS/TLS, secrets in environment variables, input validation, rate limiting, token authentication and least privilege;
• predict the output of Flask login/session snippets and use a security checklist for your project.

Words you need

Idea 1: Threats and the two big questions

The OWASP Top 10 is the well-known list of the most common web application weaknesses. You do not need to memorise it; know the family: broken access control, cryptographic failures (plain-text passwords, no HTTPS), injection (SQL, XSS), insecure design, security misconfiguration (debug mode on, default passwords), vulnerable components, authentication failures, logging failures. Attacks come from the browser side (the user, or a script in their page) and from the network (someone reading the wire).

Access control models.

Real paper answers: "a forum unlocks images once a user makes more than 25 posts" is ABAC; "access by job role in an organisation" is RBAC; "grants access by department, job title or current location" is ABAC.

HTTP authentication schemes (a real match-the-column):

Do not mix: base64 can be decoded by anyone; a hash cannot be reversed; encryption can be reversed with a key.

Idea 2: Passwords: hash, salt, never store plain text

If you store passwords as text, anyone who reads your database (a leak, a backup, a curious admin) learns every password, and people reuse passwords. So store only a hash.

Why not encryption? Encryption can be reversed by whoever holds the key, and the key sits on the same server. A hash cannot be reversed: you hash what the user types at login and compare the two hashes.

Why a salt? The same password always gives the same hash, so an attacker can precompute a huge table of hashes of common passwords (a rainbow table) and look yours up. A salt is random data added before hashing, stored with the hash, so two users with the same password get different hashes and precomputed tables are useless. Good password hashes (bcrypt, scrypt, PBKDF2, Argon2) are also deliberately slow, to make guessing expensive. A plain fast hash such as SHA-256 on its own is a poor password hash.

from werkzeug.security import generate_password_hash, check_password_hash
h1 = generate_password_hash("secret")
h2 = generate_password_hash("secret")
print(h1 == h2)                          # False (different random salts)
print(check_password_hash(h1, "secret")) # True
print(check_password_hash(h1, "Secret")) # False
print(h1[:12], len(h1))                  # scrypt:32768:8:1$...  (length 162 on our machine)

We ran it. The stored string contains the method, its settings, the salt and the hash, so check_password_hash needs only the stored string and the typed password. Older Werkzeug versions start with pbkdf2:sha256:...; both are fine. bcrypt (a separate library) works the same way: bcrypt.hashpw(pw, bcrypt.gensalt()) and bcrypt.checkpw(pw, hash).

# register
user = User(name=name, pw=generate_password_hash(password))   # store the HASH
db.session.add(user); db.session.commit()

# login
user = User.query.filter_by(name=name).first()
if user and check_password_hash(user.pw, password):
    login_user(user)
else:
    return "bad credentials", 401        # same message for 'no such user' and 'wrong password'

for vu in valid_users:
    if vu["uid"] == args["uid"] and vu["pwd"] == args["pwd"]:
        return "You are authorized!!"
    else:
        return "You are unauthorized!!"      # else is INSIDE the loop

Idea 3: Cookies and sessions

HTTP is stateless: each request is separate. To "remember" a user, the server gives the browser a session id in a cookie; the browser sends it back every time.

Server response:  Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax
Next request:     Cookie: session=abc123

Both statements in a real question were true: cookies let a web app recognise users, and they can hold login data, language, location and similar information.

Flask's session. Flask keeps the session in the cookie itself, as a signed (not encrypted) value. The signature uses SECRET_KEY, so the user cannot change it without detection, but the user can read it. We decoded one: the cookie held {"role":"general","user":"a"} in readable base64. So: never store secrets in session, and keep the SECRET_KEY secret. Setting SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SECURE, SESSION_COOKIE_SAMESITE configures the flags.

app.config['SECRET_KEY'] = "yekterces"

@app.route('/login')
def log_in():
    user = request.args['user']
    role = request.args['role'] if 'role' in request.args else 'general'
    session['user'], session['role'] = user, role
    return "Logged in successfully!"

@app.route('/home')
def land():
    if 'user' in session:
        if session['role'] == 'admin':
            return f"Welcome {session['user']}"
        return abort(401)
    return abort(404)

@app.route('/logout')
def log_out():
    session.pop('user', None); session.pop('role', None)
    return "Logged out sucessfully!"

Session memory arithmetic. A server-side session store with 1.5 million active sessions of 4 KB each needs 1.5 million x 4 KB = 6 GB of RAM (this exact calculation appeared in a paper; see week 7). It also shows why server sessions need a shared store (Redis) once you scale out.

Idea 4: Flask-Login and roles

Flask-Login manages "who is logged in" for you. Four ingredients:

from flask_login import LoginManager, UserMixin, login_user, logout_user, login_required, current_user

login_manager = LoginManager(app)
login_manager.login_view = "login"           # where to send anonymous users

class User(UserMixin, db.Model):             # UserMixin adds is_authenticated etc.
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String, unique=True)
    pw = db.Column(db.String)
    role = db.Column(db.String, default="user")

@login_manager.user_loader
def load_user(user_id):                      # called on each request with the id from the session
    return db.session.get(User, int(user_id))

@app.route("/login", methods=["GET", "POST"])
def login():
    if request.method == "POST":
        u = User.query.filter_by(name=request.form["name"]).first()
        if u and check_password_hash(u.pw, request.form["pw"]):
            login_user(u)                    # the USER OBJECT, not user.id, not user.name
            return redirect("/dash")
        return "bad credentials", 401
    return render_template("login.html")

@app.route("/dash")
@login_required                              # anonymous users are redirected to the login page
def dash():
    return "Welcome " + current_user.name

@app.route("/logout")
def logout():
    logout_user(); return "bye"

We ran all of this with the test client. Observed: anonymous /dash gives a 302 redirect to /login?next=%2Fdash (not 404, not 403); a wrong password gives 401; a right one gives a 302 to /dash and a session=... cookie; then /dash returns Welcome b. current_user is the logged-in User object (an anonymous placeholder if nobody is logged in).

Two real questions here: the correct registration call is login_user(user) (the object), and a real snippet that called login_user(u1) for Rose then logout_user() printed, in order, Rose logged in, current user is Rose, logged out when visited as /, /home, /logout.

Roles (RBAC). With Flask-Security you attach roles to users and write @roles_required('admin') (all roles needed) or @roles_accepted('admin', 'editor') (any one). With plain Flask-Login you can write the decorator yourself:

def roles_required(*roles):
    def deco(fn):
        @wraps(fn)
        @login_required
        def inner(*a, **k):
            if current_user.role not in roles:
                return "forbidden", 403          # authenticated but not authorised
            return fn(*a, **k)
        return inner
    return deco

@app.route("/admin")
@roles_required("admin")
def admin(): return "admin area"

Tested: user b (role user) gets 403 on /admin; user a (role admin) gets admin area. A user can have many roles; model it with a many-to-many table (roles in a real paper are a Role table with a relationship back to User).

Idea 5: CSRF, XSS and SQL injection

CSRF (cross-site request forgery)

You are logged in to your bank. In another tab you open a hostile page that contains a hidden form posting to bank.com/transfer. Your browser attaches your cookie automatically, so the bank thinks you sent it. Defences:

• CSRF token: a random secret value put in each form (<input type="hidden" name="csrf" ...>) and kept in the session. The server accepts a POST only if the submitted token equals the session's. The hostile page cannot read your page, so it cannot know the token.
• SameSite cookies, and never change data with GET.
• Flask-WTF does this for you (CSRFProtect(app) and {{ form.csrf_token }}). A manual version we tested:

def token():
    if "csrf" not in session: session["csrf"] = secrets.token_hex(16)
    return session["csrf"]

@app.post("/pay")
def pay():
    if request.form.get("csrf") != session.get("csrf"): abort(403)
    return "paid"

Result: no token gives 403, a wrong token gives 403, the right token gives paid.

XSS (cross-site scripting)

If user-written text is placed into a page as HTML, an attacker's script runs in the victim's browser (it can steal data, act as the user). Defence: escape output. Jinja autoescape (on for .html templates) turns < into <:

render_template_string("<p>{{ x }}</p>", x="<script>alert(1)</script>")
#  <p>&lt;script&gt;alert(1)&lt;/script&gt;</p>        (safe: shown as text)
render_template_string("<p>{{ x|safe }}</p>", x="<script>alert(1)</script>")
#  <p><script>alert(1)</script></p>                    (dangerous: runs)

Never use |safe or Markup() on user input. On the JS side use textContent, not innerHTML (week 8). HttpOnly cookies and a Content-Security-Policy header limit the damage.

SQL injection

If you build SQL by gluing strings, the user's input can change the meaning of the query. We ran it:

name = "asha"; pw = "' OR '1'='1"
q = f"select * from u where name='{name}' and pw='{pw}'"
# select * from u where name='asha' and pw='' OR '1'='1'      -> returns the row: login bypassed!

Another payload, asha' --, turns the rest of the line into a comment. Fix: parameterised queries, where the database receives the SQL and the values separately, so values are always data, never code:

cur.execute("select * from u where name=? and pw=?", (name, pw))   # returned [] for the same attack

The ORM is safe by default: User.query.filter_by(name=n) and User.name == n always bind parameters (our attack string returned no user). It becomes unsafe again if you build raw SQL with f-strings in db.session.execute(text(f"...")); use text("... :n") with parameters.

Idea 6: Transport, secrets, validation, limits, tokens

HTTPS and TLS. HTTPS is HTTP inside TLS, which gives encryption (nobody on the way can read), integrity (nobody can alter) and authentication of the server (a certificate from a trusted authority proves the site is the real bank.com). It protects passwords, cookies and form data on the wire. It does not fix XSS or SQL injection. Use the Secure cookie flag with it.

Secrets and environment variables. SECRET_KEY, database passwords and API keys must not be written in the code or pushed to Git. Read them from the environment:

import os
app.config["SECRET_KEY"] = os.environ["SECRET_KEY"]   # fails loudly if missing

Keep a local .env (listed in .gitignore) and a .env.example without real values. Anyone who learns the SECRET_KEY can forge Flask sessions.

Input validation. Treat all input as hostile: check type, length, range and format on the server (and on the client for comfort). Prefer an allow list (only letters and digits) to a block list. A real End Term: frontend validation improves user experience, backend validation is mandatory for security because the frontend can be bypassed, and the backend should check the same constraints.

Rate limiting. Limit how many requests an address or user may make in a time window, to slow brute force password guessing and abuse (Flask-Limiter: @limiter.limit("5 per minute")). Our small hand-made version let 3 requests through and refused the 4th and 5th: [True, True, True, False, False]. Return 429 Too Many Requests.

Token-based authentication (introduction). Instead of a server-side session and a cookie, the server gives a signed token (for example a JWT, or a random string). The client sends it in every request: Authorization: Bearer <token>. The server only verifies the signature, so it keeps no session state (stateless, good for scaling) and the same token works for a mobile app or JavaScript calling your REST API. Tokens need an expiry and HTTPS; if stored in localStorage they can be stolen by XSS. You will use token auth with the REST API in MAD2.

Principle of least privilege. Give every person and program the smallest access that lets it do its job: the web app's database user should not be able to drop tables; a normal user gets the user role, not admin; an API key can be read-only. If something is compromised, the damage is small.

Idea 7: A secure project checklist

Your turn

Exam radar

Quick quiz

Viva: say it out loud

Recap

Practise with real exam questions

These come straight from past papers (with the real figures and the official answer key). Open 60 real questions on this week   All End Term papers