Microsoft запрещает сотрудникам пользоваться Slack, Google Docs, AWS

Microsoft запрещает сотрудникам пользоваться Slack, Google Docs, AWS

Microsoft запрещает сотрудникам пользоваться Slack, Google Docs, AWS

Согласно политике Microsoft, сотрудникам на рабочих местах запрещено пользоваться онлайн-сервисами, принадлежащими конкурирующим корпорациям. Причина довольно проста — техногигант хочет скрыть от глаз компаний-конкурентов внутренние процессы.

Среди попавших в черный список сервисов есть всем известные имена — Slack, Google Docs и Amazon Web Services. Microsoft приучает служащих использовать внутренние альтернативы для коммуникации и хранения данных.

Такой подход, по мнению руководства американской корпорации, сводит к минимуму риск утечки важной внутренней информации в руки третьих лиц.

Однако и часть собственных сервисов Microsoft считает недостаточно надежными для использования сотрудниками. Так, например, в немилость попал приобретенный не так давно GitHub.

Как передает издание GeekWire, Microsoft опасается, что Google и Amazon получат доступ к разработкам корпорации, что позволит им успешнее конкурировать с техногигантом.

Например, руководство компании считает, что мессенджер Slack не может обеспечить приемлемый уровень защиты интеллектуальной собственности Microsoft.

Еще одной программой, запрещенной внутри Microsoft, стала Grammarly. На первый взгляд — решение странное, однако стоит присмотреться к возможностям Grammarly, чтобы понять причину.

Как известно, Grammarly предназначена для проверки правописания и грамматики, но эта же программа фиксирует и записывает каждую нажатую вами клавишу. Другими словами, все, что вы печатаете в документе или набираете в электронном письме, может попасть в руки третьих лиц.

Новая атака на кеш 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