uz
Feedback

Firibgarlarga uchmang! Telemetrio bunday kanallarni topadi va belgilaydi 👉 Belgini ko‘rmoqchi bo‘lsangiz, obuna bo‘ling

ИнфоБез

ИнфоБез

Kanalga Telegram’da o‘tish

Канал посвящен информационной безопасности По всем вопросам: @altmainf Уважаемый менеджер: @altaiface

Ko'proq ko'rsatish
4 077
Obunachilar
-124 soatlar
+17 kun
-1430 kun
Obunachilarni jalb qilish
Okt '26
Oktabr '26
+9
0 kanalda
Sentabr '26
+14
0 kanalda
Get PRO
Avgust '26
+4
0 kanalda
Get PRO
Iyul '26
+5
0 kanalda
Get PRO
Iyun '26
+6
0 kanalda
Get PRO
May '26
+9
0 kanalda
Get PRO
Aprel '26
+4
0 kanalda
Get PRO
Mart '26
+13
0 kanalda
Get PRO
Fevral '26
+20
0 kanalda
Get PRO
Yanvar '26
+7
1 kanalda
Get PRO
Dekabr '25
+15
1 kanalda
Get PRO
Noyabr '25
+8
0 kanalda
Get PRO
Oktabr '25
+16
0 kanalda
Get PRO
Sentabr '25
+16
0 kanalda
Get PRO
Avgust '25
+28
0 kanalda
Get PRO
Iyul '25
+28
0 kanalda
Get PRO
Iyun '25
+15
0 kanalda
Get PRO
May '25
+18
0 kanalda
Get PRO
Aprel '25
+21
0 kanalda
Get PRO
Mart '25
+34
0 kanalda
Get PRO
Fevral '25
+17
0 kanalda
Get PRO
Yanvar '25
+22
0 kanalda
Get PRO
Dekabr '24
+17
0 kanalda
Get PRO
Noyabr '24
+20
0 kanalda
Get PRO
Oktabr '24
+27
0 kanalda
Get PRO
Sentabr '24
+49
0 kanalda
Get PRO
Avgust '24
+24
0 kanalda
Get PRO
Iyul '24
+21
0 kanalda
Get PRO
Iyun '24
+24
0 kanalda
Get PRO
May '24
+34
1 kanalda
Get PRO
Aprel '24
+22
0 kanalda
Get PRO
Mart '24
+38
0 kanalda
Get PRO
Fevral '24
+33
1 kanalda
Get PRO
Yanvar '24
+32
0 kanalda
Get PRO
Dekabr '23
+50
0 kanalda
Get PRO
Noyabr '23
+63
2 kanalda
Get PRO
Oktabr '23
+21
0 kanalda
Get PRO
Sentabr '23
+27
0 kanalda
Get PRO
Avgust '23
+23
0 kanalda
Get PRO
Iyul '23
+16
0 kanalda
Get PRO
Iyun '23
+26
0 kanalda
Get PRO
May '23
+14
0 kanalda
Get PRO
Aprel '23
+29
0 kanalda
Get PRO
Mart '23
+55
0 kanalda
Get PRO
Fevral '23
+551
0 kanalda
Get PRO
Yanvar '23
+779
0 kanalda
Get PRO
Dekabr '22
+637
0 kanalda
Get PRO
Noyabr '22
+912
0 kanalda
Get PRO
Oktabr '22
+1 037
0 kanalda
Get PRO
Sentabr '22
+1 150
0 kanalda
Get PRO
Avgust '22
+2 594
0 kanalda
Get PRO
Iyul '22
+1 122
0 kanalda
Sana
Obunachilarni jalb qilish
Esdaliklar
Kanallar
24 Oktabr+1
23 Oktabr0
22 Oktabr+2
21 Oktabr0
20 Oktabr+2
19 Oktabr0
18 Oktabr0
17 Oktabr0
16 Oktabr0
15 Oktabr0
14 Oktabr0
13 Oktabr0
12 Oktabr0
11 Oktabr+2
10 Oktabr0
09 Oktabr0
08 Oktabr0
07 Oktabr0
06 Oktabr0
05 Oktabr0
04 Oktabr0
03 Oktabr0
02 Oktabr+1
01 Oktabr+1
Kanal postlari
Web Security #14. CORS: кто имеет право читать ответ Представим два сайта:
https://frontend.example
https://api.example
JavaScript на frontend хочет сделать:
fetch("https://api.example/profile")
Браузер видит:
Origin:
https://frontend.example
а ресурс находится на другом origin:
https://api.example
Здесь вступает в игру CORS — Cross-Origin Resource Sharing. Сервер может ответить:
Access-Control-Allow-Origin: https://frontend.example
Браузер понимает:
Этот origin разрешён.
Если сервер не разрешил origin, браузер ограничит доступ JavaScript к ответу. Очень важно: CORS — это в первую очередь механизм браузера. Он не является универсальным firewall. Например:
Attacker
   |
   v
