elkapitanoНа странице имеется живой поиск, он обращается к web api сервису, как можно ограничить сервис, чтоб он был недоступен по прямому адресу.
Какую защиту можно сделать, чтобы предотвратить получению злоумышленником всей информации используя сервисОтделить поиск от "всей информации".

Axeleronelkapitano,

Все достаточно стандартно.
1) Используйте Post вместо Get запроса.
2) Используйте защищенный канал https вместо http, желательно подписанный Thawte или Verisign.И что это даст?

Стандартная практика - это сайт разместить в DMZ, а сервис в другом месте локальной сети.
Таким образом сайт будет доступен извне, сервис будет доступен сайту, но извне сервис будет не доступен.

AxeleronskyANA,

Если Вы используете https протокол, Ваш сервис будет доступен только приложению/сайту, а все сообщения шифруются на транспортном уровне механизмом, доступном для понимания только данному приложению/сайту. Почему по Вашему мнению это ничего не даст?На сайте есть публичный поиск товара. При чём тут POST и SSL?

Вот Вам GET over HTTP: http://www.ozon.ru/?context=search&text=MVC5

AxeleronПубличный поиск товара не означает возможность дать весь список поиска по начальным буквам наименований товаров, что в Вашем примере как раз и происходит. Тут никакой выделенный сервер для сервиса не поможет.Вы так и не поняли, что нужно ТС :)

Есть внутренний сервис, что умеет выдавать список товаров согласно фильтру. Плюс он ещё много чего умеет, например позволяет добавлять товары, удалять товары, менять им цены и т.п.

И есть публичный сайт, которому доступна лишь одна функция - это поиск товара.
Вот сайт размещается в DMZ, общается с сервисом, при этом извне нельзя обратиться к сервису и получить доступ к полному функционалу.

AxeleronЕще как более простой и менее затратный вариант реализации, если веб-сервер и сервис-сервер - это два разных сервера, то прост давать доступ к сервису по IP-адресу разрешенных серверов.Гениально, Вы изобрели DMZ!

AxeleronskyANA,

Я понял вопрос ТСа так как я понял ) А Ваш совет "Отделить поиск от "всей информации" я бы серьзно даже не воспринял - просто слишком обще.Надо было спросить, что я имел в виду
AxeleronTС захотел поподробнее, я поподробнее и рассказал в плане реализации. Согласен, c SSL немного перебор. Для Web API лучше всего использовать уникальный токен и Post метод.Да не нужен ему никакой токен. Зачем внутри локальной сети какие-то токены?

AxeleronПосмотрел что за DMZ. Не уверен одно ли и то же (я не сетевик), но я имел в виду IP Restrict, настраевымый в IIS.Чтобы понять материал из Википедии, не надо быть сетевиком

AxeleronskyANA,

А Вы абсолютно уверены, что решение для локальной сети только жаждомо ТСом?

elkapitano...www.testsite.com...Ну хватит уже :)

www.testsite.com - это публичный сайт, он хостится на сервере в DMZ. Последний имеет доступ к private (локальной) network, где хостится сервис.

Разве так сложно понять, прочитав Википедию?

AxeleronskyANA,

Я вижу большие недостатки у Вашего решения, перевешивающие, на мой взгляд, программные. Например, кто будет настаривать DMZ в пределах складского предприятия? Сколько все это оборудование будет стоить? Да и вообще, по-моему, DMZ совсем строится для другого уровня угроз безопасности. Даже, если и будет от него толк, то, походу, вы любитель пушкой по воробьям. Все гораздо проще решается на уровне ахритектуры приложения сервиса...Дайте линк на Ваш сервис, защищёный POST и SSL

AxeleronskyANA,

Уже закрыли тему вчера вроде? Как же Вы сюда пишете, если тема закрыта?

То есть линка не будет, одни пустые рассуждения? Тогда с наступающим!