Атаки по межсайтовым запросам (CSRF) очень распространены в веб-приложениях и могут нанести значительный вред, если это разрешено. Если вы никогда не слышали о CSRF, я рекомендую вам посетить страницу OWASP .
К счастью, предотвращение CSRF-атак довольно просто, я постараюсь показать вам, как они работают и как мы можем защитить от них как можно менее навязчивым способом в веб-приложениях на основе Java.
Представьте, что вы собираетесь совершить перевод денег на защищенной веб-странице вашего банка, когда вы нажимаете на опцию перевода, загружается страница формы, которая позволяет вам выбрать дебетовые и кредитные счета и ввести сумму денег для перемещения. Когда вы удовлетворены вашими опциями, вы нажимаете «отправить» и отправляете информацию формы на веб-сервер вашего банка, который, в свою очередь, выполняет транзакцию.
Теперь добавьте к изображению следующее: вредоносный веб-сайт (который вы, конечно, считаете безопасным) открыт в другом окне / вкладке вашего браузера, пока вы невинно перемещаете все свои миллионы на сайте вашего банка. Этот злой сайт знает структуру веб-форм банка, и когда вы просматриваете его, он пытается публиковать транзакции, снимающие деньги с ваших счетов и вносящие их на счета злого повелителя, он может делать это, потому что у вас открытая и действительная сессия с Банки сайта в одном браузере! Это основа для атаки CSRF.
Один простой и эффективный способ предотвратить это — генерировать случайную (то есть непредсказуемую) строку при загрузке начальной формы передачи и отправлять ее в браузер. Затем браузер отправляет этот фрагмент данных вместе с параметрами передачи, и сервер проверяет их перед утверждением транзакции для обработки. Таким образом, вредоносные веб-сайты не могут публиковать транзакции, даже если у них есть доступ к действительному сеансу в браузере.
Чтобы реализовать этот механизм в Java, я решил использовать два фильтра: один для создания соли для каждого запроса, а другой для его проверки. Поскольку запросы пользователей и последующие проверки POST или GET, которые должны быть проверены, не обязательно выполняются по порядку, я решил использовать кэш на основе времени для хранения списка допустимых строк соли.
Первый фильтр, используемый для генерации новой соли для запроса и сохранения ее в кеше, может быть закодирован следующим образом:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
package com.ricardozuasti.csrf;import com.google.common.cache.Cache;import com.google.common.cache.CacheBuilder;import com.google.common.cache.CacheLoader;import com.google.common.cache.LoadingCache;import java.io.IOException;import java.security.SecureRandom;import java.util.concurrent.ExecutionException;import java.util.concurrent.TimeUnit;import javax.servlet.*;import javax.servlet.http.HttpServletRequest;import org.apache.commons.lang.RandomStringUtils;public class LoadSalt implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { // Assume its HTTP HttpServletRequest httpReq = (HttpServletRequest) request; // Check the user session for the salt cache, if none is present we create one Cache<String, Boolean> csrfPreventionSaltCache = (Cache<String, Boolean>) httpReq.getSession().getAttribute("csrfPreventionSaltCache"); if (csrfPreventionSaltCache == null){ csrfPreventionSaltCache = CacheBuilder.newBuilder() .maximumSize(5000) .expireAfterWrite(20, TimeUnit.MINUTES) .build(); httpReq.getSession().setAttribute("csrfPreventionSaltCache", csrfPreventionSaltCache); } // Generate the salt and store it in the users cache String salt = RandomStringUtils.random(20, 0, 0, true, true, null, new SecureRandom()); csrfPreventionSaltCache.put(salt, Boolean.TRUE); // Add the salt to the current request so it can be used // by the page rendered in this request httpReq.setAttribute("csrfPreventionSalt", salt); chain.doFilter(request, response); } @Override public void init(FilterConfig filterConfig) throws ServletException { } @Override public void destroy() { }} |
Я использовал Guava CacheBuilder для создания солт-кэша, так как он имеет ограничение по размеру и время ожидания для каждой записи. Чтобы сгенерировать настоящую соль, я использовал Apache Commons RandomStringUtils , работающий на Java 6 SecureRandom для обеспечения сильного начального уровня.
Этот фильтр следует использовать во всех запросах, заканчивающихся на странице, которая будет связывать, публиковать или вызывать через AJAX защищенную транзакцию, поэтому в большинстве случаев рекомендуется сопоставлять его с каждым запросом (возможно, за исключением статического содержимого, такого как изображения). CSS и т. Д.). Это отображение в вашем web.xml должно выглядеть примерно так:
|
01
02
03
04
05
06
07
08
09
10
11
|
...<filter> <filter-name>loadSalt</filter-name> <filter-class>com.ricardozuasti.csrf.LoadSalt</filter-class></filter>...<filter-mapping> <filter-name>loadSalt</filter-name> <url-pattern>*</url-pattern></filter-mapping>... |
Как я уже сказал, для проверки соли перед выполнением безопасных транзакций мы можем написать другой фильтр:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
package com.ricardozuasti.csrf;import com.google.common.cache.Cache;import java.io.IOException;import javax.servlet.*;import javax.servlet.http.HttpServletRequest;public class ValidateSalt implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { // Assume its HTTP HttpServletRequest httpReq = (HttpServletRequest) request; // Get the salt sent with the request String salt = (String) httpReq.getParameter("csrfPreventionSalt"); // Validate that the salt is in the cache Cache<String, Boolean> csrfPreventionSaltCache = (Cache<String, Boolean>) httpReq.getSession().getAttribute("csrfPreventionSaltCache"); if (csrfPreventionSaltCache != null && salt != null && csrfPreventionSaltCache.getIfPresent(salt) != null){ // If the salt is in the cache, we move on chain.doFilter(request, response); } else { // Otherwise we throw an exception aborting the request flow throw new ServletException("Potential CSRF detected!! Inform a scary sysadmin ASAP."); } } @Override public void init(FilterConfig filterConfig) throws ServletException { } @Override public void destroy() { }} |
Вы должны настроить этот фильтр для каждого запроса, который должен быть защищен (т.е. извлекает или изменяет конфиденциальную информацию, перемещает деньги и т. Д.), Например:
|
01
02
03
04
05
06
07
08
09
10
11
|
...<filter> <filter-name>validateSalt</filter-name> <filter-class>com.ricardozuasti.csrf.ValidateSalt</filter-class></filter>...<filter-mapping> <filter-name>validateSalt</filter-name> <url-pattern>/transferMoneyServlet</url-pattern></filter-mapping>... |
После настройки обоих сервлетов все ваши защищенные запросы должны потерпеть неудачу :). Чтобы исправить это, вы должны добавить к каждой ссылке и публикации формы, которая заканчивается защищенным URL, параметр csrfPreventionSalt, содержащий значение параметра запроса с тем же именем. Например, в форме HTML на странице JSP:
|
1
2
3
4
5
6
|
...<form action="/transferMoneyServlet" method="get"> <input type="hidden" name="csrfPreventionSalt" value="<c:out value='${csrfPreventionSalt}'/>"/> ...</form>... |
Конечно, вы можете написать собственный тег, красивый код Javascript или любой другой, который вы предпочитаете, чтобы вставить новый параметр в каждую нужную ссылку / форму.
Ссылка: Предотвращение CSRF в веб-приложениях Java от нашего партнера по JCG