Lyft запускает соревнование по по распознаванию объектов в 3D

image

Один из важнейших игроков на рынке беспилотных автомобилей на днях запустил на платформе Kaggle первое соревнование по по распознаванию объектов с 3D м призовым фондом $25000. Срок соревнования 2 месяца. Официальная статистика уже говорит о 35 участниках и 45 сабмитах.

Целью соревнования является дать толчок к исследованию серьезной и непростой задачи для беспилотных автомобилей — по распознавание объектов в 3D. Обычно исследования в данной сфере проходят за закрытыми дверями в специализированных научных учреждениях. Организаторы соревнования стремятся понизить техническую планку для вхождения желающих в эту специфическую область и дать возможность более широкой аудитории принять участие в решении непростых задач и создании новых инноваций в сфере беспилотного транспорта.

Данное соревнование кажется интересным, поскольку дает возможность взглянуть на передовые решения одной из самых актуальных проблем на текущий момент воочию и попробовать свои силы в решении этой проблемы. Для проведения экспериментов организаторы предоставили доступ к крупномасштабному набору реальных сырых данных с датчиков, полученных многочисленной флотилией беспилотных автомобилей компании в ограниченной географической области. Данные включают данные лидара, карту, изображение с камеры. Нужно предсказать трехмерные ограничивающие «коробки» (bounding volumes) и классы всех объектов в сцене.

Принять участие в соревновании может любой желающий. Всем заинтересовавшимся в соревновании желаю удачи в участии и новых достижений!


ссылка на оригинал статьи https://habr.com/ru/post/467405/

Ты — Изгой

Привет, обращаюсь к тебе, к так называемому программисту.
Как дела твои? Чествуешь ли ты ответственность за происходящее вокруг? Когда общаешься с женой/девушкой/детьми/родными? Когда общаешься с продавщицей? Когда общаешься с кондуктором? Когда тебя проверяют в аэропорту? Когда ты пытаешься снять себе очередную квартиру? Когда машины с беспилотником сбивают людей?
Твоя надежда на понимание течения твоих мыслей — бессмысленна! Как бессмысленно разговаривать с китами на языке дельфинов! «С днем программиста» — подумаешь ты, выпив пива. И в правду забыв себе сказать: «Из твоего окружения тебя понимает лишь толика!»
Тебя не замечают в прошивке роутеров, тебя не замечают в компьютерах, в операционных системах, в холодильнике, в микроволновке, тебя не замечают в телефонах, ты — zero. Прими это.
Если ты стоя в общественном транспорте видишь человека, у которого не открылся сайт — ты виноват!
Если ты стоишь перед банкоматом, и человек не смог снять денег — ты виноват!
Если человек не смог заплатить налоги — ты виноват!
Если ты, придя в гости, слышишь «ооо, этож программист, давай ка подчини миксер!»
Если ты стоя в магазине пятый в очереди думаешь «Как так? Ну неужели не понятно, что вон та кнопка!» — ты виноват!
Если поезда\машины сходят с пути — ты виноват!
Если самолёты столкнулись — ты виноват!
Если утка не долетела до юга из-за сбоя навигационной системы, из-за wi-fi — ты виноват!

Скажу тебе правду, Zero — твой новый ник!


ссылка на оригинал статьи https://habr.com/ru/post/467411/

Habr Special #18 / Новые гаджеты Apple, полностью модульный смартфон, деревня программистов в Беларуси, феномен XY

В этом выпуске:


Во время разговора мы упоминали (или очень хотели) эти материалы:


Где еще можно послушать:

  1. Эппл-подкасты
  2. Спотифай
  3. Саундклауд
  4. Яндекс-музыка
  5. ВК
  6. Ютуб
  7. Оверкаст
  8. Покеткаст
  9. Кастбокс
  10. Гугл-подкасты
  11. РСС


Участники

  • Иван Звягин, baragol
  • Адель Мубаракшин, exr
  • Николай Землянский, klauss_z
  • Далер Алиёров, daleraliyorov

