Search

EP-4423647-B1 - DETECTING AND PROTECTING AGAINST INCONSISTENT USE OF CROSS-SITE REQUEST FORGERY MITIGATION FEATURES

EP4423647B1EP 4423647 B1EP4423647 B1EP 4423647B1EP-4423647-B1

Inventors

  • KHAN, Safwan, Mahmud

Dates

Publication Date
20260506
Application Date
20220926

Claims (15)

  1. A method for detecting cross-site request forgery vulnerabilities, comprising: receiving (502) a source code (402) of a web application (106), the source code including a server-side source code (404) and a client-side source code (406); identifying (504, 514) a framework (405) used by the server-side source code and a web framework (407) used by the client-side source code; and generating (518) an indication of a cross-site request forgery vulnerability within the source code based on a determination (508, 512, 516) that: a first feature (442) of the framework is incorrectly applied to an authentication function (103) within the server-side source code, wherein the first feature causes an anti-forgery token (204) to be generated when the authentication function is executed, and wherein the first feature causes the anti-forgery token to be included in a cookie (216) when the authentication function is executed, a second feature (444) of the web framework is incorrectly applied to a web request generation function within the client-side source code, wherein the second feature ensures that a web request (240) generated by the web request generation function includes a copy of the anti-forgery token, and a third feature (446) of the framework is incorrectly applied to a server-side function (113) that responds to the web request, wherein the third feature verifies that the anti-forgery token included in the cookie matches the copy of the anti-forgery token included in the web request.
  2. The method of claim 1, wherein the second feature copies the anti-forgery token from the cookie into a hidden input element (238) of a web form (239) that is included in the web request or the second feature copies the anti-forgery token from the cookie into an HTTP header submitted with the web request.
  3. The method of claim 1, wherein the indication of the cross-site request forgery vulnerability is generated based on a determination that the second feature and the third feature do not use a same name when accessing the anti-forgery token in the web request or a determination that the first feature and the second feature do not use a same name when accessing the anti-forgery token in the cookie.
  4. The method of claim 1, wherein the determination is made based on a static analysis of framework usage in the server-side source code and a static analysis of framework usage in the client-side source code.
  5. The method of claim 1, wherein the determination that the first feature is incorrectly applied to the authentication function includes identifying the authentication function within the server-side source code and determining that the first feature is not applied to the identified authentication function.
  6. A device comprising: one or more processors (602); and a computer-readable storage medium having encoded thereon computer-executable instructions that cause the one or more processors to: receive a source code (402) for a web application (106), the source code including a server-side source code (404); identify a framework (405) used by the server-side source code; and generate an indication of a cross-site request forgery vulnerability within the server-side source code based on a framework-based static analysis determination that: a first feature (442) of the framework is not applied to an authentication function (103) within the server-side source code, wherein the first feature causes an anti-forgery token (204) to be generated when the authentication function is executed, and wherein the first feature causes the anti-forgery token to be included in a cookie (216) when the authentication function is executed, and a second feature (446) of the framework is not applied to a server-side function (113) that responds to a web request (240), wherein the second feature verifies that the anti-forgery token included in the cookie matches the anti-forgery token included in the web request.
  7. The device of claim 6, wherein the authentication function receives a user credential, authenticates the user credential, generates an anti-forgery token, and includes the generated anti-forgery token in an individual web response.
  8. The device of claim 6, wherein generating an indication of a cross-site request forgery vulnerability within the server-side source code comprises generating a list of locations in the source code where a cross-site request forgery is found.
  9. The device of claim 6, wherein the artifact token generation request is received from the cloud-hosted application, and wherein the framework is identified based on a file extension of a file in the source code, the existence of a framework-specific file name or directory structure within the source code, or the existence of a framework-specific identifier name within the source code.
  10. A computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to: receive a source code (402) for a web application (106), the source code including a server-side source code and a client-side source code; identify a framework (405) used by the server-side source code and a web framework (407) used by the client-side source code; and generate an indication of a cross-site request forgery vulnerability within the server-side source code based on a determination that: a first feature (442) of the framework is not applied to a authentication function (103) within the server-side source code, wherein the first feature causes an anti-forgery token (204) to be generated when the authentication function is executed, and wherein the first feature causes the anti-forgery token to be included in a cookie (216) when the authentication function is executed, a second feature (444) of the web framework is incorrectly applied within the client-side source code, wherein the second feature causes the anti-forgery token to be copied from the cookie to an HTML form (239) within a web response, and a third feature (446) of the framework is not applied to a server-side function (113) that responds to a web request (240), wherein the third feature verifies that the anti-forgery token included in the cookie matches the anti-forgery token included in the web request.
  11. The computer-readable storage medium of claim 10, wherein the determination that the first feature of the framework is not applied to the authentication function includes searching a plurality of files of the server-side source code for the authentication function and determining that the authentication function does not have an attribute associated with the first feature of the framework.
  12. The computer-readable storage medium of claim 11, wherein the determination that the first feature of the framework is not applied to the authentication function includes searching for a base class of a class that includes the authentication function and determining that the base class does not have an attribute associated with the first feature of the framework.
  13. The computer-readable storage medium of claim 11, wherein the determination that the first feature of the framework is not applied to the authentication function includes determining that a global configuration setting does not enable the first feature of the framework for the authentication function.
  14. The computer-readable storage medium of claim 10, wherein the indication of the cross-site request forgery vulnerability is generated based on a determination that the framework is incompatible with the web framework.
  15. The computer-readable storage medium of claim 10, wherein the determination that the second feature of the web framework is not applied includes searching a plurality of files for an HTML form element that does not include an individual anti-forgery token insertion attribute or a function that generates an HTML form element that is not proximate to an individual anti-forgery token insertion attribute.

