• Как именно устроены session и cookies?

    @deliro
    1. Нет никакой синхронизации. Сервер может только указать клиенту, что ему нужно установить куку X в значение Y хэдером Set-Cookie и считать с пришедшего на сервер запроса куки (все куки отправляются в каждом запросе на сервер).
    2. Сессии могут храниться на клиенте (signed cookie session). При этом используется подпись куки с помощью HMAC, чтобы данные сессии не могли быть свободно изменены клиентом. Но обычно сессии хранятся на сервере. Тут выбор огромный: от баз данных и key-value хранилищ (Redis, например) до простых файлов. При этом, клиенту посылается кука ID сессии (так сервер идентифицирует юзера), которую злоумышленник может стащить. Таким кукам, дабы защитить юзеров от XSS, ставится флаг HttpOnly, который советует браузеру не давать эту куку скриптам вроде JS. В этом случае, стащить куку получится только завладев браузером, файловой системой юзера или через багу браузера.
    3. Смотри второй ответ. В некоторых случаях - да. Но редко.
    4. Можно передавать значение session id в строке URL (GET - параметром), вроде такого: example.com/some/page/?session_id=2af26905dcf31a1d... Некоторые сервисы используют это, как fallback вариант, однако, он очень небезопасен, т.к. любой XSS или простой безобидный JS вроде Яндекс.Метрика видит весь URL. Так что, посылаем юзера включать куки.
    Ответ написан
    4 комментария
  • Какую защиту использовать от спам ботов?

    @egorinsk
    Повторяю способы защиты, выбирайте любой, который нравится:

    Начнем со случая, когад у вас маленький (меньше 100 тыс юников в день/1 млн зарегистрированных юзеров) сайт.

    1) Сделать невидимое поле с именем email. 98% ботов-дебилов его заполнят, дальше вы понимаете, что с ними делать и куда вносить их IP. Чтобы не палиться, не пишите style=display:none, а скройте его чуть хитрее.

    Этот способ у меня отсеивает практически всех ботов на одном сайте. Правда, там боты, не заточенные под сайт, а просто, которые ходят и заполняют все формы подряд своей рекламой. Типа Хрумера наверно.

    2) Заполняемое яваскриптом поле типа hidden. Куча ботов не выполняют яваскрипт. Куки, кстати, наоборот, большинство ботов исправно присылают. Реферер и юзер-агент тоже обычно у них правильный.

    3) Более радикальный подход — убрать кнопку submit, заменив ее на div, который по событию onclick собирает значения полей формы и отправляет их аяксом. Аттрибут action тега form сделать указывающим на скрипт-ловушку. Если бот не написан специально под ваш сайт, он тупо не сможет отправить такую форму.

    Ок, допустим, вам не повезло, и ваш сайт с миллионами пользователей атакуют спамеры специально написанными скриптами. Что мы можем вам предложить?

    4) Добавлять вычисляемые/расшифровываемые яваскриптом поля. Внезапная смена алгоритма шифрования в 2 часа ночи скорее всего сдаст тех ботов, которые смогли через нее пробиться, но не успели переписать алгоритм.

    5) Проверять поддержку клиентом Flash (загружать флешку и через нее подписывать форму кодом).

    6) Проверять соответствие User-Agent и уровня поддержки технологий HTML5/CSS3 (например, определенные версии браузеров не поддерживают border-radius, другие поддерживают, и тд.)

    Более серьезные возможности дают методы статистического анализа. Например, можно вычленять из сообщений несловарные слова (это будут ссылки например) и анализировать источники их отправки. Например, если 1000 пользователей начинает за час отправлять по 100 сообщений не-друзьям с одним и тем же словом super-shop — это явный признак спам-рассылки. Для таких систем надо собирать статистику и писать белые/черные правила, вводить негласные лимиты подозрительных действий, в общем. серьезная работа.

    Можно, как вконтакте, привязывать аккаунты к телефонам. это работает.

    Еще немного рассуждений на эту тему тут: habrahabr.ru/qa/16920/#answer_70019

    А использование капчи в формах говорит о лени/низкой квалификации/урезанном бюджете или непрофессионализме и причиняет неудобства пользователям.
    Ответ написан
    1 комментарий