Получить произвольную страницу в браузере и обработать через JavaScript

Но читаю интернет и поражаюсь: похоже, что такого действия в браузере сделать нельзя.

Ты понимаешь последствия того, что это было бы возможно?

Ты DDOS'ер придумываешь что ли?

Ты понимаешь последствия того, что это было бы возможно?

Не понимаю. Сейчас серверов в интернете около миллиарда. Людей на земле 8 миллиардов. Соотношение 1:8, не такое уж большое. При этом с сервера можно делать кроссдоменные запросы, а с браузеров - нет. Какая разница откуда идет запрос? Какая разница что ломать - сервер или браузер? Везде будут последствия.

В браузере это помогает бороться с XSS — не сможешь слить куки на другой сервер.

Так, нашел такую штуку как букмарклеты:

Букмарклет(bookmarklet) - это javascript-код, который сохраняется как закладка в браузере. Он работает за счет использования протокола <a href="javascript:...">.

Выбирая такую закладку, вы запускаете яваскрипт-код в контексте текущей страницы. А дальше он уже может делать что угодно: править страницу, делать запросы к серверу и, вообще, использовать всю мощь современного javascript.

В общем, можно пойти по пути JSONP. Грузить страницу как яваскрипт-код (уж его-то можно брать с любого домена):

<script type="text/javascript"
         src="https://yandex.ru/search/?text=привет">
</script>

Нет, не побег из тега <Script>.

Надо запретить исполняться коду внутри фальшивого тега <script>, например через атрибут defer + несуществующий скрипт который никогда не загрузится.

Потом попробовать вытянуть содержимое файльшивого <script> из DOM-модели.

Что именно ты хочешь сделать с полученным текстом?

Сравнить его с ответом другого поисковика (поисковиков).

chromium-browser --disable-web-security

Позволит без CORS делать что хочешь.

Нужно кроссбраузерно.

хакеры на моем лоре

pjscrape

Надо писать расширение для браузера.

Нужно кроссбраузерно.

Тогда надо написать расширение для нескольких браузеров. Mozilla уже начала работу над автоматическим портированием расширений для Chrome.

А если ты хочешь, чтобы всё происходило на твоём сайте, где ты будешь показывать рекламу, зарабатывать деньги и не делиться с «Яндексом», то увы...

И как ты будешь уверен что другие боты работают по тому же алгоритму? А если эти боты еще и js/ajax выполняют и за прочими ресурсами ходят? Тогда их страница будет отличаться от твоей.

разве нельзя обратиться AJAX-запросом по урлу?

А если ты хочешь, чтобы всё происходило на твоём сайте

Я хотел чтоб все было распределенно.

разве нельзя обратиться AJAX-запросом по урлу?

Можно только к урлу своего домена.

pjscrape

Я чет не понял, в какой среде оно выполняется?

И как ты будешь уверен что другие боты работают по тому же алгоритму? А если эти боты еще и js/ajax выполняют и за прочими ресурсами ходят? Тогда их страница будет отличаться от твоей.

А это неважно. Можно на крайняк засунуть ответ поисковика в отдельный фрейм.

ёпрст, напиши простой сервер на python/node/whatever и отдавай json-ом со своего домена. Работы на 10 минут.

ёпрст, напиши простой сервер на python/node/whatever и отдавай json-ом со своего домена. Работы на 10 минут.

Это не проблема.

Просто после N-го количества запросов поисковик перестает отдавать контент. Просит капчу с предупреждением.

iframe?

Ну тогда нужно юзать платные сервисы от поисковиков, или делать LB кластер из серверов.

Просит капчу с предупреждением.

Удивительно! Вот же они жадные скоты!

Я хотел чтоб все было распределенно.

В www это не предусмотрено. Чтобы было распределённо, надо писать программу-клиент.

Хорошо, вот еще вариант:

Браузер не может получить доступ к данным, загруженным с другого домена. Он может только выполнить сторонний яваскрипт или только показать стороннюю картинку. Мы с этим соглашаемся.

Тогда вопрос в том, можем ли мы переслать эти данные в другое место. Например, к себе на сервер. Мы их не читаем, а только пересылаем. Это тоже запрещено?

Тогда вопрос в том, можем ли мы переслать эти данные в другое место. Например, к себе на сервер. Мы их не читаем, а только пересылаем. Это тоже запрещено?

