Синтаксис заголовка HTTP HSTS

Question

Из спецификации здесь :

Синтаксис ABNF (расширенная форма Бэкуса-Наура) для заголовка STS поле приведено ниже. Он основан на общей грамматике, определенной в разделе 2 [RFC2616] (который включает в себя понятие «подразумевается линейный пробел ", также известный как" подразумеваемый * LWS ").

 Strict-Transport-Security = "Strict-Transport-Security" ":"
                             [ directive ]  *( ";" [ directive ] )

А здесь ,

подразумевается * LWS Грамматика, описанная в этой спецификации, основана на словах. Кроме если не указано иное, линейный пробел (LWS) может быть включен между любыми двумя соседними словами (токен или строка в кавычках), и между соседними словами и разделителями, не меняя интерпретация поля. Хотя бы один разделитель (LWS и / или

  separators) MUST exist between any two tokens (for the definition
  of "token" below), since they would otherwise be interpreted as a
  single token.

Учитывая спецификации. Пример:

Strict-Transport-Security: max-age="31536000"

В1: Означает ли это, что разрешено добавлять только один пробел между каждыми двумя словами? то есть этот заголовок правильный (обратите внимание на пробел до и после знака равенства)?

 Strict-Transport-Security : max-age = "31536000"

В2: Требуются или необязательны ли котировки на номер "31536000"?

Q3: Есть ли спецификации. объяснение включает в себя несколько пробелов или строго допускается только один пробел? например как насчет:

 Strict-Transport-Security : max-age        = "31536000"

В4: Допустимо ли добавление одинарных или двойных кавычек вокруг ключа или значений? Например, это приемлемо:

 "Strict-Transport-Security" : "max-age"="31536000"

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

Answer 1

Strict-Transport-Security : max-age = "31536000"

Этот заголовок, на мой взгляд, не корректен, так как имеет пробел между field-name и :. Раздел 4.2 RFC 2616 гласит «Каждое поле заголовка состоит из имени, за которым следует двоеточие («: »), и значения поля.« , т. Е. Ничего о LWS после имени. Но на самом деле не совсем ясно, если это просто не упоминает LWS, поскольку оно подразумевается, или если оно явно не упоминает LWS, поскольку это здесь не разрешено. На самом деле реализации различаются, и это может быть использовано для разных интерпретаций в разных системах.

Что касается LWS между именем параметра и значением параметра, я думаю, что это соответствует определению подразумеваемого LWS , то есть оно действительно. Но подразумеваемый LWS не означает, что вы можете добавить только один пробел, говорится в 2.1 "... По крайней мере один разделитель (LWS и / или разделители) ДОЛЖЕН существует между любыми двумя токенами ... ", что означает, что на самом деле может быть несколько пробелов или ни одного (просто разделитель).

Q2: котировки на номер "31536000" обязательны или необязательны?

RFC 6797 имеет явные примеры в разделе 6.2, которые должны прояснить это:

Strict-Transport-Security: max-age=15768000 ; includeSubDomains

... Значение директивы max-age может быть опционально в кавычках:

Strict-Transport-Security: max-age="31536000"

Q3: Есть ли спецификации. объяснение включает в себя несколько пробелов или строго допускается только один пробел? например как насчет:

Опять же, это не ограничивает количество пробелов для подразумеваемой LWS.

 "Strict-Transport-Security" : "max-age"="31536000"

Имя поля и имя параметра определяются как token. Токены не должны быть указаны.

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

Ты чертовски прав. Это не только сложно, но часто сбивает с толку, недостаточно ясно, а иногда спецификации даже противоречат друг другу. Обработка критических данных как свободного текста с необязательным LWS в различных пространствах, необязательное или обязательное цитирование ... дает множество способов для реализации и анализа и часто неожиданных.

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