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

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

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

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

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

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

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


html standards oembed
person David Ammouial    schedule 31.08.2011    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

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

person mmalone    schedule 03.11.2011

arrow_upward
1
arrow_downward

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

person Bonnici    schedule 28.09.2011

arrow_upward
0
arrow_downward

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

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

Шаги:

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

  3. Эксплойт:

    • by denial-of-service (DOS): e.g. redirect the URL to a tarpit or feed it a 1GB json response.
    • с помощью межсайтового скриптинга (XSS): внедрить случайный HTML-код на страницы, которые могут видеть другие люди.
    • путем кражи файла cookie сеанса администратора через XSS: теперь злоумышленник может войти в вашу CMS, чтобы загрузить файлы и использовать еще больше.

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

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

person vdboor    schedule 24.03.2013
comment
Если я интерпретирую это свойство, а вас беспокоят DDoS-атаки, вы можете сделать все это без oEmbed. Из-за этого я не вижу никакой дополнительной уязвимости. Что касается XSS-атак, да, именно поэтому, если вы разрешаете встраивание случайного интернет-контента на свой сайт, вы размещаете его в iframe, используя другой домен (и, желательно, также очищаете его от скриптов). Это касается контента с YouTube, а также с какого-то случайного сайта. Вы никогда не доверяете стороннему контенту, независимо от того, известен источник или нет. - person ravisorg; 03.06.2014