Звукорежиссер
Сергей Дмитриев

Продюсер
Лев Пикалёв


Подкаст сделан при помощи «Подкастерской».


Прошлые выпуски


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



ссылка на оригинал статьи https://habr.com/ru/company/habr/blog/467395/

Приносить нельзя запретить: как реализовать концепцию BYOD и не нанести ущерба информационной безопасности

image

С каждым годом всё больше компаний в том или ином виде внедряют у себя концепцию BYOD. По данным исследования Global Market Insights к 2022 году объём рынок BYOD превысит 366 млрд долларов, а Cisco сообщает, что 95% организаций в том или ином виде допускает использование личных устройств на рабочих местах, причём такой подход позволяет экономить 350 долларов в год в расчёте на сотрудника. Одновременно BYOD создаёт множество сложностей для ИТ-службы и массу разнообразных рисков для компании.

Возможность выполнять рабочие задачи с помощью собственных гаджетов многие воспринимают как элемент свободы, прогрессивного подхода к взаимоотношениям компания-сотрудник и вообще типичный пример стратегии win-win. В целом нет никаких причин сомневаться: сотрудник с удовольствием использует для решения задач оборудование, которое выбрал сам, а компания получает сотрудника, который всегда на связи и выполняет работу даже в нерабочее время. По данным Frost & Sullivan, BYOD добавляет к рабочему времени сотрудников до 58 минут в день и увеличивает продуктивность на 34%.
Несмотря на все преимущества BYOD порождает проблемы — проблемы несовместимости и своевременной установки обновлений безопасности, кражи и поломки личных устройств. И это лишь небольшая часть головной боли, которую приходится терпеть во имя удобства. О том, как решить эти проблемы, сохранив баланс между безопасностью и эффективностью, поговорим в этом посте.

BYOD
Расшифровывается как Bring Your Own Device, или «принеси своё устройство». В 2004 году VoIP-провайдер BroadVoice предложил подключать к своей сети оборудование клиентов и обозначил такой способ как BYOD. В 2009 Intel «обновила» понятие BYOD, несколько расширив его значение. С лёгкой руки Intel термин стал означать использование сотрудниками компаний личных устройств для решения бизнес-задач.
Поскольку строгого определения BYOD нет, в разных организациях эту концепцию могут понимать по-разному. Например, некоторые компании разрешают сотрудникам использовать личные устройства для решения рабочих вопросов, но все расходы на связь и ремонт сотрудник несёт сам. Другие компании компенсируют эти затраты, либо подключают работников к корпоративному договору.
Поскольку в случае BYOD компания не выбирает устройства, которые используют сотрудники, в полный рост встаёт проблема совместимости. Устранить её, заодно решив вопросы финансово-правового характера, позволяет CYOD — ещё одна подобная BYOD концепция.

CYOD
Аббревиатура CYOD расшифровывается как Choose Your Own Device — «выбери своё устройство». В рамках этой концепции сотрудник может выбрать из перечня типовых устройств то, которое наилучшим образом позволит ему решать его задачи. В зависимости от корпоративной политики CYOD может разрешать или запрещать использование корпоративных устройств для личных целей.

COPE
Этот термин расшифровывается как Corporate-Owned, Personally Enabled и означает, что выбранные сотрудником устройства приобретаются компанией, но их настройкой и обслуживанием он занимается сам. Как правило, COPE предполагает и возможность использования устройства в личных целях.

РОСE
POCE — Personally owned, company enabled, «куплено сотрудником, разрешено в компании». По сути, это просто ещё одно название для BYOD.

Преимущества BYOD


Для сотрудников
• одно устройство для личных и рабочих задач (если это не противоречит корпоративной политике),
• возможность использования самых новых моделей устройств,
• мобильность,
• гибкий график,
• дистанционная работа.

