Ты же знаешь что переучиваться сложнее чем сразу учиться правильно.
Не надо так советовать, у нас из без этого поповщины хватает.
andrewkard пишет:
А что лучше 5000 функций в коде
Три класса (или на худой конец файла с десятком ф-ций).
И пусть пишет global -- это гораздо правильнее (в контексте, да, он их не знает, но все же классов, их области видимости и инкапсуляции) чем тупоголовая передача параметров.
При рефакторе будет легче поудалять кучу глобалов и понатыкать $this, чем перепиливать апи с кол-вом и порядком аргументов.
Утверждения противоречат друг другу, следовательно, выбери какое-то одно утверждение либо докажи отсутствие противоречия.
Наш реферер проверяется именно в контексте CSRF, а не митм. А любая CSRF содержит в себе митм. Поэтому я и сказал "в этом контексте".
Мелкий пишет:
при старте сессии генерируется токен
И даже если он меняется, то:
а) От чужого хоста это спасает, да...
б) На довренном домене/поддомене НЕ спасает, т.к. атакующий может сходить на нужную страницу аяксом и сматчить оттуда токен, затем сфрмировав запрос с токеном -- сделать какашку.
Только проблема тут уже не в CSRF, а в XSS, как я и говорил ранее.
teddy пишет:
бла-бла-бла
Согласен.
teddy пишет:
Если генерировать токен для GET параметра, и сверять этот токен ТОЛЬКО при изменении данных
Ты этот токен будешь передавать в гет-форму или гет-строку для пост-формы, которая и лежит в замазанном подгруженном айфрейме, иначе сравнивать будет не с чем.
teddy пишет:
С реферером такое не прокатит потому что ты просто убьешь любые переходы со сторонних ресурсов, что конечно же недопустимо, если речь идет не о админке
Нет же, изменение данных даже вне админки уже подразумевает точки доступа явно не являющиеся тупым ридонли, в том числе и местом входа с любого внешнего ресурса.
teddy пишет:
Ну, кто что думает?
Я пока остался при своем мнении -- реферер. Ибо реферер проще токена в реализации.
Кстати, можешь поковырять мою поделку (admin/admin) -- там на реферерах.
И даже есть места, где удаление идет через гет-параметр, например в списке пользователей (знаю, решето, и про это есть в моем TODO).
isset вполне нормальный выбор, если не требуется проверять NULL-ы
teddy пишет:
Лучше проверить например на isset, потому что данного ключа может просто не существовать
Так существование или нуллы?
teddy пишет:
наивный Попробуй ответить на вопрос Мелкого
Мелкий пишет:
какая тебе проблема попросить браузер пользователя сделать не GET-запрос на атакуемую страницу, а тот же POST?
Аяксом, вестимо, только, аяксом (ну ладно, еще форму в ифрейм отправить). Но!!!
1) Если мы говорим о том же самом сайте, то у нас XSS, а это другая проблема, не так ли?
2) Если каким-то образом атакующий узнал о том, что жертва ходит на другой конкретный сайт, то,
даже при условии что, на стороне другого сайта будет XSS, или сторонний сайт принадлежит атакующему:
а) для аякса (1): сработает COP (Cross Origin Policy).
б) для аякса (2): при условии что домен "родственный", ты не подумал про CORS.
в) и для аякса (3) и для ифрейма (1): ты не подумал про COP для POST (проверить реферер).
Бонус: реферер статичен, в отличии от токенов, и не требует соотв. обвязки и пинания туда-сюда-обратно.
И давай не будем говорить что реферер можно подделать -- в этом контексте у нас не MiTM.
А вот и подмывательное БИДЭ, давно я его не видел.
Или это BazaDannyh? И как тогда это переводится на английский?
1) Ты забыл поставить LIMIT 1
2) Кто за тебя будет фетчить результат?
3) mysql_ устарело и будет удалена (если уже не удалена) в новых версиях пхп.
4) $_POST['login']может вообще не быть если форму не сабмитили.
5) Включай полный уровень вывода ошибок, без него жизни нет.
6) Читать: http://forum.php.su/topic.php?fo...33&topic=793
проверить например на isset, потому что данного ключа может просто не существовать
Не надо нам тут гвозди забивать двуручной пилой.
Deonis пишет:
Устроит
1) Перенести хранение сессии в БД, полностью и чтоб она только там была.
2) Стартовать сессию (ага, к БД не забудь подключиться) всегда, вне зависимости от того кто это, гость или пользак.
И если гость -- формировать идентичный профилю пользака объект, с пометкой что это гостевая роль.
3) Перевести все, требующие защиты от CSRF места, на POST/PUT/DELETE запросы.
После чего не использовать CSRF-токен вообще.
Только учти что эти три пункта легко могут обеспечить тебя гемором на пол года вперед.
Поэтому определись:
а) готов ли ты к долгоделу?
б) готов ли ты велосипедить?
в) может лучше взять серьезный фреймворк? там все это есть
г) может оставить все как есть?