Asp дополнительные вопросы безопасности

Содержание

SOAP и вопросы безопасности

Любая динамично развивающаяся компания однажды задумывается о необходимости защиты своей информации. Казалось бы, что может быть проще: достаточно запереть в сейф все наиболее важные документы и спрятать подальше ключ. Но на деле решение проблем информационной безопасности далеко не так тривиально: как быть с электронной почтой, программами, да и без распределенных приложений компании уже не обойтись? Протокол упрощенного доступа к объектам SOAP (Simple Object Access Protocol) построен на основе протокола HTTP и идеально подходит для разработки многокомпонентных распределенных приложений, работающих в Internet.

Спецификация самого протокола SOAP и вопросы его использования в Web-приложениях достаточно подробно освещены в литературе. Для работ с SOAP можно воспользоваться и библиотекой Microsoft SOAP Toolkit, рассчитанной на среду Visual Studio 6.0. С ее помощью можно осуществить переход от COM-приложений к SOAP-приложениям.

Архитектура SOAP Toolkit

Компоненты SOAP Toolkit берут на себя основную часть служебных функций по формированию и распаковке SOAP-вызовов в формате XML, а также по транспортировке их по протоколу HTTP. Все, что остается сделать программисту, — настроить компоненты своего приложения для их последующего использования.

Оценивая данную схему с точки зрения защиты информации, можно сразу выявить слабое звено: это передача пакетов по протоколу HTTP через глобальную сеть. Действительно, вероятность перехвата вызовов локальных COM-компонентов крайне мала, но в глобальной сети любой, обладая определенным опытом, может перехватывать IP-пакеты. Для решения данной проблемы можно предложить несколько способов. Самый простой и надежный — шифрование SOAP-сообщений; конкретный механизм шифрования зависит от архитектуры приложения. Еще один способ — аутентификация пользователей и разграничение прав доступа.

Оба способа можно реализовать с помощью стандартных средств SOAP Toolkit. Вместе с тем, следует учесть, что решение будет различным в зависимости от используемого в приложении интерфейса доступа к объектам библиотеки (SOAP Toolkit позволяет использовать два интерфейса — высокого и низкого уровня).

Рис. 1. Функциональная схема приложений на основе SOAP Toolkit

Высокоуровневый интерфейс

Все операции по обработке SOAP-сообщений со стороны клиентского приложения выполняются в этом случае компонентом SOAPClient, а со стороны сервера — SOAPServer при помощи специального обработчика — «слухача». В терминологии SOAP так называют ASP- или ISAPI-приложение, выполняющее обработку HTTP-запросов и преобразование их в SOAP-вызовы.

Рассмотрим задачу построения простейшего SOAP-клиента с использованием высокоуровневого интерфейса. При наличии WSDL-файла с описанием службы (этот файл может быть сгенерирован автоматически при помощи WSDL Generator, входящего в состав библиотеки SOAP Toolkit), вызов метода удаленной службы может выглядеть так:

Листинг 1. Код высокоуровневого SOAP-клиента

На стороне сервера этот вызов будет обработан слухачом и передан объекту SOAPServer, который произведет необходимые операции и вернет результат в виде SOAP-сообщения. Например, код ASP-страницы может выглядеть так:

Листинг 2. Код высокоуровневого ASP-слухача

Интерфейс высокого уровня избавляет разработчика от необходимости вникать в суть процессов формирования и обработки SOAP-сообщений. Но вместе с тем он лишен и возможности какого-либо контроля над ними. В результате, зашифровать или иным образом засекретить эти сообщения не представляется возможным. Однако ситуация не столь безнадежна, как кажется: в SOAP предусмотрена возможность обеспечения защиты соединения по протоколу Secure Sockets Layer. Для того чтобы использовать возможность установки защищенного SSL-соединения, понадобится программный сертификат. При этом важно помнить, что понадобится как минимум два сертификата: один для сервера и один для клиента. В случае работы с несколькими клиентами лучше получить отдельный сертификат для каждого из них.

Далее, необходимо немного доработать код SOAP-клиента, указав на использование SSL и название сертификата, который будет использоваться для установки соединения:

Листинг 3. Код высокоуровневого SOAP-клиента с использованием SSL

Код серверного приложения менять не надо, достаточно лишь установить защищенный режим («Require client certificates») на каталог Internet Information Services, который содержит файлы с описанием службы. При этом можно также включить сопоставление предъявляемых сертификатов именам пользователей домена («Enable client certificate mapping»), что позволит разрешить использование данной службы только определенным категориям пользователей, исключая неправомерный доступ к конфиденциальной информации.

SOAP Toolkit поддерживает и ряд других известных механизмов:

  • аутентификации с помощью имени и пароля;
  • аутентификации на основе Active Directory;
  • Kerberos (Windows 2000);
  • NTLM (на основе доменных имен Windows NT);
  • на основе заголовков SOAP-сообщений;
  • аутентификации через прокси-сервер.

Процедура реализации любого из этих методов аналогична случаю SSL. Достаточно лишь указать требуемые параметры соединения для SOAP-клиента (например, имя пользователя и пароль), а также настроить соответствующие права доступа к службе с помощью Internet Information Services.

Иначе обстоят дела в случае, когда нужно разграничить права доступа пользователей к отдельным методам. Поскольку стандартными средствами данную возможность реализовать нельзя, придется самостоятельно доработать код SOAP-слухача. Например, анализируя предъявляемый пользователем сертификат и запрашиваемый им метод, можно решать вопрос о разрешении или запрещении доступа. В случае ASP-слухача данные о сертификате пользователя можно получить из серверного объекта Request. К примеру, можно идентифицировать пользователя на основе имени сертификата:

Листинг 4. Код ASP-слухача с использованием SSL
Рис. 2. Настройка SSL на сервере

Низкоуровневый интерфейс

