Хорошо, если ваш веб-сервер скомпрометирован, то вся эта логика будет доступна в виде обычного текста в вашем PHP-файлах, так что SQS дизайн не очень сильно изменится. Они, вероятно, даже не нужно было бы понять все эти вещи, а просто выполнять некоторые из вашего кода.

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

Теперь то, что может быть - это полностью зависит от вашего приложения. Позвольте мне привести вам пример, предполагая, что вы бежите обмен - или любой другой веб-сайт по поддержанию вкладов людей - и эти операции мы обсудим это снятие запрашиваемых пользователями. Это позволило бы два проектных решений, которые не могут быть возможны в различного рода веб-сайт, но прекрасно в обмене: 1) каждый вывод должен быть подтвержден, нажав на ссылку, отправленную на адреса электронной почты пользователя; 2) нет вывода не возможен в течение 24 часов после изменения электронной почты.

У вас есть эти три сервера: веб-сервер, сервер проверки, bitcoind сервера, которые общаются друг с другом, используя SQS, не зная друг друга IP-адреса и т.д.

Так что пользователь заходит на ваш сайт и запросы вывода. Ваш веб-сервер создает SQS сообщение, адресованное к серверу проверки. Сервер проверки создает маркер подтверждения и готовит ссылку для отправки электронной почты пользователя. Когда пользователь получает сообщение электронной почты, он нажимает на ссылку, и это снова обрабатывается ваш веб-сервер, который посылает другое сообщение SQS на сервер проверки. Сервер проверки подтверждает, что маркер является действительным, и создает SQS сообщение для bitcoind сервера для планировать сделки.

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

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

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

Так что теперь для хакера, чтобы несанкционированное изъятие было необходимо: 1) взломать ваш веб-сервер; 2) пользователь изменения адреса электронной почты в базе данных; 3) ждать в течение более 24 часов; 4) в пользователе (ей времени) нужно будет игнорировать измененное сообщение уведомления по электронной почте, которые вы послали их с сервера проверки; 5) только после того, как эти 24 часа после изменения электронной почты пользователей и пользователей, не предупреждая Вас о несанкционированном изменении электронной почты, хакер может запросить вывод; Теперь проверка Sever отправляет по электронной почте подтверждение вывода хакерской модифицированный адрес электронной почты, так что он может получить по электронной почте, подтвердить маркер и транзакция будет планироваться. Это весьма маловероятно, особенно, когда пользователь получает уведомление об изменении электронной почты (и это делается с независимой, проверка сервера, так что хакер не сможет остановить это).

Бонус момент: в дополнение к пользователю не реагирует на изменения электронной почты, хакер действительно должен был бы знать, как работает вся эта система, так что он на самом деле нужно, чтобы сделать изменения по электронной почте и ждать 24 часа. Поскольку код отвечает за проверку будет на другом сервере, хакер не смог прочитать код и узнать о своих внутренних правил проверки, так что на самом деле не какой-нибудь способ, чтобы они знали об этом. Даже если они знают, что ни один отзыв не возможен в течение 24 часов изменения электронной почты, они, вероятно, думают, что изменение modified_at поля будет делать трюк, не зная, что вы на самом деле отслеживать модификации меток времени на отдельном сервере, так и в отдельной базе данных.

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