8 вещей, которые специалисты InfoSec должны знать о сети
Знания о сети нужны не только сисадминам. Давайте оживим в памяти необходимые понятия, которые должны знать специалисты InfoSec.
https://proglib.io/p/for-infosec/
#web #security
Знания о сети нужны не только сисадминам. Давайте оживим в памяти необходимые понятия, которые должны знать специалисты InfoSec.
https://proglib.io/p/for-infosec/
#web #security
Библиотека программиста
8 вещей, которые специалисты InfoSec должны знать о сети
Знания о сети нужны не только сисадминам. Давайте оживим в памяти необходимые понятия, которые должны знать специалисты InfoSec.
30 ресурсов по безопасности, которые точно пригодятся
По мере развития индустрии специалисты по безопасности черпают все новую и новую информацию. Но как понять, что знаний достаточно?
https://proglib.io/p/information-security-guide/
#security
По мере развития индустрии специалисты по безопасности черпают все новую и новую информацию. Но как понять, что знаний достаточно?
https://proglib.io/p/information-security-guide/
#security
Библиотека программиста
30 ресурсов по безопасности, которые точно пригодятся
По мере развития индустрии специалисты по безопасности черпают все новую и новую информацию. Но как понять, что знаний достаточно?
13 лучших инструментов по анализу данных для хакера
https://proglib.io/p/hack-materials/
#digest #security
https://proglib.io/p/hack-materials/
#digest #security
Библиотека программиста
13 лучших инструментов по анализу данных для хакера
Редакция Библиотеки программиста подготовила информационно-обучающий обзор инструментов для анализа данных и улучшения скилов хакера.
Криптография и главные способы шифрования информации
https://proglib.io/p/methods-of-encryption/
#security
https://proglib.io/p/methods-of-encryption/
#security
Библиотека программиста
Криптография и главные способы шифрования информации
В XXI веке криптография играет серьезную роль в цифровой жизни современных людей. Кратко рассмотрим способы шифрования информации.
Работа с протоколом Ethernet
1. Введение
2. Общие сведения о сетях
3. Стандарты Ethernet (часть I)
4. Стандарты Ethernet (часть II)
5. Коммутация
6. VLAN
7. Безопасность (часть I)
8. Безопасность (часть II)
Ссылка на плейлист: https://www.youtube.com/watch?v=i1GGtXce-QQ&list=PLVxaI3iD653AIrsowxY6AXXm2lqgFSBCX
#security
1. Введение
2. Общие сведения о сетях
3. Стандарты Ethernet (часть I)
4. Стандарты Ethernet (часть II)
5. Коммутация
6. VLAN
7. Безопасность (часть I)
8. Безопасность (часть II)
Ссылка на плейлист: https://www.youtube.com/watch?v=i1GGtXce-QQ&list=PLVxaI3iD653AIrsowxY6AXXm2lqgFSBCX
#security
YouTube
Работа с протоколом Ethernet: Введение
Вводное видео про серию вебинаров, в которых обсуждается протокол Ethernet.
Информация технического характера начинается в следующем видео, так что если хочется перейти сразу к делу, эту серию можно смело пропустить.
Открыта запись на курсы, в которых рассказывается…
Информация технического характера начинается в следующем видео, так что если хочется перейти сразу к делу, эту серию можно смело пропустить.
Открыта запись на курсы, в которых рассказывается…
Кража паролей: как наши учетные записи уводят через npm-пакет
https://proglib.io/p/steal-password/
#common #security
https://proglib.io/p/steal-password/
#common #security
#security
Пройдите этот короткий тест из 8 вопросов, чтобы понять, смогли бы вы отличить спам от обычного сообщения. К каждому ответу имеется равёрнутое объяснение.
https://phishingquiz.withgoogle.com
Пройдите этот короткий тест из 8 вопросов, чтобы понять, смогли бы вы отличить спам от обычного сообщения. К каждому ответу имеется равёрнутое объяснение.
https://phishingquiz.withgoogle.com
#security #practice
XSS-атака
Этим постом мы открываем подборку полезных материалов о безопасности веб-приложений. И начнем с одной из самых популярных атак на веб-приложения — межсайтовое выполнение сценариев или межсайтовый скриптинг (XSS, англ. Cross-Site Scripting). Вы спросите, почему XSS, если Cross-Site Scripting? Такая аббревиатура была выбрана во избежание путаницы с Cascading Style Sheets.
Итак, почему XSS правильнее называть атакой, а не уязвимостью? Дело в том, что XSS является лишь одним из возможных способов эксплуатации уязвимости определенного класса, а устранение уязвимости позволяет избавиться и от всех эксплуатирующих ее атак, а вот устранение конкретной атаки — от уязвимости не избавляет. Подробнее можно ознакомиться с довольно качественной статьей на хабре. Не обращайте внимание на год, ведь тема не теряет свою актуальность.
Так что это за зверь такой, XSS-атака? XSS позволяет злоумышленнику внедрить вредоносный код на страницу веб-приложения (например, веб-сайта) и отправить его обратно в браузер пользователя, где этот код будет выполнен. Причиной этому являются доверительные отношения разработчика приложения к входным данным или некорректная фильтрация входных данных. Разновидности XSS-атак: постоянная (хранимая) XSS, при которой вредоносный код хранится на стороне сервера (например, в базе данных) и отдается каждому пользователю, посещающему зараженную страницу; непостоянная (отраженная) XSS, при которой пользователю необходимо посетить специально сформированную ссылку; XSS в DOM-модели, которая возникает на стороне клиента во время обработки данных внутри JavaScript сценария.
Вишенкой на торте является возможность попрактиковаться на тестовых лабораториях от компании PortSwigger, разработчика ПО для тестирования на проникновение под названием «Burp Suite». Необходимо проникнуться данной темой, чтобы не допускать подобных проблем безопасности в своих приложениях. А если среди подписчиков есть хакеры с белыми шляпами, то им особенно интересен будет данный ресурс. Все кликабельные ссылки на странице ниже представляют из себя тестовую лабораторию.👇
https://proglib.io/w/8831f5f0
XSS-атака
Этим постом мы открываем подборку полезных материалов о безопасности веб-приложений. И начнем с одной из самых популярных атак на веб-приложения — межсайтовое выполнение сценариев или межсайтовый скриптинг (XSS, англ. Cross-Site Scripting). Вы спросите, почему XSS, если Cross-Site Scripting? Такая аббревиатура была выбрана во избежание путаницы с Cascading Style Sheets.
Итак, почему XSS правильнее называть атакой, а не уязвимостью? Дело в том, что XSS является лишь одним из возможных способов эксплуатации уязвимости определенного класса, а устранение уязвимости позволяет избавиться и от всех эксплуатирующих ее атак, а вот устранение конкретной атаки — от уязвимости не избавляет. Подробнее можно ознакомиться с довольно качественной статьей на хабре. Не обращайте внимание на год, ведь тема не теряет свою актуальность.
Так что это за зверь такой, XSS-атака? XSS позволяет злоумышленнику внедрить вредоносный код на страницу веб-приложения (например, веб-сайта) и отправить его обратно в браузер пользователя, где этот код будет выполнен. Причиной этому являются доверительные отношения разработчика приложения к входным данным или некорректная фильтрация входных данных. Разновидности XSS-атак: постоянная (хранимая) XSS, при которой вредоносный код хранится на стороне сервера (например, в базе данных) и отдается каждому пользователю, посещающему зараженную страницу; непостоянная (отраженная) XSS, при которой пользователю необходимо посетить специально сформированную ссылку; XSS в DOM-модели, которая возникает на стороне клиента во время обработки данных внутри JavaScript сценария.
Вишенкой на торте является возможность попрактиковаться на тестовых лабораториях от компании PortSwigger, разработчика ПО для тестирования на проникновение под названием «Burp Suite». Необходимо проникнуться данной темой, чтобы не допускать подобных проблем безопасности в своих приложениях. А если среди подписчиков есть хакеры с белыми шляпами, то им особенно интересен будет данный ресурс. Все кликабельные ссылки на странице ниже представляют из себя тестовую лабораторию.👇
https://proglib.io/w/8831f5f0
#security #practice
SQL-инъекция
В одном из постов ранее мы рассматривали одну из популярных атак на пользователя под названием XSS-атака. Сегодня давайте рассмотрим уязвимость «внедрение операторов SQL» или SQL-инъекцию, возникающую как следствие недостаточной проверки принятых от пользователя значений, что позволяет модифицировать запросы к базам данных (БД). Несмотря на то, что на сайте была рассмотрена эта тема, стоит остановиться поподробнее на ней.
Итак, вы знаете, что для работы с БД был разработан специальный язык SQL-запросов. В качестве примера, рассмотрим приложение, которое обращается к базе данных со следующим запросом: SELECT name FROM members WHERE name = 'user' AND password ='123456'.
Запрос означает следующее: выбрать (SELECT) поле name из (FROM) таблицы members где (WHERE) значение поля name равно user (name = 'user') и (AND) значение поля password равно 123456 (password ='123456'). Этот запрос вызывает обход таблицы, в результате которого делается сравнение с каждой строкой, и если наше условие является для какой-либо строки истиной, то она попадает в результаты.
При этом значения «user» и «123456» приложение получает от пользователя — например, в рамках страницы входа на сайт. Предположим, что вместо user пользователь ввёл такую строку: user' --.
Тогда запрос к базе данных будет иметь вид: SELECT name FROM members WHERE name = 'user' -- ' AND password ='123456'.
Две чёрточки (--) означают комментарий до конца строки, т.е. всё, что за ними, больше не учитывается. Следовательно, из выражения условия «исчезает» часть ' AND password ='123456'. Поскольку в комментарии осталась закрывающая кавычка, то она также была введена с именем пользователя, чтобы не сломать синтаксис и не вызвать ошибку, в результате, фактически, к базе данных делался следующий запрос: SELECT name FROM members WHERE name = 'user'.
В нём была нарушена логика работы программы, заложенная разработчиками. Т.е. теперь поиск в таблице производится только по имени. И если имя совпало, то строка попадает в результаты независимо от введённого пароля. Данным примером мы хотели показать вам простоту эксплуатации SQL-инъекции. Более серьезные варианты эксплуатации вы можете посмотреть в лабораториях по ссылке ниже. В реальной ситуации, такая ошибка может быть использована на веб-сайте для входа под учётной записью администратора, для которой достаточно знать только имя, а пароль становится ненужным. Кроме обхода аутентификации, SQL-инъекция используется для извлечения информации из баз данных, вызова отказа в обслуживании (DoS), эксплуатации других уязвимостей и многого другого.
Стоит отметить, что в настоящее время подобные уязвимости встречаются довольного редко в связи с появлением различного рода фреймворков и библиотек, которые предусматривают защиту от SQL-инъекций. В рамках нашего поста был рассмотрен пример SQL-инъекции в реляционной СУБД MySQL (существуют также Oracle, Microsoft SQL Server, PostgreSQL, MariaDB). А возможны ли NoSQL-инъекции? Да! Redis, MongoDB, memcached — все эти программные продукты относятся к классу нереляционных СУБД. Интерес к перечисленным базам данных в последнее время значительно возрос и ходит миф, что нереляционные СУБД безопасны, так как они не используют SQL и злоумышленник не может провести на них атаки типа SQL-инъекция. Если в систему невозможно внедрить SQL-код, это еще не значит, что она безопасна. NoSQL закрывает одну потенциальную уязвимость, при этом открывая с десяток других, которые позволяют совершать разнообразные вредоносные действия.
Попрактиковаться в эксплуатации SQL-инъекций можно здесь: https://proglib.io/w/6682ab1c
SQL-инъекция
В одном из постов ранее мы рассматривали одну из популярных атак на пользователя под названием XSS-атака. Сегодня давайте рассмотрим уязвимость «внедрение операторов SQL» или SQL-инъекцию, возникающую как следствие недостаточной проверки принятых от пользователя значений, что позволяет модифицировать запросы к базам данных (БД). Несмотря на то, что на сайте была рассмотрена эта тема, стоит остановиться поподробнее на ней.
Итак, вы знаете, что для работы с БД был разработан специальный язык SQL-запросов. В качестве примера, рассмотрим приложение, которое обращается к базе данных со следующим запросом: SELECT name FROM members WHERE name = 'user' AND password ='123456'.
Запрос означает следующее: выбрать (SELECT) поле name из (FROM) таблицы members где (WHERE) значение поля name равно user (name = 'user') и (AND) значение поля password равно 123456 (password ='123456'). Этот запрос вызывает обход таблицы, в результате которого делается сравнение с каждой строкой, и если наше условие является для какой-либо строки истиной, то она попадает в результаты.
При этом значения «user» и «123456» приложение получает от пользователя — например, в рамках страницы входа на сайт. Предположим, что вместо user пользователь ввёл такую строку: user' --.
Тогда запрос к базе данных будет иметь вид: SELECT name FROM members WHERE name = 'user' -- ' AND password ='123456'.
Две чёрточки (--) означают комментарий до конца строки, т.е. всё, что за ними, больше не учитывается. Следовательно, из выражения условия «исчезает» часть ' AND password ='123456'. Поскольку в комментарии осталась закрывающая кавычка, то она также была введена с именем пользователя, чтобы не сломать синтаксис и не вызвать ошибку, в результате, фактически, к базе данных делался следующий запрос: SELECT name FROM members WHERE name = 'user'.
В нём была нарушена логика работы программы, заложенная разработчиками. Т.е. теперь поиск в таблице производится только по имени. И если имя совпало, то строка попадает в результаты независимо от введённого пароля. Данным примером мы хотели показать вам простоту эксплуатации SQL-инъекции. Более серьезные варианты эксплуатации вы можете посмотреть в лабораториях по ссылке ниже. В реальной ситуации, такая ошибка может быть использована на веб-сайте для входа под учётной записью администратора, для которой достаточно знать только имя, а пароль становится ненужным. Кроме обхода аутентификации, SQL-инъекция используется для извлечения информации из баз данных, вызова отказа в обслуживании (DoS), эксплуатации других уязвимостей и многого другого.
Стоит отметить, что в настоящее время подобные уязвимости встречаются довольного редко в связи с появлением различного рода фреймворков и библиотек, которые предусматривают защиту от SQL-инъекций. В рамках нашего поста был рассмотрен пример SQL-инъекции в реляционной СУБД MySQL (существуют также Oracle, Microsoft SQL Server, PostgreSQL, MariaDB). А возможны ли NoSQL-инъекции? Да! Redis, MongoDB, memcached — все эти программные продукты относятся к классу нереляционных СУБД. Интерес к перечисленным базам данных в последнее время значительно возрос и ходит миф, что нереляционные СУБД безопасны, так как они не используют SQL и злоумышленник не может провести на них атаки типа SQL-инъекция. Если в систему невозможно внедрить SQL-код, это еще не значит, что она безопасна. NoSQL закрывает одну потенциальную уязвимость, при этом открывая с десяток других, которые позволяют совершать разнообразные вредоносные действия.
Попрактиковаться в эксплуатации SQL-инъекций можно здесь: https://proglib.io/w/6682ab1c
#security
Набор практических рекомендаций для комплексной защиты веб-приложений.
https://proglib.io/w/7e59f217
Набор практических рекомендаций для комплексной защиты веб-приложений.
https://proglib.io/w/7e59f217
DEV Community
Web Application Security Checklist (2021)
The original post can be read here. Overview It's scary out there for developers! One mis...
#security #pentest
Специалисты из Detectify проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных им удалось выяснить, какие ошибки в конфигурациях встречаются чаще всего. В результате получилась полезная статья, которая раскрывает следующие неправильные настройки Nginx:
- Отсутствие корневого каталога
- Небезопасное использование переменных
- Чтение необработанного ответа сервера
- merge_slashes отключены
Но история на этом не закончилась. Проект Gixy помог найти множество неправильных конфигураций промежуточного ПО. Ознакомиться можно здесь.
Специалисты из Detectify проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных им удалось выяснить, какие ошибки в конфигурациях встречаются чаще всего. В результате получилась полезная статья, которая раскрывает следующие неправильные настройки Nginx:
- Отсутствие корневого каталога
- Небезопасное использование переменных
- Чтение необработанного ответа сервера
- merge_slashes отключены
Но история на этом не закончилась. Проект Gixy помог найти множество неправильных конфигураций промежуточного ПО. Ознакомиться можно здесь.
Хабр
Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым
Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мише...
#security
Если вы когда-нибудь задумывались, как OAuth 2.0 работает «под капотом» — посмотрите это. Автор статьи рассматривает все потоки OAuth 2.0 с использованием простых и понятных файлов GIF, а также короткого текстового описания.
Если вы когда-нибудь задумывались, как OAuth 2.0 работает «под капотом» — посмотрите это. Автор статьи рассматривает все потоки OAuth 2.0 с использованием простых и понятных файлов GIF, а также короткого текстового описания.
DEV Community
🔑 OAuth 2.0 flows explained in GIFs
In this post, we will be covering all OAuth 2.0 flows using GIFs that are simple and easier to unders...
#security
Николай Мозговой (разработчик и ментор в Sigma Software) знакомит читателей с основными понятиями информационной безопасности для разработчиков.
https://proglib.io/w/12c121f4
Николай Мозговой (разработчик и ментор в Sigma Software) знакомит читателей с основными понятиями информационной безопасности для разработчиков.
https://proglib.io/w/12c121f4
ДОУ
Шпаргалка по кибербезопасности для разработчиков
Вопрос кибербезопасности должен быть предметом особого внимания не только для экспертов, но и для рядовых разработчиков. Однако не каждый проект может позволить себе отдельного специалиста по безопасности, поэтому весьма вероятно, что нести это бремя придется…
#security
Представьте, что в вашем приложении есть несколько протоколов и токенов, более 200 миллионов пользователей и тысячи типов устройств.
В таком случае работа с протоколами безопасности, токенами идентификации, а также с аутентификацией пользователей и устройств может стать сложной задачей, не так ли? В Netflix успешно с ней справились. Читайте статью, если интересны детали реализации.
https://proglib.io/w/14aa2790
Представьте, что в вашем приложении есть несколько протоколов и токенов, более 200 миллионов пользователей и тысячи типов устройств.
В таком случае работа с протоколами безопасности, токенами идентификации, а также с аутентификацией пользователей и устройств может стать сложной задачей, не так ли? В Netflix успешно с ней справились. Читайте статью, если интересны детали реализации.
https://proglib.io/w/14aa2790
#security
А вы / ваша команда обновляете сторонние библиотеки в проектах?
В исследовании Veracode State of Software Security (SoSS) v11: Open Source Edition было обнаружено, что в 79% случаев сторонние библиотеки никогда не обновляются разработчиками после включения в кодовую базу.
Этот отчет SoSS ориентирован на приложения и компоненты с открытым исходным кодом и основан на анализе 13 миллионов сканирований более 86,000 репозиториев, содержащих более 301,000 уникальных библиотек. В анализ также включены результаты опроса об использовании стороннего программного обеспечения от почти 2000 разработчиков.
Кроме того, разработчики поставили «Безопасность» только на третье место по важности при выборе библиотеки, что крайне печально.
Источник
А вы / ваша команда обновляете сторонние библиотеки в проектах?
В исследовании Veracode State of Software Security (SoSS) v11: Open Source Edition было обнаружено, что в 79% случаев сторонние библиотеки никогда не обновляются разработчиками после включения в кодовую базу.
Этот отчет SoSS ориентирован на приложения и компоненты с открытым исходным кодом и основан на анализе 13 миллионов сканирований более 86,000 репозиториев, содержащих более 301,000 уникальных библиотек. В анализ также включены результаты опроса об использовании стороннего программного обеспечения от почти 2000 разработчиков.
Кроме того, разработчики поставили «Безопасность» только на третье место по важности при выборе библиотеки, что крайне печально.
Источник
#practice #security
У платформы для изучения криптографии CryptoHack появился целый курс. Даже если у вас нет учетной записи, вы можете посетить все испытания и погрузиться в крипто-головоломки.
https://proglib.io/w/c7f8e937
У платформы для изучения криптографии CryptoHack появился целый курс. Даже если у вас нет учетной записи, вы можете посетить все испытания и погрузиться в крипто-головоломки.
https://proglib.io/w/c7f8e937
#security #guide
Справочник по разработке безопасных веб-приложений: лучшие практики, анализ и исправление уязвимостей.
https://proglib.io/w/3e42e3da
Справочник по разработке безопасных веб-приложений: лучшие практики, анализ и исправление уязвимостей.
https://proglib.io/w/3e42e3da
vladtoie.gitbook.io
Secure Coding Handbook | Secure Coding Handbook
#privacy #security
Таблица, в которой представлены результаты аудита конфиденциальности популярных веб-браузеров. Все значки кликабельные — можно получить конкретное подтверждение результатов. А вы каким браузером пользуетесь?
https://proglib.io/w/1c4a031a
Таблица, в которой представлены результаты аудита конфиденциальности популярных веб-браузеров. Все значки кликабельные — можно получить конкретное подтверждение результатов. А вы каким браузером пользуетесь?
https://proglib.io/w/1c4a031a
privacytests.org
Which browsers are best for privacy?
An open-source privacy audit of popular web browsers.
This media is not supported in your browser
VIEW IN TELEGRAM
#writeup #security
Новые инструменты — новые угрозы: команда OpenAI исправила критическую уязвимость захвата учетной записи ChatGPT
Можно было захватить чью-то учетную запись, просмотреть историю чатов и получить доступ к платежной информации.
Началось все с того, что на бэкенде некорректно обрабатывалось расширение, и вместо css возвращался конфиденциальный json-файл:
chat.openai[.]com/api/auth/session.css -> 400 ❌
chat.openai[.]com/api/auth/session/test.css -> 200 ✔️
Подробности — под катом.👇
🧵Читать в Твиттере
🧵Читать в Thread Reader App (если Твиттер не открывается)
Новые инструменты — новые угрозы: команда OpenAI исправила критическую уязвимость захвата учетной записи ChatGPT
Можно было захватить чью-то учетную запись, просмотреть историю чатов и получить доступ к платежной информации.
Началось все с того, что на бэкенде некорректно обрабатывалось расширение, и вместо css возвращался конфиденциальный json-файл:
chat.openai[.]com/api/auth/session.css -> 400 ❌
chat.openai[.]com/api/auth/session/test.css -> 200 ✔️
Подробности — под катом.👇
🧵Читать в Твиттере
🧵Читать в Thread Reader App (если Твиттер не открывается)