Интерфейс SOAP Toolkit низкого уровня обеспечивает гораздо большую гибкость. Его использование позволяет разработчику самостоятельно формировать SOAP-сообщения на стороне клиента и обрабатывать их на сервере. При этом используются уже другие компоненты библиотеки (такие как SOAPReader, SOAPSerializer и др.), которые обеспечивают лишь поддержку правильного формата формируемых сообщений и передачу их по протоколу HTTP. Остальное придется реализовывать самостоятельно.

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

Листинг 5. Код низкоуровневого SOAP-клиента

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

Антон Варфоломеев (antonv@digdes.com) — сотрудник компании Digital Design (Санкт-Петербург).

Поделитесь материалом с коллегами и друзьями

Безопасность приложений ASP.NET

Общие вопросы безопасности веб-приложений и виды угроз

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

К основным, наиболее популярным видам угроз относятся:

  • отказ в обслуживании (DoS);
  • перехват конфиденциальной информации;
  • неправомочный доступ к конфиденциальной информации;
  • неправомочная модификация информации в приложении;
  • подмена данных.

Существует еще ряд угроз, однако они менее критичны, чем перечисленные выше угрозы.

DoS-атака (denial of service, отказ в обслуживании) – это вид атаки на приложение , при котором генерирует большое число одновременных запросов к приложению. Цель этой атаки вывести приложение из работоспособного состояния (или существенно снизить производительность ).

В момент осуществления DoS-атаки на приложение , к нему генерируется большое количество одновременных запросов. Поскольку ресурсы каждого веб-сервера, обслуживающего это приложение ограничены, в какой-то момент времени веб- сервер начинает не справляться с обработкой очередных запросов и производительность приложения снижается. Если в какой-то момент времени сервер не способен обработать запрос , он возвращает пользователю сообщение о невозможности обращения к ресурсам приложения. Таким образом, пользователи не смогут корректно работать с приложением. Защита от DoS-атаки производится путем блокирования IP-адресов, от которых поступает большое число запросов. В этом случае сервер не тратит ресурсы на обработку этих запросов и начинает функционировать нормально. Однако сложность подобных атак заключается в том, что злоумышленники могут атаковать сервер одновременно с нескольких IP-адресов. В этом случае необходимо заблокировать диапазон IP-адресов злоумышленников.

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

Атака , связанная с перехватом конфиденциальной информации производится с целью получить какую-либо информацию, передаваемую между клиентом и сервером с целью дальнейшего ее использования. Обычно к такой информации относятся пароли, используемые для доступа к приложениям, номера счетов в банке, номера кредитных карт и т.д.

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

Для защиты от подобных атак обычно используется шифрование канала, по которому передается информация . В этом случае злоумышленник не в состоянии перехватить информацию. Для шифрования трафика, передаваемого по протоколу HTTP обычно используется модификация протокола – HTTPS . В этом случае клиент и сервер безопасно обмениваются ключами шифрования информации, после чего используя этот ключ шифруют все передаваемые данные. Злоумышленник не в состоянии анализировать зашифрованные данные, если только он не получит ключ шифрования . В целом, использование протокола HTTPS является надежной защитой от данного вида угроз.

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

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

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

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

Для защиты от подобных атак следует использовать рекомендации, приведенные для защиты от предыдущего вида атак.

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

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

Для защиты от подобных атак следует также прибегать к шифрованию трафика. В этом случае злоумышленник не сможет подменить данные, передаваемые серверу.

Как видно, существует большое количество угроз. Поэтому при разработке веб-приложений всегда следует помнить в потенциальной возможности атаки приложения и строить приложение в соответствии с требованиями безопасности.

Краткие итоги

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

Модель безопасности ASP.NET

Модель безопасности ASP . NET имеет встроенные механизмы по обеспечению безопасности приложения. При этом она базируется на основе понятия стража. Модель стражей применяет модель конвейера к организации инфраструктуры безопасности. Такая модель предполагает, что безопасное приложение всегда имеет больше механизмов защиты, чем необходимо. Каждый из этих механизмов реализован как страж, отвечающий за проверку конкретных условий защиты. Если один из таких стражей не сработает, то злоумышленник столкнется со следующим стражем в конвейере. Чем больше таких стражей содержится в приложении, тем труднее злоумышленнику деструктивно воздействовать на приложение .

Как уже упоминалось, каждый страж выполняет проверку на одно условие. При этом как видно из приведенной схемы, в конвейере присутствуют несколько стражей, каждый из которых обеспечивает свой алгоритм защиты. Таким образом, с помощью одного или нескольких стражей можно реализовать каждый из уровней безопасности. ASP . NET включает в себя базовую инфраструктуру безопасности, в рамках которой обеспечивается безопасность на следующих уровнях:

Аутентификация. Этот уровень безопасности отвечает за определение текущего пользователя и отвечает на вопрос «Кто работает с приложением?»;
Авторизация. Этот уровень безопасности отвечает за определение полномочий текущего пользователя и отвечает на вопрос «Какие операции данный пользователь может выполнять?»;
Конфиденциальность. Этот уровень безопасности отвечает за то, чтобы данные, передаваемые от сервера клиенту, не были прочитаны третьими лицами. Обычно этот уровень реализуется за счет применения шифрования канала с использованием протокола HTTPS;
Целостность. Этот уровень безопасности отвечает за то, чтобы данные передаваемые от клиента серверу не были подменены третьими лицами. Обычно этот уровень реализуется за счет использования цифровых подписей.

В рамках инфраструктуры безопасности ASP . NET поддерживаются механизмы аутентификации, авторизации и хранения пользовательской информации на сервере.

Аутентификация в приложениях на базе ASP . NET может осуществляться следующими способами:

  • аутентификация формами;
  • аутентификация Windows;
  • аутентификация с помощью паспортов;
  • специализированным механизмом аутентификации.

Самым простым способом аутентификации является аутентификация формами. При таком подходе пользователь должен ввести имя пользователя и пароль на странице ASP . NET .

Аутентификация Windows позволяет определить пользователя на основе корпоративной политики. Например, в качестве хранилища информации о пользователях может быть Active Directory .

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

Можно разработать специфичный механизм аутентификации, реализуя соответствующий провайдер . В этом случае разработчик сам определяет процесс аутентификации.

Для того чтобы использовать встроенный механизм аутентификации формами, необходимо его настроить. Для этого используется файл «web.config«. Конфигурационный файл содержит секцию » authentication «, которая содержит всю необходимую информацию.

Как видно, при настройке задается имя формы, адрес страницы для ввода имени пользователя и пароля, а также таймаут, по истечении которого сервер «забудет» про аутентифицированного пользователя и ему нужно будет указать имя и пароль еще раз.

После задания указанных настроек необходимо определить место хранения учетных данных пользователей. Одним из таких мест может быть файл конфигурации.

В этом примере атрибут » passwordFormat » секции » credentials » определяет способ хранения пароля. Значение » clear » указывает на то, что пароль хранится в открытом виде. Кроме этого, пароль можно хранить в виде хэша MD5 или SHA1.

После задания всех настроек можно воспользоваться механизмом аутентификации формами. Для этого необходимо воспользоваться классом FormsAuthentication и его статическими методами Authenticate , SignOut , RedirectFromLoginPage и RedirectToLoginPage . Таким образом, программный код для выполнения входа в систему может выглядеть следующим образом.

Теперь, на каждой странице становится возможным проверить выполнен ли вход в систему и, если выполнен, то кем. Для этого можно воспользоваться свойствами IsAuthenticated и Name объекта IIdentity , доступ к которому можно получить, используя текущий контекст — HttpContext.Current.User.Identity .

Несмотря на то, что аутентификация формами закладывает только базовый механизм реализации аутентификации, задачи, которые приходится решать в процессе создания безопасных приложений, как правило, одни и те же. Такими операциями могут быть операции входа в систему и выхода из нее, наделение полномочиями того или иного пользователя, заведение новых пользователей и т.д. В то же время механизм аутентификации формами позволяет выполнить только процесс аутентификации, и не предоставляет возможности выполнить другие описанные операции .

Именно поэтому в ASP . NET существует механизм Membership API . По сути, Membership API – это интерфейс , который позволяет:

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

Таким образом, Membership API – это интерфейс для реализации различных поставщиков для хранения информации о пользователях. Такое абстрагирование на уровне интерфейса позволяет быть независимым от конкретной реализации поставщика и одинаково работать, например, с поставщиком на основе базы данных или Active Directory . ASP . NET включает ряд готовых поставщиков для SQL Server и Active Directory . Это позволяет хранить данные о пользователях и ролях в SQL Server или в Active Directory . Кроме того, можно разработать собственный поставщик, который в качестве хранилища будет использовать другой источник (например, файл на жестком диске). Для этого необходимо создать класс -наследник MembershipProv >System.Web.Security » и указать его в конфигурационном файле.

Для того, чтобы использовать Membership API в своих приложениях необходимо выполнить несколько шагов:

  • сконфигурировать аутентификацию формами в конфигурационном файле;
  • настроить хранилище данных для Membership API и указать его в конфигурационном файле;
  • создать пользователей в хранилище данных;
  • создать страницу регистрации и входа в систему, используя собственные или существующие элементы управления.

Наиболее часто в качестве хранилища данных используется база данных на основе SQL Server . Для SQL Server разработана готовая схема данных, которая позволяет хранить пользователей, пароли, роли и т.д. Для того чтобы создать подобную схему данных в вашей БД необходимо воспользоваться утилитой aspnet_regsql , которая расположена в папке «C:\Windows\Microsoft.NET\Framework\v2.0.50727«. Эта утилита поддерживает два режима работы – консольный и графический. Для запуска утилиты в консольном режиме необходимо указать параметры:

В этой команде указывается имя сервера » (local) » и имя базы данных » MyDB «. Кроме того, можно запустить эту утилиту без параметров, тогда она будет работать в графическом режиме. В этом случае необходимо указать мастеру нужные параметры, после чего будет создана нужная схема данных.

Для создания указанной схемы данных необязательно пользоваться утилитой aspnet_regsql . В папке «C:\Windows\Microsoft.NET\Framework\v2.0.50727» расположены скрипты для SQL Server , которые позволяют создать или удалить эту схему данных. Поэтому для создания базы данных можно вручную запустить эти SQL -скрипты. Список файлов для создания и удаления схемы:

  • InstallCommon.sql
  • InstallMembership.sql
  • InstallPersistSqlState.sql
  • InstallPersonalization.sql
  • InstallProfile.SQL
  • InstallRoles.sql
  • InstallSqlState.sql
  • InstallSqlStateTemplate.sql
  • InstallWebEventSqlProv >

После создания схемы данных необходимо сконфигурировать провайдер Membership API . Для этого в секции » system.web » необходимо создать секцию » membership «, внутри которой указать нужных провайдеров. Кроме того, в атрибуте » defaultProvider » секции » membership » необходимо задать имя текущего провайдера. Таким образом, конфигурационный файл может выглядеть следующим образом.

Как видно, при добавлении нового поставщика задается его имя, тип и строка соединения с базой данных, которая задается в секции » connectionStrings «.

После этого Membership API готов к работе. Для создания новых пользователей и удаления старых, можно воспользоваться статическими методами CreateUser и DeleteUser класса Membership

После выполнения аутентификации следует процесс авторизации. Сам процесс авторизации может поддерживаться на двух уровнях:

  • можно определить пользователей, которые имеют доступ к ресурсам на уровне каталога. Таким образом, можно предоставить доступ к ресурсам каталога только определенному кругу пользователей;
  • в модели безопасности ASP.NET поддерживаются роли. Роль – это группа пользователей, в которой контроль доступа осуществляется для всех пользователей, входящих в эту группу. Например, при отображении страницы можно проверить входит ли пользователь в заданную роль, и, если пользователь в нее входит, то отобразить конфиденциальную информацию; в противном случае – вывести сообщение об ошибке.

