| << предыдущая заметка | следующая заметка >> |
Температура 38, лежу в кровати с мобильником, делать нечего, размышляю. Ну никак не получается у меня выстроить концепцию сервера на одном домене. Ход мысли таков:
ДАНО: Авторизованный пользователь Вася Пупкин pupkin.binoniq.net зашел в блог соседа по серверу hacker.binoniq.net, где имеется (пока не выгнали) вредоносный JS-код. Это данность, которая не обсуждается. Вопрос в том, как сделать так, чтобы: 1) Хакер не смог украть васину авторизацию, 2) Хакер не смог заставить браузер Васи выполнить от имени Васи системные действия (оставить комментарий, например). Рассмотрим оба случая.
1) Авторизация у Васи — в куке, действующей для всего сервера *.binoniq.net Куку можно подсмотреть, но она привязана к Васиному IP, поэтому воспользоваться ею хакер не сможет. Если у Васи сменился IP — кука автоматически (незаметно для Васи) восстановится через переброску на служебный поддомен x.binoniq.net, для которого у Васи в браузере имеется вторая кука — не привязанная к IP, зато узкой видимости: только серверу x.binoniq.net. Разумеется, хакер может в своем аккаунте заставить браузер Васи открыть в iframe 1x1 этот x.binoniq.net, и даже, насколько я понимаю, получить средствами JS доступ к его содержимому (сервер-то родной). Но не к кукам ифрейма — window.[iframe x.binoniq].document.cookie браузер ему не покажет. Ведь не покажет же? Я правильно рассуждаю?
Тут есть еще, правда, тонкость, потому что я планирую использовать не только куки, но еще, например, браузерные хранилища. Но либо на них распространяются те же принципы, либо я их буду использовать для чего-то менее важного, нежели авторизация. Не суть.
Иными словами, по 1 пункту я не вижу изъянов. Проблемы с пунктом 2.
2) Чтобы от имени Васи (и незаметно для него) хакер смог выполнить системное действие (например, оставить комментарий), ему достаточно с помощью JS заставить васин браузер послать соответствующий аякс-запрос на сервер, типа:
Ajax(«comment.php»,{action:«send_comment»,id:123,text:«Я СОШОЛ СУМА И ПЕШУ ХУЙНЮ»});
Чтобы это стало невозможным, я планировал любые системные действия выполнять в два этапа: сперва окно, затем действие. Открывается окно (форма редактирования, вопрос «удалить пост?» и т.п.). Это окно содержит также уникальный токен, без которого сервер не примет действие:
Ajax(«comment.php»,{token:8AC4D5F3E05D1,action:«send_comment»,id:123,text:...
Это работает, если всплывающее окно на странице распахивается так, что доступа к нему и его токену у хакера нет, например грузится в iframe с системного x.binoniq.net. Хакер может распахнуть перед Васиным носом форму написания нового комментария, но не более. Вася сперва удивится, затем пожалуется в поддержку и хакера закроем.
Проблема в том, что мне сейчас подумалось: если x.binoniq.net на родном сервере, то хакер имеет доступ к его содержимому — всякие там window.[iframe x.binoniq].innerHTML — и вполне может прочесть конструкцию var token="8AC4D5F3E05D1" или
<INPUT TYPE=SUBMIT VALUE=«ОТПРАВИТЬ» ONCLICK='Ajax(«comment.php»,{token:8AC4D5F3E05D1.........>
Разумеется, все это невозможно, если домен для системных операций делать абсолютно чужим: не x.binoniq.net, а binoniq.ru Но мне очень не хочется предлагать всем, кто захочет себе поставить движок сервиса, регистрировать два домена.
Мне кажется, все-таки должно быть красивое решение. Но я его пока не вижу.
А вы?
| << предыдущая заметка | следующая заметка >> |

О Сатана, куда катится интернет.
А ваши слова насчет "сотен килобайт" и вовсе обнаруживают полное непонимание. Идите в ЖЖ. Открыл пост с комментариями - 2мб. Нажал "написать комментарий" - загрузилась новая страница еще на 1мб. Нажал "отправить", получил страницу "ваш коментарий отправлен, вы можете его посмотреть здесь" - еще 1мб. Пошел туда - снова 2мб. Красота!
И фраза про "любую страницу, на которую всегда можно сослаться" великолепна. Особенно если вспомнить сайт Мегафона, где, как оказалось, можно сослаться на чужие формы написания СМС с их текстом. Прекрасны сайты, которые для любой системной операции грузят отдельную страницу, на которую можно отдельно ссылаться.
А ваше возмущение Jquеry я охотно разделяю - действительно тормозная штука, помогающая начинающим осваивать JS, который им без этого слишком был бы сложен.
Так что мои вкусы с яндексовским топом не совпадают.
1. Классический сервис имеет доменное имя и пытается его раскрутить. Я строю свободную систему для независимых равноправных сайтов, среди которых binoniq.net не обязан быть самым массовым.
2. Классический сервис пытается заставить людей завести здесь аккаунт, только тогда они получат полноправный сервис. Я строю систему, в которой нет разницы между аккаунтами моего сайта и любого другого, поддерживающего наш открытый коммуникационный протокол.
3. В классическом сервисе взаимодействие между пользователями обеспечивает сервер. У меня - браузер пользователя. Собирать по нужным серверам нужные данные - это его задача. Простейший пример - френдлента с разных серверов в реальном времени: В конечном итоге работать с сетью binoniq будет можно, даже открыв браузером локальный файл c:/binoniq.htm с тонким клиентом, если родной сайт вдруг упал.
4. Классический сервис не использует браузерные хранилища. В моей системе браузер пользователя - это ресурс сети. В случае недоступности отдельных серверов текстовые данные смогут восстановиться в общем доступе, сохранившись в чьих-то браузерах.
Есть еще куча нюансов, связанных с концепцией сверхдинамичной страницы (жизнь которой не прекращается после загрузки, а лишь начинается), принципом сверхдинамичного контента (контент всегда формируется в реальном времени для конкретного пользователя) и т.п. Но это нюансы технические. А идеологические - те, что я перечислил. Иными словами, этот проект абсолютно не для ценителей классического веба 1.0 образца 90-х. Возможно, даже не для ценителей современного. Вот только бы удалось задуманное. Технически оно осуществимо.
Именно так - написать нельзя. Проверка этой авторизации делалась на клиенте.
Сколько потребовалось времени, чтобы это неудобство протокола обойти?
Сейчас, на первый взгляд, все выглядит примерно так же: защита от хакеров строится на поведении жаба-скриптов в браузерах. Правда, тут вроде как бы пользователь заинтересован в том, чтобы все работало как надо, но как-то это неосторожно.
Вон, к примеру, известная почтовая программа тоже по идее должна вложения как надо показывать, но сколько вирусов построены были на дырках в ней.
вместо написания клиентов под венду, магось и бубунту вас ждет написание тонких клиентов под ослика, лису и вебкит, как минимум. а когда потом придут опероманы и человеко-хромъ-о-ножки, да с лора забредут фанаты линкса, то всё, пизда отделу техподдержки =))
имхо, сервак у вас занимается всякой фигней. то, что должен делать клиент, генерится на серваке. почему бы серваку не заниматься базой с версионным хранением контента, обработкой загружаемых фоток, хранением статических файлов, и т.д.? отдавать только ответ в виде json. а браузер уже сам обработает эти данные и отстроит страницу?
здесь получается, что все скрипты динамические, некэшируемые и вообще говоря ошибка в темплейте чуть ли не до 500 Server Error может довести.
кстати страница с постом и комментарием вообще может быть размером 2кб, скрипты к ней около 10-20кб чтоб совсем от души (ну плюс запрещенная к упоминанию здесь вами "j query для новичков" в 31кб, которая кстати сказать закэширована с гугля у половины интернета) и стили, сменой которых без перезагрузки страницы можно влегкую менять дизайн.
а те 2 мегабайта, которые идут с жж, это тот же шлак, который вы раз от разу грузите majax'ом, ну только объем его в жж феерически велик, а так те же уши.
зы два раза пытался запустить этот движок. так ничего и не получилось. видимо очень критична версия apache, php, mysql и бог знает еще чего.
ззы nothing personal.
Та мешанина объектов, которые выводятся на странице, не поддается осмыслению и описанию. Где-то у вас ссылкой кнопка, где-то кнопкой, где-то onclick висит, где-то текст на ссылке из css тянется. Структура такая, что перенести стилями один блок в другое место - это значит везде с точностью до пикселя прописать position:absolute (утрирую), вложенность разных сущеностей в один контейнер и наоборот, когда семантически похожие сущности лежат в разных местах. По моему мнению, шаблон должен быть вообще один. А дизайн менять разными файлами стилей. С текущими шаблонами это нереально, я пробовал.
Про другие сервисы мне неинтересно говорить вообще. В пример негодного блогохостинга привели вы, я лишь провел параллель. И что кто там посылает кому из них тоже неинтересно.
Может быть, вопросов с безопасностью в конечном итоге стало бы меньше.
У Лукьяненко такой:
Отдельно есть темплейты для комментариев и т.п.
Движок отображает любой дизайн, какой нарисуешь и положишь в /template
Сам я не дизайнер и вопросами дизайна не занимаюсь, писать мне по поводу дизайна не имеет смысла. Не нравится дизайн Лукьяненко? Нарисуйте ему другой шаблон.
1. template = <div id='loginobr' style='cursor:pointer; padding:2px; margin: 1px 10px 1px 10px; border:1px dotted #B0B0B0;' onclick="majax('login.php',{action:'openid_form'})">
2. <INPUT type='text' size='7' style="color: #777777" value="поиск" onclick="majax('okno.php',{a:'search'})">
3. <a title='Заходы на эту страницу по ссылкам<br>и через поисковики.' href="javascript:{majax}">статистика</a>
плюс ко всему то, что прошито в переменные шаблона тоже может содержать разметку, как я понимаю.
тут вопрос не дизайна, а подхода к коду, который одновременно генерится+шаблонизируется+стайлится+скриптится совместно с данными.
зы ладно, заканчиваю, удалились далеко от топика.
ззы выздоравливайте.
И что вам мешает написать в шаблон что-то, что нравится больше, я тоже не понимаю.
это шаблон, рукописный. Вася Пупкин, который заведет блог на этом движке в первую очередь будет пытаться не украсть чужую авторизацию, а сменить дизайн. И легкой задачей это не будет.
Конкретно не нравится. div комментария, который отдает движок (берется не из шаблона, а именно движок генерит Html код), поменять нельзя. с id'шником, name'ом, class'ом и style'ом одновременно.
> И что вам мешает написать в шаблон что-то, что нравится больше, я тоже не понимаю.
Написать можно, но не все. Тут даже проблема больше в том, чтобы не сломать, чтоб оно работать продолжало...
Отдайте json с комментариями браузеру, он сам отстроит дерево в нужном виде, не надо гонять тучу одинакового некэшируемого html'я. То же касается обращения к серваку за очередным окошком - лишние это запросы.
Вы правы в том, что некоторые старые модули движка рисуют иногда свой код, я их планомерно подчищаю.
По всем остальным вопросам - с вашего позволения останусь при своем мнении. Я уже услышал весь спектр советов: от совета прекратить строить велосипед и набрать кучи готовых библиотек на любой случай - и до совета отказаться от браузера и написать с нуля собственный клиент :)
Я, конечно, нищеброд и все такое.
Ссылка:
Добавлю, что эта технология, на мой взгляд, является лучшим способом отделить данные от UI (то бишь представление).
И еще добавлю, что современные браузеры позволяют "рендерить" XSLT самостоятельно, а не на стороне сервера, например, таки способом сделано в yandex mail.
Ну и PS.
В России, почему то, незаслуженно мало внимания уделяется данной технологии (приятное исключение - Хостсиэмэс, ссылку не даю, чтобы не считали рекламой). Разве что поседение пару лет стали на нее переходить (примеры - лебедев, яндекс).
Вы меня конечно извините, но меня волнуют гораздо более серьезные вопросы, чем чей-то чужой язык, который (в некоторых браузерах) поможет преобразовывать данные в текст :)
Вот если бы вы мне прислали язык кэширования данных в браузерных хранилищах... Или язык-стандарт команд для межсайтового общения окон... Было бы дело, чтоб мне самому мнемонику не выдумывать.
А как данные в текст преобразовать - это задачки для класса информатики.
Я рекомендую XSLT исключительно для шаблонизации. Т.е. это готовый мощнейший шаблонизатор. Уверяю вас, реализовать такое это задача не для уроков информатики, жестко ошибаетесь ) На это просто без слез смотреть нельзя, уж извините ) Это не хуже чем у остальных подобных, но возможности, грубо говоря, ограничены тупой подстановкой str_replace. XSL решает задачу куда изящнее. У лебедева на сайте студии одно из лучших русскоязычных описаний технологии
Касаемо межбраузерного/межсайтового взаимодействия могу рассуждать только теоретически, с практикой не знаком вообще. Но что-то мне подсказывает, что XML и тут подойдет. Более того, можно задействовать встроенный в браузер XSL процессор для рендеринга HTML. Например, браузер запрашивает у другого браузера информацию в виде XML (чистые данные), затем берет XSL шаблон (загружает с сервера или берет еще откуда то, с какого-то хранилища) и рендерит HTML. Но это теория, не уверен, что можно реализовать такое. В любом случае, стандартов не так много - XML, JSON возможно еще Protocol Buffers от Google.
За страницы, которые весят 1мб, нужно отрывать руки вебмастеру и засовывать их в плечи. Тем более, если это страница "написать комментарий". А сейчас, если вы не в курсе, в LJ это заменили на кнопку "Expand" на аяксе, которые нужно каждую нажать, дождаться загрузки (прогресс которой нигде не показывается), а если загрузка не прошла, нажать еще раз. И так для каждой ветки. Ну а если отключился от интернета, то ложись и помирай, этих комментариев ты не увидишь. Лично мне проще было бы загрузить страницу на 1мб со всеми комментариями к посту. Тем более оверхед на сотню аяксозапросов будет побольше, о нагрузке на процессор я уже не говорю.
> И фраза про "любую страницу, на которую всегда можно сослаться" великолепна. Особенно если вспомнить сайт Мегафона, где, как оказалось, можно сослаться на чужие формы написания СМС с их текстом. Прекрасны сайты, которые для любой системной операции грузят отдельную страницу, на которую можно отдельно ссылаться.
На страницы с результатом POST-запросов (в которых нормальные люди отправляют содержимое формы) сослаться нельзя, никак. И я практически уверен, что эти GET-страницы там появились именно в результате увлечения их написателей красивыми формочками для ввода текста на основе "Современных веб-технологий". И жопоруких кодеров этих самые технологии не спасут.
С этим я абсолютно согласен, но это перпендикулярно вашей концепции статических страниц.
Статическая страница несет в себе все необходимое на все случаи жизни: скрытые меню, формы поиска, системы авторизации, логина-разлогина, формы написания комментария (и скрипты проверки его полей), и плюс вагон скриптов на все случаи жизни, и вообще все, что может понадобиться пользователю чисто теоретически.
На практике же 99% всех посетителей, загрузив конкретную страницу, не нуждаются на ней ни в форме поиска, ни в меню логина с выпадающими вереницами фейсбучно-гугловских иконок, и прочей фигне.
Я проектирую сайт таким образом, чтобы в странице не содержалось ничего лишнего, а все нужное подгружалось аяксом, если вдруг потребуется. Захотел человек сделать поиск по сайту или залогиниться? Пожалуйста, мигом подгрузилась с сервера нужная форма и нужные скрипты.
Вот вы думаете, что это желтое окно формы комментария находится в коде страницы? Отнюдь, там находится лишь команда majax('comment.php',{a:'comform',dat:1945}), которая подгружает его с сервера. А строчка "опции" в форме комментария - подгружает дополнительную панельку, которая большинству при написании комментария не нужна: majax('comment.php',{a:'loadpanel',idhelp:this.id}) И так далее. Слава богу, что современный интернет (даже мобильный) позволяет это делать мгновенно. Все, что не нужно на странице 99% посетителей, должно в коде отсутствовать, а грузиться по аяксу.
А если челоно задержки при подгрузке всяких запчастей сайта все-таки ощутимы и я предпочитаю загрузить все сразу, нагрузка на процессор при этом гораздо меньше, а размером можно пренебречь. Тем более, каквек отключился от сети или у него нестабильное соединение? Придется сидеть без комментариев, поиска и прочего, а если что-то понадобилось, то подключаться.
Интернет, нынче, конечно, быстрый, все стерпит, но зачем экономить десять килобайт при загрузке страницы, чтобы потом дергать сервер на каждый чих (а задержка никуда не делась, и опять же AJAX-запросы никак не отслеживаются видимым пользователю образом), грузить процессор перелопачиванием тонн HTML?
Полагаю, у нас с вами абсолютно перпендикулярные понимания технологий, и спор не имеет смысла.
В любом случае у меня в движке все красивости ограничены вот этими желтыми окошками системного интерфейса. Все остальное - на редкость некрасивое и целиком зависит от дизайнера и его темплейтов и css.
А кто не доверяет, тот пусть регистрирует второй домен.
через регистрацию
Флаг HttpOnly для cookies. Может это решит проблему (кроме Safari).
Есть уязвимости: но может
быть для Вашего случая они не страшны?
Честно скажу, что одна из причин, почему я хочу разрешить скрипты и железно изолировать авторизацию - это как раз чтобы впредь не париться и не изучать мегабайтные описания всевозможных хаков и уязвимостей.
Потому что иначе придется пару лет посвятить фильтрам пользовательского контента и затыканию всех дырок (при этом заткнется всё полезное, включая создание собственных дизайнов), и все равно в итоге окажется, что в каком-нибудь из модулей заметки какой-то пользователь догадался указать темплайт, в котором css, а в этом css команда border:IEexecCalculate(%10%20\\onmouseover="АЦКИЙ ХАК"), и пиздец, у половины пользователей теперь украдена авторизация.
Хочется дыру заткнуть глобально, а не маневрируя между описаниями существующих хаков.
Ты позволяешь себе не считать 9% пользователей (такова доля IE6, данные современные)? :-(
Пока ещё очень даже актуально проверять проекты на совместимость с IE6.
Меня, как раз, Гугл убил тем, что принудительно перестал поддерживать браузер, который нормально выполняет ВСЕ функции того же Gmail'а и YouTube.
IE имеет море проблем в принципе, любой. Версия - не главное, и нечего на ней ставить акцент.
Так, к примеру, можно быть залогиненным в ГМейле, но не на Ютубе. В таком случае авторизация на Ютубе происходит в один клик, без ввода пароля (ибо оба используют авторизацию через accounts.google.com)
Вообще тот же гугл глобально всех авторизует на *.blogger.com, при том, что в шаблон своего блога можно вставить какой угодно JS. Но как они решают там проблемы с безопасностью, я не в курсе
Я даже не говорю о том, что пользователь будет ходить по чужим журналам вечно разлогиненный (а значит, не будет попадать в статистику посещений, не сможет оставить комментарий и т.п.).
Но что помешает хакеру написать document.getElementById('кнопка залогиниться').click() ?
Либо я вас не понимаю, либо вы не в теме совсем.
>Но что помешает хакеру написать >document.getElementById('кнопка залогиниться').click() ?
пользователя перебросит на форму авторизации (не аутентификации, а именно авторизации) на x.binoniq.net, которая спросит "бложик с домена хакерского хочет от вашего имени насрать в ленту" - дать/недать
посмотрите, как OAuth работает у всяких писькомерялок для твиттора.
но ведь проблема существует не для тех, кто регит *свои* домены, а для тех, кто использует домены на *вашем* хостинге, разве нет?
попробуйте рассмотреть ту же проблему, но вместо hacker.binoniq.net, подставить standalone-hacker-bioniq.net и отдельную инсталяцию движка на этом серверею
1) один домен для личных сайтов-движков, где нет проблем взлома отдельного пользователя, потому что пользователь ровно один.
2) два домена для сервисов, на которых живет куча людей - для сервисов это обычно не проблема. (домены вида пользователь.сервис.net/.ru, например)
Мы как бы говорим с вами о разных вещах - я о том, куда поближе спрятать ключ от автомобиля, но не оставлять в дверце, а вы о том, что надо, уходя, снимать колесо, и тогда не страшно, что машина не заперта :)
Речь была про ифреймы, а не хождение по разным страницам. Вообще не о том, извините еще раз.
А по теме - ни хера не соображаю.
и этому:
то документы могут лезть друг к другу во внутренности только если оба на это согласились (явно установили document.domain в одинаковое значение)
Из того, что я понял - это какие-то спецификации новых браузеров? Есть опасения, что старые их не поддерживают и не знают, что такое window.domain
А вот идея сменить протокол - она по-своему интересна. Скорее всего, доменные фичи были и в старых браузерах с самого начала. А настроить отвечать site.ru:81 все-таки проще, чем заводить второе доменное имя. Хотя...
Тут вкратце на родном:
http://ru.wikipedia.org/wiki/Правило_ограничения_домена
А тут вроде неплохо о разных методах XSS:
ЗЫ Кириллица в УРЛах не нравится движку?
Вверху каждого комментария есть +/- понравилось не понравилось. У меня при наведении на них мышью стрелка меняется на стрелку изменения размера окна (вверх-вниз) - это так и задумано или особенность моей системы?
2. Чтобы вредоносный скрипт не причинил бед, очевидно нужен уникальный токен, который нельзя получить никак иначе.
Например, это может быть дополнительная временная кука проставленная для сайта pupkin.binoniq.net, точно так же недоступная для JS. Иными словами, разделены авторизация и право на действие.
Оградить Васю от автопоста на самой странице hacker.binoniq.net - невозможно, в силу того, что скрипт может "распахнуть" окно коммента, вбить текст и сделать сабмит. Но это уже будут проблемы самого хакера, верно?
Оградить от автопоста запросто: если окно коммента открывается таким образом через frame, что оно на hacker.binoniq.net становится недоступным (хоть и на его странице), он никакой субмит сделать в нем не сможет. Вопрос именно в том, как сделать его недоступным, не прибегая к заведению второго домена.
Альтернативный вариант "чтобы два раза не вставать" - техническим доменом может являться сам домен юзера. Т.е. весь пост идет только с его домена и кука разрешающая посты - тоже привязана только к его домену, а не ко всему binoniq.net
Ситуация когда у пользователя одновременно два браузера и он оба их активно использует - не слишком часта, мягко говоря, но тем не менее.
Отдельный забавный момент - многие браузеры не умеют чистить это хранилище.
Attacks using cross-subdomain cooking
This is like cross-site cooking, except that it does not rely on browser vulnerabilities. Rather, it relies on the fact that wildcard cookies can be set by one subdomain that affect other subdomains
зависит от того, насколько сильно у тебя все завязано конкретно на сессиях, хотя таким способом можно подменять вообще любые куки.
вектор атаки: хакер устанавливает для Васи куку на домен "*.binoniq.net", у Васи слетает авторизация. Вася заходит в свой бложег, логинится, у хакера есть кука и если он может послать запрос в блог Васи с того же IP, что и Вася (а он может, увы), то Вася будет песать хуйню
Наберите "домашние биотуалеты" в Google прямо сейчас!
а если хакер сидит с Васей в одном интернет кафе (коллега по работе решил пошутить)? привязка к IP пройдет и Вася сойдет с ума и будет песать хуйню
Подтверждаю, бесит.
Когда вся страница не помещается в окне браузера, удобно нажимать стрелки, чтобы прокручивать её выше/ниже и правее/левее.
Долго уже читаю всю эту утопию и не понимаю, как ты не видишь простой вещи: конечному пользователю вообще доверять нельзя. И его браузеру доверять нельзя. Точка.
Браузерам нельзя доверять.
У них есть дополнения, и миллион компаний пишет всякую хрень, которая предлагает установить собственное дополнение ("Вы согласны установить наш тулбар для просмотра голых сисек Натали Портман?", как самый примитивный пример), которое будет резвиться на просторах браузера как угодно, игнорируя всю безопасность и любые стандарты, по которым, как ты думаешь, можно что-то надёжно накодить.
То есть, не может быть доверия вообще секюрити того же javascript, когда на стороне пользователя может стоять абсолютно всё, что угодно. Кривые бэты и дополнения - это ещё хороший вариант.
И не нужно думать, что пренебрежительно малое количество пользователей подвержено угрозам.
Один простенький вирус - и вместо "восстановления информации по данным браузеров пользователей" будет полная жопа.
Я уже молчу о том, сколько критически личной информации могут высрать браузеры при такой концепции распределённого хранения информации.
Для этого достаточно очень мелких и незаметных ошибок.
Не идиоты годами придумывали существующие системы.
Ты, я так понимаю, уверен, что идиоты, но это опасная иллюзия.
Остаётся, конечно, вариант, что ты специально создаёшь уязвимую систему. Вот только и от этого толку - ноль. Она сразу войдёт в список малваре в фаерволлах и антивирусах.
(Фух. Высрался. Даже не знаю, почему хотелось.)
Мы говорим о системе, которая строится на СТАНДАРТНОЙ политике безопасности, используемой во всех браузерах.
Если какой-то умник установил себе в браузер дополнение, нарушающее эту политику, и злоумышленник смог украсть ЕГО авторизацию - это его проблема. Будь как все, не ломай свой браузер.
А что касается восстановления информации из непроверенных источников - это всего лишь вопрос проверки подлинности, он решается хоть цифровой подписью.
По крайней мере, куку поставленную в lleo.me/pupkin/ у меня не получается прочитать в pupkin.lleo.me. Чем не "другой" домен?
всего комментариев: 128