Для компании
• снижение расходов — компании не приходится приобретать устройства для работы сотрудников,
• повышение уровня мотивации сотрудников,
• доступность сотрудников в нерабочее время,
• более высокая оперативность решения срочных вопросов,
• снижение потребности в офисных помещениях.

Риски и угрозы BYOD


Риски, связанные с BYOD — закономерное следствие преимуществ концепции. Чем больше свободы получают сотрудники, использующие личные устройства для взаимодействия с сетью компании, тем больший потенциальный ущерб они могут нанести.

Потеря или кража устройства
Если сотрудник потеряет ноутбук, на котором выполнял работу для компании, это создаст массу проблем. С течением времени на устройстве неизбежно скапливаются корпоративные документы, в том числе конфиденциальные, а также документы, содержащие персональные данные. Утечка такой информации с большой вероятностью может привести к штрафам, конкуренты или злоумышленники могут воспользоваться ими для шантажа или просто продать на чёрном рынке киберпреступникам, которые занимаются организацией целевых или фишинговых атак.
А ведь помимо документов на устройстве сохраняются учётные данные для доступа в корпоративную сеть и/или ключи шифрования, записанные в реестр, чтобы не возиться с токенами. Используя эти сведения, злоумышленник может проникнуть в сеть, похитить всё, до чего сможет дотянуться, установить вредоносное ПО.
Ещё одна проблема состоит в том, что лишённый своего рабочего инструмента сотрудник не может делать то, за что ему платят. И этот вопрос требуется решить как можно быстрее. Если крупная корпорация, скорее всего, сможет подобрать оборудование из резерва, в стартапе на такую роскошь рассчитывать не приходится.

Уязвимости и вредоносное ПО
Очевидно, что сотрудники, работающие по схеме BYOD, будут использовать свои устройства для решения не только рабочих, но и личных задач. Завершив работу, они будут смотреть онлайн-видео, искать рефераты для детей и играть в игры, скачанные с торрент-трекеров. И с ненулевой вероятностью то же будут делать их дети.
Результат такого легкомыслия, как правило, не слишком вдохновляет: на устройстве появляются вредоносные программы — шпионы, шифровальщики и бэкдоры. При подключении к корпоративной сети весь набор малвари будет искать себе новые жертвы. И не исключено, что найдёт. Но и без этого похищенные логины, пароли и реквизиты корпоративных банковских карт не принесут пользы.
Даже если сотрудник ведёт себя ответственно, не посещает подозрительные сайты и не скачивает пиратский софт, остаётся проблема фишинговых писем, а также поддержание ОС и программ в актуальном состоянии. Используя известные уязвимости, вредоносы могут проникнуть на устройство самостоятельно либо с минимальным участием пользователя, щёлкнувшего по ссылке в письме, очень похожем на обычное письмо контрагента.

Мобильность как проблема
Разъездной характер использования оборудования в рамках BYOD означает не только повышенный риск лишиться любимого гаджета, но и риски, связанные с конфиденциальностью. Любители работать в кофейнях и других публичных местах не принимают во внимание тот факт, что
• они находятся в поле зрения посторонних людей и камер видеонаблюдения, а это значит, что пароли, которые они вводят, и документы, с которыми работают, оказываются достоянием посторонних;
• использование общедоступных сетей Wi-Fi в аэропортах и отелях несёт риск того, что передаваемая информация будет перехвачена, либо на устройство проникнет вредоносный скрипт;
• активное использование мобильного интернета в роуминге может привести к финансовым потерям.

Как защититься?


Риски, которые создаёт BYOD, невозможно полностью исключить. Но сочетая организационные и технические мероприятия, можно минимизировать или даже полностью исключить ущерб. В качестве основных способов обеспечения безопасности BYOD выделяют виртуализацию, управление мобильными устройствами, приложениями и данными, а также интеллектуальные системы защиты конечных точек.

