Страницу ты подгрузить сможешь из соображений юзер-френдли, и даже форму отправишь, но что-то изменить, если мне не понравится реферер, я тебе просто не дам.
А реферер тебе понравится Сразу после первого клика по какой нибудь ссылке в айфрейме. Да, это сложно провернуть, но факт остается фактом, это осуществимо технически.
Если хорошенько покопаться, может ещё варианты найдутся.
Например если кто то покопается в настройках/плагинах браузера жертвы, может поставить постоянный реферер. Надо глянуть что там предлагают конфиги и аддоны.
Плюс, при наличии XSS уязвимости, твой реферер легко подменится каким нибудь курлом и сессайди будет на руках для осуществления успешного запроса.
Да, понимаю что это другая проблема. Но получается что защита от CSRF на реферерах не самодостаточна - ещё один минус в копилку реферера...
И да, не всегда хакер имея sessid на руках захочет это сделать своими руками.
Что бы например не попасть в лог или тупо не упереться на ограниченное пользование по IP. Поэтому даже если увели sessid, не факт что проблемы будут создавать своими руками посему даже в таком случае CSRF имеет место быть.
Это смотря как приготовить.
Смотри, ты знаешь адрес этого топика и хочешь запостить от моего имени сообщение используя айфрейм. Ты знаешь адрес топика, но не знаешь мой GET токен(предположим что он тут есть). Страницу ты подгрузить сможешь из соображений юзер-френдли, но форму или сам токен я тебе просто не отдам, потому что адрес был запрошен без валидного параметра-токена.
Эти корсы и фреймопшены не кроссбраузерны и говорить тут неочем хотя бы потому, что клиентское приложение не должно заниматься безопасностью сервера.
DeepVarvar пишет:
Социальная инженерия сразу обсерится, т.к. придется мазанную форму сначала бросить просто в админку, затем заставить кликнуть на список пользаков, а потом уже что-то делать с пользаком ))
Да. Это хорошо, что ты понимаешь что проверка реферера не надежна ))
А я в свою очередь понимаю, что провести такую атаку очень сложно, но я сейчас не говорю про сложность атаки, а про наличие уязвимости в конечном счете...
DeepVarvar пишет:
А токен это (само|недо|пере)произвольный текст?
В отличии от реферера, нужно быть гадалкой что бы его угадать. Ну или уметь его украсть. Тут уже все зависит уровня безопасности приложения или дурости юзера.
А реферер - в большинстве CSRF атак обычно известен заранее. Разница же очевидна.
DeepVarvar пишет:
Понимаешь, да?
Да. А ещё я понимаю, что сервер не должен зависеть от клиента в плане безопасности.
Никогда не знаешь какие фичи/дыры/при обновлении браузера или просто казалось бы "безобидные настройки" отправляемых заголовков есть в наличии.
Ты этот токен будешь передавать в гет-форму или гет-строку для пост-формы, которая и лежит в замазанном подгруженном айфрейме
Нет Этого токена не будет в POST форме, в этом то и вся фича
Правда в сыром виде такой подход плохо сказывается на юзабельности если токен одноразовый. Придется дополнительно шаманить что бы юзер честно открывая несколько вкладок одной и той же страницы не отхвачивал бед реквест при сохранении данных.
Это пока единственный вариант который я смог придумать против замазанного айфрейма, который был бы более надежным чем X-Frame-Options
DeepVarvar пишет:
Я пока остался при своем мнении -- реферер. Ибо реферер проще токена в реализации.
Насчет простоты да, согласен. Но согласись это HTTP, его заголовки - произвольный текст
никогда не знаешь что придет на ум хитрожопому программисту, поэтому лучше не доверять таким данным. Например против замазанного айфрейма реферер бессилен
как вручную построить этот XML-запрос (у каждого веб-сервиса же он разный)
Сначала просто обратитесь к этим сервисам через SoapClient, далее вызовите необходbмый метод, затем вызовите __getLastRequest() и получите нужный XML для запроса (не забываем выставить опцию trace в true).
Далее методом POST отправляйте этот XML(как тело POST запроса) тем же курлом туда, где живет WSDL службы. Не забудьте установить Content-Type как text/xml.
В ответ должен вернуться XML с данными, которые можно будет распарсить например с помощью simplexml
На сколько помню это всё, что нужно. Пробуйте (Добавление)
Ну и конечно же в конце избавьтесь от SoapClient, раз уж отправляете сырые запросы
Не придирайся Кому-кому уж тебе точно должно быть понятно, почему я подчеркнул нулл.
И да, я в курсе что isset проверяет значения, а не ключи. Почему я так выразился - думаю должно быть понятно
Вернемся к CSRF.
Во первых когда ты говорил про
Цитата:
Перевести все, требующие защиты от CSRF места, на POST/PUT/DELETE запросы.
После чего не использовать CSRF-токен вообще.
О проверке реферера ты ничего не сказал. Ок, пусть так.
Да, браузер при отправке формы так же отправляет реферера, этим или отсутствием реферера можно воспользоваться(палка двух концов) для валидации запроса.
Но, если подгрузить атакуемую страницу на свою(мы злоумышленники) через iframe и пригласить туда жертву - можно осуществить CSRF атаку даже при проверке реферера на сервере жертвы.
Да, нельзя будет сделать это автоматически ввиду ограничений для кроссдоменных запросов, но есть одно НО.
Подгрузив атакуемую страницу через iframe, ты можешь "замазать" её собственной версткой, не скрыв iframe.
Даем ссылку жертве на нашу страничку и говорим, заполни форму по этой ссылке и получишь такие то плюшки.
Инпуты, которые будет заполнять жертва - будут инпутами той зоны, где авторизованна жертва.
Все что нужно злоумышленнику, это сделать качественные декорации вокруг разметки, которая подгружена из атакуемой страницы с помощью iframe.
И при отправке такой формы, реферером будет URL того сервера, с которого был подгружен контент.
И не важно это тот же самый сайт или нет.
CSRF успешно удался.
Но ведь скажешь ты, "в таком случае и токен не спасет, потому что он так же будет загружен через iframe в форму и окажется валидным при проверке на сервере", на что я отвечу:
Если генерировать токен для GET параметра, и сверять этот токен ТОЛЬКО при изменении данных, то атакующий ничего сделать не сможет.
Он может знать адрес атакуемой страницы и запросить её через iframe, но не будет знать токен аутентефицированного пользователя. Поэтому данные не будут сохранены. Желательно что бы токен был одноразовым, ведь утащить токен из GET параметра не составил труда.
Почему сравнивать токен из GET ТОЛЬКО при изменении данных? Что бы люди которые будут ходить например из поисковика могли успешно посетить страницу по этому адресу. С реферером такое не прокатит потому что ты просто убьешь любые переходы со сторонних ресурсов, что конечно же недопустимо, если речь идет не о админке.
Скажешь, можно можно воспользоваться X-Frame-Options? Не все браузеры это поддерживают. Фича относительно новая да и обязывать клиента следить за безопасностью сервера тоже не надежно.
Скажешь, можно написать js, который будет "запрещать" подгрузку через iframe? Sandbox у iframe способен убить js.
Не пойму, с каких пор проверка на наличие ключа перед его использованием, стало забиванием гвоздей двуручной пилой?
isset вполне нормальный выбор, если не требуется проверять NULL-ы.
DeepVarvar пишет:
3) Перевести все, требующие защиты от CSRF места, на POST/PUT/DELETE запросы.
После чего не использовать CSRF-токен вообще.
Есть ли смысл записывать токен в БД и при каждом запросе сверять его еще и там?
Нет. В двойной сверке с данными, которые хранятся на сервере, нет необходимости.
Deonis пишет:
Да и вообще, имеет ли смысл использовать токен после успешной авторизации, если работа ведется по SSL?
Задача - обезопасить себя от CSRF атак, поэтому нужно задействовать более подходящий для задачи механизм, то есть токены. Желательно одноразовые.
Deonis пишет:
Может быть достаточно просто проверять: есть сессия или нет?
Если речь о CSRF, то не достаточно. Нужно обязательно сверять токен отправленный клиентом и тот, что хранится на сервере. Ну а если токен от клиента не пришел, то такой запрос можно считать не валидным.
Deonis пишет:
$_SESSION['login'] === true;
Так это, вроде бы, не надёжно.
Лучше проверить например на isset, потому что данного ключа может просто не существовать.
Если нужно проверить на наличие ключа + сверить значение этого ключа, то действуем соответственно.
Так как вы нажимаете enter после ввода числа, затем вызываете nextInt(), происходит считывание только числового значения, а символ переноса строки порожденный нажатием enter остается висеть в буфере. Но после компилятор встречает вызов nextLine(), считывает оставшийся в буфере символ переноса строки и "идёт дальше" что бы вывести в консоль слово Last.
Решений данной проблемы несколько.
Самый простой - вызвать sc.nextLine(); после вызова nextInt() и таким образом считать зависший в буфере символ переноса строки.
Viper
Если вы читали внимательно, то я написал finfo/exif, т.е один из перечисленных, а не конкретно exif или оба сразу.
Что касается доступности - если пишем серьезное приложение, на шаредах ему не место, а если это не шаред, тогда речи о "недостающих" расширениях быть и не может.
И вообще, нормальный шаред хостер включает подобные расширения не задумываясь (если они отключены). А ненормальными лучше не пользоваться
Viper пишет:
плохо читали?
Viper пишет:
mp3 тоже конвертить в картинку?
Ага. Только плохо читали вы, а не я.
teddy пишет:
для картинок меня ещё не подводило
Мы же сейчас про картинки говорим?
Вообщем, я умываю руки)) Не хочу спорить с "аргументами". (Добавление)
teddy пишет:
Бывают случаи, когда mime из $_FILES точнее чем finfo/exif
Уточню, действительно только для случаев, когда mime определяется HTTP клиентом, например, браузером.
Viper
Хм а где тут костыль? это скорее усиление "брони" приложения.
Хуже не будет, успокоит школьников, добавит поинтов пристижа в копилку безопасности.
А так да, как уже говорил, это можно обойти.
DelphinPRO
Инструкцию давать нужно. Ибо не дашь инструкцию сейчас - запомнит, и будет думать, что все пучком. Поэтому инпуты всюду дырявые.
да кстати, одного getimagesize тоже не достаточно, и его тоже можно обойти
Ладно, как обычно, пишу зря) Полагайтесь на type и ждите гостей, если вы не "Неуловимый Джо".
Самое прикольное то, что насовать левые файлы можно как в случае первой предложенной проверки, так и в случае второй ))
Да, это распространенные "варианты", но спасут только от определенных ситуаций.
Эти проверки, скорее, для пристижа Что бы спугнуть часть нападающих
Но спать спокойно не выйдет.
Я предлагаю,
1. Обязательно проверять расширение файла
2. Если оно валидно, пересохранять картинку используя GD (это выкинет вредоносный код из файла, если он есть)
3. Если сохраняете файлы в директории у себя на сервере, отключайте там возможность исполнять PHP код.
4. Не позволять пользователю контролировать название загруженных файлов (переименовывать их)
Естественно это не все нюансы безопасности загрузки файлов, но для картинок меня ещё не подводило.
И да, если проверять mime, то лучше ещё и проверить соответствие mime из $_FILES и finfo/exif.
Бывают случаи, когда mime из $_FILES точнее чем finfo/exif. Угу.
Могут быть конечно проблемы при сравнении со всякими pjpeg, но будьте добры, используйте алиасы для "кривых" типов. Гулять так гулять)
Вообщем у меня всё, более подробно - в поисковиках и бложеках ну и конечно же собственные "ковыряния", куда же без них
Убрал много букаф выше.
Видимо, нужно было показать код... В спойлере реализация того, как я предпочитаю вести процесс рендеринга.
Правда много чего я оттуда убрал, что бы сосредоточиться конкретно на рендеринге.
Например убрал родительский класс, где реализован __call для плагинов, вместо интерфейса в addChild указал конкретную реализацию и ещё кое что.
Как видишь, "подсистема" очень проста. Если копнуть чуть глубже, то в конечном счете все ещё проще.
Если стало интересно, могу расписать workflow, где общий рендеринг сводится просто к "однажды инициализировать общий шаблон, а дальше просто возвращать массив из action-a".
Покажи, как ты реализуешь этими функциями наследование шаблонов?
Наследование шаблонов? Не, я таким не занимаюсь) У меня несколько иной подход к генерации разметки. Для меня есть только объект View в который можно встраивать такие же объекты с неограниченным уровнем вложенности (иерархия однотипных объектов)
Это все что нужно чтоб встроить один шаблон в другой когда это требуется. В самих вьюшках так же спокойно использую плагины для вью, например $this->translate('phrase'); (а ты как их юзаешь? много танцевать приходится?)
Только непонятно в чем удобство. Я действительно этого не понимаю.
ob_start, extract, include, ob_get_clean - этих 4 функций достаточно что бы сгенерить полноценный шаблон используя нативный синтаксис.
Кстати это как раз один из тех немногих случаев, где я готов защитить сторону экономии на спичках(собственный синтаксис и разметку в n строк кто то же парсит) Ну да ладно... )
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 1465
Сразу после первого клика по какой нибудь ссылке в айфрейме. Да, это сложно провернуть, но факт остается фактом, это осуществимо технически. 
))
Что то ты какой то наивный сегодня ))
