Защита сервера PHP от угонщика

Question

ПРЕДПОСЫЛКА: Я реализую PHP-сервер без HTTPS/SSL. На этом я хочу подтвердить, что пользователь, выполняющий вызовы на сервер, имеет значение, предполагая, что связь между приложением и сервером просматривается угонщиком (хакером с сетевым снифером). Я также предполагаю, что угонщик является владельцем приложения, пытающимся выяснить, как приложение взаимодействует с сервером, чтобы взломать мою систему. Я не буду контролировать, кто является владельцем приложения.

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

Он настроен так, что вызывающие параметры одного вызова не могут быть повторно использованы в следующий раз, так что, если угонщик может видеть сообщение, используемое в сеансе, они ничего не могут с ним поделать. Их использование просто указывает, что вызов «не разрешен». Я на 99% уверен, что подключил все связанные дыры к сеансовой связи, так что угонщик не может вторгнуться в мою среду.

ПРОБЛЕМА: Угонщик увидит исходный запрос сеанса, повторно использует эти параметры, чтобы получить новый сеанс и использовать их, чтобы в конечном итоге выяснить, как сеанс вызывает работу.

ВОПРОС: Какую стратегию вы бы использовали, чтобы подтвердить, что только мое приложение разговаривает с сервером во время первоначального запроса сессии, а не угонщик, олицетворяющий мое приложение, чтобы начать сеанс?

Примечание: Сохранение параметров запуска сеанса нереально. Одна из моих идей заключается в том, чтобы вставить «GMT time + N seconds» в случайно сгенерированный код, а затем проверить, установлено ли в GMT GMT + N значение сервера GMT <; таким образом, случайно сгенерированный код становится недействительным в течение N секунд.

Answer 1

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

Причина, по которой HTTPS так широко используется, потому что работает. Лично я бы предложил купить SSL-сертификат.

Атаки «Человек-в-середине» будут выполняться очень легко в этой системе. Подумайте, получает ли злоумышленник сообщение от вашего клиента, с недавно вычисленным кодом, о котором вы говорите. Что мешает им модифицировать остальную часть сообщения? Код по-прежнему зависит от того, что ожидает сервер, поэтому он просто будет обслуживать запрос, который делает клиент (который на самом деле является злоумышленником).

Будучи в состоянии Аутентифицировать, проверить и маскировка информации в пути являются ключевыми элементами в системе, как это. Ваша система действительно не делает ничего из этого.

Answer 2

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

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