Защитите скрипт от ботов и нежелательных запросов на размещение данных

Question

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

Эти php-скрипты получают данные, отправленные им (userid, friendid и т. Д.) - в настоящее время php-скрипты просто проверяют правильность публикуемых данных, а затем обрабатывают запрос, если данные присутствуют и действительны.

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

Управление сессиями было бы первой линией защиты, но поскольку веб-приложение написано на другом языке, я не могу его использовать - и иногда сценарии php находятся в другом домене (хотя на одном сервере).

Другой метод, который я рассмотрел, заключался в том, чтобы зарегистрировать создание токена пользователя для связи с пользователем и сохранить его на стороне Android, а затем при запросе этих сценариев php отправить идентификатор пользователя и токен.И проверьте токен для этого пользователя в удаленной базе данных - это затруднит догадку отправки учетных данных для злонамеренного пользователя.Ясно, что это не самый лучший вариант, потому что токен хранится локально и идет по проводам, но я отвлекся.

Вопрос: существуют ли более эффективные методы для защиты этих исполняемых сценариев php от выполнения без использования?управления сессиями?Имеет ли смысл идея моего токена?

Примечание. Я могу использовать SSL для любых / всех запросов.

Answer 1

Я точно знаю, что вам нужно, если вы готовы к задаче.Ваш API должен реализовывать OAuth2.0.

То, что OAuth может предоставить вам, является безопасным способом передачи информации в службу и обратно, обеспечивая конфиденциальность всей секретной информации и доступ к этой информации только нужным людям.Он дает каждому пользователю уникальную подпись.

OAuth используется Facebook, Google, Twitter и т. Д., Чтобы предоставить разработчикам безопасный доступ к информации, не позволяя всем делать то, что им не следует делать.

OAuth поддерживает ColdFusion, Java, PHP, C #, dotNet, VB.net, LIST, Javascript, Perl, Python, Ruby и многие другие.

http://oauth.net/

Answer 2

Управление сеансами или OAuth - лучшие решения, но не самые простые.Более простой способ - реализовать алгоритм хеширования как в приложении, так и в сценариях PHP.Когда приложение готовит запрос, вы хэшируете некоторые значения, которые отправляются на сервер с использованием вашего секретного метода.Этот хеш отправляется с запросом.Сервер делает то же самое и сравнивает два хэша.Когда они одинаковы, он знает, что запрос от приложения (или кто-то, кто взломал ваш алгоритм).Если это не так, сервер может просто игнорировать запрос.

Пример:

Данные: ИД пользователя= 2042;имя = JohnDoe;email = john-doe@someprovider.com

Hash (в PHP, но вы должны также реализовать его в приложении):

<?php

$userid = 2042;
$name = 'JohnDoe'
$email = 'john-doe@someprovider.com';

// Remove some letters with other letters
$name = str_replace(array('a', 'd', 'g'), array('E', 'x', '9'), $name);

// Reverse a string
$email = strrev($email);

// Make a super secret hash (with salt!)
$hash = sha1('fnI87' . $useris . '87bk;s.' . $name . 'unf%gd' . $email);

// Some more fun
$hash = str_rot13($hash);

?>

Запрос: http://www.your-server.com/script.php?userid=2042&name=JohnDoe&email=john-doe@someprovider.com&hash=YOUR-GENERATED-HASH

ТеперьСервер может применить тот же метод хеширования и сравнить полученный хеш с хешем, отправленным с запросом.

Answer 3

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

Когда вы генерируете токен, рекомендуется использовать стандартный и проверенный алгоритм вместо того, чтобы изобретать свой собственный и / или полагаться на безвестность.Даже если это выглядит в основном безопасно, это может быть не так.Например, существуют известные атаки против идеи MD5, описанной выше (легко добавить данные в сообщение, не зная ключа, и получить другой действительный MAC). HMAC-SHA1 разработан для того, чтобы их избежать.

Первое, что нужно: если вы можете, do использует SSL для всех запросов.Это позволит выполнить несколько вещей одновременно:

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

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

• срок действия токенов: так что даже если кто-то завладеет им, он не сможет использовать его бесконечно.
• способ отзыва токенов
• может иметь разные токены для разных частей (сервисов) веб-приложения, поэтому вы можете предоставить / отозвать доступ только к необходимым сервисам

Чтобы убедиться, что вы (т. Е. Ваше веб-приложение) единственные, кто может выдавать указанные токены, вы должны подписать их ключом, который есть только у вас.Поскольку подписывающее лицо и верификатор одинаковы (вы), вам не нужно использовать криптографию с открытым ключом, HMAC должен это делать.Вы можете, например, объединить имя пользователя, время выдачи и любую другую соответствующую информацию и использовать их в качестве входных данных для HMAC.Упакуйте эти параметры вместе с подписью (вывод HMAC), чтобы создать токен, и приложение будет отправлять его с каждым запросом.Проверьте на сервере и разрешите доступ, если он действителен, потребуйте повторный вход в систему (новый токен), если истек срок действия, иначе запретите доступ.

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

• реализуют логику подписи в собственном коде
• не хранят необработанный ключ, а извлекают его во время выполнения из битов и кусков, хранящихся в разныхмест

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

Answer 4

Я хотел бы предложить более абстрактный подход, но похожий на подход Джонатана.

Я делаю следующие предположения:

• У вас есть PHP-скрипт, который любой может вызвать(если они знают URL / прослушивают сетевые пакеты).
• Ваше приложение для Android с закрытым исходным кодом;Это означает, что если у вас есть хеш-алгоритм, никто, но вы будете знать, что это такое.
• Вы хотите запретить кому-либо напрямую вызывать PHP-скрипты - обходя приложение и любую безопасность, которую вы, возможно, там встроили.

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

Идея состоит в том, что вы генерируете подпись длякаждый запрос, который может сделать только ваше приложение (т.е. соль + хеш).

$input = array(
    "userid" => 1234,
    "friendid" => 2345
    "etc" => "..."
);

$salt = "s3kr4tsal7"; // this is essentially your app signature
$signature = md5($salt . serialize($input));  // you could also use json_encode or any other to-string serialization
                                              // pick whichever is easy to do in PHP and in your app

$request = array(
    "input" => $input,
    "signature" => $signature
); // send this

Затем в своем скрипте PHP проверьте, соответствует ли подпись вычисленной подписи.Это похоже на решение Джонатана, но оно допускает любой ввод, оно не зависит от $email или какого-либо другого свойства.Я также не думаю, что вам нужен слишком сложный алгоритм хеширования, просто md5 с солью «достаточно сложно».

Существует еще один тип атаки, о котором вы должны знать, и это переигровка.атака.

Если вы посмотрите на данные RAW , проходящие через линию, вы можете перехватить их и просто воспроизвести снова.Если вы знаете, какое действие имеет какой выход, вы можете просто повторить вывод.

Типичным решением для атаки воспроизведения является метод проб и ответов.SSL делает это за вас, но вы также можете сделать собственную реализацию (но это значительно сложнее).