Основные преимущества Spring Security 3.2.0 RC1: заголовки безопасности

Этот пост был изначально написан Робом Винчем из SpringSource. 

Это мой последний пост в серии из двух статей о Spring Security 3.2.0.RC1. В моем  предыдущем посте  обсуждалась защита CSRF Spring Security. В этом посте мы обсудим, как использовать Spring Security для добавления различных заголовков ответов для защиты вашего приложения.

ЗАГОЛОВКИ БЕЗОПАСНОСТИ

Многие из новых функций Spring Security в 3.2.0.RC1 реализованы путем добавления заголовков к ответу. Основой для этих функций послужила усердная работа  Мартена Дейна . Если имя звучит знакомо, возможно, потому, что одна из его публикаций в 10K + на весенних форумах помогла вам.

Если вы используете конфигурацию XML, вы можете добавить все заголовки по умолчанию, используя  элемент <headers /> Spring Security  без дочерних элементов, чтобы добавить все заголовки по умолчанию в ответ:

<http ...>
    ...
    <headers />
</http>

Если вы используете конфигурацию Java Spring Security, по умолчанию добавляются все заголовки безопасности по умолчанию. Их можно отключить с помощью конфигурации Java ниже:

@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends
   WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http
      .headers().disable()
      ...;
  }
}

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

• Контроль кеша
• Параметры типа контента
• HTTP Строгая Транспортная Безопасность
• X-Frame-Options
• X-XSS-ЗАЩИТА

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache

Простое добавление элемента <headers /> без дочерних элементов автоматически добавит Cache Control и несколько других средств защиты. Однако, если вы хотите только управление кэшем, вы можете включить эту функцию, используя пространство имен Spring Security XML с  элементом <cache-control /> .

<http ...>
...
<headers>
<cache-control />
</headers>
</http>

Точно так же вы можете включить только управление кэшем в Java Configuration следующим образом:

@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.cacheControl()
.and()
...;
}
}

Если вы действительно хотите кэшировать конкретные ответы, ваше приложение может выборочно вызывать HttpServletResponse.setHeader (String, String)  для переопределения заголовка, установленного Spring Security. Это полезно для обеспечения правильного кэширования таких вещей, как CSS, JavaScript и изображения.

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

@EnableWebMvc
public class WebMvcConfiguration extends WebMvcConfigurerAdapter {
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry
.addResourceHandler("/resources/**")
.addResourceLocations("/resources/")
.setCachePeriod(31556926);
}
// ...
}

Исторически браузеры, в том числе Internet Explorer, пытались угадать тип содержимого запроса, используя  анализатор содержимого . Это позволило браузерам улучшить взаимодействие с пользователем, угадав тип контента на ресурсах, которые не указали тип контента. Например, если браузер обнаружил файл JavaScript, для которого не указан тип содержимого, он сможет угадать тип содержимого и затем выполнить его.

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

Отслеживание содержимого можно отключить, добавив следующий заголовок в наш ответ:

X-Content-Type-Options: nosniff

Как и в случае с элементом управления кэшем, директива nosniff добавляется по умолчанию при использовании элемента <headers /> без дочерних элементов. Однако если вы хотите больше контролировать, какие заголовки добавляются, вы можете использовать   элемент <content-type-options />, как показано ниже:

<http ...>
...
<headers>
<content-type-options />
</headers>
</http>

Заголовок X-Content-Type-Options добавляется по умолчанию с настройкой Spring Security Java. Если вы хотите больше контроля над заголовками, вы можете явно указать параметры типа контента с помощью следующего:

@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.contentTypeOptions()
.and()
...;
}
}

Когда вы вводите веб-сайт вашего банка, вы вводите mybank.example.com или https://mybank.example.com? Если вы пропустите протокол https, вы потенциально уязвимы для атак Man in the Middle . Даже если веб-сайт выполняет перенаправление на https://mybank.example.com, злоумышленник может перехватить первоначальный HTTP-запрос и манипулировать ответом (т. Е. Перенаправить на https://mibank.example.com и украсть свои учетные данные).

Многие пользователи опускают протокол https, и именно поэтому  была создана HTTP Strict Transport Security (HSTS) . После добавления mybank.example.com в качестве  хоста HSTS браузер может заранее знать, что любой запрос к mybank.example.com должен интерпретироваться как https://mybank.example.com. Это значительно снижает вероятность возникновения атаки «Человек посередине».

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

<http ...>
...
<headers>
<hsts />
</headers>
</http>

@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.hsts()
.and()
...;
}
}

<http ...>
    ...
    <headers>
        <frame-options />
    </headers>
</http>

@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.frameOptions()
.and()
...;
}
}

<http ...>
...
<headers>
<xss-protection />
</headers>
</http>

@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.xssProtection()
.and()
...;
}
}