Asp net удалить файл
Как я могу предотвратить их показ?
@PavelMorshenyuk Извините, вы тоже нашли способ удалить имя сервера? Принятый ответ не удаляет СерверX-Powered-By пользовательский заголовок в IIS Начиная с IIS 7, вы можете удалить его, добавив следующее web.config :
Добавьте это, чтобы web.config избавиться от X-AspNet-Version заголовка:
Наконец, удалите X-AspNetMvc-Version , отредактируйте Global.asax.cs и добавьте следующее в Application_Start событие:
Вы также можете изменить заголовки во время выполнения через Application_PreSendRequestHeaders событие в Global.asax.cs . Это полезно, если значения вашего заголовка являются динамическими:
+1 - Ради интереса, 1) Зачем тебе? 2) Имеет ли это какое-либо негативное влияние? Вы делаете это из соображений безопасности, чтобы скрыть, какие технологии вы используете для создания своих веб-страниц. Это заставляет хакеров работать немного усерднее. @BritishDeveloper Это была рекомендация, которая вышла из обзора безопасности. Я думаю, что лучше не рекламировать свой технологический стек, потому что это помогает хакерам нацеливать определенные уязвимости с этой платформой. @RedFilter Спасибо за ваш быстрый и подробный ответ! На IIS 8 это не удаляет X-Powered-By заголовок. Смотрите другие ответы о том, как этого добиться web.config .Вы также можете удалить их, добавив код в ваш файл global.asax:
Работает ли это с вашими файлами содержимого / изображениями / и т. Д., Которые не проходят путь кода? что ты положил в "Сервер"? должно ли быть так? Response.Headers.Remove («Сервер: Microsoft-IIS / 7.0»); ? или это должен быть "Сервер"? пожалуйста, помогите кому-то еще странно, что PreSendRequestHeaders на самом деле предварительно отправляет заголовки ответа? Лучший вариант, но требует iis7 + Вам не нужно <clear /> их . достаточно удалить . также вы можете добавить это в system.webserver, чтобы удалить другую уязвимость: code <security> <requestFiltering> <verbs> <add verb = «ОПЦИИ» позволили = «ложь» /> </ verbs> </ requestFiltering> </ security> code Я думаю, что элемент <clear /> очищает все заголовки, включая 'X-Powererd-By', поэтому элемент <remove /> является избыточным.Чтобы удалить заголовок сервера , в файле Program.cs добавьте следующую опцию:
Чтобы удалить заголовок X-Powered-By , если он развернут в IIS, отредактируйте ваш web.config и добавьте следующий раздел в тег system.webServer:
Чтобы удалить заголовок сервера , в файле global.asax добавьте следующее:
а затем в вашем файле web.config добавьте следующий раздел <modules>:
Однако у меня была проблема, когда подпроекты не могли найти этот модуль. Не смешно.
Удаление заголовка X-AspNetMvc-Version
Спасибо Microsoft за то, что сделали это невероятно трудным. Или, возможно, это было ваше намерение, чтобы вы могли отслеживать установки IIS и MVC по всему миру .
В наше время это считается «наихудшей практикой», и трудно поверить, что Microsoft по-прежнему делает «небезопасным» значение по умолчанию и так сложно выбрать «безопасный». Это напоминает мне о том, как Windows скрывает общие расширения файлов по умолчанию, поэтому ничего не подозревающие пользователи будут нажимать на вирусы. Кажется, я вспоминаю, как Билл Гейтс в 2003 году объявил «безопасным по умолчанию» - что случилось с этой идеей? @mikenelson, если вам от этого легче, пытаться удалить тег Server в nginx так же сложно - мне пришлось взломать сам исходный код. О , RemoveServerHeaderModule это не сработает в проекте WebAPI.и удалите заголовок X-AspNetMvc-Version, изменив свой файл Global.asax.cs следующим образом:
Как описано в разделе « Пользовательские заголовки». Вы можете удалить заголовок «X-Powered-By», применив следующий раздел конфигурации к вашему web.config:
Используя ответ bkaid, я могу удалить заголовок «Сервер». IIS 8. Ответ bkaid хорош, но требует кодирования, поэтому я нашел решение, которое я описал, более удобным, поскольку оно основано на конфигурации.Как показано на странице Удаление стандартных заголовков сервера на странице веб-сайтов Windows Azure , вы можете удалить заголовки следующим образом:
Помимо стандартных настроек system.web вы можете определить собственные настройки приложения, например строку подключения к базе данных, используя <appSettings> . Следовательно, ваш самый общий набросок Web.config будет:
Давайте обсудим детали обеих групп разделов.
Группа system.web
Давайте рассмотрим наиболее ценные настройки, которые вы можете сделать в группе разделов system.web, в алфавитном порядке.
<authentication>
Раздел аутентификации контролирует тип аутентификации, используемый в вашем веб-приложении, который содержится в режиме атрибута. Вы введете значение «Нет», если кто-то может получить доступ к вашему приложению. Если требуется аутентификация, вы будете использовать «Windows», «Forms» или «Passport» для определения типа аутентификации. Например:
Кодирование осуществляется через атрибуты requestEncoding и responseEncoding . Значения должны быть одинаковыми во всех средах с одним сервером. В этом примере культура приложения установлена на голландский. Если вы не предоставите культуру, приложение будет использовать региональные настройки сервера.
Первый атрибут определяет количество запросов, которые сервер может поставить в очередь в памяти во время интенсивного трафика. В этом примере, если уже есть 100 запросов, ожидающих обработки, следующий запрос приведет к ошибке 503 («Сервер слишком занят»).
<sessionState>
<trace>
trace.axd трассировки вашего приложения находится в корневой папке приложения под именем trace.axd . Вы можете изменить отображение информации о трассировке в разделе трассировки.
Атрибуты, которые вы будете искать изначально, включены: localOnly и pageOutput .
Установите для localOnly значение false, чтобы получить доступ к журналу трассировки с любого клиента. Если вы установите значение pageOutput в «true», информация о трассировке будет добавляться внизу каждой веб-страницы.
Группа appSettings
Помимо параметров конфигурации веб-сайта, о которых я говорил в предыдущих параграфах, вы будете знать, что программисту часто нравится использовать пользовательские константы всего приложения для хранения информации на нескольких страницах. Наиболее привлекательным примером такой пользовательской константы является строка подключения к базе данных, но вы, вероятно, можете думать о десятках других из вашего собственного опыта.
Общим знаменателем этих констант является то, что вы хотите программно извлекать их значения из вашего кода. Файл Web.config предоставляет возможность сделать это, но в качестве меры безопасности эти константы должны быть включены в группу <appSettings> . Как и <system.web> , <appSettings> является прямым дочерним тегом <appSettings> конфигурации Web.config.
Типичная группа пользовательских разделов будет выглядеть примерно так:
Пример показывает, что ключи и значения могут быть включены в пользовательские настройки приложения с помощью <add> . Способ доступа к такому значению на любой из ваших веб-страниц показан ниже:
Да, это так просто! Обратите внимание, что значением этих настроек всегда является строковый формат.
Ключевые составляющие RESTful
Веб-сервисы прошли долгий путь с момента их появления. В 2002 году W3C выпустил определения WSDL и SOAP веб-сервисов. Это сформировало стандарт по созданию веб-сервисов.
В 2004 году W3C выпустил определение ещё одного стандарта под названием RESTful. В последние годы этот стандарт стал довольно популярным. На данный момент он используется многими известными сайтами по всему миру, в число которых входят Facebook и Twitter.
3–4 декабря, Онлайн, Беcплатно
Ключевые составляющие реализации RESTful:
Методы RESTful
- POST — с его помощью можно создать новую запись сотрудника;
- GET — с его помощью можно запросить список сотрудников;
- PUT — с его помощью можно обновить данные сотрудников;
- DELETE — с его помощью можно удалять записи сотрудников.
Посмотрим на это с точки зрения одной записи. Допустим у нас есть запись сотрудника под номером 1. Вот какое значение могли бы иметь следующие действия:
- POST — этот метод нельзя применить, так как сотрудник с номером 1 уже существует;
- GET — этот метод можно использовать для получения данных о сотруднике под номером 1;
- PUT — этот метод можно использовать для обновления данных сотрудника под номером 1;
- DELETE — этот метод можно использовать для удаления записи сотрудника под номером 1.
Почему RESTful
В основном популярность RESTful обусловлена следующими причинами:
1. Разнородные языки и среды — это одна из основных причин:
- У веб-приложений, написанных на разных языках, есть возможность взаимодействовать друг с другом;
- Благодаря RESTful эти приложения могут находиться в разных средах, будь то Windows или Linux.
Представим, что для работы с такими сайтами как Facebook, Twitter, Google и т. д. клиентскому приложению нужно знать, на каких языках и на какой платформе они написаны. Основываясь на этих знаниях, мы могли бы написать код для взаимодействия с ними, однако это превратилось бы в сущий ад.
Facebook, Twitter и Google дают доступ к их функциональности посредством RESTful веб-сервисов. Это даёт возможность любому клиентскому приложению взаимодействовать с этими сервисами с помощью REST.
2. Технологический бум – сегодня всё должно работать на разнообразных устройствах, будь то смартфон, ноутбук или кофеварка. Представляете, каких бы усилий стоило наладить взаимодействие этих устройств с помощью обычных веб-приложений? RESTful API делают эту задачу гораздо проще, поскольку, как было упомянуто выше, вам не нужно знать, что у устройства «под капотом».
3. Появление облачных сервисов — всё переезжает в облако. Приложения медленно перемещаются в облачные системы вроде Azure или Amazon, которые предоставляют большое количество API на основе RESTful архитектуры. Следовательно, приложения должны разрабатываться таким образом, чтобы они были совместимы с облаком. Так как все облачные архитектуры работают на основе REST, логично разрабатывать веб-сервисы тоже на REST-архитектуре, чтобы извлечь максимум пользы из облачных сервисов.
RESTful архитектура
Приложение или архитектура считается RESTful, если ей присущи следующие характеристики:
Принципы и ограничения RESTful
Архитектура REST основывается на нескольких характеристиках, которые описаны ниже. Любой RESTful веб-сервис должен им соответствовать, чтобы называться таковым. Эти характеристики также известны как принципы проектирования, которым нужно следовать при работе с RESTful-сервисами.
RESTful клиент-сервер
Это самое важное требование REST-архитектуры. Оно означает, что на сервере располагается RESTful веб-сервис, который предоставляет необходимую функциональность клиенту. При отправке клиентом запроса к веб-сервису сервер должен либо отклонить его, либо принять и предоставить соответствующий ответ.
Отсутствие состояния
Многослойная система
Суть этой концепции заключается в том, что любой дополнительный слой вроде промежуточного (слой, в котором создаётся бизнес-логика; это может быть дополнительный сервис, с которым клиент взаимодействует до сервера) можно поместить между клиентом и сервером, на котором располагается RESTful веб-сервис. Однако этот слой должен быть внедрён прозрачно, чтобы он не нарушил взаимодействия клиента и сервера.
Единообразие интерфейса
- POST — для создания ресурса;
- GET — для его получения;
- PUT — для его обновления;
- DELETE — для его удаления.
Веб-сервисы можно создавать на множестве языков. Многие IDE можно использовать для создания REST-сервисов.
Наш сервис будет работать со следующим набором данных «туториалов»:
| TutorialId | TutorialName |
|---|---|
| 0 | Arrays |
| 1 | Queues |
| 2 | Stacks |
Мы реализуем следующие RESTful методы:
- GET Tutorial — при его вызове клиент получает все доступные TutorialName;
- GET Tutorial/TutorialId — при его вызове клиент получает TutorialName, соответствующее переданному TutorialId;
- POST Tutorial/TutorialName — при его вызове клиент отправляет запрос на добавление туториала с переданным TutorialName;
- DELETE Tutorial/TutorialId — при его вызове клиент отправляет запрос на удаление туториала с TutorialName, соответствующему переданному TutorialId.
Теперь создадим шаг за шагом наш веб-сервис.
Шаг первый
После выбора этой опции должно появиться новое диалоговое окно, о котором мы поговорим в следующем шаге.
Шаг второй
Если далее у вас появилось следующее окно, выбирайте вариант «Пустой»:
После этого должно открыться окно, где в обозревателе решений можно увидеть наш проект:
Шаг третий
В открывшемся окне найдите опцию «Служба WCF (с поддержкой технологии AJAX)» и дайте ей имя TutorialSevice.svc:
Шаг четвёртый
Теперь нам нужно внести изменения в конфигурационный файл Web.config. Он содержит настройки, необходимые для правильной работы приложения. Наше изменение позволит приложению отправлять и принимать данные как RESTful веб-сервис.
Откройте конфигурационный файл:
Шаг пятый
Пора приниматься за код. Откройте файл TutorialService.svc. Сначала добавим код для отображения наших данных. Создадим список со строками «Arrays», «Queues» и «Stacks». Они будут отражать имена доступных туториалов:
Шаг шестой
Теперь напишем код для нашего метода GET в том же файле. Этот метод будет запускаться при каждом вызове сервиса из браузера. Он будет использоваться для получения доступных туториалов:
В самом методе GetAllTutorials() находится код, который собирает все названия туториалов и возвращает их в одной строке.
Шаг седьмой
Код, показанный ниже, нужен для того, чтобы вернуть соответствующий TutorialName при получении GET-запроса с TutorialId :
Метод GetTutorialByID() реализует описанную логику. Обратите внимание на то, что мы приводим TutorialId к типу Integer . Это связано с тем, что всё передаваемое в адресную строку браузера является строкой. А поскольку индексом списка не может быть строка, мы добавляем код, необходимый для преобразования в число.
Шаг восьмой
Настала очередь кода для метода POST, который будет вызываться каждый раз, когда мы захотим добавить строку в наш список туториалов с помощью POST-запроса:
На первой строке находится атрибут WebInvoke , прикреплённый к нашему методу, что позволяет вызывать его с помощью POST-запроса. Для атрибутов RequestFormat и ResponseFormat мы указываем JSON, так как именно с этим форматом работает RESTful веб-сервис.
Шаг девятый
Осталось добавить метод для работы с DELETE-запросами. Он будет вызываться каждый раз, когда мы будем пытаться удалить существующее значение из списка с помощью DELETE-запроса:
Первая-вторая строки ничем особо не отличаются от предыдущих методов, они сигнализируют о том, что нижеуказанный метод будет вызываться при каждом DELETE-запросе.
В самом методе DeleteTutorial() мы приводим переданный TutorialId к типу Integer и удаляем из списка соответствующий элемент.
В итоге код должен выглядеть так (не учитывая элементов, которые были там изначально):
Запускаем наш веб-сервис
Мы создали наш веб-сервис, пора его запустить.
Сначала кликните правой кнопкой по файлу проекта Webservice.REST и выберите опцию «Назначить автозагружаемым проектом», чтобы Visual Studio запустила этот проект при запуске всего решения:
Теперь осталось запустить проект. Рядом с кнопкой запуска будет указано имя браузера, в котором будет запускаться проект. Автоматически будет предложен браузер по умолчанию, однако вам ничто не мешает выбрать другой:
Прим. перев. В вашем случае сервис может запуститься на localhost с другим портом. Далее в статье мы будем использовать значение 51056, однако не забывайте заменять его на своё, когда будете пытаться запускать примеры.
В этом примере браузер делает GET-запрос и тем самым вызывает написанный нами метод GetAllTutorials() , который возвращает список со всеми туториалами.
Тестируем веб-сервис
Выше мы увидели, как браузер делает GET-запрос для вызова GetAllTutorials() . Давайте проверим другие сценарии.
1. GET Tutorial/TutorialId — при вызове этого RESTful API клиент должен получить TutorialName , соответствующий переданному TutorialId .
В этот раз был вызван метод GetTutorialByID() , который вернул туториал с индексом 1 — «Queues».
2. POST Tutorial/TutorialName — при вызове этого API клиент отправляет запрос на добавление переданного TutorialName , который сервер должен добавить в список. В этот раз нам понадобится инструмент Fiddler, который можно бесплатно скачать с официального сайта.
Запустите Fiddler и выполните следующие действия:
Нажмите на кнопку «Execute». После этого нашему сервису будет отправлен запрос на добавление «Trees».
3. DELETE Tutorial/TutorialId — при вызове этого API клиент отправит запрос на удаление из списка TutorialName , которое соответствует переданному TutorialId .
Запустите Fiddler и выполните следующие действия:
Если мы опять запросим список всех туториалов, мы увидим, что их стало меньше на один:
О безопасности веб-приложения желательно начинать задумываться с самого начала процесса разработки. Веб-сайт никогда не будет надежно защищен до тех пор, пока вы не предпримите все необходимые меры, чтобы защитить веб-сервер от максимально возможного количества существующих уязвимостей.
Автор: AJ Kumar
О безопасности веб-приложения желательно начинать задумываться с самого начала процесса разработки. Веб-сайт никогда не будет надежно защищен до тех пор, пока вы не предпримите все необходимые меры, чтобы защитить веб-сервер от максимально возможного количества существующих уязвимостей. Даже если исходный код надежно защищен, злоумышленники все равно могут найти лазейку. И даже когда уязвимости отсутствуют вовсе, сервер так и или иначе взаимодействует с другими системами, что вполне может стать причиной незаконного проникновения. В конце концов, сервер обслуживают люди, которые часто не обладают достаточной компетенцией в этих вопросах.
IIS-уязвимости
Существует огромное количество видов атак на веб-сайт, начиная от лазеек в базах данных и уязвимостей в исходном коде и заканчивая вирусами, недовольными сотрудниками и социальной инженерией. Однако полная классификация всех возможных атак на IIS-сервер выходит за рамки этой статьи. Но в целом, можно сказать, что целями злоумышленников являются механизмы аутентификации, авторизации и аудита. Вначале взломщик подбирает пароль и пытается попасть в систему как легитимный пользователь. После успешной аутентификации хакер пытается получить доступ к другим ресурсам посредством изменения политики безопасности сервера. И, наконец, потом злоумышленник удаляет следы, поскольку каждое действие пользователя обычно записывается в лог при помощи механизмов аудита.
Более того, некоторые хакеры осуществляют так называемые «пассивные» атаки, следы от которых обнаружить еще сложнее. Во время пассивной атаки злоумышленник вообще не предпринимает никаких действий, а просто наблюдает за тем, что происходит в системе. Таким образом, детектирование, предупреждение и противодействие подобного рода атакам может быть затрудненно в особенности там, где работают неграмотные администраторы или плохо проработана политика безопасности.
Безопасность IIS
Рисунок 1: Средства безопасности в IIS
Регулирование прав доступа
Запрет на соединение предпочтительнее конфигурировать на как можно более низком уровне в модели OSI.
Чтобы сконфигурировать политику относительно DNS для разрешения доступ всем, кроме специально указанных адресов, кликните на ‘Edit Feature Settings’. Появится окно ‘IP Address and Domain Restrictions’.
Рисунок 2: Запрет на доступ определенным клиентам
Затем вы можете создать правила для определенных хостов или подсетей. Чтобы создать правило, разрешающее доступ для конкретного клиента или подсети, кликните на “Allow Entry” и укажите отдельный IP-адрес или диапазон IP-адресов.
Рисунок 3: Разрешение на доступ определенным хостам
Настройка MIME-Type
Рисунок 4: Добавление нового MIME type
Фильтрация запросов
<security>
<requestFiltering>
<verb sallowUnlisted=”false” >
<add verb=”GET” allowed=”true” />
</verbs>
</requestFiltering>
</security>
Другой пример, когда фильтруются запросы, содержащие имена файлов, которые не соответствуют набору правил. Подобные запросы можно разрешить или отклонить. Если запрос отклонен, в лог будет записан статус 404.7. Для фильтрации запросов на основе имен файлов используйте шаблон ниже:
<security>
<requestFiltering>
<fileExtensions allowUnlisted=”false” >
<add fileExtension=”.asp” allowed=”true” />
</fileExtensions>
</ requestFiltering>
</security>
Запрос также может быть отклонен при превышении определенного размера запроса.
<security>
<requestFiltering>
<requestLimits
maxAllowedContentLength=”200000000”
maxUrl=”30” />
</requestLimits>
</ requestFiltering>
</security>
И последний пример, в котором запросы фильтруются на основе подстрок (в данном случае – «. .»), входящих в URL.
<security>
<requestFiltering>
<denyUrlSequence>
<add sequence=”. .” />
</denyUrlSequence>
</ requestFiltering>
</security>
Настройка пула приложений
Когда необходимо получить информацию из внешнего источника, может возникнуть конфликт, поскольку довольно сложно разделить между собой пулы веб-приложений. Иначе говоря, код, запущенный внутри одного пула, будет влиять на работоспособность другого пула. Чтобы в некоторой степени предотвратить этот конфликт, в IIS предусмотрена настройка пула приложений. Каждый пул приложений имеет свой конфигурационный файл, которых хранится в папке %systemdriver\inetpub\temp\appPools, и дополнительный идентификатор безопасности (SID), инжектируемый в соответствующий процесс w3wp.exe. Соответственно, каждый конфигурационный файл пула закреплен за своим SID’ом через права доступа.
Полная изоляция пулов между собой позволяет исключить возможность влияния вредоносного сайта на соседние пулы, находящиеся на одном сервере. Если один из сайтов будет скомпрометирован, другие останутся защищенными.
Рисунок 5: Добавление пула приложений
Настройка ISAPI
В IIS можно запретить или разрешить те или иные расширения ISAPI. Если расширение запрещено, при запросе файла соответствующего типа в лог заносится статус 404.2, поскольку злоумышленник может удаленно внедрить и выполнить вредоносный код. После добавления новых расширений в дальнейшем необходимо провести аудит безопасности сервера. Чтобы добавить расширение, укажите имя фильтра и путь к библиотеке DLL.
Рисунок 6: Добавление нового расширения
Настройка логов
Хакеры часто проводят DOS-атаки, отправляя на сервер огромные запросы, что в свою очередь может сказаться на размере логов. При помощи логов, например, можно выявить факты неправомерного доступа. В ОС Windows имеет встроенная функция записи в журнал важной информации: время авторизации, попытки подбора пароля и т. д., что является одним из признаков атаки. Для каждого сайта можно настроить систему фиксации событий в формате W3C.
Рисунок 7: Настройка логов
В IIS есть возможность оповещения, как для успешных, так и для неудачных попыток входа в систему, чтобы администратор смог быстро обнаружить подозрительную активность.
Настройка страниц ошибок
Злоумышленник может получить конфиденциальную информацию о сервере или приложении во время возникновении ошибки. Все дело в том, что если сервер не в состоянии обработать неизвестную фатальную ошибку, то помимо статуса ошибки отображается дополнительная информация, которая может заинтересовать хакера. На рисунке ниже как раз показан такой случай, где злоумышленнику доступно имя пользователя, пароль, IP-адрес сервера, структура базы данных и т. д.
Рисунок 8: Неудачный пример страницы с ошибкой
Вместо страницы, показанной выше, для каждого типа ошибки следует привязывать заранее заготовленную страницу, чтобы скрыть конфиденциальную информацию.
В IIS есть возможность выдачи различных страниц с ошибками для конечных пользователей, администраторов и разработчиков.
Рисунок 9: Настройка страниц ошибок
Даже после грамотной настройки IIS не следует забывать о безопасности приложений. В последнее время много внимания уделяется уязвимостям в веб-приложениях: SQL-инъекциям, межсайтовому скриптингу, воспроизведению сессий (session replay), RFI и многим другим. С каждым днем злоумышленники становятся все более изощренными. Таким образом, свои позиции следует защищать со всех фронтов.
В статье мы рассмотрели способы защиты приложения посредством грамотной конфигурации IIS, включая ограничение доступа по IP-адресу, настройку MIME-Type, фильтрацию запросов, настройку пула приложений, ISAPI и страниц ошибок. Таким образом, на данный момент у вас должно появиться более полное понимание относительно безопасности в целом и в частности относительно настроек, повышающих безопасность IIS.
Читайте также: