Классы Uri и WebView разбирают URL-адреса, содержащие обратную косую черту в правах доступа (информацию о хосте или пользователе)

Question

При использовании URI

String myUri = "https://evil.example.com\\.good.example.org/";
// or
String myUri = "https://evil.example.com\\@good.example.org/";

в Java на Android обратная косая черта в информации о хосте или пользователе авторитетной части URI вызывает несоответствие между синтаксическим анализом android.net.Uri и android.webkit.WebView в AndroidURI относительно его хоста.

• Класс Uri (и cURL ) обрабатывают evil.example.com\.good.example.org (первый пример) или даже good.example.org (второй пример) какхост URI.
• Класс WebView (и Firefox и Chrome) рассматривают evil.example.com (оба примера) как хост URI.

Является ли это известным, ожидаемым или правильнымповедение?Два класса просто следуют различным стандартам?

Глядя на спецификацию, кажется, что ни RFC 2396 , ни RFC 3986 не допускают обратной косой черты в пользовательской информации или полномочиях.

Есть ли обходной путь для обеспечения согласованного поведения, особенно в целях проверки?Выглядит ли следующий патч разумным (для использования с WebView и для общей корректности)?

Uri myParsedUri = Uri.parse(myUri);

if ((myParsedUri.getHost() == null || !myParsedUri.getHost().contains("\\")) && (myParsedUri.getUserInfo() == null || !myParsedUri.getUserInfo().contains("\\"))) {
    // valid URI
}
else {
    // invalid URI
}

Один из возможных недостатков заключается в том, что этот обходной путь может не охватить все случаи, которые вызывают анализ несогласованных хостов.Знаете ли вы что-нибудь еще (кроме обратной косой черты), которое вызывает несоответствие между двумя классами?

Answer 1

Это известное, ожидаемое или правильное поведение?

ИМО, это не так.Для URI и WebView.Поскольку RFC не допустит обратной косой черты, они могли бы предупредить об этом.Однако это менее важно, потому что это не влияет на работу вообще, если входной сигнал соответствует ожидаемому .

Два класса просто следуют различным стандартам?

Класс URI и WebView строго следуют одним и тем же стандартам.Но из-за того, что они являются разными реализациями, они могут вести себя иначе, чем неожиданный ввод.

Например, "^(([^:/?#]+):)?((//([^/?#]*))?([^?#]*)(\\?([^#]*))?)?(#(.*))?" это регулярное выражение в URI, которое используется для анализаURIs.Синтаксический анализ URI в WebView выполняется нативными методами CPP.Несмотря на то, что они следуют одним и тем же стандартам, у них есть шансы дать другой результат (по крайней мере, для неожиданных исходных данных).

Выглядит ли следующий патч разумным?

Не совсем (см. Ответ на следующий вопрос).

Знаете ли вы что-нибудь еще (кроме обратной косой черты), которое вызывает несоответствие между двумя классами?

Поскольку вы так обеспокоены последовательным поведением, яне будет предлагать ручную проверку.Даже программисты, написавшие эти классы, не могут перечислить все такие сценарии.

Решение

Если я правильно понимаю, вам нужно загрузить URL-адреса, предоставленные ненадежными внешними источниками (которые могут использовать злоумышленники, если есть дыра в петле), но вам нужно определить,хост правильно.

В этом случае вы можете проанализировать его, используя сам класс URI и использовать URI#getHost() для идентификации хоста.Но для WebView вместо передачи исходной строки URL-адреса передайте URI#toString().

Answer 2

Известно, что Android WebView 4.4 преобразует некоторые URL-адреса , в связанной проблеме приведены некоторые шаги, описанные, как это предотвратить.Из вашего вопроса не совсем ясно, основана ли ваша потребность на этом вопросе или на чем-то еще.

Вы можете замаскировать обратную косую черту и другие знаки с помощью соответствующего номера в таблице символов.В URL-адресах число записывается в шестнадцатеричном формате.

Hexadecimal: 5C
Dezimal: 92
Sign: \

К коду добавляется % для каждого знака в URL-адресе, после замены ваш код выглядит следующим образом:

String myUri = "https://evil.example.com%5C%5C.good.example.org/";
// or
String myUri = "https://evil.example.com%5C%5C@good.example.org/";

может потребоваться добавить косую черту в отдельный домен и путь:

String myUri = "https://evil.example.com/%5C%5C.good.example.org/";
// or
String myUri = "https://evil.example.com/%5C%5C@good.example.org/";

Возможно ли, что обратные слеши вообще никогда не будут использоваться для связи по сети, а служат как выходящиедля некоторых процедур, таких как регулярные выражения или для вывода в JavaScript (Json) или для некоторых других шагов?

Bonus; -)
Ниже приведен php-скрипт, который печатаеттаблица для большинства знаков UTF-8 с соответствующими числами в шестнадцатеричном и разл.(он все еще должен быть заключен в HTML-шаблон, включая, возможно, css):

<?php
    $chs = array('0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F');
    $chs2 = $chs;
    $chs3 = $chs;
    $chs4 = $chs;
    foreach ($chs as $ch){
        foreach ($chs2 as $ch2){    
            foreach ($chs3 as $ch3){
                foreach ($chs4 as $ch4){
                    echo '<tr>';
                    echo '<td>';
                    echo $ch.$ch2.$ch3.$ch4;
                    echo '</td>';
                    echo '<td>';
                    echo hexdec($ch.$ch2.$ch3.$ch4);
                    echo '</td>';
                    echo '<td>';
                    echo '&#x'.$ch.$ch2.$ch3.$ch4.';';
                    echo '</td>';
                    echo '</tr>';
                }
            }
        }
    }
?>