Совет по безопасности: доступ по SSL и API

Question

Мой API (настольное приложение) связывается с моим веб-приложением, используя базовую HTTP-аутентификацию по SSL (в основном я просто использую https вместо http в запросах).В моем API реализована логика, которая гарантирует, что пользователи не отправляют неверную информацию, но у меня проблема в том, что кто-то может обойти API и использовать curl для возможной публикации неверных данных (получение учетных данных тривиально, поскольку регистрация в моем веб-приложениисвободно).

Я подумал о следующих параметрах:

1. Дублируйте логику API в веб-приложении, чтобы даже если пользователи пытаются обмануть систему с помощью curl или другого инструментаони представлены с одинаковыми условиями.

2. Выполните дополнительную проверку подлинности, чтобы убедиться, что только мой API может взаимодействовать с моим веб-приложением.(Возможно, SSL-сертификаты клиента?).

3. Шифрование данных (База 64?)

Я знаю, что я немного параноидаленпользователи подделывают мое веб-приложение с помощью скручиваемых инструментов, но я бы предпочел быть в безопасности, чем сожалеть.Дублирование логики действительно болезненно, и я бы предпочел этого не делать.Я мало знаю о клиентских сертификатах SSL, могу ли я использовать их в сочетании с базовой HTTP-аутентификацией?Будут ли они обрабатывать мои запросы дольше?Какие еще есть варианты?

Заранее спасибо.

Answer 1

SSL защищает вас от атак «человек посередине», но не от атак, инициированных на стороне клиента SSL.Сертификат клиента, встроенный в ваш клиентский API, позволит вам идентифицировать, что данные были обработаны клиентским API, но не поможет вам выяснить, изменила ли клиентская сторона данные вручную перед их шифрованием.Технически пользователь ssavy на стороне клиента всегда может найти способ изменить данные путем отладки через клиентский API.Лучшее, что вы можете сделать, - это поставить блокпосты на своем клиентском API, чтобы его было сложнее расшифровать.Проверка на стороне сервера - действительно путь.

---

Рассмотрите возможность рефакторинга кода проверки, чтобы его можно было использовать с обеих сторон.

Answer 2

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

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

Base-64 не является шифрованием. Это просто способ кодирования байтов в виде более простых в обращении символов.

Answer 3

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

Для меня ваши варианты:

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

• Настраиваемый заголовок HTTP в вашем настольном приложении, проверка его существования / значения на стороне сервера или просто использование существующего заголовка User-Agent. Поскольку вы шифруете трафик, вы не сможете легко увидеть отправляемый вами HTTP-заголовок, поэтому вы можете установить его имя и значение по своему усмотрению. Проверка на стороне сервера сродни заверению вас, что клиент, отправляющий запрос, почти наверняка использует ваше настольное приложение.

Я бы лично пошел по специальному маршруту заголовка. Возможно, он не идеален на 100%, но если вы заинтересованы в том, чтобы совершал простейшую возможную вещь, чтобы уменьшить риск , он кажется мне лучшим маршрутом. Это не лучший вариант, если вы не используете HTTPS (потому что тогда любой может увидеть заголовок, если он щелкнет по снифферу), но, учитывая, что вы используете HTTPS, он должен работать нормально.

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