С какой угрозой безопасности я могу столкнуться при использовании веб-сервисов? - PullRequest
1 голос
/ 01 сентября 2010

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

<configuration>
    <system.web>
    <webServices>
        <protocols>
            <add name="HttpGet"/>
            <add name="HttpPost"/>
        </protocols>
    </webServices>
    </system.web>
</configuration>

Ответы [ 3 ]

0 голосов
/ 15 сентября 2010

Причина, по которой HttpGet и HttpPost по умолчанию отключены, заключается в том, что их легко можно использовать для атак XSS.От http://msdn.microsoft.com/en-us/library/ff648667.aspx:

Отключая ненужные протоколы, включая HttpPost и HttpGet, вы уменьшаете площадь поверхности атаки.Например, внешний злоумышленник может встроить вредоносную ссылку в электронное письмо, чтобы выполнить внутреннюю веб-службу с использованием контекста безопасности конечного пользователя.Отключение протокола HttpGet - эффективная контрмера.Во многих отношениях это похоже на атаку XSS.Вариант этой атаки использует тег на общедоступной веб-странице для встраивания вызова GET в веб-службу интрасети.Обе атаки могут позволить постороннему вызвать внутреннюю веб-службу.Отключение протоколов снижает риск.

Подробнее о атаках XS см. http://en.wikipedia.org/wiki/Cross-site_scripting.

Я обычно избегаю использования HttpGet и HttpPost возможно.Если это веб-сервис, который каким-либо образом управляет деньгами, я избегаю его любой ценой.По возможности используйте веб-службы SOAP.

0 голосов
/ 15 сентября 2010

Я думаю, вы должны перейти на веб-сервисы на основе WCF. Помимо всех других преимуществ, которые WCF имеет по сравнению с asmx, WCF 4 имеет автоматический выбор формата ответа (json или xml) на основе заголовка принятия HTTP или при отсутствии такой же, как формат сообщения запроса.

В целом, если у вас есть общедоступные веб-сервисы, вам следует беспокоиться о DOS-атаке. В худшем случае это может привести к сбою в работе вашего сервиса, в лучшем случае это откажет законным абонентам вашего WS. Искаженные сообщения SOAP, XML бомбы могут быть использованы для атаки DOS.

0 голосов
/ 01 сентября 2010

В целом, когда вы внедряете базовый веб-сервис SOAP, вы открываете сервис для всего мира, хорошего и плохого.Основное беспокойство, которое вы должны учитывать в своем коде, это проверка входных данных.Наивный прием струн, в частности, может быть очень разрушительным.Если есть ЛЮБОЕ значение, число может быть тем, что вы не можете обработать, ищите его и не продолжайте.Если вы принимаете строки, убедитесь, что вы тщательно очистили их (ищите и очень с подозрением относитесь к точкам с запятой и избегайте каждого «специального символа», который вы видите).

Обычная атака на наивный сервис, который использует неанализованные строки в запросе SQL, может выглядеть как «ABC»; drop database master; ».Если ваш код вставил это в SQL-запрос, не заметив искусственное завершение запроса и вредоносный скрипт, вы можете очистить свой рабочий стол на следующий день.Решение очень простое;экранируйте одиночную кавычку, замените точку с запятой представлением ASCII или Unicode, из которого вы можете перевести обратно (или просто удалить его), и вызов службы будет рассматривать его как мусор.

Это вызываетвторой момент;Ваши веб-службы, даже если они являются вашим кодом, должны вызывать большие подозрения в остальной части вашей системы.Веб-сервисы должны использовать аутентификацию БД, которая предоставляет минимально возможные разрешения для выполнения своей работы.Если ваша служба использует учетную запись администратора или администратора, вы почти наверняка ошибаетесь;Приведенный выше запрос, если он будет выполнен, будет фактически выполнен, и ваша основная БД исчезнет, ​​что сделает ваш сервер БД неработоспособным.Если ваша служба использует имя входа, которое очень строго контролирует разрешения только для того, что требуется службе, SQL Server будет раздражать, но это бесконечно предпочтительнее потери основной базы данных.

Кроме того, будьте очень внимательны при обработке исключений.Неправильно сформированное исключение, которое будет возвращено через SOAP во многом подобно действительному результату, может содержать конфиденциальную информацию, побуждая злоумышленника попытаться заставить ваш сервис выдать исключение, содержащее полезную информацию о реализации, стоящей за сервисом.Исключения SQL / ADO особенно полезны для злоумышленников, поскольку они предоставляют информацию о вашей структуре данных, которая может быть использована для создания проблем.Ищите вещи, которые могли бы выбросить исключения вне вашего контроля, и корректно обрабатывать ситуацию, прежде чем CLR или другие уровни, более глубокие, чем ваш код, могут помешать этому.Перехват всех исключений, как правило, является плохой практикой в ​​других местах, но «поймать и отпустить» с некоторой очисткой может быть хорошей идеей, и очень распространенные перенаправления 500 ошибок, которые обычно указывают на перехват исключений, являются обычной практикой в ​​вебосфере.Если вы хотите или должны добавить исключение в свой код, тщательно его продумайте и не включайте в него информацию, которую вы не хотите, чтобы мир знал.

С архитектурной точки зрения думайте о своих услугах как о электрическихрозетка в стене.Вилки являются ЕДИНСТВЕННЫМ способом получить то, что вы хотите (мощность) от стены.Вы знаете, что есть J-коробки, кабелепровод, переключатели и т. Д., Но вы не можете получить к ним доступ без большого (буквального) взлома.Следуя этой аналогии, ваши конечные точки должны быть настроены на прослушивание указанных, известных портов, а остальная часть системы должна выглядеть как стена снаружи;все остальные порты должны быть закрыты.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...