Google введет новые правила доступа к данным Gmail для приложений

Google введет новые правила доступа к данным Gmail для приложений

Google введет новые правила доступа к данным Gmail для приложений

Google введет более строгие правила для сторонних приложений, которые хотят получить доступ к ящикам пользователей Gmail. В компании отметили, что правила должны вступить в силу в следующем году, 9 января.

Это своего рода ответ корпорации на скандал, связанный с доступом сторонних приложений к почте пользователей сервиса Gmail. Напомним, что в июле интернет-гиганту пришлось оправдываться, чтобы вернуть доверие пользователей.

Согласно новой политике, которая вступит в силу в начале следующего года, доступ к ящикам пользователя получат только те приложения, которые непосредственно имеют дело с почтовым сервисом. Например: email-клиенты, сервисы резервного копирования электронной почты и так далее.

Разработчики приложений должны будут переписать их с учетом новой политики. Те приложения, которые обеспечивают только функцию отправки писем, вынуждены адаптировать разрешения под новые условия, так как со следующего года им запретят читать письма пользователей.

Google заявила, что разработчики должны отправить приложения на повторную проверку не позднее 15 февраля. Программы, которые не будут соответствовать новым требованиям, будут удалены 22 февраля.

Если вы интересуетесь вопросом безопасности ящика Gmail и аккаунта Google, рекомендуем ознакомиться с нашей статьей «Как защитить почту Gmail и аккаунт Google».

Напомним, сегодня интернет-гигант признался в утечке данных 500 000 аккаунтов пользователей сервиса Google Plus.

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru