Как стать автором
Обновить

Комментарии 54

Интересно насчет .DS_store, в метаданных может быть интересная информация, но в интернете ничего путного про расшифровку не нахожу
а есть копия пресида-то? интересно как вконтактик сетапится :)
НЛО прилетело и опубликовало эту надпись здесь
Интересно, сколько людей сейчас пошло добавлять .DS_Store в .gitignore.
НЛО прилетело и опубликовало эту надпись здесь
Откройте для себя ~/.gitignore_global. Исключительно удобно и просто.

Включить gitignore_global: touch ~/.gitignore_global && config --global core.excludesfile ~/.gitignore_global
Не совсем понял насчет мусора. В каком смысле подчищается лимит?
Тоже не понял вашего вопроса.
Это несвязанные пункты.
Подчищается история сообщений. Т.е. не все сообщения сохраняются в переписке.
А заметили какую-то закономерность в подчистке истории сообщений? Неужели реальные, неспамные сообщения удаляют? Как-то похоже, что экономят на спичках.
Не знаю, не знаю.
Думаю речь идет о млрдах ключей. Так что далеко не спички.
Особо не исследовал этот вопрос, можно посмотреть.
Просто решил отмотать по максимуму переписку с одним из контактов — сообщения, которые были отправлены более 2х назад уже недоступны.
НЛО прилетело и опубликовало эту надпись здесь
Вот сегодня читал старую переписку свою года 2008 части сообщений тупо нет, так что да подтверждаю база чистится причём сообщения пропали рандомно, то с моей стороны то со стороны собеседника.
Похоже что старые сообщение просто исключаются из бэкапа/дублирования, и в случае падения сервера происходит автоматическая «чистка».
Мои сообщения удаляют? То есть буквально, я открою историю, и за какой-нибудь 2009 год у меня может не оказаться сообщений?
То, что фото и документы доступны по прямой ссылке после удаления — это огромная проблема.
Время для редактирования закончилось…
Идём в сообщество/паблик/etc
Нажимаем предложить новость.
Заливаем картинку, например, демотиватор.
Отправляем предложенную новость.
Перезагружаем страницу сообщества, снова «Предложить новость»
Видим предложенную новость.
Кликаем на время отправки.
Лайкаем залитый демотиватор и делимся с друзьями.
Оп. У нас на стене есть демотиватор от имени сообщества.
Круто (:
Уже не работает.
Шустро.
Сорри. Надо просто кликнуть на саму картинку и лайкать ее а не пост.
Сейчас VK стал уже более-менее адекватным по отношению к безопасности и приватности данных, а вот пару лет назад с помощью нехитрой связки m.vk.com + VK API + user api можно было выдрать на порядок больше информации, чем человек (как он полагал) позволил узнать с сайта
Был даже легализованный вариант — durov.com
Неужто так и не нашли, как залить анимированную гифку?
Я только залил png'шку с php кодом внутри :)
Сейчас, вроде, любое изображение 100% пересохраняется, что не дает загрузить подобное изображение, нет?
Ну вроде как да.
Тем не менее анимогифки время от времени всплывают.
Может, надо заливать картинки через API, в качестве аватарки или ещё как-нибудь?

Честно говоря не ставил перед собой подобной задачи, постараюсь посмотреть.
Но все те гифки, которые были загружены до этого, сейчас удалены. И новых я не видел.
Предыдущий баг был жив всего несколько часов и год-два назад, насколько я знаю.
Всё просто… Через документы заливают.
И они живой анимацией прямо на странице проигрываются? :) Что-то не видел)
Сейчас, конечно, проверю
прикреплённый аттачем документ открывается в отдельной вкладке.
а в ленту вставляется превьюха, которая, естественно, генерится.
может, можно как-то перенести документ в категорию фоток?
Я сейчас попробовал на моменте отправки сообщения с изображением подсунуть гифку из документов вместо обычной фотки — не выйдет (не вышло), формат отправляемых данных разный.
вот так не проходит:
{
act:post
al:1
attach1: ид_документа
attach1_type:photo
}

