Лучший способ обеспечить безопасность веб-сайта с интерфейсом JavaScript / REST back end?

Question

Я хотел бы создать следующий проект:

• общедоступный серверный интерфейс REST API, к которому может обращаться любой аутентифицированный клиент
• пользовательский интерфейс со статическими файлами в HTML / CSS /Javascript с Backbone.js jQuery вызывает REST back-end

На самом деле в моей архитектуре есть три стороны: front-end, который является клиентом back-end, back-end ипользователь, который хочет пройти аутентификацию на странице входа в систему.

Каков наилучший способ защиты трех сторон, участвующих в этой архитектуре?

На самом деле, я считаю, что это просто невозможно сделатьбезопасное приложение на внешнем интерфейсе, если я все делаю в javascript, поэтому я намерен делегировать аутентификацию / авторизацию уровню прокси на моем сервере.Что вы об этом думаете?

Я намерен использовать OAuth для защиты своей REST-части, но я не уверен, нужно ли мне использовать 2-х или 3-х стороннюю реализацию.Каков правильный подход в этом случае?

ОБНОВЛЕНИЕ : во время поиска более подробного на SO сайте, я нашел эту тему , что именно то, что я хотел быделать, за исключением того, что я хочу использовать Java на стороне сервера, а не DotNet.Если я хорошо понимаю, на самом деле мой веб-сайт похож на любой клиент моего REST API, за исключением того, что он единственный, который имеет право создавать учетные записи новых пользователей.Потому что, если мой REST API доступен только через OAuth (как в Twitter), кто может выполнить создание учетной записи пользователя раньше?Я прав?

Answer 1

Одной из основных проблем с этой архитектурой является тестирование. Автоматизированные инструменты будут испытывать проблемы при тестировании этой системы на наличие распространенных уязвимостей, таких как SQL-инъекция, Прямая ссылка на объект . Полезным инструментом для тестирования странных архитектур является открытый исходный код OWASP Zed Attack Proxy или проприетарный BURP-прокси. Тестирование займет много времени и потребует человека, который хорошо разбирается в уязвимостях веб-приложений. Мы часто называем этих людей Пентестерами .

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