Я работаю над веб-приложением и попросил запустить VAPT против него перед выпуском.Как request.getHeader («Происхождение») предотвращает атаки Cross Site Request Forgery?
Тогда я скачал Vega и быстро просмотрел мой веб-приложение и наткнулся на вопрос VAPT следующим образом:
Vega обнаружил, что ресурс установлен небезопасный Cross-Origin совместного использования ресурсов (CORS) контроль доступа , CORS предоставляет механизмы, позволяющие серверу ограничить доступ к ресурсам для межсайтовых запросов до определенных доверенных доменов. Сервер, о котором идет речь, разрешил ресурс из любого источника, установив значение ответного заголовка «Access-Control-Allow-Origin» в значение подстановочного знака. Это представляет угрозу безопасности, поскольку любой сайт может выдавать запросы на ресурсы доступа, независимо от их происхождения.
Тогда я начал находить решение, чтобы исправить это и наткнулся на this пост и реализовал filter как это было предложено в ответ следующим образом:
@Component
public class CORSFilter implements Filter {
@Override
public void init(FilterConfig filterConfig) throws ServletException {
}
@Override
public void doFilter(ServletRequest req, ServletResponse res,
FilterChain chain) throws IOException, ServletException {
HttpServletResponse response = (HttpServletResponse) res;
HttpServletRequest request = (HttpServletRequest) req;
response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));
response.setHeader("Access-Control-Allow-Methods",
"POST, GET, OPTIONS, DELETE");
response.setHeader("Access-Control-Max-Age", "3600");
response.setHeader("Access-Control-Allow-Headers", "x-requested-with");
chain.doFilter(request, response);
}
public void destroy() {
}
}
Теперь, когда я снова просмотрел Vega против веб-приложение, он еще не перечислил ту же проблему, которая, как я считаю, спасла мой webapp от атак CSRF.
Теперь, после прочтения this пост, я имею в виду о том, как request.getHeader("Origin") предотвращает Cross Site Request Forgery attacks, так как независимо от происхождения либо https://webapp.com или https://evil.com, запрос всегда справедливо для применения как я собирание "Access-Control-Allow-Origin" из самого запроса заголовка.
Может ли кто-нибудь помочь мне в понимании концепции, как настройка request.getHeader("Origin") экономит у CSRF attacks?
Спасибо.
Понимание после прочтения @rism ответа и Патрик Grimard post:
Когда клиентское приложение делает запрос AJAX, браузер сначала отправляет предполетный OPTIONS запроса к серверу, чтобы определить, что клиент разрешен делать, для запроса, кроме GET, и поэтому мы должны установить Access-Control-Allow-Origin как для происхождения, так и для определенного домена как часть заголовка ответа.
На примере POST, когда клиент посылает запрос, браузер сначала делает предполетной OPTIONS запрос на сервер и ответ сервера к OPTIONS запросу содержит заголовки, которые инструктируют браузер, для которого всех origin запроса разрешается. Помимо добавления response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin")); сайт по-прежнему уязвим, поэтому нам необходимо явно указать IP-адреса в Apache (для приложения, развернутого в кластере), как сделано here или в Tomcat, как описано here.
Еще у меня есть одно сомнение, если мы ограничиваем IP-адрес на самом серверном уровне, чем мы на самом деле нужно установить "Access-Control-Allow-Origin" как часть заголовка ответа?
Если вы используете новейшую версию весенней безопасности, там встроена поддержка cors, вам не нужно писать фильтр – xenoterracide
Да, вам все равно нужно будет отправить заголовок ACAO, потому что хотя ограничение IP может ограничить допустимое в связанные диапазоны IP, запрос по-прежнему будет, по-видимому, перекрестным.Поэтому, хотя ограничение IP может выступать в качестве белого списка, вы все еще не можете делать CORS без заголовка ACAO. Даже запрос от a.example.com к b.example.com является перекрестным, и для использования AJAX потребуются заголовки CORS. – rism
Чтобы быть ясным, CORS на самом деле является частью клиентской технологии спецификации HTML5. Итак, я предполагаю, что вы говорите о запросах AJAX от браузеров на стороне клиента? В противном случае, если вы действительно говорите о вызовах сервера к серверу, то CORS не совсем уместен, так как это браузер, который использует политику одного и того же происхождения, а не сервер. – rism