Так ведь именно это и запрещено. Ты думал, стандарты HTML созданы для защиты «Яндекса» от тебя? Вся эта катавасия свистопляска Весь этот цирк с конями и огнями нужен для того, чтобы владелец сайта X не мог получить доступ к личным данным пользователя на сайте Y без явного согласия сайта Y в виде CORS. Если бы был какой-то способ сделать так, чтобы скрипты с сайта X могли прочитать данные пользователя на сайте Y и как-то их обработать, но ни в коем случае не послать «к себе на сервер», наверное, это было бы разрешено.

Так ведь именно это и запрещено. Ты думал, стандарты HTML созданы для защиты «Яндекса» от тебя? Вся эта катавасия свистопляска Весь этот цирк с конями и огнями нужен для того, чтобы владелец сайта X не мог получить доступ к личным данным пользователя на сайте Y без явного согласия сайта Y в виде CORS.

А почему это ее запрещено для серверной части, не могу я понять. Ну сделел кулхацкер себе прокси и крутит байтами как хочет. Если быть последоватеььным, то получение данных надо запрещать и для любых несвоих серверов. Тогда уж точно никто ничего не похитит. Почему же так не делают, а отдают проксям данные?

А почему это ее запрещено для серверной части, не могу я понять. Ну сделел кулхацкер себе прокси и крутит байтами как хочет.

Не совсем понимаю, о чём ты. Ты имеешь в виду, что кулхацкер делает прокси, юзер делает себе подключение к интернету через этот прокси, а кулхацкер делает MITM-атаку? Или что?

Потому что смотри:

1) Допустим, в моей локалке есть некий сервис, недоступный из-вне. На нём лежат супер-секретные данные. Но я не беспокоюсь - ведь он доступен только из локалки. Я захожу на сайт Васи Пупкина, который содержит скрипт, который обратится по адресу из локалки, скачает все секретные данные, а затем отправит на сервер. PROFIT.

2) Допустим, я залогинен на сайте X. Я захожу на вредоносный сайт Y. Он содержит в себе маааленький iframe, который я не замечу (он скрыт, находится за пределами экрана, имеет размер 1х1 пиксель - что угодно), в котором прогружается сайт X. Разумеется, при этом сайту X отправляются все нужные куки и во фрейме авторизация также будет. А затем с помощью JavaScript и DOM-операциями, владелец сайта Y сможет сделать от моего лица что угодно на сайте X. Если это форум/соцсеть - запостить от моего имени спам, если это админка сайта, то совершить дефейс и т. д. и т. п. То же самое касается и AJAX-запросов - при их выполнении сервер получит все необходимые куки для данного домена. А значит скрипт, который может послать AJAX-запрос, может сделать что угодно (в рамках того, что позволяет AJAX API сайта X) от имени пользователя на сайте X, хотя сам находится на сайте Y.

Скажешь, что ты неуловимый Джо? Есть набор сайтов вроде гугла, мейлрушечки, вконтактика и т. п. 90% пользователей непрерывно залогинены хоть на одном из них. А между тем угон аккаунтов на них может принести профит. Соответственно, сайту злоумышленника (или же хакер может взломать и заразить вполне мирный сайт) есть смысл разместить код, проверяющий авторизацию популярных сервисов и атакующий, если она есть. А вот браузер с защитой от XSS так сделать ему не даст.

ее=не

Для GET'а без кук CORS не нужен. Другое дело, что в запросе обязательно будет X-Requested-With, а там уже сервер может отдать всё что угодно. :)

Для GET'а без кук CORS не нужен. Другое дело, что в запросе обязательно будет X-Requested-With, а там уже сервер может отдать всё что угодно. :)

Ну а почему тогда нет доступа даже к JS коду публичного API:

Почему не видно текста JavaScript скрипта после загрузки?

Там никаких кук не используется.

в какой среде оно выполняется?

в браузере

есть отдельный вариант для ноды.

Как эвакуирусь из бара домой, проверю.

Таки да, попутал. Даже без preflight'а необходимо, чтобы были CORS-хедеры в ответе. Сорре.

Но читаю интернет и поражаюсь

Я вот читаю и тебя и поражаюсь. Как такого можно не знать.

А хочешь еще одно открытие.
К странице в iframe через js нет никакого доступа, вообще О_О!!!

Если iframe с этого же домена, то спокойно можно получать и изменять DOM..

http://www.w3schools.com/jsref/prop_frame_contentdocument.asp

Вариант подключения стороннего сервиса через script чем тебе не разновидность кросс-доменности? Практически то-же самое.

Нету распределенности. Через яваскрипт запросы к поисковику с разных ip-шников. Через прокси только с одного хоста и через 1000 запросов его ip-шник будет забанен.