Виртуализация
Прелесть этой технологии в том, устройство пользователя задействуется исключительно для получения доступа к виртуальному рабочему месту. Все документы и программы также располагаются там же и не копируются на устройство. Обслуживанием виртуальных рабочих мест занимаются ИТ-специалисты компании, поэтому всё, что требуется от сотрудника — держать в секрете реквизиты для доступа к корпоративной сети. Это не поможет, если на устройство проникнет шпионская программа, но исключит утечку данных при краже.

MDM, MCM, MAM и другие системы управления мобильными устройствами
Системы управления мобильными устройствами позволяют централизованно управлять всем BYOD-зоопарком, задавая ограничения на документы, на ресурсы, к которым пользователь имеет доступ и на операции, которые он может выполнять при подключении к корпоративной сети.
Например, инструмент Microsoft Intune поддерживает устройства на базе Windows, macOS, iOS, Android и позволяет администраторам:
• автоматически удалить корпоративные данные, если устройство не подключается к службе в течение заданного времени;
• установить запрет на сохранение корпоративной информации в любые расположения, кроме «OneDrive для бизнеса»;
• запросить ПИН-код или отпечаток пальца для доступа к приложениям Office;
• запретить копирование корпоративных данных из Office в личные приложения.
Подобные решения для управления мобильными устройствами предлагают Apple (Apple MDM), Citrix — XenMobile, Cisco — Meraki, Trend Micro — Enterprise Mobile Security и ряд независимых производителей.

Защита BYOD
Даже самое продвинутое управление не поможет, если на устройство проникнет малварь, поэтому в случае с BYOD в качестве обязательного компонента стоит использовать защитные решения класса XDR (X Detection and Response, где X соответствует разнообразным корпоративным средам). Такие системы способны обнаружить и помочь остановить неизвестные угрозы, обеспечивая мониторинг всех информационных систем на предприятии. Подход к XDR Trend Micro включает в себя подсистему EDR (Trend Micro Apex One), которая формирует многоуровневую защиту конечных устройств, а также сетевые продукты семейства Deep Discovery, позволяющие выявлять угрозы на узлах без агентов безопасности.

Что в итоге


Неконтролируемое применение BYOD может создать компаниям огромные проблемы. Чтобы в полной мере почувствовать все преимущества использования личных устройств для решения задач бизнеса, необходимо учитывать риски и защищать сетевой периметр и устройства пользователей. Дополнительный уровень защиты обеспечит разработка и внедрение в повседневную практику политики безопасности, на которую могут ориентироваться пользователи в процессе работы.


ссылка на оригинал статьи https://habr.com/ru/company/trendmicro/blog/467399/

Три типовых ошибки в сфере безопасности, о которых должен знать каждый React-разработчик

Автор статьи, перевод которой мы сегодня публикуем, говорит, что React — это её любимая библиотека для создания интерактивных интерфейсов. React одновременно и лёгок в использовании, и достаточно хорошо защищён. Однако это не значит, что React-приложения совершенно неуязвимы. Очень легко впасть в неоправданное спокойствие, решив, что о XSS-атаках можно не волноваться из-за того, что в проекте используется React.

Уязвимости React чаще всего проявляются тогда, когда разработчик думает, что он использует защитные механизмы этой библиотеки, хотя на самом деле оказывается, что это не так. Поэтому важно правильно оценивать возможности React, и знать о том, какие задачи программисту нужно решать своими силами.

Сегодня мы поговорим о типичных уязвимостях React, о том, как находить их во время код-ревью, и о том, как от них защищаться.

Первый (очень короткий) пример, касающийся межсайтового скриптинга

Межсайтовый скриптинг (Cross site scripting, XSS) — это клиентская уязвимость, которая способна привести к серьёзным проблемам. XSS-атаки происходят тогда, когда злоумышленник способен обмануть веб-сайт и заставить его выполнять произвольный JavaScript-код в браузерах его пользователей.

Отражённая (reflected) XSS-атака выполняется посредством ссылки, содержащей текстовую информацию, которая обрабатывается браузером в виде кода. Например — это поле формы, в которое, на стороне клиента, введён особый текст запроса.

Хранимая (stored) XSS-атака — это ситуация, в которой атакующий имеет доступ к серверу, и когда код, выполняемый на сервере, формирует то, что попадает на веб-страницу клиента. Типичными векторами подобных атак является загрузка на серверы комментариев и изображений.

Червь Samy эксплуатировал XSS-уязвимость MySpace. Это был один из самых быстрораспространяющихся вирусов всех времён.

Уязвимые веб-сайты могут подвергнуть своих пользователей риску кражи паролей или персональных данных. И это — обычный способ эксплуатации других уязвимостей. Вредоносные скрипты чаще всего используются для рассылки спама и для перенаправления пользователей на мошеннические сайты. Подобное может повредить репутации и SEO-показателям успешно атакованного сайта.

Уязвимость №1: контроль над исходным состоянием страницы, которое используется в ходе серверного рендеринга

Иногда, когда мы формируем исходное состояние страницы, мы, что опасно, создаём документ на основе JSON-строки. Эта уязвимость выглядит в коде примерно так:

<script>window.__STATE__ = ${JSON.stringify({ data })}</script>

Это опасно из-за того, что метод JSON.stringify(), ни о чём не «думая», преобразует любые предоставленные ему данные в строковую форму (до тех пор, пока это — валидные JSON-данные), представляющую собой то, что будет выведено на странице. Если у { data } есть поля, которые может редактировать недоверенный пользователь, вроде имени пользователя или сведений о пользователе, в подобные поля можно внедрить нечто, подобное следующему:

{ username: "pwned", bio: "</script><script>alert('XSS Vulnerability!')</script>" }

Этот паттерн часто применяется при серверном рендеринге React-приложений, в которых используется Redux. Он присутствовал в официальной документации Redux, в результате много учебных руководств и шаблонов приложений-примеров, которые можно найти на GitHub, всё ещё его используют.

Не верите? Тогда убедитесь в этом сами. Поищите в Google по тексту «react server side rendering example app» и попробуйте выполнить эту атаку на любом из результатов поиска с первой страницы.

▍Выявление уязвимости во время код-ревью

Ищите вызовы метода JSON.stringify(), принимающие переменные, которые могут содержать недоверенные данные в теге script. Вот пример, который раньше был в документации Redux:

function renderFullPage(html, preloadedState) {     return `         <!doctype html>         <html>             <head>                 <title>Redux Universal Example</title>             </head>             <body>                 <div id="root">${html}</div>                 <script>                     window.__PRELOADED_STATE__ = ${JSON.stringify(preloadedState)}                 </script>                 <script src="/static/bundle.js"></script>             </body>         </html>         ` }

А вот — кусок кода из приложения-примера, который нашёлся на GitHub:

function htmlTemplate( reactDom, reduxState, helmetData ) {     return `     <!DOCTYPE html>     <html>     <head>         <meta charset="utf-8">         ${ helmetData.title.toString( ) }         ${ helmetData.meta.toString( ) }         <title>React SSR</title>         <link rel="stylesheet" type="text/css" href="./styles.css" />     </head>          <body>         <div id="app">${ reactDom }</div>         <script>             window.REDUX_DATA = ${ JSON.stringify( reduxState ) }         </script>         <script src="./app.bundle.js"></script>     </body>     </html>     `;      }

Иногда обнаружить эту уязвимость немного сложнее. Следующий код тоже окажется небезопасным — в том случае, если не выполнено правильное экранирование context.data:

const RenderedApp = htmlData.replace('{{SSR}}', markup)     .replace('<meta-head/>', headMarkup)     .replace('{{data}}', new ArrayBuffer(JSON.stringify(context.data)).toString('base64'))

При выполнении серверного рендеринга обращайте внимание на то, что именно рендерится. Если то, что вводит пользователь, не экранировано соответствующим образом и выводится в DOM — это может быть опасным.

