#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
#pentest #bugbounty #practice
Kontra OWASP Top 10 — это коллекция бесплатных интерактивных руководств о наиболее популярных уязвимостях и некоторых инцидентах безопасности.
Разработчики данных тренингов считают, что каждый инженер-программист должен иметь бесплатный доступ к обучению безопасной разработке. Kontra OWASP Top 10 — их первый шаг в этом направлении.
Вдохновленные реальными уязвимостями и тематическими исследованиями, они создали серию интерактивных учебных модулей по безопасности приложений, чтобы помочь разработчикам понять, выявить и уменьшить проблемы безопасности в своих приложениях.
Красиво, кликабельно, наглядно: https://proglib.io/w/26094237
Kontra OWASP Top 10 — это коллекция бесплатных интерактивных руководств о наиболее популярных уязвимостях и некоторых инцидентах безопасности.
Разработчики данных тренингов считают, что каждый инженер-программист должен иметь бесплатный доступ к обучению безопасной разработке. Kontra OWASP Top 10 — их первый шаг в этом направлении.
Вдохновленные реальными уязвимостями и тематическими исследованиями, они создали серию интерактивных учебных модулей по безопасности приложений, чтобы помочь разработчикам понять, выявить и уменьшить проблемы безопасности в своих приложениях.
Красиво, кликабельно, наглядно: https://proglib.io/w/26094237
Kontra
Application Security Training For Developers | Kontra
Kontra is an Application Security Training platform built for modern development teams.
#practice #security
У платформы для изучения криптографии CryptoHack появился целый курс. Даже если у вас нет учетной записи, вы можете посетить все испытания и погрузиться в крипто-головоломки.
https://proglib.io/w/c7f8e937
У платформы для изучения криптографии CryptoHack появился целый курс. Даже если у вас нет учетной записи, вы можете посетить все испытания и погрузиться в крипто-головоломки.
https://proglib.io/w/c7f8e937
#bugbounty #pentest #practice #learning
Введение в современную веб-разработку
Подобные видеоуроки полезны для новичков в охоте за ошибками, т. к. охватывают прошлую и настоящую картину веба, в частности: микросервисы, ООП, MVC, фреймворки, middleware и многое другое. И почему же уязвимости вроде SQL-инъекций встречаются реже? Все ответы в видеоуроке.
https://proglib.io/w/dbed1735
Введение в современную веб-разработку
Подобные видеоуроки полезны для новичков в охоте за ошибками, т. к. охватывают прошлую и настоящую картину веба, в частности: микросервисы, ООП, MVC, фреймворки, middleware и многое другое. И почему же уязвимости вроде SQL-инъекций встречаются реже? Все ответы в видеоуроке.
https://proglib.io/w/dbed1735
YouTube
Katie Explains: Modern Web Development (GIVEAWAY)
I often tell people not to focus too much on CTFs or challenges on Twitter, but why? Well modern web dev has come a long way and many challenges just aren't realistic to what the modern web looks like. In this video I'll be breaking down these changes and…
#practice #pentest #bugbounty #hacking #career
Как стать этичным хакером в 2022 году: смотреть & читать 🔥
Как стать этичным хакером в 2022 году: смотреть & читать 🔥
YouTube
How to Be an Ethical Hacker in 2022
Sponsor: https://go.intigriti.com/thecybermentor
Blog Post: https://tcm-sec.com/so-you-want-to-be-a-hacker-2022-edition/
Academy: https://academy.tcm-sec.com
Timestamps:
0:00 - Introduction
0:53 - Intigriti Sponsorship
1:55 - Building a Foundation
2:10 …
Blog Post: https://tcm-sec.com/so-you-want-to-be-a-hacker-2022-edition/
Academy: https://academy.tcm-sec.com
Timestamps:
0:00 - Introduction
0:53 - Intigriti Sponsorship
1:55 - Building a Foundation
2:10 …
⚡️Команда PortSwigger на своей площадке представила новую тему по NoSQL
Погрузитесь в мир безопасности баз данных NoSQL — прочитайте учебные материалы, а затем выполните лабораторные работы, чтобы проверить свои знания.
#practice #pentest
Погрузитесь в мир безопасности баз данных NoSQL — прочитайте учебные материалы, а затем выполните лабораторные работы, чтобы проверить свои знания.
#practice #pentest