Илья Бирман учит, что пагинация на сайтах должна иметь логику, а не тупо переключать между пронумерованными страницами. Цифра «4» не сообщает ничего о том, что пользователь увидит, нажав на нее.

Если объекты отсортированы по дате, надо ставить в листалку даты. Если есть другой признак для разделения, используйте его. Пример — платья на сайте «Мэри Трюфель». Ничего страшного, что количество элементов на страницах разное.

Месяц назад стало известно, что в 2012 году была украдена база с паролями пользователей Дропбокса. Видимо, после этого они решили рассказать, как пароли хранятся сейчас.

Пароли оборачиваются в несколько слоев.

1. Пароль хешируется с помощью SHA512. Так все пароли приводятся к одной длине (64 байта) с минимальными потерями энтропии на бит. Если этого не делать, то возможны проблемы: либо bcrypt будет брать только первые 72 байта пароля и отбрасывать всё остальное, либо он будет обрабатывать длинные пароли очень долго. Кроме того, судя по утечке, в какой-то момент в Дропбоксе хешировали одним SHA512, а потом стали использовать bcrypt. Похоже, проще всего было перейти, просто захешировав имеющиеся SHA512.
2. Потом хеш подается на вход алгоритму хеширования bcrypt с рабочим фактором 10. Этот хеш вычисляется очень медленно (100 миллисекунд на серверах Дропбокса). Поэтому исходное значение трудно подобрать брутфорсом, потребуется слишком много времени. Соль уникальна для каждого пароля и тоже хранится в базе данных.
3. Полученный на предыдущем шаге результат шифруется с помощью симметричного шифра AES256. Ключ (он называется перец) один для всех, он хранится отдельно от базы с паролями. Поэтому если эта база снова будет украдена, взломщики, не знающие перца, не смогут добраться даже до хешей. С другой стороны, если перец будет скомпрометирован, Дропбокс просто расшифрует хеши и зашифрует их уже с новым перцем.

Ник Коленда прочитал двадцать книг по проектированию UI и выписал из них способы улучшения интерфейсов сайтов.

Список большой, его удобно использовать как источник идей для небольших улучшений уже существующих сайтов.

Эрик Бернхардссон описывает проблему «дрейфа состояния». Она возникает, когда есть два компонента, между которыми должны синхронизироваться данные:

• Компонент-издатель, который отсылает компоненту-подписчику изменения.
• Сторонний сервис, который присылает уведомления нашему сервису с помощью вебхуков.
• Бэкенд, который отправляет новые данные на фронтенд через вебсокеты.

Какие-то из уведомлений обязательно потеряются. Причин этому много — TCP-соединения разрываются; сообщения приходят, когда подписчик лежит; баги в коде мешают правильно отправить или принять сообщения. Между компонентами начинает накапливаться расхождение в состояниях.

Решения два:

1. Обеспечить твердые гарантии доставки сообщения. (Например, как Кафка.)
2. Добавить подписчику механизм самоисправления, когда он сам полностью перезагружает состояние из источника.

В идеале нужно реализовать оба.

Бауке ван дер Бейл показывает уязвимости, позволяющие любому сайту украсть данные из базы, работающей на компьютере посетителя. Уязвимы Redis, Memcached и Elasticsearch. Атака на них состоит из двух частей.

1. Межпротокольный скриптинг. У Redis и Memcached простой текстовый протокол, в котором игнорируются все невалидные команды. Это значит, что браузер может успешно выполнить такой HTTP-запрос к Redis, отправив его на localhost:6379:

POST / HTTP/1.1
Host: localhost:6379

SET abc 123
QUIT

(В ближайшей версии Redis это поправят, но костыльно: команды POST и Host: станут алиасами для QUIT.)

Протокол Elasticsearch основан на HTTP, поэтому запросы к нему можно делать без дополнительных хитростей.

Хотя браузер и может выполнить эти запросы, он не прочитает ответ из-за same-origin policy. Чтобы обойти это, используется вторая атака.

2. Перепривязка DNS. Когда браузер резолвит домен злого сайта, он получает ответ с маленьким временем жизни (например, 1 минута). Во время следующего (уже аяксового) запроса браузер снова резолвит этот домен, но вместо настоящего IP-адреса получает 127.0.0.1. После этого код сайта сможет выполнять запросы на локальном компьютере без ограничений.

В сочетании с другой атакой на Redis злоумышленник способен не только украсть данные, но и исполнить произвольный код на компьютере жертвы. Например, перезаписав ей .bash_profile.

Ван дер Бейл демонстрирует работоспособность атаки на extractdata.club.