Таким образом, инфраструктура ASP . NET содержит ряд готовых механизмов по обеспечению безопасности приложения.

Краткие итоги

Модель безопасности ASP . NET построена на понятии стражей. Каждый страж выполняет проверку на определенное условие. Если при обработке запроса хотя бы один страж отказал в обслуживании, пользователю сообщается об ошибке. Механизмы безопасности ASP . NET обеспечивают полный цикл по обеспечению безопасности приложения, включая процессы аутентификации и авторизации. Для обеспечения работы с информацией о пользователях используется механизм Membership API .

Улучшение безопасности сайта

Что такое взлом сайта?

Сайт считается взломанным, если посторонний человек (не важно каким путем) получил доступ к файлам вашего сайта, которые хранятся на сервере.

Зачем взламывают сайты?

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

Способы взлома сайтов и защита от них

Кража паролей от FTP и хостинга

Если на компьютере вебмастера есть вирус (или вебмастер дал свои пароли от FTP\хостинг-аккаунта человеку, у которого на компьютере вирус), то 90%, что эти пароли попадут авторам вируса и со временем сайт будет взломан.

Как избежать?

Следите, чтобы на вашем компьютере не было вирусов, а также старайтесь никому не давать пароли от хостинг-аккаунта и доступа по FTP. А если даете, то убедитесь, что у этого человека нет вирусов на компьютере. Поменяйте пароли на более длинные (сложные) и старайтесь не хранить их на компьютере, и тем более в браузере. Также рекомендуем использовать безопасное SSH-соединение для загрузки файлов сайта на сервер.

Хостинг-провайдер

Очень часто взломы происходят по вине хостинг-провайдера, т.к. на сервере может быть установлено устаревшее программное обеспечение, которое легко взламывается. Причем вебмастер на это не может никак повлиять.

Что делать?

Здесь все просто — размещайте сайты на надежном хостинге, который имеет хорошую репутацию и много клиентов. В нашем футере, можно найти рейтинги проверенных хостинг-провайдеров, с учетом потребностей вашего сайта.

Взлом CMS (системы управления сайтом)

Не важно какая у вас CMS (платная, бесплатная или самописная). Если она популярная, то тысячи хакеров со всего мира ищут в ней уязвимости, чтобы иметь универсальный способ взломать одним махом десятки тысяч сайтов. Но если хакеры постоянно ищут «дыры» в коде систем управления сайтом, то разработчики этих CMS постоянно выпускают обновления (патчи), которые закрывают «дыры» и улучшают безопасность.

Что делать?

Следите за тем, чтобы на вашем сайте была актуальная версия CMS, причем скачанная с официального сайта разработчика, а не не откуда-попало. Если CMS разработанная специально под ваш сайт (самописная), то актуальным будет заказать аудит безопасности сайта. Где его заказывать? Это сложный вопрос, т.к. компаний, которые качественном этим занимаются — единицы, и они берут за это немалые деньги. При выборе такой компании обращайте внимание на портфолио, а также спросите у их клиентов, на сколько качественно они работают. Мы же подготовили рекомендации по безопасности для отдельно взятых CMS (Joomla и Worpress).

Взлом сайта через модули и компоненты

Если взять любую из вышеуказанных CMS в голом виде (без сторонних модулей и компонентов), то взломать ее будет трудно даже хакерам высокого уровня. Основную опасность несут расширения (модули, компоненты, плагины), которые создаются сторонними разработчиками. Так например, устанавливая компонент комментариев, который создан на тяп-ляп, вы позволите хакеру вместо комментария или прикрепленной картинки залить на ваш сайт PHP-скрипт, который и позволит совершить взлом.

Что делать?

Не используйте дополнительные расширения от подозрительных разработчиков. Также предельно внимательно относитесь к бесплатным плагинами и компонентам.

Установка прав доступа на файлы

Если установить права 777 на какой-либо файл вашего сайта, то это будет означать, что любой человек, сможет прочитать, записать и выполнить этот файл. И конечно же это ведет к тому, что однажды хакер забросит на ваш сайт PHP-код, который его взломает и даст контроль над сайтом.

Как исправить?

Старайтесь, чтобы на все папки Вашего сайта были выставлены права 755, а на файлы 644. Но в первую очередь посоветуйтесь с разработчиком CMS, хостером или опытным программистом, т.к. изменение прав на файлы, может привести к тому, что сайт будет работать некорректно. Детальнее о правах доступа и их изменении читайте в нашей статье.

SQL-Инъекция

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

Как защититься?

В первую очередь использовать хорошо защищенную CMS. Если же вы разбираетесь в программировании, то от SQL-инъекций можно спастись с помощью фильтрации SQL-запросов. Например, в PHP есть функция mysql_real_escape_string, которая удаляет потенциально опасный код из запросов.

XSS (межсайтовый скриптинг)

Суть этой атаки сводится к тому, что хакер подкладывает вредоносный код вместо логина, пароля и прочих данных, которые могут вводить пользователи.

Как избежать?

К сожалению таким атакам часто подвергаются даже очень известные сайты (VK, Facebook и т.д.) и противостоять им достаточно трудно. Наш совет — используйте хорошую CMS или наймите опытного программиста. Если на программиста нет денег, то постарайтесь убрать со своего сайта возможность зарегистрироваться и иметь собственный аккаунт для любых пользователей.

Советы по безопасности сайта

  1. Проверяйте сайт на наличие вирусов. О том, как это сделать читайте здесь.
  2. Делайте бекап сайта как можно чаще (для большинства сайтов — раз в сутки).
  3. Лог-файлы содержат все запросы отправляемые к серверу, и как правило, могут помочь выявить лазейку, через которую сайт был взломан. Если вы в них конечно разбираетесь. Но даже, если не разбираетесь, то сохраняйте их как можно чаще, т.к. хостинг-провайдер хранит логи определенное время (около 2 недель). Если же ваш сайт заразили в более ранний срок, то использовать лог-файлы для обнаружения «дыры» уже не получится.
  4. Если на вашем сайте есть функции оплаты (нужно вводить номера банковских карт и т.д.), то либо используйте безопасный протокол https, либо пользуйтесь внешними сервисами оплаты.

