А заметили какую-то закономерность в подчистке истории сообщений? Неужели реальные, неспамные сообщения удаляют? Как-то похоже, что экономят на спичках.
Не знаю, не знаю.
Думаю речь идет о млрдах ключей. Так что далеко не спички.
Особо не исследовал этот вопрос, можно посмотреть.
Просто решил отмотать по максимуму переписку с одним из контактов — сообщения, которые были отправлены более 2х назад уже недоступны.
Вот сегодня читал старую переписку свою года 2008 части сообщений тупо нет, так что да подтверждаю база чистится причём сообщения пропали рандомно, то с моей стороны то со стороны собеседника.
Время для редактирования закончилось…
Идём в сообщество/паблик/etc
Нажимаем предложить новость.
Заливаем картинку, например, демотиватор.
Отправляем предложенную новость.
Перезагружаем страницу сообщества, снова «Предложить новость»
Видим предложенную новость.
Кликаем на время отправки.
Лайкаем залитый демотиватор и делимся с друзьями.
Оп. У нас на стене есть демотиватор от имени сообщества.
Сейчас VK стал уже более-менее адекватным по отношению к безопасности и приватности данных, а вот пару лет назад с помощью нехитрой связки m.vk.com + VK API + user api можно было выдрать на порядок больше информации, чем человек (как он полагал) позволил узнать с сайта
Честно говоря не ставил перед собой подобной задачи, постараюсь посмотреть.
Но все те гифки, которые были загружены до этого, сейчас удалены. И новых я не видел.
Предыдущий баг был жив всего несколько часов и год-два назад, насколько я знаю.
Я сейчас попробовал на моменте отправки сообщения с изображением подсунуть гифку из документов вместо обычной фотки — не выйдет (не вышло), формат отправляемых данных разный.
Раньше можно было залить gif-ку переименовав ее, а сейчас все, закрыли данную возможность. Интересно, чем опасен в плане безопасности анимированный gif (ну кроме раздражения пользователей фактом анимации)
BeLove, «две очень похожих статьи» в начале раздела Обзор являются одной и той же статьей. Первая версия на Insight IT была оригиналом, а вторая является её адаптацией для печати на бумаге в журнале Хакер.
1. Anti-CSRF токены
«Но как они его красиво реализовали» это сарказм? токен никак не должен зависить от параметров которые легко может узнать сам хакер — фром айди и ту айди… токен простой рандом хеш, без выпендрежа
2. Собственно, сабж. Сайт нельзя отобразить в iframe, что правильно. Запретить отображение сайта в iframe можно различными способами
что правда? x-frame-options не передается и vk.com и m.vk.com преспокойно фреймится и кликджекится homakov.blogspot.hk/2012/06/saferweb-with-new-features-come-new.html
3. Поправили буквально за день-два. «Баунти» программы у них нет. В ответ было мол — поправили, проверьте и всё. P.S. Сниффер успешно внедрился, но это ничего не дало, из-за первого пункта про систему авторизации
такой XSS это просто *здеццц. насчет баунти — я тоже находил серьезный баг в oauth, за куда меньший баг фб мне 2к дали habrahabr.ru/post/150756/
вк огромная свалка не компилированного не минифицированого vanilla js кода. гребаный стыд
статья хорошая +1
ненужно ничего каждый раз гененрировать. 1 раз генерация при первом заходе на ресурс, сохраняется в сессии, сессия хранится прямо в куки подписана(прочесть и изменить ее нельзя)
при каждом запросе сессия шлется вместе ст океном на сервер и токен из запроса сверяется с токеном из сессии. кешировать все можно. даже для устаревших токенов если вы удалили сессию я делал патч для jquery_ujs для синхронизации
зачем ему меняться? если нет XSS то из куки его не вытащить а если есть то это другой уровень проблемы
я изначально сказал что решение НЕ красивое. Зачем писать gen_hash(form_id + to_id etc + salt) когда можно просто 1 раз сгенерить random строку. защита от CSRF и роуты написана не профессионалом и это очевидно — как заметил ТС не везде есть защита и более того GET иногда используется для state changing действий
Про анти-CSRF токены я сказал без сарказма. Пару аргументов:
1) Использовать сессии — хранить лишние данные для млнов юзеров или не хранить? Выбор — не хранить
2) Куки — вообще, смотря как реализовать. Вообще, это плохой стиль, писать ненужную инфу для юзера ему в куку. И в зависимости от реализации может возникнуть проблема при работе с множеством вкладок заканчивая совершенно другими
3) Ну и третий, самый главный. Подобные токены полностью решают проблему Parameter Tampering. Подмена параметров невозможна, каждое действие подписано.
1) зачем хранить? signed cookie
2) это не не нужная инфа и не плохой стиль. это stateless стиль, зачем нагружать сервер когда клиент может взять на себя то что подписано
3) да, такая же идея всплыла у яхуды катза после mass assi… кароче не для всех сервисов это нормально. как будете ajax запросы подписывать, когда неизвестно какие параметры придут?
Ха! интересно что можно выловить, используя уязвимостьPHP к неизвестным HTTP методам, и соответсвенно обходу .htaccess. HTExploit надо из дома натравить.
Что под капотом у vk.com