Библиотека программиста | программирование, кодинг, разработка
82.2K subscribers
3.11K photos
147 videos
88 files
6.35K links
Все самое полезное для программиста в одном канале.

Список наших каналов: https://tttttt.me/proglibrary/9197
Учиться у нас: https://proglib.io/w/a32a0d94

Обратная связь: @proglibrary_feedback_bot

По рекламе: @proglib_adv
Прайс: @proglib_advertising
Download Telegram
#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
​​#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
#pentest #bugbounty #practice

Kontra OWASP Top 10 — это коллекция бесплатных интерактивных руководств о наиболее популярных уязвимостях и некоторых инцидентах безопасности.

Разработчики данных тренингов считают, что каждый инженер-программист должен иметь бесплатный доступ к обучению безопасной разработке. Kontra OWASP Top 10 — их первый шаг в этом направлении.

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

Красиво, кликабельно, наглядно: https://proglib.io/w/26094237
#practice #security

У платформы для изучения криптографии CryptoHack появился целый курс. Даже если у вас нет учетной записи, вы можете посетить все испытания и погрузиться в крипто-головоломки.

https://proglib.io/w/c7f8e937
#bugbounty #pentest #practice #learning

Введение в современную веб-разработку

Подобные видеоуроки полезны для новичков в охоте за ошибками, т. к. охватывают прошлую и настоящую картину веба, в частности: микросервисы, ООП, MVC, фреймворки, middleware и многое другое. И почему же уязвимости вроде SQL-инъекций встречаются реже? Все ответы в видеоуроке.

https://proglib.io/w/dbed1735
⚡️Команда PortSwigger на своей площадке представила новую тему по NoSQL

Погрузитесь в мир безопасности баз данных NoSQL — прочитайте учебные материалы, а затем выполните лабораторные работы, чтобы проверить свои знания.

#practice #pentest