Если у вас остались вопросы, или вы знаете, чем можно дополнить данную статью — пишите это в комментариях. На вопросы постараемся ответить, а статью — дополним.

Asp дополнительные вопросы безопасности

Этот раздел посвящен технологии прежних версий. Веб-службы XML и клиенты веб-служб XML должны создаваться с использованием Windows Communication Foundation .

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

Веб-службы, созданные с помощью ASP.NET, могут выбирать параметры безопасности из вариантов проверки подлинности и авторизации, предлагаемых ASP.NET, и настраиваемой безопасности на основе протокола SOAP. ASP.NET совместно со службами IIS обеспечивает несколько вариантов проверки подлинности и авторизации. Можно также создать настраиваемые параметры проверки подлинности, например, использовать заголовки SOAP. Дополнительно ASP.NET предлагает возможность, называемую олицетворение, делать запросы с использованием учетных данных клиента. Дополнительные сведения об использовании олицетворения см. в разделе Олицетворение ASP.NET.

В этом разделе приводятся сводные данные о параметрах авторизации и проверки подлинности, доступных для веб-служб, построенных с помощью ASP.NET. Дополнительные сведения о параметрах безопасности, доступных для веб-приложений ASP.NET, см. в разделах Безопасность веб-приложений ASP.NET и Построение безопасных приложений ASP.NET. Проверка подлинности, авторизация и безопасное взаимодействие .

Дополнительные сведения о доступе к удаленным ресурсам из приложений, основанных на ASP.NET, см. в разделах «Модель олицетворения или делегирования» и «Модель доверенной подсистемы» главы 3 документа Построение безопасных приложений ASP.NET.

Параметры проверки подлинности для XML-веб-служб

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

В следующей таблице представлена сводка по параметрам проверки подлинности, доступным для веб-служб, построенных с помощью ASP.NET. Параметры, перед которыми указано слово Windows, относятся к параметрам проверки подлинности Microsoft Windows, доступным для веб-служб, созданных с помощью ASP.NET.

Сводка вариантов проверки подлинности

Используйте для небезопасной идентификации клиентов, так как имя пользователя и пароль передаются в виде обычного текста в строках с кодировкой Base 64. При проверке подлинности этого типа пароли и имена пользователей кодируются, но не шифруются. Целеустремленный злонамеренный пользователь, оснащенный инструментом мониторинга сети, может перехватывать имена пользователей и пароли.

Windows — Обычная по SSL

Используйте для безопасной идентификации клиентов в интернет-сценариях. Имя пользователя и пароль передаются по сети с использованием шифрования SSL, а не в виде обычного текста. Этот вариант относительно прост в настройке и работает для интернет-сценариев. Однако использование протокола SSL снижает производительность.

Используйте для безопасной идентификации клиентов в интернет-сценариях. Для шифрованной передачи учетных данных клиента используется хэширование, поэтому пароль не передается в виде простого текста. Кроме того, дайджест-проверка подлинности может работать через прокси-серверы. Однако она не имеет широкой поддержки на других платформах.

Windows — Встроенная проверка подлинности Windows

Использует NTLM или Kerberos. Используется криптографический обмен с веб-браузером Microsoft Internet Explorer пользователя.

Windows — Сертификаты клиента

Используйте для безопасной идентификации клиентов в интернет-сценариях и сценариях интрасети. Требуется, чтобы каждый клиент получил сертификат от взаимно доверенного центра сертификации. Дополнительно сертификаты могут сопоставляться учетным записям пользователя, которые используются службами IIS для доступа к веб-службе.

Не поддерживается веб-службами. Это система, с помощью которой запросы, не прошедшие проверку подлинности, перенаправляются на форму HTML с помощью перенаправления со стороны клиента HTTP. Большинство клиентов веб-служб не захотят предоставлять учетные данные с помощью пользовательского интерфейса; если требуется использовать проверку подлинности с формами, необходимо придумать обходной способ.

Заголовки SOAP – Настраиваемая

Полезно как для безопасных, так и для небезопасных интернет-сценариев. Учетные записи пользователя передаются в заголовке SOAP сообщения SOAP. Веб-сервер, независимо от платформы, на которой размещена веб-служба, обеспечивает реализацию настраиваемой проверки подлинности.

Для всех перечисленных выше вариантов, кроме использования заголовков SOAP, параметры безопасности задаются с помощью сочетания файлов конфигурации и служб IIS. Вариант использования настраиваемых заголовков SOAP подробно рассматривается после раздела «Проверка подлинности», так как это решение включает в себя как проверку подлинности, так и авторизацию.

Проверка подлинности Windows

Как службы IIS, так и ASP.NET обеспечивают поддержку проверки подлинности для веб-приложений, включая веб-службы, с использованием безопасности, встроенной в ОС Windows. Windows обеспечивает три варианта проверки подлинности: обычная, дайджест и встроенная проверка подлинности Windows. Кроме того, каждый вариант может использоваться с протоколом SSL. Так как во всех предлагаемых ОС Windows вариантах проверки подлинности, кроме обычной, данные в той или иной форме шифруются, дополнительный уровень шифрования, предлагаемый протоколом SSL, обычно используется только с вариантами «Обычная» и «Сертификаты клиента».

Независимо от используемого варианта проверки подлинности Windows, процедуры настройки веб-службы и клиента веб-службы аналогичны. Дополнительные сведения см. в разделе Как настроить XML-веб-службу для проверки подлинности Windows. Для использования проверки подлинности Windows не требуется добавлять код в веб-службу, так как параметры проверки подлинности задаются в файле конфигурации и службах IIS. В клиент веб-службы необходимо добавить код для передачи учетных данный клиента в веб-службу.