Description

BACKGROUND Cross-Site Request Forgery (CSRF) is a vulnerability that enables a hacker to submit a web request as if it had been submitted by an authenticated user. The exploit targets a user that has authenticated with a web application using a web browser. So long as the user remains authenticated, the web application will trust any request that originates from the same browser. If the authenticated user is tricked into submitting a malicious request, the web application will trust the malicious request as it would any other request sent by that user. This enables the hacker to perform any action the user is authorized to perform. A successful CSRF attack can result in damaged client relationships, unauthorized fund transfers, changed passwords, data theft, session cookie stealing etc. For example, a hacker may target a user that has authenticated with an online banking web application. When the user authenticates (e.g. "logs-in"), the bank's web application sends a cookie with an authentication token to the user's browser. The browser stores the cookie and will provide the cookie with any subsequent web request sent to the web application until the cookie is erased. At some point, the user is tricked into clicking on a link provided by the hacker. The user may come across the link in an email, on a social networking site, etc. The link may mimic the formatting and style of the bank, display text that seems authentic coming from a bank, and is directed to a website with an address that seems like an official bank website. For example, the link might display "Click here to open a BankTwo checking account and get a free toaster", while the link may direct the user to a website named "create-banktwo-checkingaccount.com". In other scenarios, instead of mimicking the bank's formatting and style, the link may target an apparently benign website created by the hacker, such as a news aggregator or a blog. Either way, once the link is clicked, the user's browser opens a new tab and navigates to a malicious web page created by the hacker. The malicious web page contains a Hypertext Markup Language (HTML) form crafted by the hacker that, when submitted, sends a malicious HTTP request to the bank's web application. The hacker may craft the form to be compatible with the bank's web application - i.e. the attributes and child elements of the form have names and values expected by the bank's web application. In some scenarios, the form is submitted automatically in the background when the malicious web page is loaded. For example, the HTML form may include an action attribute and input elements that cause money to be transferred from the user's account to the hacker's account. When the form is submitted, the user's browser attaches the cookie containing the authentication token to the HTTP request, just as it would for any other HTTP request sent to the bank's website. Upon receiving the form and the cookie, the bank's web application will use the authentication token to verify that the user is still logged in. If so, the bank's web application will perform the action specified by the malicious request. For example, the form may request that $100 be transferred from the user's checking account to the hacker's account. There are many techniques used to mitigate CSRF attacks: requiring re-authentication for every potentially vulnerable operation, rejecting requests based on the referrer header, using the SameSite cookie attribute, etc. One of the most robust and well-established techniques is called "Double Submit Cookie". When implementing "Double Submit Cookie", a server-side portion of the web application embeds a randomly generated anti-forgery token into the cookie that stores the authentication token. A client-side portion of the web application copies the anti-forgery token from the cookie into the body of an HTTP request or into a header of an HTTP request. For example, the client-side portion of the web application may copy the anti-forgery token into an HTML form included in the body of an HTTP request, or into a CSRF header of an HTTP request. Throughout this document, copying the anti-forgery token into an HTTP request refers to copying the anti-forgery token into the body of the HTTP request or copying the anti-forgery token into a header of the HTTP request. The server-side portion of the web application then determines if the request is valid by determining if the anti-forgery token embedded in the cookie matches the anti-forgery token embedded in the body of the HTTP request or a header of the HTTP request. Throughout this document, determining whether the anti-forgery token embedded in a cookie matches the anti-forgery token in an HTTP request refers to determining whether the anti-forgery token embedded in the cookie matches an anti-forgery token in the body of the HTTP request or an anti-forgery token in a header of the HTTP request. The hacker is unable to obtain the anti-forgery token that the web appl