Security vulnerability: Auth Bypass in Dart due to incorrect parsing of the backslash characters in the URL

[khyati82]

TL;DR: Backslash is not recognized as equivalent to forward slash in URLs, leading to potential auth bypasses in web apps

There is a Auth Bypass vulnerability in your service at https://github.com/dart-lang/sdk.

URI parsing is done in https://github.com/dart-lang/sdk/blob/main/sdk/lib/core/uri.dart (likely around this part but didn't find the exact place)

The dart:uri library is a core dart library that is used to parse and validate URLs. However, it is vulnerable to the "backslash-trick" due to incorrect parsing of the backslash characters in the URL. This can be used to bypass certain types of URL validation checks and when used in conjunction with the dart:html library can lead to issues such as CSRF, XSS etc.

The dart:html library exposes fairly powerful web APIs to the developer such as the the iframe API, window.location API, object elements and the lower-level fetch API to name a few. In traditional web development, the developer is responsible for safegaurding and validating the data that is consumed by these APIs. For example, the developer might write the following code to validate the URL that is passed to the src attribute to a iframe from a user-supplied source:

const url = new URL(urlString);
if (url.hostname == 'google.com') {
  const iframe = document.createElement('iframe');
  iframe.src = urlString;
  // receive messages from the iframe or send messages
}

However, when writing something similar for Dart, the check against the host (using the URI) class can be bypassed and would not be complete.

final uri = Uri.parse(urlString);
if (uri.host == 'google.com') {
  var iframe = IFrameElement();
  iframe.src = urlString;
  // receive messages from the iframe or send messages
}

The code above is not safe because the developer is not able to guarantee that the URL is valid. A input like http://othersite.com\@google.com/ (or http://othersite.com:123\@google.com/) will be evaluated to have a hostname of google.com whereas the browser would resolve this to othersite.com loading the attacker controlled domain in the iframe. This could lead to unwanted disclosure of data to the attacker or even a cross-site scripting attack depending on how the messages between the two frames are being handled.

[lrhn]

This was fixed in https://dart-review.googlesource.com/c/sdk/+/258120

The Dart Uri class, which implements RFC 3986, has several differences from the WhatWG URL class (which matches what browsers do).

This difference had the misfortune of making a validation check made on the Dart Uri class not actually mean what it was intended to when the same URL was passed to a browser.

[khyati82]

This is tied to the security advisory
GHSA-m9pm-2598-57rj

[khyati82]

This issue has been fixed in Dart sdk 12.8.2 & fluter sdk 3.3.3