Если в качестве составной части механизма проверки подлинности, используемого веб-службой, выбран протокол SSL, его необходимо настроить с помощью служб IIS для веб-приложения, в котором размещена веб-служба, или для самой веб-службы. Описание службы и, следовательно, прокси-классы, создаваемые из описания службы, будут отражать тот факт, что веб-служба использует протокол SSL (если доступ к описанию службы и странице справки службы производиться с использованием протокола SSL). URL-адрес веб-службы в описании службы будет иметь префикс «https». Дополнительные сведения о настройке SSL см. в документации по службам IIS.

Проверка подлинности с помощью сертификата клиента

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

Сертификат клиента можно получить в центре сертификации, который сам может быть веб-сервером или доверенной промежуточной инстанцией между клиентом и сервером. После того, как сертификат получен и веб-сервер настроен на прием сертификатов клиентов, клиент при вызове веб-службы может отправить сертификат клиента на веб-сервер по соединению SSL. Дополнительные сведения о сертификатах клиентов см. в документации по службам IIS. Дополнительные сведения о настройке проверки подлинности с помощью сертификатов клиентов см. в разделе Как настроить XML-веб-службу для проверки подлинности Windows.

Варианты авторизации для XML-веб-служб

Цель авторизации — определить, можно ли конкретному пользователю предоставить запрошенный тип доступа к определенному ресурсу. Существуют два основных способа авторизации доступа к определенному ресурсу: авторизация файла и авторизация URL-адреса. Авторизация файла может использоваться, если используется проверка подлинности Windows, так как разрешения задаются в службах IIS для отдельных файлов. Авторизация URL-адреса может применяться вместе с любым встроенным механизмом проверки подлинности, поддерживаемым ASP.NET. В авторизации URL-адреса настройка выполняется посредством файла конфигурации, в котором можно выборочно предоставлять или запрещать доступ пользователей к любым файлам, связанным с ASP.NET, включая ASMX-файлы.

Дополнительные сведения о настройки авторизации для отдельных файлов см. в документации служб IIS.

Дополнительные сведения о настройке авторизации с помощью файла конфигурации см. в разделе Авторизация в ASP.NET.

Настраиваемая проверка подлинности с помощью заголовков SOAP

Механизмы проверки подлинности Windows, включая сертификаты клиентов, используют транспорт HTTP, а протокол SOAP не зависит от транспорта. Веб-службы, созданные с помощью ASP.NET, используют протокол SOAP через HTTP, а также реализации HTTP-POST и HTTP-GET, которые возвращают документы XML, не являющиеся документами SOAP. Поэтому одной из причин создания настраиваемого механизма проверки подлинности является разделение проверки подлинности и транспорта. Этого можно добиться, передавая учетные данные для проверки подлинности в заголовке SOAP.

Заголовки SOAP — отличный способ передачи вне полосы или передачи информации, не связанной с семантикой веб-службы. В отличие от элемента Body сообщения SOAP, который содержит входные и выходные параметры для работы веб-службы, обрабатываемые методом веб-службы, элемент Header является необязательным и, таким образом, может обрабатываться инфраструктурой. То есть, обрабатываться инфраструктурой, разработанной для обеспечения настраиваемого механизма проверки подлинности.

Описание одного из способов использования заголовков SOAP для проверки подлинности см. в разделе Как выполнять нестандартную проверку подлинности с использованием заголовков SOAP.

Чтобы использовать заголовки SOAP для проверки подлинности, клиент веб-службы должен передавать свои учетные данные в веб-службу, добавляя ожидаемый заголовок SOAP в запрос SOAP и занося в этот заголовок учетные данные клиента. Чтобы использовать проверку подлинности с заголовками SOAP, веб-служба должна выполнить две операции: указать, что она ожидает заголовок SOAP, содержащий учетные данные для проверки подлинности, и авторизовать доступ клиента к веб-службе.

MVC с помощью ASP.NET, удостоверяющих личность отдельных учетных записей — Как добавить вопросы безопасности?

Вот мой сценарий:

Мне нужно, чтобы захватить по крайней мере 3 вопроса безопасности & ответы как часть регистрации пользователя для сайта (построено в MVC 5 с помощью отдельных учетных записей пользователей в качестве средства проверки подлинности). Что я могу сделать, расширив объект ApplicationUser.

Все идет нормально.

Я хотел бы задать эти вопросы в процессе восстановления пароля.

Я не нашел никакой поддержки вопросам безопасности в рамках ASP.NET Identity.

Нужно ли мне реализовать вопросы безопасности из стороны встроенного в библиотеке UserStore или есть существующая поддержка похожа на Секретные вопросы в функциональности ASP.NET Membership в .NET 2.0?

Примечание: Дайте мне знать, если вам нужна дополнительная информация.

Безопасность ASP.NET

ASP.NET MVC — не самый трендовый, но довольно популярный стек в среде веб-разработчиков. С точки зрения противодействия хакерам, его стандартный функционал дает вам кое-какой базовый уровень безопасности, но для защиты от абсолютного большинства хакерских атак нужен дополнительная уровень защиты. В этой статье мы рассмотрим основы, которые должен знать о безопасности ASP.NET любой разработчик (будь то Core, MVC, MVC Razor или Web Forms).

Начнем со всем известных видов атак.

SQL Injection

Как ни странно, но в 2020 году injection и, в частности, SQL injection находятся на первом месте среди «Toп-10 рисков безопасности OWASP» (Open Web Application Security Project). Данный тип атаки подразумевает, что введенные пользователем данные используются на серверной стороне в качестве параметров запроса.

Пример классической SQL-инъекции скорее характерен именно для приложений Web Forms. От атак помогает защититься использование параметров в качестве значений запроса:

Если вы разрабатываете MVC-приложение, то Entity Framework прикрывает некоторые уязвимости. Получить сработавшую в MVC/EF-приложении SQL-инъекцию нужно умудриться. Однако это возможно, если вы выполнните SQL-код с помощью ExecuteQuery или вызовите плохо написанные хранимые процедуры.

Несмотря на то что ORM позволяет избежать SQL-инъекции (за исключением приведенных выше примеров), рекомендуется ограничивать атрибутами значения, которые могут принимать поля модели, а значит, и формы. Например, если подразумевается, что в поле может быть введен только текст, то с помощью Regex укажи диапазон ^[a-zA-Z]+$. А если в поле должны быть введены цифры, то укажите это как требование:

В Web Forms ограничить значения вы можете с помощью валидаторов. Пример:

Начиная с .NET 4.5 Web Forms используют Unobtrusive Validation. А это значит, что не требуется писать какой-то дополнительный код для проверки значения формы.

Валидация данных, в частности, может помочь защититься от еще одной всем известной уязвимости под названием cross-site scripting (XSS).

Типичный пример XSS — добавление скрипта в комментарий или запись в гостевую книгу. Выглядеть он может так:

Как вы понимааете, в данном примере куки с вашего сайта передаются в качестве параметра на какой-то хакерский ресурс.

В Web Forms можно совершить ошибку с помощью примерно такого кода:

Понятно, что вместо username может быть скрипт. Чтобы избежать выполнения скрипта, можно как минимум использовать другое ASP.NET-выражение: , которое энкодит свое содержимое.

Если мы используем Razor, то строки автоматически энкодируются, что сводит возможность реализации XSS к минимуму — злоумышлений сможет ее провернуть, только если вы грубо ошибетесь, например используя @Html.Raw(Model.username) или юзая в своей модели MvcHtmlString вместо string.

Для дополнительной защиты от XSS данные кодируются еще и в коде C#. В .NET Core можно использовать следующие кодеры из пространства имен System.Text.Encodings.Web: HtmlEncoder, JavaScriptEncoder и UrlEncoder.

Следующий пример вернет строку

Для дополнительной защиты можно использовать заголовок content-security-policy. Он позволит загружать контент лишь с определенных ресурсов. Например, можно разрешить запуск скриптов только с текущего сайта:

Есть еще возможность указать доверенные сайты, доступ к содержимому которых разрешен. Следующий заголовок тоже помогает защититься от XSS, хотя, как правило, он включен браузерами по умолчанию: x-xss-protection. Пример:

Clickjacking

Сайт может показать пользователю окошко, ссылку или баннер, поверх которого добавлена скрытая кнопка/ссылка внутри прозрачного iframe. И получается, что пользователь кликает на что-то, на что он хочет кликнуть, но при этом фактически он щелкает на скрытый объект против своей воли.

Установка заголовка X-FRAME-OPTIONS со значением DENY запретит помещать страницы твоего сайта в iframe. Если у вас на сайте нет фреймов, то это хороший вариант. Если же вы используете iframe для отображения страниц, то значение SAMEORIGIN разрешит отображать страницы сайта во фрейме, но только на других страницах того же самого вашего сайта.

MIME sniffing

Зачастую хакер может загрузить вредоносный код в виде файла с совершенно безобидным расширением. Допустим, используя в качестве тега video. И может случиться так, что браузер распознает файл как код и выполнит его. Чтобы этого не произошло, может использоваться установка заголовка X-Content-Type-Options: nosniff. При получении этого заголовка браузер будет проверять, соответствует ли формат содержимого файла тому, который указан (эта проверка и называется MIME sniffing).

Referrer-Policy

Браузеры автоматически добавляют в заголовки запросов при переходе на сайт ссылку на тот, с которого был совершен переход. Это очень удобно для аналитики. Например, не составит большого труда написать код, который соберет статистику со списком ресурсов, откуда посетители заходят на ваш сайт. Однако если в строке адреса на вашем сайте имеются запросы с какой-то конфиденциальной информацией, то очень желательно было бы скрыть эту информацию от других сайтов. Например:

Для того чтобы скрыть ссылку при переходе на чужой сайт, можно установить заголовок со значением Referrer-Policy: no-referrer.

Каким образом можно добавить на сайт заголовки запросов?

Заголовки запросов можно установить как с помощью настроек IIS, так и из кода приложения. Настройку IIS рассматривать не будем, а поговорим про варианты установки заголовков из кода.

Несколько вопросов безопасности в членстве ASP.NET

Мы используем поставщик членства ASP.NET для управления пользователями в нашем приложении.

Все было в порядке, пока у нас не было нового требования. Пользователи должны иметь возможность выбирать несколько вопросов безопасности и давать ответы на них.

При восстановлении пароля пользователю будет задан один из вопросов безопасности, и если пользователь правильно ответит, пароль будет отправлен.

По умолчанию членство ASP.NET предоставляет только один вопрос безопасности и один ответ безопасности. Есть ли способ заставить его использовать несколько?

Создание собственного пользовательского провайдера ASP.NET будет ключевым. Кроме того, вам нужно будет создать собственный шаблон для элементов управления .NET, которые используют пароль Q, чтобы вы могли отображать несколько разделов вопросов/ответов.

Возможно, вам придется установить, чтобы поставщик членства не использовал вопрос/ответ на пароль, но программировал его самостоятельно. По умолчанию он использует этот единственный Q/A для управления безопасностью; но поскольку вам нужно несколько, может быть проще использовать пользовательскую логику для управления этим.

EDIT: единственное, что я могу придумать, — это иметь два определения поставщика, каждый со своим собственным вопросом/ответом на пароль, чтобы вы эффективно хранили две записи в базе данных для каждого пользователя. Дело в том, что элементы управления пользовательского интерфейса не будут работать с этим подходом, поэтому вам нужно будет настраивать пользовательский интерфейс.

Безопасность

В этой главе рассматриваются:

  • Обязательная аутентификация и авторизация
  • Предотвращение атак межсайтового скриптинга
  • Снижение риска межсайтовой подделки запроса
  • Как избежать атаки JSON hijacking

В предыдущих главах мы рассмотрели Ajax и валидацию на стороне клиента. В этой главе мы продолжим обсуждать проблемы на стороне клиента и научимся защищать наши приложения от вредоносного ввода. Безопасность является одним из важнейших вопросов для онлайн-сервисов. Мы часто видим сообщения в новостях о громких взломах систем, где хакеры смогли украсть личную информацию или в сети были раскрыты конфиденциальные данные.

Печальная реальность такова, что многие из этих инцидентов можно было бы легко предотвратить. Как разработчикам нам необходимо создавать наши приложения с учетом требований безопасности для предотвращения такого рода проблем.

Вопрос 2. Преимущества ASP.NET перед ASP

Преимущества ASP.NET перед ASP

· Компилируемый код выполняется быстрее, большинство ошибок отлавливается ещё на стадии разработки

· Значительно улучшенная обработка ошибок времени выполнения, с использованием блоков try..catch

· Пользовательские элементы управления (controls) позволяют выделять часто используемые шаблоны, такие как меню сайта

· Использование метафор, уже применяющихся в Windows-приложениях, например, таких как элементы управления и события

· Расширяемый набор элементов управления и библиотек классов позволяет быстрее разрабатывать приложения

· ASP.NET опирается на многоязыковые возможности .NET, что позволяет писать код страниц на VB.NET, Delphi.NET, Visual C#, J# и т. д.

· Возможность кэширования всей страницы или её части для увеличения производительности

· Возможность кэширования данных, используемых на странице

· Возможность разделения визуальной части и бизнес-логики по разным файлам («code behind»)

· Расширяемая модель обработки запросов

· Расширенная событийная модель

· Расширяемая модель серверных элементов управления

· Наличие master-страниц для задания шаблонов оформления страниц

· Поддержка CRUD-операций при работе с таблицами через GridView

· Встроенная поддержка AJAX

· ASP.NET имеет преимущество в скорости по сравнению с другими технологиями, основанными на скриптах.

Здесь можно привести определённые сравнения. Так, ASP — производная от Win32, XML и HTML; PHP — от XML, HTML, Java и CDI, тогда ASP.NET — от HTML и .NET(XML и XAML соответственно). При этом, если обычно Rich Media Application создают при помощи Flash, теперь это делается с помощью модуля Silverlight, так же через сам ASP.NET. ASP.NET — богатейшая[источник не указан 435 дней] среда для разработки и развёртывания веб-ресурсов. В ASP.NET можно работать с любым .NET языком, вплоть до Managed C++ и Visual Basic, что позволяет не задумываться о переходе на C#.

Корпорация Майкрософт выпустила несколько расширений для ASP.NET:

ASP.NET MVC Framework

Ключевым сервисом промежуточной среды для создания распределенных систем является обеспечение обмена данными между компонентами распределенной системы. В настоящий момент существуют две концепции взаимодействия программных компонент: обмен сообщениями между компонентами и вызов процедур или методов объекта удаленной компоненты по аналогии с локальным вызовом процедуры. Поскольку в настоящее время любое взаимодействие между удаленными компонентами в конечном итоге основано на сокетах TCP/IP, первичным с точки зрения промежуточной среды является низкоуровневый обмен сообщениями на основе сетевых сокетов, сервис которых никак не определяет формат передаваемого сообщения. На базе протоколов TCP или HTTP затем могут быть построены прикладные протоколы обмена сообщений более высокого уровня абстракции для реализации более сложного обмена сообщениями или удаленного вызова процедур.

Удаленный вызов является моделью, происходящей от языков программирования высокого уровня, а не от реализации интерфейса транспортного уровня сетевых протоколов. Поэтому протоколы удаленного вызова должны обязательно базироваться на какой либо системе передачи сообщений, включая как непосредственное использование сокетов TCP/IP, так и основанные на нем другие промежуточные среды для обмена сообщениями. Реализация высокоуровневых служб обмена сообщениями, в свою очередь, может использовать удаленный вызов процедур, основанный на более низкоуровневой передаче сообщений, использующей, например, непосредственно сетевые сокеты. Таким образом, одна промежуточная среда может использовать для своего функционирования сервисы другой промежуточной среды, аналогично тому, как один протокол транспортного или сетевого уровня может работать поверх другого протокола при туннелировании протоколов.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Да какие ж вы математики, если запаролиться нормально не можете. 8426 — | 7330 — или читать все.

Вопросы общественной безопасности ASP.NET приложений

November 2020

219 раз

Чрезвычайно защищенное приложение ASP.NET является необходимость быть написаны на моей работе и вместо траление через Интернет ищет лучшие практики мне было интересно, какие соображения и вообще, что все должно быть сделано для обеспечения веб-приложение, общественность в безопасности.

Конечно, мы приняли во внимание комбинации пользователя / пасс, но там должны быть гораздо более глубоким уровнем, чем это. Я говорю о каждом уровне и слое, т.е. приложения

  • Использование URL переписывания
  • MasterPages
  • Sitemaps
  • пулы соединений
  • данные сессии
  • Кодирование паролей.
  • Использование хранимых процедур вместо прямых заявлений SQL

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

6 ответы

Это больше , чем toppic я думаю , что вы , возможно , воплотить в жизнь. Самый лучший совет , чтобы заставить кого — то , что уже знает , кто может посоветовать вам. В противном случае я хотел бы начать с чтения документа Microsoft « Улучшение веб — приложений безопасности: угрозы и контрмеры » , но имейте в виду , что работает на 919 печатных страниц.

Вы должны уточнить идею «хранимых процедур» в только с помощью параметризованных запросов. Это будет заботиться о большинстве ваших проблем там. Вы можете также ограничить поля на UI и вырезать или кодировать повреждающих символы, такие как досадные «;» .

Илон Маск рекомендует:  Сокращённое значение цвета
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Вариант проверки подлинности Описание