Лучший способ защитить веб-сайт архитектуры back end front/REST back end?

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

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

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

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

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

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

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

Ответ 1

Одной из основных проблем безопасности с этой архитектурой является тестирование. У автоматизированных инструментов возникнет проблема с тестированием этой системы для общих уязвимостей, таких как SQL Injection, Direct Object Reference. Полезным инструментом для тестирования странных архитектур является OWASP с открытым исходным кодом Zed Attack Proxy или проприетарный прокси-сервер BURP. Тестирование потребует много времени и требует наличия у кого-то хорошего понимания уязвимостей веб-приложений. Мы часто называем этих людей Pentesters.

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