?
Раньше можно было залить gif-ку переименовав ее, а сейчас все, закрыли данную возможность. Интересно, чем опасен в плане безопасности анимированный gif (ну кроме раздражения пользователей фактом анимации)
Думаю, ограничение существует как раз таки из эстетических соображений.
>> Узнать возраст через поиск

Вот зачем рассказали, прикроют же (: (сам пользовался иногда)
POST к статике по умолчанию закрыт nginx'ом, так что это не заслуга вконтакте ;)
НЛО прилетело и опубликовало эту надпись здесь
возможно тем, что веб-серверу нужно вычитать от клиента тело запроса, которое потом все-равно придется выбросить.
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
токен никак не должен зависить от параметров которые легко может узнать сам хакер — фром айди и ту айди… токен простой рандом хеш, без выпендрежа

Рандом хэш ведь придется запоминать на стороне сервера?
С их вариантом на сервере ничего запоминать не надо и можно получив токен проверить его на валидность, а что хакер знает параметры не страшно (их же и так из параметров формы можно взять), если он не узнает соль.
signed cookie, ничего запоминать не надо. идеальное решение, сделано в рельсах например
И еще у рандомного хэша минус, что форму с ним нельзя закэшировать и при выводе формы надо каждый раз тратить ресурсы на его рассчет, а их токен можно. По идее их токен это просто подпись формы, не вижу тут минусов, хакер может ее узнать только войдя в аккаунт жертвы.
ненужно ничего каждый раз гененрировать. 1 раз генерация при первом заходе на ресурс, сохраняется в сессии, сессия хранится прямо в куки подписана(прочесть и изменить ее нельзя)
при каждом запросе сессия шлется вместе ст океном на сервер и токен из запроса сверяется с токеном из сессии. кешировать все можно. даже для устаревших токенов если вы удалили сессию я делал патч для jquery_ujs для синхронизации
И в чем тогда скрытый смысл рандомности токена, если он не меняется всю сессию?
Получается то же самое, что и у них – токен для формы будет неизменным (сессия может длиться и неделями и месяцами).
Никак не пойму где вы видите уязвимость в их варианте, с которой справится рандомный токен.
зачем ему меняться? если нет XSS то из куки его не вытащить а если есть то это другой уровень проблемы
я изначально сказал что решение НЕ красивое. Зачем писать gen_hash(form_id + to_id etc + salt) когда можно просто 1 раз сгенерить random строку. защита от CSRF и роуты написана не профессионалом и это очевидно — как заметил ТС не везде есть защита и более того GET иногда используется для state changing действий
> я изначально сказал что решение НЕ красивое. Зачем писать gen_hash(form_id + to_id etc + salt) когда можно просто 1 раз сгенерить random строку.

Дело вкуса, мне их вариант нравится больше, чем рандомный токен.
Они своим токеном подписывают параметры формы и значит можно проверить, что параметры формы не менялись, чего рандомный токен не даст. Наверное это помогает бороться со спамботами.
Про анти-CSRF токены я сказал без сарказма. Пару аргументов:
1) Использовать сессии — хранить лишние данные для млнов юзеров или не хранить? Выбор — не хранить
2) Куки — вообще, смотря как реализовать. Вообще, это плохой стиль, писать ненужную инфу для юзера ему в куку. И в зависимости от реализации может возникнуть проблема при работе с множеством вкладок заканчивая совершенно другими
3) Ну и третий, самый главный. Подобные токены полностью решают проблему Parameter Tampering. Подмена параметров невозможна, каждое действие подписано.
1) зачем хранить? signed cookie
2) это не не нужная инфа и не плохой стиль. это stateless стиль, зачем нагружать сервер когда клиент может взять на себя то что подписано
3) да, такая же идея всплыла у яхуды катза после mass assi… кароче не для всех сервисов это нормально. как будете ajax запросы подписывать, когда неизвестно какие параметры придут?
Ха! интересно что можно выловить, используя уязвимостьPHP к неизвестным HTTP методам, и соответсвенно обходу .htaccess. HTExploit надо из дома натравить.
Я чуть что чуть более чем ничего.
Было бы странно, если бы сервера VK работали на апаче с mod_php
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории