Разве CSRF не является проблемой безопасности браузера?
Спасибо Мэтью за это решение, но я нашел отличный вариант, чтобы избежать ненужных результатов. Так что синтаксис почти такой же, но я добавил к --format дополнительный параметр ppid Идентификатор родительского процесса, в большинстве случаев я считаю, что родительский процесс всегда имеет номер 1 в выводе, что помогает сортировать его так, как я хочу.
Это выглядит следующим образом:
shell: >
ps -e --format="ppid pid cmd" |
grep process.cfg |
sed -e "s/[[:space:]]\+/ /g"
register: output_process
И вывод выглядит следующим образом:
1 54345 /var/local/bin/application -c /var/local/etc/process.cfg
6435 6577 grep --color=auto process.cfg
Теперь легко использовать для сортировки ансибельные модули:
- name: Kill process
become: yes
shell: "kill {{ output_process.stdout_lines[0].split(' ')[2] }}"
Что это делает? он выбирает строку 0, которая является первой строкой, разделяет вывод между пробелами и выбирает третью фразу. В выходных есть :space: до ppid, поэтому PID является третьим
Еще раз спасибо за ваше решение Мэтью, это может быть полезно в другом случае.
6 ответов
Почему браузер не отправил бы cookie?
Расположите наборы (http://www.sitea.com) cookie для пользователя.
Пользователь перешел на сайт B (http://www.siteb.com). Интеграция функций Site B с сайтом - щелкает здесь, чтобы сделать что-то на сайте A! Пользователи нажимают "здесь".
Насколько браузер может сказать, пользователь принимает сознательное решение выполнить запрос на сайт A, таким образом, это обрабатывает его тот же способ, которым это обработало бы любой запрос на сайт A, и это включает передающий сайт cookie в запросе на сайт A.
Править: Я думаю, что основной вопрос здесь - то, что Вы думаете, что существует различие между cookie аутентификации и другими cookie. Cookie могут использоваться для хранения чего-либо - пользовательские настройки, последний высокий счет или маркер сессии. Браузер понятия не имеет, для чего используется каждый cookie. Я хочу, чтобы мои cookie всегда были доступны сайту, которые устанавливают их, и я хочу, чтобы сайт удостоверился, что принимает необходимые меры предосторожности.
Или Вы говорите, что, если Вы ищете Yahoo "Gmail" и затем нажимаете на ссылку, которая берет Вас на http://mail.google.com, Вы не должны быть зарегистрированы, даже если бы Вы сказали, Gmail для хранения Вас вошел в систему, потому что Вы нажали на ссылку от другого сайта?
Не случается так, что браузер отправляет cookie в или от внешнего домена, это - то, что Вы аутентифицируетесь, и сайт не проверяет источник запроса, таким образом, это рассматривает его, как будто запрос прибыл из сайта.
До, должен ли браузер запретить это... что относительно многих ситуаций, где запросы перекрестного сайта желательны?
Править: чтобы быть ясным, Ваш cookie не отправляется через домены.
Много старых протоколов имеет большие дыры в системе безопасности - вспоминают о недавно обнаруженных уязвимостях DNS. Как в основном любая сетевая безопасность, это - ответственность конечных точек; да, это сосет это, мы должны зафиксировать это сами, но намного более трудно зафиксировать на уровне браузера. Существуют некоторые очевидные (<img src = "logoff.php">, выглядит чертовски подозрительным, правильно?), но всегда будут пограничные случаи. (Возможно, это - сценарий GD в файле PHP, в конце концов.) Что относительно запросов Ajax? И так далее...
Я не знаю, что существует очень браузер, может сделать в той ситуации, так как точка нападения XSRF должна направить браузер к другой точке в приложении, которое выполнило бы что-то плохо. К сожалению, браузер понятия не имеет, является ли запрос, который предписывается отправить, злонамеренным или нет. Например, учитывая классический пример XSRF:
<img src="http://domain.com/do_something_bad" />
для браузера не очевидно, что что-то плохо происходит. В конце концов, как это для знания различия между этим и этим:
<img src="http://domain.com/show_picture_if_authenticated" />
Cookie для сайта никогда не отправляются в другой сайт. На самом деле, для реализации успешного нападения CSRF у взломщика не должно быть доступа к этим cookie.
В основном взломщик обманывает пользователя, на которого уже входят целевой сайт в щелчок на ссылку или загрузку изображения, которое сделает что-то на целевом сайте с учетными данными того пользователя.
Т.е. пользователь выполняет действие, и взломщик обманул пользователя в выполнение так.
Некоторые люди сказали, что не думают, что существует много браузер, может сделать.
Посмотрите это:
http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
Это - обзор предложения по новому HTTP-заголовку, чтобы помочь смягчить нападения на CSRF.
Предложенным названием заголовка является "Источник", и это - в основном заголовок "Referer" минус путь и т.д.