Comments 54
Интересно насчет .DS_store, в метаданных может быть интересная информация, но в интернете ничего путного про расшифровку не нахожу
а есть копия пресида-то? интересно как вконтактик сетапится :)
UFO landed and left these words here
UFO landed and left these words here
Откройте для себя ~/.gitignore_global. Исключительно удобно и просто.

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

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

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

Вот зачем рассказали, прикроют же (: (сам пользовался иногда)
POST к статике по умолчанию закрыт nginx'ом, так что это не заслуга вконтакте ;)
UFO landed and left these words here
возможно тем, что веб-серверу нужно вычитать от клиента тело запроса, которое потом все-равно придется выбросить.
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
Only those users with full accounts are able to leave comments. Log in, please.