Какой смысл в конечных точках API oEmbed и схемах URL по сравнению с тегами ссылок? - PullRequest
Новая
       13

Какой смысл в конечных точках API oEmbed и схемах URL по сравнению с тегами ссылок?

3 голосов
/ 01 сентября 2011

В спецификации oEmbed упоминается 2 различных способа поиска содержимого URL oEmbed:

  1. Зная конечную точку API веб-сайта и передавая через параметр GET URL-адрес, по которому вы хотите получить информацию, если он соответствует объявленному шаблону URL.
  2. Обнаружение URL версии oEmbed благодаря заголовку HTML <link rel="alternate" type="application/json+oembed" ... /> (или text/xml+oembed).

Второй способ выглядит более общим, поскольку вам не нужно хранить и поддерживать целый список поставщиков. Более того, списки провайдеров являются признаком централизованного интернета, где существует всего несколько действующих лиц. Этот подход вряд ли масштабируем.

Однако я вижу применение для первого подхода для веб-сайтов, которые могут анализировать ресурсы, предоставленные кем-то другим. Например, я могу предоставить oEmbed версию видео-страниц с сайта Foo. Однако по нескольким причинам, главным образом связанным с безопасностью, я бы не стал доверять кому-то, кто говорит: «Я могу разобрать для вас ресурс X», если только автор X не согласится с этим, что возвращает нас к подходу 2.

Итак, мой вопрос: что я здесь упустил? Какая польза от первого метода работы с oEmbed? Например, зачем хранить (и поддерживать в актуальном состоянии) целый список конечных точек и шаблонов , как это делает oohEmbed , если у вас есть универсальный способ его обнаружения на лету и практически для любого ресурса на интернет?

Как очень тесно связанный вопрос, который, я думаю, может быть задан одновременно (пожалуйста, исправьте меня, если я ошибаюсь): что произойдет, если не предоставить центральную конечную точку для содержимого oEmbed, а, скажем, сказать , ожидайте параметр «? version = oembed» для каждого URL, который возвращает версию oEmbed вместо стандартной?

Ответы [ 3 ]

3 голосов
/ 03 ноября 2011

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

В долгосрочной перспективе мы планировали использовать часть работы, которую Эран Хаммер-Лахав делал над открытием, а не заново его изобретать (опять же, плохо). К сожалению, его идеи до сих пор не получили широкого распространения, и в Интернете все еще не хватает хорошего стандартизированного способа сделать подобные вещи.

1 голос
/ 28 сентября 2011

Я надеялся найти здесь ответ, но похоже, что все остальные так же смущены, как и мы. На мой взгляд, преимущество использования опции 1 состоит в том, что она использует только 1 запрос json вместо потенциально дорогого запроса html, за которым следует запрос json. Вы всегда можете использовать вариант 2 в качестве запасного варианта, если вы не можете сопоставить шаблон в своем предварительно запеченном списке поставщиков oEmbed.

0 голосов
/ 24 марта 2013

OEmbed обнаружение является серьезной проблемой безопасности. Например, WordPress имеет белый список поддерживаемых провайдеров OEmbed.

Предположим, что каждый случайный URL в Интернете может вызывать код OEmbed. Это означает, что каждый может взломать ваш сайт.

Шаги:

  1. Создайте новый сайт, добавьте открытие OEmbed.
  2. Разместите URL формы на вашем сайте. Теперь ваш сайт выполняет OEmbed от моего имени.

  3. Exploit:

    • отказом в обслуживании (DOS): например, перенаправьте URL-адрес на тарпит или отправьте в ответ 1 ГБ json.
    • с помощью межсайтового скриптинга (XSS): вставлять случайный HTML-код на страницы, которые могут видеть другие люди.
    • похитив сессионный cookie-файл администратора через XSS: теперь злоумышленник может войти в вашу CMS для загрузки файлов и использовать еще больше.

Это XSS по максимуму, с небольшим, чтобы остановить его. Единственная вменяемая вещь - это внесение в белый список правильных конечных точек. Это конечные точки oEmbed явно указаны.

Если вы хотите что-то масштабируемое, вам могут понравиться www.noembed.com и www.embedly.com. Они предоставляют поддержку OEmbed для различных сайтов, которые сами не выполняют OEmbed.

...