Server
CORS не означает автоматически:
"Server не принимает запросы от attacker"
Он регулирует, может ли browser-код прочитать cross-origin response. Ещё одна распространённая ошибка:
Access-Control-Allow-Origin: *
вместе с неправильной конфигурацией credentials. Поэтому CORS нужно рассматривать вместе с:
Origins
Cookies
Credentials
Authentication
Browser security model
Практика: Открой DevTools → Network. Найди запрос к API. Посмотри:
Origin
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Затем ответь на вопрос:
Какой именно origin сервер разрешает читать этот response?

2
Web Security #13. JWT: что находится внутри токена JWT часто используется для authentication и передачи claims. Выглядит он примерно так: xxxxx.yyyyy.zzzzz У JWT три части: header.payload.signature Например, payload может содержать: { "sub": "123", "role": "user" } Здесь: sub = идентификатор пользователя role = его роль Важный момент: JWT обычно не является зашифрованным контейнером. Payload можно декодировать и прочитать. Поэтому нельзя помещать туда секреты вроде: password private_key API secret Но тогда возникает вопрос: Если payload можно прочитать и изменить, почему нельзя просто поменять role=user на role=admin ? Потому что существует signature. Упрощённо: Header + Payload | v Secret key | v Signature Сервер пересчитывает подпись и проверяет, что токен не был изменён. Если payload изменили: { "role": "admin" } подпись уже не соответствует содержимому. Практическая безопасность JWT зависит от: Проверки signature Проверки algorithm Проверки expiration Проверки issuer/audience Безопасного хранения токена Главная ошибка новичка: «JWT — это зашифрованный пароль». Нет. JWT — это формат передачи подписанных данных. Практика: Возьми JWT из своей учебной лаборатории. Разбери: Header Payload Signature Попробуй понять: Какие данные находятся внутри? Какие claims используются? Есть ли expiration? Как сервер проверяет подпись?
268
3
Учишься в 9-11 классе и изучаешь программирование? Прими участие в олимпиаде Высшая проба по промышленному программированию о
Учишься в 9-11 классе и изучаешь программирование? Прими участие в олимпиаде Высшая проба по промышленному программированию от Яндекса и ВШЭ! Получи опыт решения кейсов из индустрии, подарки от Яндекса, БВИ или 100 баллов по профильному предмету. Регистрируйся до 20 октября! Узнать больше #реклама 16+ olymp.hse.ru О рекламодателе
169
4
Web Security #12. Burp Suite: учимся видеть HTTP До этого мы много говорили о запросах: GET /profile?id=123 HTTP/1.1 Cookie: session=abc123 Теперь нужен инструмент, который позволит удобно их изучать. Один из основных инструментов Web Security — Burp Suite. Схема работы: Browser | v Burp Suite | v Server Burp получает HTTP-запрос и показывает его нам. Например: GET /profile?id=123 HTTP/1.1 Host: lab.local Cookie: session=abc123 Теперь можно увидеть: Method URL Parameters Headers Cookies Body Response Особенно полезен Repeater. Можно взять запрос: GET /profile?id=123 HTTP/1.1 отправить его в Repeater и изменить: GET /profile?id=124 HTTP/1.1 Затем сравнить ответы. Именно так удобно исследовать: IDOR Authentication Authorization Input validation API Cookies Headers Burp не ищет уязвимости вместо тебя. Он помогает задавать вопросы: Что произойдёт, если изменить ID? Что произойдёт, если убрать cookie? Что произойдёт, если изменить method? Что произойдёт, если изменить parameter? Практика: Возьми учебную лабораторию. Сделай пять шагов: 1. Открой страницу. 2. Найди запрос в Proxy. 3. Отправь его в Repeater. 4. Измени одно значение. 5. Сравни Response. Изменяй только один параметр за раз. Так гораздо легче понять причинно-следственную связь.
273
5
Авторизованные курсы по оборудованию Eltex от дилера №1 Проводим учебные курсы, включающие практические занятия и лабораторны
Авторизованные курсы по оборудованию Eltex от дилера №1 Проводим учебные курсы, включающие практические занятия и лабораторные работы. По итогу успешной сдачи экзаменов обучающемуся выдаётся официальный сертификат от завода Eltex. ⚡Обучение в офисе или онлайн ⚡Опытный преподавательский состав ⚡Лабораторные работы - 50% времени ⚡Обучение юридических и физических лиц Записаться #реклама 16+ eltexcm.ru О рекламодателе
150
6
Web Security #11. File Upload: почему загрузка файла — это security-проблема Почти каждый сайт умеет принимать файлы: Аватар Документ Резюме Изображение PDF Допустим, приложение принимает: POST /upload HTTP/1.1 Content-Type: multipart/form-data И разработчик проверяет: filename заканчивается на .jpg Кажется, что всё хорошо. Но расширение файла — это только одна характеристика. Нужно учитывать: Имя файла Расширение MIME type Реальное содержимое Размер Место хранения Права доступа Способ последующей обработки Например, сервер может ожидать: avatar.jpg Но если приложение неправильно проверяет содержимое и потом размещает загруженный файл в web-доступном каталоге, это может создать серьёзную проблему. Безопасная архитектура обычно выглядит так: Upload ↓ Validate ↓ Generate server-side filename ↓ Store outside executable web directory ↓ Serve as data Например: Пользователь: avatar.jpg Сервер: f83a91c2.bin И приложение само решает, как отдавать этот файл. Главная мысль: Загруженный пользователем файл — недоверенные данные. Практика: В учебной лаборатории найди upload functionality. Изучи: Какие расширения разрешены? Проверяется ли MIME type? Проверяется ли содержимое? Где хранится файл? Можно ли открыть его напрямую через URL?
289
7
REKONFA: что интересного вас ждёт 15 октября 15 октября встречаемся на REKONFA — большой конференции Яндекс Рекламы. На сцене
REKONFA: что интересного вас ждёт 15 октября 15 октября встречаемся на REKONFA — большой конференции Яндекс Рекламы. На сцене: — Глеб Доброрадных — о рекламном рынке и эффективности в сложных условиях — Алексей Штоколов — о новых продуктах и технологиях — Лиза Смирнова — о 360°-форматах и новых точках контакта — Александр Пушной — о человеке и ИИ — Александр Умаров — о персональном подходе, который помогает влюблять клиентов в бренд — Яна Чурикова — об актуальных задачах предпринимателей — Татьяна Мужицкая — о целях и энергии — Антон Беляев — об индивидуальности и проектах, которые любят зрители Вне сцены — зона продуктов Яндекс Рекламы, три игры, викторина, зоны Яндекс Ярда и eLama и нетворкинг. 15 октября, Москва, ВТБ Арена и онлайн. Участие бесплатное. Зарегистрироваться #реклама 18+ ya.rekonfa.ru О рекламодателе
153
8
Web Security #10. SSRF: когда сервер делает запрос вместо пользователя Представим сервис, который скачивает картинку по URL. Пользователь отправляет: POST /download HTTP/1.1 Content-Type: application/json { "url": "https://example.com/image.jpg" } Сервер делает запрос: Web Server | | GET https://example.com/image.jpg v example.com Всё нормально. Но теперь представим архитектуру: Internet | v Web Server | +---- Internal API | +---- Database | +---- Admin panel Web Server может иметь доступ к внутренним сервисам. Обычный пользователь — нет. Если пользователь может управлять URL, возникает важный вопрос: Может ли он заставить сервер обратиться к внутреннему ресурсу? Это и есть основная идея SSRF — Server-Side Request Forgery. Проблема не в самом HTTP-запросе. Проблема в том, что: Пользователь | | управляет URL v Web Server | | имеет другие сетевые права v Internal Network Сервер становится посредником между пользователем и внутренней сетью. Защита обычно включает: Allowlist destinations Network segmentation Запрет доступа к внутренним адресам Безопасную обработку redirects Контроль DNS и URL Практика: Используй специальную SSRF-лабораторию. Нарисуй схему: Клиент ↓ Web application ↓ Что может увидеть web application? Это упражнение часто полезнее, чем простое запоминание SSRF payload'ов.
251
9
2 курса в подарок при обучении команды — Я.Практикум Расширьте навыки команды без доплат. Получите 3 курса Яндекс Практикума
2 курса в подарок при обучении команды — Я.Практикум Расширьте навыки команды без доплат. Получите 3 курса Яндекс Практикума по цене 1 Развивайте команду по трём направлениям — платите за одно. Так тоже можно. Оформите обучение в Практикуме для себя или сотрудников до 31 октября и получите бесплатно 2 курса: ✅ «Базовые навыки работы с ИИ» — о том, как применять ИИ в ежедневных рабочих задачах. ✅ «Экономика и бизнес-модель продукта» — о юнит-экономике и способах монетизации продуктов. Подберите обучение под любой запрос: в каталоге Практикума 180+ актуальных программ по ИИ, разработке, менеджменту, аналитике и другим направлениям. С нами уже сотрудничают 6000+ компаний. Начните и вы развивать команду с фокусом на бизнес-результат. Оставить заявку и получить бонусы Узнать больше #реклама 16+ practicum.yandex.ru О рекламодателе
148
10
Web Security #9. Path Traversal Представим сайт с загрузкой документов: /download?file=report.pdf Сервер хранит документы: /app/files/ report.pdf invoice.pdf manual.pdf Приложение получает имя файла: file = request.args["file"] open("/app/files/" + file) Разработчик ожидает: report.pdf Но проблема в том, что file контролирует пользователь. Приложение должно гарантировать: Файл находится внутри /app/files/ а не просто добавлять пользовательский текст к пути. Если проверка сделана неправильно, пользователь может попытаться заставить приложение обратиться к файлу за пределами разрешённого каталога. Именно это называется Path Traversal. Упрощённая схема: /app/files/ | +-- report.pdf | +-- invoice.pdf Приложение должно разрешать только файлы из этого каталога. Безопаснее: base = "/app/files/" requested = resolve(base, user_input) if not requested.startswith(base): return 403 Конкретная реализация зависит от языка и framework, но идея одна: Нельзя позволять пользовательскому вводу произвольно определять путь к файлу. Практика: В учебной лаборатории найди endpoint: /download?file=... Посмотри: что принимает параметр; как он используется; есть ли проверка пути; что происходит при указании несуществующего файла.
201
11
Услуги дата-центра в Москве Размещение и аренда серверного оборудования в дата-центре. 👍 4 современных дата-центра в Москве.
Услуги дата-центра в Москве Размещение и аренда серверного оборудования в дата-центре. 👍 4 современных дата-центра в Москве. 👍 Лицензированный оператор связи. 👍 Индивидуальные конфигурации выделенных серверов под задачи клиента. 👍 Круглосуточная техническая поддержка в Телеграм, без ботов. Узнать цену #реклама 16+ itsoft.ru О рекламодателе
165
12
Web Security #8. CSRF: когда браузер отправляет запрос не по твоей воле Представим, что ты вошёл на: bank.example У браузера есть: Cookie: session=abc123 Теперь ты открываешь другой сайт. Он может попытаться заставить браузер отправить запрос к bank.example. Например: POST /change-email Если браузер автоматически прикладывает нужную cookie, сервер может увидеть: session=abc123 и решить: Это запрос Alice. Хотя Alice сама его не инициировала. Это и есть основная идея CSRF. Упрощённо: Alice вошла в банк | v Браузер хранит session cookie | v Alice открывает другой сайт | v Другой сайт пытается вызвать действие | v Браузер отправляет запрос | v Bank получает cookie Один из классических механизмов защиты — CSRF token. Например: <input type="hidden" name="csrf" value="random-token" > Сервер знает правильный token и проверяет его. Другой важный механизм: SameSite cookie Он ограничивает некоторые cross-site сценарии отправки cookies. Важно не путать: XSS означает, что атакующий добился выполнения JavaScript в контексте приложения. CSRF означает, что браузер жертвы может отправить нежелательный запрос с её полномочиями. Практика: Открой CSRF-лабораторию. Посмотри: какой запрос изменяет состояние; есть ли CSRF token; проверяет ли сервер token; какие cookie используются.
222
13
Олимпиада Высшая проба: промышленное программирование Участвуй в олимпиаде школьников 9-11 класса по промышленному программир
Олимпиада Высшая проба: промышленное программирование Участвуй в олимпиаде школьников 9-11 класса по промышленному программированию от Яндекса и ВШЭ. Победителям — БВИ или 100 баллов по профильному предмету в топовых вузах России. Регистрируйся до 20 октября! Узнать больше #реклама olymp.hse.ru О рекламодателе
173
14
Web Security #7. XSS: когда текст становится кодом Представим страницу профиля. Пользователь вводит имя: Alice Сервер сохраняет его. Затем приложение формирует HTML: <h1>Hello, Alice</h1> Всё нормально. Проблема появляется, когда приложение неправильно обрабатывает пользовательский ввод и браузер начинает воспринимать его как HTML или JavaScript. Например, приложение делает: element.innerHTML = username; Здесь username приходит от пользователя. Это опасный подход, если содержимое не должно быть HTML. Почему? Потому что браузер интерпретирует значение innerHTML как HTML-разметку. Вместо: Привет, Alice в страницу может попасть HTML, который браузер обработает как разметку. Если через такую точку удаётся выполнить JavaScript, это уже XSS. XSS бывает разных типов: Stored XSS Reflected XSS DOM-based XSS Например, при Stored XSS пользовательский ввод сохраняется на сервере. Другой пользователь открывает страницу. Сервер возвращает сохранённые данные. Браузер обрабатывает их как код. Схема: Attacker input ↓ Application ↓ Database ↓ Victim browser ↓ JavaScript execution Защита зависит от контекста, но основные методы: Output encoding Безопасная работа с DOM Sanitization Content Security Policy Практика: Возьми учебную XSS-лабораторию. Найди место, куда вводится текст. Посмотри: куда попадает ввод; как сервер его возвращает; как браузер его отображает. Главный вопрос: Может ли пользовательский текст оказаться там, где браузер ожидает HTML или JavaScript?
257
15
Встречай смартфон Honor — с выгодой для себя! ✅ Стильный дизайн ✅ Заряд надолго ✅ Качественные фото ✅ Быстрая и плавная работ
Встречай смартфон Honor — с выгодой для себя! ✅ Стильный дизайн ✅ Заряд надолго ✅ Качественные фото ✅ Быстрая и плавная работа Выбирай свой Honor по привлекательной цене! Купить #реклама market.yandex.ru О рекламодателе
160
16
Web Security #6. SQL Injection Представим страницу поиска: /search?q=phone Приложение получает phone. Разработчик хочет найти товары: SELECT * FROM products WHERE name = 'phone'; Проблема появляется, если SQL строится обычной конкатенацией строк: query = "SELECT * FROM products WHERE name = '" + user_input + "'" Почему это опасно? Потому что приложение смешивает две разные вещи: SQL-код + данные пользователя Если специальные символы из пользовательского ввода начинают влиять на структуру SQL-запроса, пользовательский ввод перестаёт быть просто данными. Это и есть основная идея SQL Injection. Правильный подход — parameterized query: cursor.execute( "SELECT * FROM products WHERE name = ?", (user_input,) ) Теперь база данных получает отдельно: SQL: SELECT * FROM products WHERE name = ? Данные: phone И не должна воспринимать содержимое phone как SQL-код. Главный принцип: Небезопасно: данные + SQL-код смешиваются Безопасно: SQL-код и данные передаются отдельно Практика: Возьми OWASP Juice Shop, DVWA или лаборатории PortSwigger. Найди SQL Injection лабораторию. Твоя первая задача — не запомнить payload. Нужно понять цепочку: HTTP parameter ↓ Application ↓ SQL query ↓ Database ↓ Response Когда ты понимаешь эту цепочку, становится понятно, где возникает уязвимость.
242
17
Бесплатный курс по дизайну: веб, графический и UX/UI Что внутри: — старт в дизайне с нуля — личный наставник и поддержка по х
Бесплатный курс по дизайну: веб, графический и UX/UI Что внутри: — старт в дизайне с нуля — личный наставник и поддержка по ходу обучения — доступ к платформе с уроками и заданиями — 4+ работ, которые можно добавить в портфолио — чат с участниками и единомышленниками — проверка домашних заданий и разбор ошибок — сертификат по итогам курса Подойдёт тем, кто: — хочет зайти в цифровую без большого опыта — задумывается о смене профессии — хочет освоить навык, который можно применять на практике — ищет понятный и спокойный старт в дизайне Для кого: — для новичков без подготовки — для тех, кто давно хочет попробовать себя в дизайне — для тех, кто ищет первый шаг на удаленке Узнать больше #реклама 16+ ydaev.ru О рекламодателе
170
18
Web Security #5. IDOR: когда ID недостаточно Представим интернет-магазин. У Alice есть заказ: Order #1001 Браузер получает его через: GET /api/orders/1001 HTTP/1.1 Cookie: session=alice Сервер возвращает: { "id": 1001, "owner": "alice", "total": 50 } Теперь Alice меняет номер: GET /api/orders/1002 HTTP/1.1 Cookie: session=alice И сервер возвращает: { "id": 1002, "owner": "bob", "total": 900 } Вот здесь проблема. Почему сервер отдал чужой заказ? Скорее всего, логика была примерно такой: order = database.get_order(order_id) return order Сервер получил 1002, нашёл заказ и просто вернул его. Но нужно проверить владельца: order = database.get_order(order_id) if order.owner_id != current_user.id: return 403 return order То есть недостаточно спросить: Существует ли заказ 1002? Нужно спросить: Имеет ли Alice право видеть заказ 1002? Это пример Broken Access Control. А конкретно такой сценарий часто называют IDOR — Insecure Direct Object Reference. Практика: В учебном приложении найди запрос вроде: /api/orders/123 /api/users/42 /api/documents/15 Измени идентификатор. Если сервер показывает объект другого пользователя — ты обнаружил проблему контроля доступа. Проверяй такое только в собственных системах или разрешённых лабораториях.
253
19
Почувствуйте ритм Дубая с отелями Jumeirah Семейный отдых обретает свой ритм - время для открытий, игр и особенных моментов в
Почувствуйте ритм Дубая с отелями Jumeirah Семейный отдых обретает свой ритм - время для открытий, игр и особенных моментов вместе. Узнать больше #реклама jumeirah.com О рекламодателе
172
20
Web Security #4. Authentication и Authorization Эти два понятия очень легко перепутать. Authentication отвечает на вопрос: Кто ты? Например: username: alice password: ******** Сервер проверяет пароль и говорит: Это Alice. Это authentication. Authorization отвечает на другой вопрос: Что Alice разрешено делать? Например: Alice: читать свой профиль да изменить свой профиль да удалить другого user нет открыть admin panel нет Представим запрос: GET /admin/users HTTP/1.1 Cookie: session=alice123 Сервер видит: alice123 → Alice Authentication пройдена. Но Alice — обычный пользователь. Поэтому сервер должен проверить authorization и вернуть: HTTP/1.1 403 Forbidden Проблема возникает, если сервер проверяет только наличие валидной сессии: if session_is_valid(): return admin_users() Получается: Пользователь вошёл? | да | v Отдать admin_users() Нужна дополнительная проверка: if not session_is_valid(): return 401 if not current_user.is_admin: return 403 return admin_users() Запомни простое правило: Authentication: "Кто ты?" Authorization: "Что тебе разрешено?" Многие серьёзные ошибки доступа начинаются именно с того, что эти две проверки смешивают. Практика: В учебном приложении найди страницу или API администратора. Посмотри: Что происходит без авторизации? Что происходит после обычного login? Что происходит у администратора? Сравни HTTP-ответы.
227