▍Защита

один из вариантов защиты от этой уязвимости заключается в использовании npm-модуля serialize-javascript, который предназначен для экранирования выводимого JSON. Если вы выполняете серверный рендеринг не в среде Node.js — то вам понадобится самостоятельно подобрать соответствующий пакет для используемого вами языка.

Вот команда для установки модуля:

$ npm install --save serialize-javascript

После этого его надо импортировать в файл и следующим образом переписать ранее уязвимый код, имеющий дело с window:

<script>window.__STATE__ = ${ serialize( data, { isJSON: true } ) }</script>

Вот отличная статья, посвящённая этому вопросу.

Уязвимость №2: коварные ссылки

Тег <a> может иметь атрибут href, который содержит ссылку на другую страницу сайта, на другой сайт, на некое место текущей страницы. Ссылки могут содержать и скрипты, которые выглядят примерно так: javascript: stuff(). Если вы не знали об этой возможности HTML — опробуйте её прямо сейчас, скопировав в строку браузера следующий код:

data:text/html, <a href="javascript: alert('hello from javascript!')" >click me</a>

Для веб-разработчиков это означает, что если содержимое ссылок устанавливается на основе данных, введённых пользователем — атакующий может добавить в эти данные вредоносный код, начинающийся с javascript:. Затем, если пользователь щёлкнет по нехорошей ссылке, в браузере будет запущен скрипт злоумышленника.

Эта уязвимость, определённо, характерна не только для React, но это одна из тех проблем, с которой часто сталкиваются React-разработчики, когда ожидают, что соответствующее значение должно быть автоматически правильно экранировано. Надо отметить, что в будущей версии React эта проблема будет стоять уже менее остро.

▍Выявление уязвимости во время код-ревью

Могут ли пользователи проекта добавлять на страницы ссылки, по которым могут щёлкать другие пользователи? Если это так — попробуйте добавить на страницу «ссылку» наподобие следующей:

javascript: alert("You are vulnerable to XSS!")

Если при щелчке по ссылке будет показано соответствующее окно сообщения — это значит, что проект уязвим к XSS-атакам. Попробуйте это везде, где можно добавлять ссылки. Вполне вероятно, что уязвимости окажутся подвержены не все подобные места.

▍Защита

Защита от этой уязвимости подходит не только для React-проектов. То, что именно нужно сделать, зависит от приложения. Кроме того, возможно, исправления нужно будет вносить на сервере.

Можно подумать, что для решения проблемы достаточно удалить из данных префикс javascript:. Это — пример использования стратегии «чёрного списка», которую нельзя признать удачной в деле очистки данных. У хакеров есть хитроумные способы обхода подобных фильтров, поэтому вместо подобного хода (или в дополнение к нему) сделайте так, чтобы ссылки использовали бы протокол, контролируемый по принципу «белого списка» (например — http:) и экранируйте HTML-сущности. Вот подробная статья на эту тему, касающаяся экранирования свойств, которые может контролировать злоумышленник.

Ещё одной стратегией, которая способна добавить в проект дополнительный уровень защиты, является использования механизма открытия пользовательских ссылок в новых вкладках браузера. Я, однако, не рекомендовала бы использовать эту стратегию как единственную «линию обороны» проекта. Открытие javascript:-ссылки в новой вкладке — это пример нестандартного поведения элементов страницы. Большинство браузеров без вреда для пользователя выполнят скрипт в пустой вкладке, но это не гарантировано, и, вероятно, это можно обойти, что зависит от браузера.

Рассмотрите возможность использования специального компонента UserLink, что приведёт к тому, что уязвимый тег <a> с меньшей долей вероятности попадёт на страницы вашего проекта в будущем. Кроме того, стоит добавить в проект несколько тестов и правил линтинга, нацеленных на выявление потенциально опасного кода и на то, чтобы не допустить его попадания в продакшн.

