Web Security & VulnHawk Mastery

Broken Access Control and Authentication

40 мин

Broken access control is consistently the most common serious web vulnerability: users can see or do things they should not.

IDOR / BOLA

@app.get("/invoices/<int:invoice_id>")
@login_required
def invoice(invoice_id):
    inv = db.get_or_404(Invoice, invoice_id)          # VULNERABLE: any logged-in user
    return render_template("invoice.html", invoice=inv)

Changing the number in the URL reveals other customers' invoices. Fix by scoping every query to the current user:

inv = db.first_or_404(select(Invoice).filter_by(id=invoice_id, customer_id=current_user.id))

Privilege escalation

  • Admin routes must check roles on the server, not just hide links. Returning 404 to non-staff avoids revealing admin URLs.
  • Never accept roles or permissions from the client (role=admin in a form or JSON body). Use explicit input schemas to prevent mass assignment.
  • Staff permissions should follow least privilege, with sensitive actions limited to a super administrator and logged.

Authentication essentials

  • Hash passwords with a slow, salted algorithm (bcrypt, scrypt, Argon2; Werkzeug's default is acceptable).
  • Enforce sensible password length; check against known-breached passwords where possible.
  • Rate-limit login, password reset and MFA endpoints; lock accounts temporarily after repeated failures.
  • Use the same error for unknown accounts and wrong passwords.
  • Offer multi-factor authentication (TOTP with backup codes); require it for admins.
  • Password reset tokens: random, hashed, single-use, short-lived.
  • Regenerate session IDs on login; log users out on password change; logout via POST.
  • Validate next= redirects to prevent open redirects.

CSRF

Cross-site request forgery tricks a logged-in user's browser into submitting a request to your site. Defences: CSRF tokens on every state-changing form, SameSite cookies, and never changing data on GET.

Testing access control

For every endpoint, try it as: anonymous, a normal user, a different normal user (with the first user's object IDs) and each staff role. Automate this as a test matrix; scanners rarely catch access-control bugs because they do not know your business rules.

Exercise

Write a parametrised test that requests every object-specific route in your app as the owner, another user and anonymous, asserting only the owner (or authorised staff) gets 200. Fix every failure.

Check yourself

  • What is IDOR, and how do you prevent it?
  • Why must roles never come from client input?
  • Which endpoints need rate limits?

Ваш прогресс сохраняется только в этом браузере.

Отправить на проверку (10 баллов)