Владимир Дубровин

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

Хэш используется для предотвращения утечек токена наружу, например через Referer страницы.

Нет, вы поняли неправильно. Во-первых, эксплуатация переполнения буфера зависит от того, где расположен буфер. Скорей всего вы имеете ввиду переполнение стекового буфера aka stack overrun.
При "классической" прямой эксплуатации переполнения буфера в стеке "по aleph1" в буфере размещается шел-код, затем сохраненный в стеке адрес возврата перезаписывается адресом, указывающим внутрь буфера (на шелкод), при возврате из функции выполняется шелкод.

Однако, такие приемы работали до того, как появились технологии защиты стека, неисполняемой памяти и рандомизации размещения в адресном пространстве. Сейчас для эксплуатации переполнений стека на практике обычно требуются приемы ROP (return oriented programming), т.е. ваши знания очень сильно устарели.

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

ROP представляет из себя в принципе иной подход к программированию, для разработки шел-кода предварительно необходимо собрать доступные фрагменты кода ("гаджеты"), возможность написания шел-кода зависит от собранных гаджетов и фактически требует трансляции кода в последовательность вызова гаджетов, обычные подходы к разработке кода здесь неприменимы (по крайней мере до того момента, как получен полный контроль над страницами памяти процесса).

Сама по себе SITE является частью протокола FTP, но команды, доступные через нее стандартом не определены.

Исторически, протокол FTP это расширение протокола telnet (доступа к шелу) для передачи файлов. Команда SITE дает возможность выполнить на удаленном сайте какую-то команду, которая не является частью спецификации FTP, поэтому то, что вызывается через SITE по определению является нестандартным. Раньше это обычно реализовывалось путем размещения бинарников в какой-нибудь специальной папке, типа /var/ftp/bin (т.е SITE cpfr запускал /var/ftp/bin/cpfr), и таким образом можно было дать доступ через FTP к каким-то определенным командам или скриптам, сейчас таким образом обычно реализуются нестандартные расширения.

Поместив HTML, XML, SVG и т.д. и т.п. файл на домене usercontent.google.com можно
манипулировать куками домена google.com и фишить. Поэтому пользовательский контент всегда отдается с отдельных sandbox-доменов.
Так же с отдельных доменов обычно отдается статический контент, это позволяет использовать CDN и упрощает управление кэшированием.
Отдельный домен обычно используется для PTR-записей (например 1e100.net). Для PTR часто нужна двойная валидация, т.е. PTR должна разрешаться в имя и имя обратно в тот же IP. При этом на одном IP может хоститься много доменов и быть установлено много сертификатов, включая вайлдкарды. И наоборот, один домен может хоститься на многих IP. Чтобы исключить прямое обращение к хосту по "неожиданному" для него имени в своем домене, обычно используются PTR записи в нейтральном домене. Кстати исторически принято использовать именно домены в .net. Google так же использует 1e100.net как нейтральный домен для подписи транзитных писем, раньше для этого использовался собственно домен google.com и это приводило к забавному багу, позволявшему подделывать подписи на письмах от google.com, я рассказывал о нем на PHDays 2014.
Географические домены исторически используют для организации региональных датацентов и ускорения доступа, например yahoo.jp физически расположен в Японии.

Если вы смотрите отправителей в SMTP-конверте (в логах MTA) - то это совершенно нормальные отправители. Это письма отправляемые пользователю автоматическим сервисом. На каждое отправленное письмо генерируется уникальный адрес отправителя. Это нужно, чтобы в случае если письмо не дойдет получателю и вернется сообщение о невозможности доставки (NDR), было точно известно, какое именно письмо и какому получателю не удалось доставить. NDR возвращается по адрес отправителя, т.к. адрес уникальный и привязан к отправленному письму, это позволяет однозначно сопоставить отправленное письмо и вернувшийся NDR.

К сожалению, ваша задача не решается только аутентификацией, т.к. сотрудник может "унести" наружу уже авторизованную сессию (например, скопировать куки или просто залогиниться на телефоне или создать сборщик в другой ящик, или подключиться в почтовой программе с OAuth-аутентификацией).
Вам необходима система, которая будет сама логинить пользователя в эккаунт, создавать ему сессию в GMail и передавать ее в браузер, например через плагин в браузере, который будет получать уже готовые сессионные куки и проставлять их в браузере, может быть это можно организовать через синхронизацию профиля в браузере. Но кроме этого, необходимо терминировать эту сессию когда пользователь уходит домой (например когда он логаутится или через какой-то период неактивности).
В рамках такой системы вы можете для каждого эккаунта GMail хранить пароль + TOTP-ключ, а уже для доступа к ней делать какую-то дополнительную свою единую аутентификацию + авторизацию (каким пользователям к каким эккаунтам разрешен доступ).