SP
А порох то и вообще для шахт думали пользовать
Size: a a a
2020 May 31
DL
Роботов и ИИ тоже все боятся, а используют в битвах роботов и секс-индустрии
AP
Тут есть идея AI подключить к разбору багов в ядре, отсортировать и потегать нужно, а закрытых уже изрядно известно
DL
Тут есть идея AI подключить к разбору багов в ядре, отсортировать и потегать нужно, а закрытых уже изрядно известно
Альойна же вроде этим занимается
AP
Это очень малоэффективно даже при нынешних темпах её клонирования
AS
спасибо, посмотрю
в семёрке что-то похожее через hook_field_attach_presave получалось делать
AP
Заставить бы ai переписывать модули от 7-ки под 8-ку 😄
Это давно есть - DMU https://www.drupal.org/documentation/modules/drupalmoduleupgrader
AP
Сложнее в доках 7ки на каждый устаревший хук комент со ссылкой на новый оставить (в 8ке)
ИЛ
Сложнее в доках 7ки на каждый устаревший хук комент со ссылкой на новый оставить (в 8ке)
Удалить всех семёрочников в отдельный чат!
RR
Удалить всех семёрочников в отдельный чат!
И бесполезных упырей в кепках
AI
И бесполезных упырей в кепках
И нытиков
ИЛ
И бесполезных упырей в кепках
Не надо так явно завидовать моему безупречному вкусу.
DK
Привет,
А поясните, пожалуйста по защите от CSRF.
Реализация в Drupal 8 такова, что в запрос к своему кастомному URL надо добавить token: специальный параметр или header в зависимости от метода проверки (_csrf_token или _csrf_request_header_token). Этот токен можно свободно получить получить по URL /session/token (GET).
Мне не очень понятно, от чего защищает такая защита.
1. С одной стороны, если некий скрипт имеет возможность обратиться к моему кастомному URL (POST), то что ему помешает предварительно сделать GET-запрос на /session/token?
2. С другой стороны есть обсуждение, почему небезопасно помещать этот token в drupalSettings:
https://drupal.stackexchange.com/questions/270792/is-it-a-security-issue-to-put-csrf-token-in-drupal-settings
НО при этом:
- токен форма в явном виде вписывается в HTML form > input и может быть прочитан любым скриптом прямо из DOM
- любой скрипт, который получает и передает токен, так или иначе хранит его в памяти, т. е. его можно извлечь
3. POST-запросы с другого домена в любом случае идут от имени анонимного пользователя (авторизационная cookie с сессией игнорируется). Т. е. мы говорим только о защите от скриптов, которые выполняются в контексте страницы сайта.
4. Токены не меняются со временем. По сути они просто привязаны к сессии и непонятно, зачем эта новая сущность, если и так есть session ID. Я проверил: и форма при перезагрузке не меняет свой CSRF token, и /session/token выдает всегда одно значение день ото дня.
Можете объяснить, от какого типа атак защищает такая защита вообще?
Хочется защититься от CSRF правильно, но то ли реализация в Друпале некорректная, то ли я чего-то не понимаю.
А поясните, пожалуйста по защите от CSRF.
Реализация в Drupal 8 такова, что в запрос к своему кастомному URL надо добавить token: специальный параметр или header в зависимости от метода проверки (_csrf_token или _csrf_request_header_token). Этот токен можно свободно получить получить по URL /session/token (GET).
Мне не очень понятно, от чего защищает такая защита.
1. С одной стороны, если некий скрипт имеет возможность обратиться к моему кастомному URL (POST), то что ему помешает предварительно сделать GET-запрос на /session/token?
2. С другой стороны есть обсуждение, почему небезопасно помещать этот token в drupalSettings:
https://drupal.stackexchange.com/questions/270792/is-it-a-security-issue-to-put-csrf-token-in-drupal-settings
НО при этом:
- токен форма в явном виде вписывается в HTML form > input и может быть прочитан любым скриптом прямо из DOM
- любой скрипт, который получает и передает токен, так или иначе хранит его в памяти, т. е. его можно извлечь
3. POST-запросы с другого домена в любом случае идут от имени анонимного пользователя (авторизационная cookie с сессией игнорируется). Т. е. мы говорим только о защите от скриптов, которые выполняются в контексте страницы сайта.
4. Токены не меняются со временем. По сути они просто привязаны к сессии и непонятно, зачем эта новая сущность, если и так есть session ID. Я проверил: и форма при перезагрузке не меняет свой CSRF token, и /session/token выдает всегда одно значение день ото дня.
Можете объяснить, от какого типа атак защищает такая защита вообще?
Хочется защититься от CSRF правильно, но то ли реализация в Друпале некорректная, то ли я чего-то не понимаю.
ИЛ
Dmitriy K.
Привет,
А поясните, пожалуйста по защите от CSRF.
Реализация в Drupal 8 такова, что в запрос к своему кастомному URL надо добавить token: специальный параметр или header в зависимости от метода проверки (_csrf_token или _csrf_request_header_token). Этот токен можно свободно получить получить по URL /session/token (GET).
Мне не очень понятно, от чего защищает такая защита.
1. С одной стороны, если некий скрипт имеет возможность обратиться к моему кастомному URL (POST), то что ему помешает предварительно сделать GET-запрос на /session/token?
2. С другой стороны есть обсуждение, почему небезопасно помещать этот token в drupalSettings:
https://drupal.stackexchange.com/questions/270792/is-it-a-security-issue-to-put-csrf-token-in-drupal-settings
НО при этом:
- токен форма в явном виде вписывается в HTML form > input и может быть прочитан любым скриптом прямо из DOM
- любой скрипт, который получает и передает токен, так или иначе хранит его в памяти, т. е. его можно извлечь
3. POST-запросы с другого домена в любом случае идут от имени анонимного пользователя (авторизационная cookie с сессией игнорируется). Т. е. мы говорим только о защите от скриптов, которые выполняются в контексте страницы сайта.
4. Токены не меняются со временем. По сути они просто привязаны к сессии и непонятно, зачем эта новая сущность, если и так есть session ID. Я проверил: и форма при перезагрузке не меняет свой CSRF token, и /session/token выдает всегда одно значение день ото дня.
Можете объяснить, от какого типа атак защищает такая защита вообще?
Хочется защититься от CSRF правильно, но то ли реализация в Друпале некорректная, то ли я чего-то не понимаю.
А поясните, пожалуйста по защите от CSRF.
Реализация в Drupal 8 такова, что в запрос к своему кастомному URL надо добавить token: специальный параметр или header в зависимости от метода проверки (_csrf_token или _csrf_request_header_token). Этот токен можно свободно получить получить по URL /session/token (GET).
Мне не очень понятно, от чего защищает такая защита.
1. С одной стороны, если некий скрипт имеет возможность обратиться к моему кастомному URL (POST), то что ему помешает предварительно сделать GET-запрос на /session/token?
2. С другой стороны есть обсуждение, почему небезопасно помещать этот token в drupalSettings:
https://drupal.stackexchange.com/questions/270792/is-it-a-security-issue-to-put-csrf-token-in-drupal-settings
НО при этом:
- токен форма в явном виде вписывается в HTML form > input и может быть прочитан любым скриптом прямо из DOM
- любой скрипт, который получает и передает токен, так или иначе хранит его в памяти, т. е. его можно извлечь
3. POST-запросы с другого домена в любом случае идут от имени анонимного пользователя (авторизационная cookie с сессией игнорируется). Т. е. мы говорим только о защите от скриптов, которые выполняются в контексте страницы сайта.
4. Токены не меняются со временем. По сути они просто привязаны к сессии и непонятно, зачем эта новая сущность, если и так есть session ID. Я проверил: и форма при перезагрузке не меняет свой CSRF token, и /session/token выдает всегда одно значение день ото дня.
Можете объяснить, от какого типа атак защищает такая защита вообще?
Хочется защититься от CSRF правильно, но то ли реализация в Друпале некорректная, то ли я чего-то не понимаю.
защита эта от того, что на левом сайте сделают форму удаления всего, заманят на него админа сайта и отправят её втихаря с админской кукой
DK
Ну, со сторонних сайтов вообще всё легко фильтруется по referrer/origin. Там никакой токен не нужен.
ИЛ
по безопасности хранения токена в открытом виде
если внедрять себе на сайт всякое постороннее говно, то оно конечно может токен подсмотреть и доставлять токен аяксом безопасней
но ещё безопасней не внедрять всякое говно
если внедрять себе на сайт всякое постороннее говно, то оно конечно может токен подсмотреть и доставлять токен аяксом безопасней
но ещё безопасней не внедрять всякое говно
DK
Хорошо. Я в D8 хочу встроить свой JS, который должен делать POST-запрос к D8. Безопасно ли ему передать как инициализационный параметр этот токен?
Т. е. сгенерить HTML код так:
mySctipt.run("token_here");
Это способ, который используют формы D8.
Т. е. сгенерить HTML код так:
mySctipt.run("token_here");
Это способ, который используют формы D8.
ИЛ
вполне