ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Cross-site request forgery(CSRF)
    Web/Security 2019. 9. 7. 11:42

    1. Overview

    Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

    In a CSRF attack, an innocent end-user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account.

    2. How does CSRF work

    2.1 A relevant action

    There is an action within the application that the attacker has a reason to induce. This might be a privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user's own password).

    2.2 Cookie-based session handling

    Performing the action involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. There is no other mechanism in place for tracking sessions or validating user requests.

    2.3 No unpredictable request parameters

    The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess. For example, when causing a user to change their password, the function is not vulnerable if an attacker needs to know the value of the existing password.

    3. Example

    Suppose an application contains a function that lets the user change the email address on their account. When a user performs this action, they make an HTTP request like the following:

    POST /email/change HTTP/1.1
    Host: vulnerable-website.com
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 30
    Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
    
    email=wiener@normal-user.com

    This meets the conditions required for CSRF:

    • The action of changing the email address on a user's account is of interest to an attacker. Following this action, the attacker will typically be able to trigger a password reset and take full control of the user's account.
    • The application uses a session cookie to identify which user issued the request. There are no other tokens or mechanisms in place to track user sessions.
    • The attacker can easily determine the values of the request parameters that are needed to perform the action.

    With these conditions in place, the attacker can construct a web page containing the following HTML:

    <html>
      <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
          <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
          document.forms[0].submit();
        </script>
      </body>
    </html>

    If a victim user visits the attacker's web page, the following will happen:

    • The attacker's page will trigger an HTTP request to the vulnerable web site.
    • If the user is logged in to the vulnerable web site, their browser will automatically include their session cookie in the request (assuming SameSite cookies are not being used).
    • The vulnerable web site will process the request in the normal way, treat it as having been made by the victim user, and change their email address.

    4. Preventing CSRF

    The most robust way to defend against CSRF attacks is to include a CSRF token within relevant requests. The token should be:

    • Unpredictable with high entropy, as for session tokens in general.
    • Tied to the user's session.
    • Strictly validated in every case before the relevant action is executed.

    An additional defense that is partially effective against CSRF, and can be used in conjunction with CSRF tokens, is SameSite cookies.

    5. References

    https://portswigger.net/web-security/csrf

    https://en.wikipedia.org/wiki/Cross-site_request_forgery

    https://portswigger.net/web-security/csrf/tokens

    'Web > Security' 카테고리의 다른 글

    Server-side request forgery  (0) 2019.09.07
    Cross-site tracing(XST)  (0) 2019.09.07
    SQL Injection  (0) 2019.09.07
    Secure coding  (0) 2019.09.06
    Cross-site Scripting(XXS)  (0) 2019.08.30

    댓글

Designed by Tistory.