Ссылки — это не единственные сущности, которые могут быть использованы подобным образом. Но они — наиболее вероятная цель атаки в React-приложениях. Любой элемент может быть уязвимым к данной атаке в том случае, если злоумышленник может управлять его значением URI. Ещё одной возможностью проведения этой атаки, например, является конструкция вида . Полный список атрибутов, которые могут содержать URI, можно найти в этом списке по ключевому слову %URI, воспользовавшись браузерным поиском (Ctrl+F).

Уязвимость №3: непонимание смысла конструкции dangerouslySetInnerHtml

Я чрезвычайно благодарна React за то, что предупреждение о безопасности находится прямо в имени метода. Это — имя dangerouslySetInnerHTML. Мы, несмотря на это предупреждение, всё ещё часто сталкиваемся с тем, что разработчики рискуют, выполняя небезопасные операции. То же самое можно сказать и об eval().

Рассмотрим следующий пример, который я обнаружила на сайте с первой страницы поисковой выдачи Google:

<script dangerouslySetInnerHTML={{ __html: `window.__PRELOADED_STATE__ = ${JSON.stringify(initialState)};`}}></script>

Это — пример уязвимости №1, но с одной особенностью, которая должна сразу привлечь внимание к тому, что тут что-то не так. Там, где я это нашла, сделана попытка объясниться: «Мы используем dangerouslySetInnerHTML в качестве метода очистки данных и предотвращения XSS-атак». Ну уж нет! Это неправильно. Не делайте так. Для того чтобы узнать подробности о dangerouslySetInnerHTML — почитайте документацию React.

Ещё один пример того, что подобное, на самом деле, происходит постоянно — то, как члены одной команды обнаружили, что у них имеется уязвимость, когда добавляли на страницу Markdown-разметку, используя dangerouslySetInnerHTML. Для того чтобы обезопасить себя от этого в будущем — они стали пользоваться специальным правилом линтинга.

▍Выявление уязвимости во время код-ревью

Прежде чем отправлять pull-запросы или выполнять операции слияния — полезно выполнить поиск в коде по строкам dangerouslySetInnerHTML и eval (я, кроме того, ищу так команды console.log) или воспользоваться соответствующим правилом линтера.

▍Защита

Проверьте, чтобы во всех случаях использования метода dangerouslySetInnerHTML выполнялась бы загрузка на страницу исключительно данных, которым вы можете доверять. Как узнать о том, что данным можно доверять? Если нечто пришло не от вас — это нечто может нести в себе угрозу. Сюда входят и данные, загруженные из внешних API, и то, что оформляется средствами Markdown.

Замечание о спуфинге компонентов

В 2015 году некто выяснил, что можно спуфить компоненты, передавая JSON тем компонентам, которые ожидают текст. Я смогла найти лишь один случай сообщения о спуфинге компонентов и длинное обсуждение, вызванное этим сообщением. В обсуждении речь шла о том, какова мера ответственности React в деле предотвращения XSS-атак. В итоге разработчики React выпустили исправление, которое, как кажется, способствовало устранению этой уязвимости.

Я решила не включать рассказ об этой уязвимости в статью, но эта тема может представлять интерес для дальнейших исследований.

Замечание о SSR

Уязвимость, касающаяся серверного рендеринга, столь широко распространена из-за того, что она присутствовала в документации Redux и в результате разошлась по множеству других материалов. Эту проблему исправили в 2016 году. Но и сегодня, через три года, в руководствах для новичков, разбросанных по всему интернету, всё ещё учат тому, чему учить не стоило бы.

Кстати, вот вам домашнее задание: найдите пример этой проблемы на GitHub и отправьте pull-запрос на её исправление. Вот пример.

Вместе мы сможем раз и навсегда избавиться от этой уязвимости!

Уважаемые читатели! Сталкивались ли вы с атаками на ваши React-проекты?


ссылка на оригинал статьи https://habr.com/ru/company/ruvds/blog/467255/