Comments 145
Красивое решение. Но получается эта техника позволяет какому угодно сайту получить доступ к моим персональным данным, если они возвращаются любым другим сервером в виде JSON?
Получается так.
Только если для получения JSON используется GET. Именно поэтому в ASP.NET MVC дефолтное поведение для REST-методов —
stackoverflow.com/a/8464685/236660
JsonRequestBehavior.DenyGet.stackoverflow.com/a/8464685/236660
Это не «эта техника», это абсолютно любой сайт, который использует любую из реализаций «remember me» с помощью куков.
Если вы сможете из пользовательского браузера выполнять запросы хоть куда и полностью контролировать процесс обработки ответа — тогда вы сможете делать что угодно от имени пользователя.
Если вы сможете из пользовательского браузера выполнять запросы хоть куда и полностью контролировать процесс обработки ответа — тогда вы сможете делать что угодно от имени пользователя.
Нельзя. Пофиксино в браузерах. Давно.
И все такие взяли и обновились до последней версии, да?
Это не последняя версия. Фикс был в 2007 году. Думаю 6 лет слоупокства — это уже провал.
Не знаю как сейчас, но в 2009 году этот же приём работал в сочетании с __defineSetter__ — в Хроме и FF.
haacked.com/archive/2009/06/25/json-hijacking.aspx
haacked.com/archive/2009/06/25/json-hijacking.aspx
А прервать выполнение скрипта из другого скрипта нельзя? А потом поиметь доступ к переменным.
UFO just landed and posted this here
Функции можно переопределить.
while — нельзя :)Тем не менее, если сделать какой-нибудь setTimeout, а потом сделать какой-нибудь window.stop (document.execute(«stop»)?), то не случиться ли чуда?
UFO just landed and posted this here
Т.е. запустить асинхронно другой скрипт и прервать выполнение скриптов вообще никак нельзя?
Даже если и можно, прервав выполнение, Вы остановите скрипт до объявления структур с полезной информацией.
А вам не нужно прерывать выполнение скрипта, вам нужно прервать выполнение конкретной (первой) инструкции и продолжить. Что звучит (и по факту) абсолютно нереально.
UFO just landed and posted this here
Нельзя. JS выполняется в один поток. Пока один блок кода не отработает, другой не начнет свою работу
Кроме Rhino — там можно, поскольку он построен поверх Java Runtime где есть многопочная модель.
Вы хотели сказать «многопочечная»? :)
Вы уверены? Там есть потоки?
Использовал Rhino — делал честное многопоточное приложение — 10 рабочих процессов с локом конвеера для каждого.
Если не верите мне то…
Если не верите мне то…
// целевой класс org.qxfusion.EngineInfo
// запускать так $ java org.qxfusion.EngineInfo.class
package org.qxfusion;
import java.util.*;
import javax.script.*;
public class EngineInfo {
public static void main( String[] args ) {
ScriptEngineManager mgr = new ScriptEngineManager();
List<ScriptEngineFactory> factories = mgr.getEngineFactories();
for ( ScriptEngineFactory factory : factories ) {
System.out.println( String.format(
"engineName: %s, THREADING: %s",
factory.getEngineName(),
factory.getParameter( "THREADING" ) ) );
}
}
}
Гм… <капитан>это же не JavaScript</капитан> :)
Т.е. вы из Java запускаете интерпретаторы, каждый — отдельный процесс?
Т.е. вы из Java запускаете интерпретаторы, каждый — отдельный процесс?
Вы вообще знаете что такое Mozilla Rhino? (многие путают с Mozilla Gecko — но это разные движки)
Зачем запускать новые копии ScriptEngine?
Зачем запускать новые копии ScriptEngine?
importPackage(java.lang); // куда же без него
var threadMain = function(a) { while(true) { print("Thread "+a); } } // вечный цикл
var thread1 = function() { return threadMain(1); } // поток 1
var thread2 = function() { return threadMain(2); } // поток 2
// конструктор объекта потока
var newThread = function(fn) {
return new java.lang.Thread( new java.lang.Runnable( { run: fn } ) );
}
var th1 = newThread(thread1); th1.start();
var th2 = newThread(thread2); th2.start();
// на выходе - честная работа 2 потоков (если не верите - смотрим отладчик)
Ну ок, с Rhino все приблизительно понятно.
Просто я немного не могу осознать как это согласуется с моделью работы стандартного JavaScript интерпретатора, где асинхронные методы отрабатывают по очереди.
Просто я немного не могу осознать как это согласуется с моделью работы стандартного JavaScript интерпретатора, где асинхронные методы отрабатывают по очереди.
Стоп, стоп, стоп.
Речь сейчас идет о Mozilla Rhino — он построен поверх Java где есть транзакционность данных и честная многопоточность — поэтому тут этой проблемы нету.
P.S. а Вы знаете что на Rhino есть Web серверы? по скорости он уступает V8 (JRE дает о себе знать) — но зато (1) лучше масштабируется (2) не нужны спагетти из callback (3) транзакционность присваиваний в многопоточной среде
P.P.S. ну и еще от меня — Rhino можно запустить и на QNX тоже — т.к. под нее есть JRE (от IBM) — а вот node.js не собирается там :(
Речь сейчас идет о Mozilla Rhino — он построен поверх Java где есть транзакционность данных и честная многопоточность — поэтому тут этой проблемы нету.
P.S. а Вы знаете что на Rhino есть Web серверы? по скорости он уступает V8 (JRE дает о себе знать) — но зато (1) лучше масштабируется (2) не нужны спагетти из callback (3) транзакционность присваиваний в многопоточной среде
P.P.S. ну и еще от меня — Rhino можно запустить и на QNX тоже — т.к. под нее есть JRE (от IBM) — а вот node.js не собирается там :(
Стандартный JavaScript — Вы подразумеваете ECMAScript Standart или какой-либо другой?
Поочередная модель обработки вызовов это специфика не языка, а конкретной реализации среды выполнения — т.е. движке интерпретатора.
Поочередная модель обработки вызовов это специфика не языка, а конкретной реализации среды выполнения — т.е. движке интерпретатора.
while — конструкция языка, зарезервированное слово, разве можно её переопределить?
ну придется им парсер не сложный написать или использовать готовый… Прям такая защита, что ни обойти, ни объехать. Только жизнь усложняют тем, кто по назначению использует.
UFO just landed and posted this here
А что сорцы браузеров/JS движков уже закрыли?
Правда такая атака уже не для школяров.
Правда такая атака уже не для школяров.
Очевидно, что если вы сможете пользователю подсунуть свой браузер — то не нужно особо париться. Вы в принципе тогда сможете встроить в него код, позволяющий делать что угодно с чем угодно.
Достаточно украсть куки? Если у юзера не включена 2х уровневая авторизация.
Т.е. у Гугла есть противодействие и на это. На других сайтах, где используют такой же трюк видимо будет достаточно украсть сессию/куки.
Т.е. у Гугла есть противодействие и на это. На других сайтах, где используют такой же трюк видимо будет достаточно украсть сессию/куки.
Не нужно ничего воровать — если вы смогли пользователю установить свой браузер, то можно просто использовать его как прокси.
От кражи кук более-менее спасают CSRF токены
UFO just landed and posted this here
CSRF токен — это особое поле в запросе или вызове API которое должно или (1) соответстветствовать значению токена в сессии (например PHPSESSID) или (2) закрытому (секретному) значение сессии на сервере — в случае несовпадения — запрос не выполняется.
UFO just landed and posted this here
Учитывая что Ваш коммент плюсанули — видно кто-то не знает мат. часть тоже.
Собственно прежде чем нести непонятно что — прочтите en.wikipedia.org/wiki/Cross-site_request_forgery
Давайте так — вот Вам список сайтов:
(1) www.live.com/
(2) www.gmail.com/
… думаю пока хватит…
Сделаете для них CSRF — и нет проблем :)
P.S. если не осилите — у меня еще есть уйма сайтов на попробывать
Собственно прежде чем нести непонятно что — прочтите en.wikipedia.org/wiki/Cross-site_request_forgery
Давайте так — вот Вам список сайтов:
(1) www.live.com/
(2) www.gmail.com/
… думаю пока хватит…
Сделаете для них CSRF — и нет проблем :)
P.S. если не осилите — у меня еще есть уйма сайтов на попробывать
Это всё прекрасно, но как всё-таки CSRF-токены спасают от кражи кук? (напомню, что в этой ветке мы обсуждаем «От кражи кук более-менее спасают CSRF токены»)
«Собственно прежде чем нести непонятно что» — собственно, товарищ выше всё правильно написал — если есть XSS, то можно токен из страницы получить.
Если вы не согласны — будьте немного более конкретны и укажите, в чём именно человек ошибся.
Если вы не согласны — будьте немного более конкретны и укажите, в чём именно человек ошибся.
(1) не путайте CSRF и XSS — т.к. XSS дает по сути контекст пользователя
(2) CSRF токен позволяет блокировать выполнение команды (запроса) без наличия валидного токена — таким образом просто сделав фэйковый редирект запрос не выполниться, таким образом если на сайте НЕТУ XSS то эксплуатация CSRF не выйдет — т.к. токен не получить.
Кража куки — это когда другой пользователь или скрипт минуя пользователя выполняет от его лица вредоносный запрос (например накрутить голоса, разместить комментарий и т.д.)
Про XSS можете прочесть тут — ru.wikipedia.org/wiki/XSS
P.S. нахождение XSS это большая удача — которую далеко не всегда можно найти.
(2) CSRF токен позволяет блокировать выполнение команды (запроса) без наличия валидного токена — таким образом просто сделав фэйковый редирект запрос не выполниться, таким образом если на сайте НЕТУ XSS то эксплуатация CSRF не выйдет — т.к. токен не получить.
Кража куки — это когда другой пользователь или скрипт минуя пользователя выполняет от его лица вредоносный запрос (например накрутить голоса, разместить комментарий и т.д.)
Про XSS можете прочесть тут — ru.wikipedia.org/wiki/XSS
P.S. нахождение XSS это большая удача — которую далеко не всегда можно найти.
Мы и не путали. Изначальный вопрос был «От кражи кук более-менее спасают CSRF токены»
Предполагается, что куки будут сворованы активным XSS. Если XSS есть, тогда CSRF-токены от кражи кук (и вообще чего бы то ни было) не спасают.
С этим вы согласны?
>> Кража куки — это когда другой пользователь или скрипт минуя пользователя выполняет от его лица вредоносный запрос
Я боюсь, что вы неправы. Кража куки — это «кража куки», в буквальном смысле получение данных куки другим лицом. Выполнение вредоносного запроса от лица пользователя это не кража, а, к примеру, упомянутая выше атака типа CSRF.
Предполагается, что куки будут сворованы активным XSS. Если XSS есть, тогда CSRF-токены от кражи кук (и вообще чего бы то ни было) не спасают.
С этим вы согласны?
>> Кража куки — это когда другой пользователь или скрипт минуя пользователя выполняет от его лица вредоносный запрос
Я боюсь, что вы неправы. Кража куки — это «кража куки», в буквальном смысле получение данных куки другим лицом. Выполнение вредоносного запроса от лица пользователя это не кража, а, к примеру, упомянутая выше атака типа CSRF.
UFO just landed and posted this here
Вас уже в твиттере цитируют, в курсе?)
CSRF-токены спасают от CSRF-атак, от кражи кук они не спасают и не должны.
Если злоумышленник смог своровать куку, то может своровать и токен.
Если злоумышленник смог своровать куку, то может своровать и токен.
Это если кража идет постоянно.
Если токены сделаны нормально (постоянно обновляются при каждом запросе) и между кражей и использованием кук клиент успевает наделать еще запросов, ворованный токен протухает. И наоборот, если вор юзает токен, у клиента вылезает «опаньки, иди-ка перелогинься», что есть повод задуматься как минимум или хотя бы сбросить ворованую серию токенов.
Если токены сделаны нормально (постоянно обновляются при каждом запросе) и между кражей и использованием кук клиент успевает наделать еще запросов, ворованный токен протухает. И наоборот, если вор юзает токен, у клиента вылезает «опаньки, иди-ка перелогинься», что есть повод задуматься как минимум или хотя бы сбросить ворованую серию токенов.
Перегенерация токенов на каждый запрос больше принесёт вреда, чем пользы.
С одной стороны она создаёт иллюзию защищённости (вы надеетесь, что текущий запрос клиента будет не последним, иначе «ой»). С другой стороны — проект перестанет работать, будучи открытым в нескольких вкладках одновременно. И решать эту проблему вы будете созданием не 1 токена, а кучи разных, по одному на форму, страницу, раздел, итд, на что фантазии хватит. И будете их со слезами поддерживать.
С одной стороны она создаёт иллюзию защищённости (вы надеетесь, что текущий запрос клиента будет не последним, иначе «ой»). С другой стороны — проект перестанет работать, будучи открытым в нескольких вкладках одновременно. И решать эту проблему вы будете созданием не 1 токена, а кучи разных, по одному на форму, страницу, раздел, итд, на что фантазии хватит. И будете их со слезами поддерживать.
Страницы? Вкладки? Разделы? Не, не слышал. Вы про каменный век что ли?
Вместо того, чтобы ёрничать, могли бы написать по сути, в чём я не прав (если есть что писать, конечно же).
Ну я вот как-то не встречал например банковского софта, позволяющего работать в несколько вкладок. Гугловские приложения в принципе это позволяют, но по факту там полностью новая сессия загружается для каждой вкладки. Ну и вообще, современные AJAX-приложения, как правило, одностраничные.
RIA не панацея. Хабр — многостраничный. Если вы сделаете так, как вы предложили, на Хабре, то он сломается.
Про банковский софт — банкинг, которым я пользуюсь, позволяет работать в нескольких вкладках.
Когда я работал в банке и мы писали приклад для операционистов — он тоже работал в нескольких вкладках.
Про банковский софт — банкинг, которым я пользуюсь, позволяет работать в нескольких вкладках.
Когда я работал в банке и мы писали приклад для операционистов — он тоже работал в нескольких вкладках.
Хабр — сайт. С элементами, но не более.
Я про приложения. GMail, Office365, ДБО, вот это всё.
«Позволяет работать» — может быть. Я не знаю, как там реализована защита от CSRF, я не знаю, как реализовано открытые вкладок, ну и вообще в этом нет принципиально невозможного.
Я про приложения. GMail, Office365, ДБО, вот это всё.
«Позволяет работать» — может быть. Я не знаю, как там реализована защита от CSRF, я не знаю, как реализовано открытые вкладок, ну и вообще в этом нет принципиально невозможного.
Защита от CSRF реализуется с помощью CSRF-токенов. Потому они и называются CSRF-токенами, что защищают от CSRF-атак. С помощью них НЕ защищаются от кражи кук.
В RIA, в свою очередь, тоже нет смысла изобретать что-то новое на коленке, потому что есть, как минимум, OAuth
В RIA, в свою очередь, тоже нет смысла изобретать что-то новое на коленке, потому что есть, как минимум, OAuth
Нормально реализованные CSRF токены защищают в том числе от кражи кук, кроме случая, когда кража идёт в реальном времени.
Ничего нового тут изобретать не нужно, достаточно прямыми руками реализовать.
OAuth тут вообще не при чем; даже если его нет, сервис авторизации всё равно лучше делать как отдельный сервис на отдельном поддомене и отдельном сервере (возможно виртуальном) с отдельной же базой данных.
Ничего нового тут изобретать не нужно, достаточно прямыми руками реализовать.
OAuth тут вообще не при чем; даже если его нет, сервис авторизации всё равно лучше делать как отдельный сервис на отдельном поддомене и отдельном сервере (возможно виртуальном) с отдельной же базой данных.
>> кроме случая, когда кража идёт в реальном времени.
Решения или работают, или не работают. Если для того, чтобы ваш клиент был защищён — он обязан бесконечно кликать и никогда не уходить с вашего сайта, то это не защита, а лишь иллюзия.
Прямость рук тут вообще ни при чём, это решение принципиально работает плохо (я уже несколько раз говорил о работе в нескольких вкладках, которые вы так упорно отрицаете).
>> сервис авторизации всё равно лучше делать как отдельный сервис на отдельном поддомене и отдельном сервере
Вы не путаете «авторизацию» с «аутентификацией»?
Так или иначе, расскажите как реализовать их «правильно», чтобы они работали на любом сферическом сайте, предположим, на хабре.
Решения или работают, или не работают. Если для того, чтобы ваш клиент был защищён — он обязан бесконечно кликать и никогда не уходить с вашего сайта, то это не защита, а лишь иллюзия.
Прямость рук тут вообще ни при чём, это решение принципиально работает плохо (я уже несколько раз говорил о работе в нескольких вкладках, которые вы так упорно отрицаете).
>> сервис авторизации всё равно лучше делать как отдельный сервис на отдельном поддомене и отдельном сервере
Вы не путаете «авторизацию» с «аутентификацией»?
Так или иначе, расскажите как реализовать их «правильно», чтобы они работали на любом сферическом сайте, предположим, на хабре.
Да не надо пользователю никуда кликать или «не уходить», если программист что-то слышал про очереди. И вкладки тоже не проблема, если он умеет работать с HTTP протоколом. Под авторизацией в широком смысле сегодня понимают весь процесс идентификации, аутентификации и авторизации пользователя. И да, если хакер впарил жертве трояна с функцией удаленного рабочего стола, то возможностями одного только браузера не защититься.
С уважением, ваш Кэп.
С уважением, ваш Кэп.
Вы говорите слишком общие вещи. «Если программист что-то слышал про очереди», «если руки прямые», «если умеет работать с HTTP».
Вы можете конкретно описать процесс, не юля и без прибауток про капитана?
Есть сайт — хабр. Ваше решение?
ps: каким боком тут «очереди» — непонятно (разве что вы опять, как и в случае с CSRF-токеном, термин использовали не к месту)
Вы можете конкретно описать процесс, не юля и без прибауток про капитана?
Есть сайт — хабр. Ваше решение?
ps: каким боком тут «очереди» — непонятно (разве что вы опять, как и в случае с CSRF-токеном, термин использовали не к месту)
Вы просите конспект книжки «безопасность веб-приложений для гуманитариев».
Будет время — может и напишу отдельным постом. Но вообще ничего сложного нет, следуй стандартам и на каждом шаге проверяй всё, что присылает клиент.
Вкратце есть три куки, одна — токен сессии пользователя, вторая — токен окна в рамках сессии, третья — токен следующей операции в рамках окна (и да, доп. поля под токены в формах вручную заводят разве что в джумле. И то вроде уже отказались). Дальше нужно просто всё аккуратно реализовать с учетом стандартов и особенностей работы в сети, когда некоторые запросы могут подвисать.
Будет время — может и напишу отдельным постом. Но вообще ничего сложного нет, следуй стандартам и на каждом шаге проверяй всё, что присылает клиент.
Вкратце есть три куки, одна — токен сессии пользователя, вторая — токен окна в рамках сессии, третья — токен следующей операции в рамках окна (и да, доп. поля под токены в формах вручную заводят разве что в джумле. И то вроде уже отказались). Дальше нужно просто всё аккуратно реализовать с учетом стандартов и особенностей работы в сети, когда некоторые запросы могут подвисать.
Что мешает все три своровать и использовать в своих грязных целях?
Как вы отличите «настоящего» клиента от злоумышленника, при том что и тот, и другой отправят вам одинаковые наборы куков?
Как вы отличите «настоящего» клиента от злоумышленника, при том что и тот, и другой отправят вам одинаковые наборы куков?
Ну например то, что первая кука привязана к браузеру и айпишнику, вторая — к окну, а третья обновляется при каждой операции.
Да, насчет очередей: принцип тот же, что и в электронных брелках для генерации одноразовых паролей. Вы в банке точно программистом работали?
Да, насчет очередей: принцип тот же, что и в электронных брелках для генерации одноразовых паролей. Вы в банке точно программистом работали?
Если у вас есть кука, которая привязывается к паре браузер-ip, тогда вам не нужна вторая оконная. Она не добавляет к безопасности вообще ничего (только иллюзию, что чем больше кук, тем всё лучше защищено).
Собственно, то, о чём вы сейчас говорите — стандартная защита от session fixation (и ряда родственных атак), и это всё ни с CSRF, ни с CSRF-токеном никак не связано. Вы уверены, что вы продолжаете отвечать на заданный изначально вопрос? Всё таки, пересмотрите, пожалуйста, этот тредик с самого начала.
Про очереди — как только вы перестанете выдумывать термины на ходу, а использовать устоявшиеся, вас сразу начнут понимать.
Собственно, то, о чём вы сейчас говорите — стандартная защита от session fixation (и ряда родственных атак), и это всё ни с CSRF, ни с CSRF-токеном никак не связано. Вы уверены, что вы продолжаете отвечать на заданный изначально вопрос? Всё таки, пересмотрите, пожалуйста, этот тредик с самого начала.
Про очереди — как только вы перестанете выдумывать термины на ходу, а использовать устоявшиеся, вас сразу начнут понимать.
Вторая кука нужна как раз для вкладок и окон, потому что у них третьи куки разные.
Насчет терминов — я не знаю другого перевода для queue
Насчет терминов — я не знаю другого перевода для queue
Зачем конкретно она нужна? Что именно с точки зрения безопасности вторая и третья куки добавляют? Что изменится, с точки зрения безопасности, если их не будет?
Простите, я устал.
Эти куки защищают именно от CSRF, когда некто может вставить свой код, делающий запросы на атакуемый сайт, в html-код стороннего сайта и заманить туда жертву, залогиненную на атакуемом сайте. Как раз случай, рассматриваемый в этой статье.
Если речь, допустим, о рассылке спама (GMail в контексте этой статьи; была именно такая дырка на мейл.ру), это остановит рассылку в худшем случае через 1 письмо.
Если более серьезное приложение, скажем платежная система, то каждая критическая операция должна дополнительно защищаться внешним одноразовым паролем. Если все такие операции снабжаются подобным паролем, то да, вторая и третья куки не нужны.
Эти куки защищают именно от CSRF, когда некто может вставить свой код, делающий запросы на атакуемый сайт, в html-код стороннего сайта и заманить туда жертву, залогиненную на атакуемом сайте. Как раз случай, рассматриваемый в этой статье.
Если речь, допустим, о рассылке спама (GMail в контексте этой статьи; была именно такая дырка на мейл.ру), это остановит рассылку в худшем случае через 1 письмо.
Если более серьезное приложение, скажем платежная система, то каждая критическая операция должна дополнительно защищаться внешним одноразовым паролем. Если все такие операции снабжаются подобным паролем, то да, вторая и третья куки не нужны.
UFO just landed and posted this here
>> Простите, я устал.
Вы бы не устали, если бы не растекались мыслью по дереву и не уходили от темы.
Я сейчас тезисно изложу, чтобы вы поняли, что именно вы делаете не так:
1. CSRF-токен не обязан защищать от воровства кук, он лишь защищает от CSRF-атак. Реализация: рандомный сессионный токен
2. От воровства кук защищаемся запоминая в сессии ip и браузер клиента (самый примитивный вариант).
Итого:
1. Это 2 разных способа защиты, которые между собой никак не связаны
2. Наличие одного не подразумевает наличие другого. Именно поэтому фраза «CSRF-токены защищают от воровства кук» некорректно. Не защищают они, защищают другие решения
3. 3 куки не нужны, 1 достаточно, чтобы иметь приложение защищённое как и ваше
Вы бы не устали, если бы не растекались мыслью по дереву и не уходили от темы.
Я сейчас тезисно изложу, чтобы вы поняли, что именно вы делаете не так:
1. CSRF-токен не обязан защищать от воровства кук, он лишь защищает от CSRF-атак. Реализация: рандомный сессионный токен
2. От воровства кук защищаемся запоминая в сессии ip и браузер клиента (самый примитивный вариант).
Итого:
1. Это 2 разных способа защиты, которые между собой никак не связаны
2. Наличие одного не подразумевает наличие другого. Именно поэтому фраза «CSRF-токены защищают от воровства кук» некорректно. Не защищают они, защищают другие решения
3. 3 куки не нужны, 1 достаточно, чтобы иметь приложение защищённое как и ваше
UFO just landed and posted this here
о каком токене идет речь? csrf token, signed cookie, sid?
csrf токен обновлять нет абсолютно никакого смысла. его можно украсть только через XSS и использовать только когда юзер на вашей странице. А значит пока XSS работает то он может получать новые сгенеренные токены
другое дело access_token
csrf токен обновлять нет абсолютно никакого смысла. его можно украсть только через XSS и использовать только когда юзер на вашей странице. А значит пока XSS работает то он может получать новые сгенеренные токены
другое дело access_token
И кого этот «не школяр» сможет атаковать своим патченым браузером? Себя?
Там где предполагается «по назначению», очевидно, такое вставляться не будет.
Для использования «по назначению» делают API.
Другой вариант от гугла — )]}' в начале ответа.
можно писать просто /* тогда все будет комментарием.
и вообще тема стара как мир, уже года 4 как запретили переопределять Array конструктор.
и вообще тема стара как мир, уже года 4 как запретили переопределять Array конструктор.
Путём переопределения глобального конструктора array или методов доступа злоумышленник может вызывать произвольный метод всякий раз, когда устанавливается атрибут объекта (массива или хэша), тем самым получая доступ к содержимому JSON.Нет не может, см. тоже самое правило. А конкретней — либо переопределение не будет допущено политиками броузера, либо javascript со стороны хакерского сайта не получит доступ к объектам из
<script> другого сайта (все тот же кроссдомен).Гугль и другие делают это по другим причинам:
— XSS, SQL и другие инъекции позволяещие хоть в какой-то мере cross-site scripting (ошибка разработчика сайта);
— браузер пишут тоже люди, и некоторые используют бета-версии, например nightly (ошибка разработчика браузера);
— есть люди по разным причинам допускающие у себя кроссдомен javascript (человеческий фактор);
Одного XSRF в нормальном виде однозначно не достаточно.
Как-то так.
Вы не правы. <script src= будет исполнен в контексте основного домена, не важно с какого домена грузится скрипт. Но для доступа к скрипту будут использованы куки нужного хоста.
Да нет, это вы не правы — скипт будет выполнен, и куки будут нужные. НО страничка, откуда был вызван скипт, НИКОГДА (кроме 3-х причин описаных выше) не получит данные из этого скрипта.
А вы попробуйте как нибудь эту технику и убедитесь, что такое не возможно.
UPD. вы же сами это признали комментом ниже
А вы попробуйте как нибудь эту технику и убедитесь, что такое не возможно.
UPD. вы же сами это признали комментом ниже
у вас беспорядок в суждениях. скрипт это скрипт, в нем нет никаких объектов. крос домен тут вообще не причем, тк даже если вы будете грузите такой же скрипт со своего домена вы также не сможете прочитать хеш. крос домен распростроняется только на доступы между разными ориджинами и фреймами, и на скрос доменные запросы. на своей странице вы вольны выполнять скрипты с google.com
скрипт это скрипт, в нем нет никаких объектовДолго пытался понять. :) В скрипте все объекты — все переменные, массивы, значения массивов и т.д. Следующий скрипт не работает кроссдоменно:
// BOOM - access denied:
var json = frames['script_to_google'].document.getElementById('json_from_google');
// BOOM - access denied:
var json = frames['script_to_google'].var_json_from_google;
Теперь надеюсь понятно…
>frames['script_to_google']
>frames
>script
>frames
похоже все годы инфосека прошли впустую… я просто вытекаю из этого треда… пойду читать основы html…
>frames
>script
>frames
похоже все годы инфосека прошли впустую… я просто вытекаю из этого треда… пойду читать основы html…
Теперь да. Видимо frames['script_to_google'] говорит нам что-то… или нет? При чем тут это? Мы же про <script src?
А результат выполнения
<script src=... т.е. объект JSON нужно прочитать у нас на страничке…return.js:
zlo.html:
Затем:
Вопрос: что покажет алерт c нашей странички (zloi_host.com)?
Варианты ответа:
1) taina
2) Ничего, потому что SOP ('drugoi_host.com' ne 'zloi_host.com').
var secret='taina';
zlo.html:
<script src=http://drugoi_host.com/return.js>alert(secret);</script>Затем:
http://zloi_host.com/zlo.htmВопрос: что покажет алерт c нашей странички (zloi_host.com)?
Варианты ответа:
1) taina
2) Ничего, потому что SOP ('drugoi_host.com' ne 'zloi_host.com').
У вас не правильный вызов (не делайте так никогда) — правильно будет через второй вызов:
И ответ тогда конечно 1) taina.
Но меня интересует вопрос, каким образом тогда передадутся куки от drugoi_host на drugoi_host.com? Еще интересней как вы собираетесь таким образом передавать параметры для генератора json (тот же token например)?
<script src="http://drugoi_host.com/return.js"></script>
<script>alert(secret);</script>
И ответ тогда конечно 1) taina.
Но меня интересует вопрос, каким образом тогда передадутся куки от drugoi_host на drugoi_host.com? Еще интересней как вы собираетесь таким образом передавать параметры для генератора json (тот же token например)?
1 потому что так работает веб. куки передаются всегда тому сайту к которому они принадлежат. хотите вы этого или нет
2 токен это уже другая история, токен это не кука
2 токен это уже другая история, токен это не кука
1 потому что так работает веб. куки передаются всегда тому сайту к которому они принадлежат. хотите вы этого или нетАга, но только тогда это крупная ошибка дизайна сайта — не ограничить куки на инклюд, подгружаемый через source… это что-то…
Либо токен, либо куки только на страницу (не на js)… По другому — ну никак.
Коментом ниже я признал, что переопределять Аррай «таким вот образом» стало не возможным. И SOP тут не причем.
<script src = просто грузит «текст», а затем интерпретирует его как JS в контексте того домена откуда пришел вызов, а не того домена ОТКУДА был загружен скрипт.
stackoverflow.com/questions/1618993/alternative-to-cross-domain-javascripting
<script src = просто грузит «текст», а затем интерпретирует его как JS в контексте того домена откуда пришел вызов, а не того домена ОТКУДА был загружен скрипт.
stackoverflow.com/questions/1618993/alternative-to-cross-domain-javascripting
Посмотрите еще раз сюда:
А приведенный пример из оверфлоу вообще не получит cookie…
скипт будет выполнен, и куки будут нужныеНо JSON-то от гугля (из этого выполненного скрипта) вам нужно прочитать (интерпретировать) в своей страничке. Все эти объекты JSON не доступны нигде кроме скрипта от google.com.
А приведенный пример из оверфлоу вообще не получит cookie…
Не важно откуда JSON. Когда мы юзаем script src. SOP не работает. Массив перешел к нам. Все баста.
Сейчас это не актуально, потому что необходимо решить задачу:
Для этого был трюки с переопределением массива. Сейчас зафиксино. Но это не SOP. Объект уже у нас, он есть в памяти.
Сейчас это не актуально, потому что необходимо решить задачу:
<script>
[{"data":"value"}];
//Как мне прочитать data?
</script>Для этого был трюки с переопределением массива. Сейчас зафиксино. Но это не SOP. Объект уже у нас, он есть в памяти.
Баян. ребята, это атака — JSON Hijacking, была блокирована в 2007/2008 производителями браузеров. Так что в данном случае это «страховка» на случай если изобретут новый способ перехвата и осталось «с тех времен» ибо хуже не будет. То что в статье на столько старо, что с тех пор, как переопределяли Array() уже был «изобретен» новый способ (после фикса 2007 надо было найти новый способ и его нашли):
Object.prototype.__defineSetter__('Id', function(obj){alert(obj);});
И он тоже уже пофиксен в фаерфокса версии >3.0.11…
Все это история 8)
Object.prototype.__defineSetter__('Id', function(obj){alert(obj);});
И он тоже уже пофиксен в фаерфокса версии >3.0.11…
Все это история 8)
Гениально. Теперь многие разработчики вооружаться этой «фишкой» в копилку боевых навыков.
Такая защита делается установкой в заголовок AJAX запроса токена (как в django, например — X-CSRFToken) и соответствующей проверкой на стороне сервера перед отдачей JSON'a.
Стороннему сайту ни через
Стороннему сайту ни через
<script> заголовок не передать, ни сам токен не извлечь. Или у гугла есть какие-то причины не использовать такой подход?если бекенд юзает только сайт. а как API прикажете токен устанавливать?
UFO just landed and posted this here
Sign up to leave a comment.
Зачем Google добавляет while(1); к своим JSON-ответам?