Поделиться через

Синтаксический анализ LDAP DirectoryControl теперь более строгий

  • Статья

Ранее .NET использовал System.DirectoryServices.Protocols.BerConverter для синтаксического анализа объектов System.DirectoryServices.Protocols.DirectoryControl, полученных через сеть, и для создания отправленных System.DirectoryServices.Protocols.DirectoryControl массивов байтов. System.DirectoryServices.Protocols.BerConverter использовала функциональность синтаксического анализа BER, специфичную для ОС. Эта функция синтаксического анализа теперь реализована в управляемом коде.

Предыдущее поведение

В результате использования System.DirectoryServices.Protocols.BerConverterанализ объектов System.DirectoryServices.Protocols.DirectoryControl был довольно свободным:

  • Теги ASN.1 каждого значения не были проверены.
  • Остаточные данные после завершения разбора DirectoryControl были проигнорированы, как и остаточные данные в ASN.1 SEQUENCE.
  • В Linux длины OCTET STRING, которые выходили за пределы родительской последовательности, возвращали данные за пределами этой последовательности.
  • В более ранних версиях Windows строка OCTET STRING нулевой длины возвращала null, а не пустую строку.
  • При чтении содержимого System.DirectoryServices.Protocols.DirectoryControl в виде строки в кодировке UTF8 недопустимая последовательность UTF8 не вызвала исключения.
  • При передаче недопустимой строки в формате UTF8 конструктору VlvRequestControlисключение не возникло.

Хотя и не критическое изменение, Windows всегда кодирует теги ASN.1 с четырехбайтовой длиной, в то время как Linux использует только столько байтов для длины тега, сколько это необходимо. Оба представления были допустимыми, но эта разница в поведении между платформами в настоящее время исчезла; Поведение Linux теперь также отображается в Windows.

Новое поведение

Синтаксический анализ DirectoryControl гораздо более строгий и теперь согласован между платформами и версиями:

  • Теперь проверяются теги ASN.1.
  • Конечные данные больше не разрешены.
  • Теперь проверяются длины OCTET STRINGи SEQUENCE.
  • Теперь OCTET STRINGнулевой длины всегда возвращают пустую строку.
  • Если сервер отправляет недопустимую последовательность байтов UTF8, логика синтаксического анализа System.DirectoryServices.Protocols.DirectoryControl теперь создает исключение, а не автоматически подставляя недопустимые символы с известным значением.

Мы также тщательно проверяем ошибки при вызове конструктора VlvRequestControl. Передача строки, которая не может быть закодирована как значение UTF8, теперь вызывает EncoderFallbackException.

Представленная версия

.NET 10 (предварительная версия 1)

Тип изменения, нарушающего совместимость

Это изменение представляет собой изменение в поведении.

Причина изменения

Это изменение было внесено для соответствия требованиям RFC и спецификации. В различных RFCs и разделах MS-ADTS элемент controlValue указывается как кодировка BER структуры ASN.1, описанная следующим образом (из RFC2891, раздел 1.2):

Тип управления установлен в "1.2.840.113556.1.4.474". Критическое значение равно FALSE (МОЖЕТ отсутствовать). ControlValue — это ОКТЕТНАЯ СТРОКА, значение которой является BER-кодировкой значения следующей ПОСЛЕДОВАТЕЛЬНОСТИ:

Это предотвращает хвостовые данные. Кроме того, он исключает кодировки BER структур ASN.1 с разными тегами ASN.1 и недопустимыми кодировками BER (например, OCTET STRING, который длиннее, чем содержащая его SEQUENCE).

Для конструктора VlvRequestControl раннее выбрасывание исключения означает, что пользователи могут быть уверены, что только те значения, которые они явно указывают, отправляются на сервер. Нет никаких обстоятельств, когда они могут случайно отправить EF BF BD на сервер, так как они передали строку, которая не может быть закодирована в допустимые байты UTF8.

Серверы должны соответствовать требованиям RFC и спецификаций. Обязательно обработайте EncoderFallbackException при вызове конструктора VlvRequestControl.

Затронутые API