Who Are You, and What Can You Do? (Authentication & Authorization Vulnerabilities)
It's hard to imagine a web service without a login function. Likewise, Authentication and Authorization are the foundation and core of every service. But when this foundation crumbles, the service faces its greatest threat.
Authentication: The process of verifying 'who' a user is (e.g., entering an ID/password, fingerprint scan).
Authorization: The process of checking and granting 'what' an authenticated user is permitted to do (e.g., accessing an admin page, editing someone else's post).
This week, we dove into the critical vulnerabilities that arise from these two core security functions.
1. Authentication Vulnerabilities: "Who are you?"
Authentication is a process of "proof." These attacks exploit flaws in this verification process to impersonate someone else or to skip the process entirely.
1) Authentication Based on Untrusted Client Data
One of the most basic mistakes is relying on client-side information to determine authentication status. Values stored in the browser, such as cookies or local storage, can be easily manipulated by the user.
Attack Scenario: After logging in, the server issues a cookie like
Set-Cookie: role=user. An attacker can simply use Burp Suite or the browser's developer tools (F12) to change this value torole=adminand gain administrative privileges.Key Takeaway: Never trust the user. Critical state information like permissions must be stored and validated in a server-side session.
2) Bypassing Authentication Steps (Process Step Jump)
When a service's functionality consists of multiple steps, this attack involves skipping intermediate steps and accessing the final step directly. It's often found in features like identity verification, registration, or password changes.
Attack Scenario: In a registration process with the order
Agree to Terms (step1) -> Verify Identity (step2) -> Enter Information (step3), an attacker on thestep1page can directly manipulate the URL to something like.../join?step=3, skipping thestep2identity verification and moving straight to the information entry stage.Countermeasure: At each step, the server must verify that the previous step was completed successfully, typically by using a session flag.
3) Unlimited Authentication Attempts (Brute-Force Attack)
If there is no limit on the number of login attempts, an attacker can use automated tools to try endless combinations of IDs and passwords to hijack an account.
Attack Types:
Brute-force Attack: Tries every possible combination of characters, like
aaaa,aaab, and so on.Dictionary Attack: Tries a list of commonly used words or passwords from previous data breaches.
Countermeasure: It's effective to implement account lockouts after a certain number of failed attempts, introduce CAPTCHA to block automated attacks, and add a login delay time.
2. Authorization Vulnerabilities: "Are you worthy to open this door?"
Authorization is a matter of "privilege." Any attempt by an already logged-in user to access functions or data that are not permitted to them falls under an authorization attack.
1) Client-Side Authorization Controls
This is an extremely vulnerable practice where access is restricted only by what is visible on the screen, without real security considerations. An attacker can easily bypass this using just the developer tools (F12).
Vulnerable Examples:
Hiding an admin button using HTML comments: ``.
Hiding an admin menu with the
style="display:none"attribute.Validating permissions using JavaScript:
if (user.role != 'admin') { alert('Permission denied'); return; }.
Key Takeaway: If you see a "permission denied" message instantly without a request going to the server, it's a 100% client-side control. All permission checks must be performed on the server.
2) Insecure Direct Object Reference (IDOR)
This is the alpha and omega of authorization vulnerabilities. It's an attack where a user changes the identifier (ID, number) of data they are accessing (posts, user info, files) to access another user's data.
Attack Scenarios:
When the URL for editing a post is
.../post/edit?postId=123, an attacker changes thepostIdto another number (124) to edit or delete someone else's post.In a private support forum, an attacker changes the
idvalue in.../inquiry/view?id=456to read another person's secret inquiry.
Countermeasure: For every request that accesses or modifies data, the server must cross-check: "Does the currently logged-in user (from the session) have ownership of/permission for the requested object (e.g., postId=124)?"
3) Guessing Hidden Functionality
This attack involves directly accessing admin pages or special feature pages that are not visible to regular users by guessing their URLs.
Attack Scenario: An attacker tries to access common admin page URLs like
https://example.com/admin,https://example.com/manager.jsp, orhttps://example.com/dashboard.Countermeasure: While using complex, hard-to-guess URLs can help, the fundamental solution is to apply strong server-side authorization checks to every administrative page.
댓글 없음:
댓글 쓰기