ИнфоБез
前往频道在 Telegram
Канал посвящен информационной безопасности По всем вопросам: @altmainf Уважаемый менеджер: @altaiface
显示更多4 077
订阅者
-124 小时
+17 天
-1430 天
正在加载数据
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
十月 '2610月 '26
十月 '26
+9
在0个频道中
九月 '26
+14
在0个频道中
Get PRO
八月 '26
+4
在0个频道中
Get PRO
七月 '26
+5
在0个频道中
Get PRO
六月 '26
+6
在0个频道中
Get PRO
五月 '26
+9
在0个频道中
Get PRO
四月 '26
+4
在0个频道中
Get PRO
三月 '26
+13
在0个频道中
Get PRO
二月 '26
+20
在0个频道中
Get PRO
一月 '26
+7
在1个频道中
Get PRO
十二月 '25
+15
在1个频道中
Get PRO
十一月 '25
+8
在0个频道中
Get PRO
十月 '25
+16
在0个频道中
Get PRO
九月 '25
+16
在0个频道中
Get PRO
八月 '25
+28
在0个频道中
Get PRO
七月 '25
+28
在0个频道中
Get PRO
六月 '25
+15
在0个频道中
Get PRO
五月 '25
+18
在0个频道中
Get PRO
四月 '25
+21
在0个频道中
Get PRO
三月 '25
+34
在0个频道中
Get PRO
二月 '25
+17
在0个频道中
Get PRO
一月 '25
+22
在0个频道中
Get PRO
十二月 '24
+17
在0个频道中
Get PRO
十一月 '24
+20
在0个频道中
Get PRO
十月 '24
+27
在0个频道中
Get PRO
九月 '24
+49
在0个频道中
Get PRO
八月 '24
+24
在0个频道中
Get PRO
七月 '24
+21
在0个频道中
Get PRO
六月 '24
+24
在0个频道中
Get PRO
五月 '24
+34
在1个频道中
Get PRO
四月 '24
+22
在0个频道中
Get PRO
三月 '24
+38
在0个频道中
Get PRO
二月 '24
+33
在1个频道中
Get PRO
一月 '24
+32
在0个频道中
Get PRO
十二月 '23
+50
在0个频道中
Get PRO
十一月 '23
+63
在2个频道中
Get PRO
十月 '23
+21
在0个频道中
Get PRO
九月 '23
+27
在0个频道中
Get PRO
八月 '23
+23
在0个频道中
Get PRO
七月 '23
+16
在0个频道中
Get PRO
六月 '23
+26
在0个频道中
Get PRO
五月 '23
+14
在0个频道中
Get PRO
四月 '23
+29
在0个频道中
Get PRO
三月 '23
+55
在0个频道中
Get PRO
二月 '23
+551
在0个频道中
Get PRO
一月 '23
+779
在0个频道中
Get PRO
十二月 '22
+637
在0个频道中
Get PRO
十一月 '22
+912
在0个频道中
Get PRO
十月 '22
+1 037
在0个频道中
Get PRO
九月 '22
+1 150
在0个频道中
Get PRO
八月 '22
+2 594
在0个频道中
Get PRO
七月 '22
+1 122
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 24 十月 | +1 | |||
| 23 十月 | 0 | |||
| 22 十月 | +2 | |||
| 21 十月 | 0 | |||
| 20 十月 | +2 | |||
| 19 十月 | 0 | |||
| 18 十月 | 0 | |||
| 17 十月 | 0 | |||
| 16 十月 | 0 | |||
| 15 十月 | 0 | |||
| 14 十月 | 0 | |||
| 13 十月 | 0 | |||
| 12 十月 | 0 | |||
| 11 十月 | +2 | |||
| 10 十月 | 0 | |||
| 09 十月 | 0 | |||
| 08 十月 | 0 | |||
| 07 十月 | 0 | |||
| 06 十月 | 0 | |||
| 05 十月 | 0 | |||
| 04 十月 | 0 | |||
| 03 十月 | 0 | |||
| 02 十月 | +1 | |||
| 01 十月 | +1 |
频道帖子
Web Security #14. CORS: кто имеет право читать ответ
Представим два сайта:
https://frontend.example https://api.exampleJavaScript на 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 ServerCORS не означает автоматически:
"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 классе и изучаешь программирование?
Прими участие в олимпиаде Высшая проба по промышленному программированию от Яндекса и ВШЭ!
Получи опыт решения кейсов из индустрии, подарки от Яндекса, БВИ или 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.
⚡Обучение в офисе или онлайн
⚡Опытный преподавательский состав
⚡Лабораторные работы - 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 — большой конференции Яндекс Рекламы.
На сцене:
— Глеб Доброрадных — о рекламном рынке и эффективности в сложных условиях
— Алексей Штоколов — о новых продуктах и технологиях
— Лиза Смирнова — о 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 курса Яндекс Практикума по цене 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 современных дата-центра в Москве.
👍 Лицензированный оператор связи.
👍 Индивидуальные конфигурации выделенных серверов под задачи клиента.
👍 Круглосуточная техническая поддержка в Телеграм, без ботов.
Узнать цену
#реклама 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 класса по промышленному программированию от Яндекса и ВШЭ.
Победителям — БВИ или 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 по привлекательной цене!
Купить
#реклама
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
Что внутри:
— старт в дизайне с нуля
— личный наставник и поддержка по ходу обучения
— доступ к платформе с уроками и заданиями
— 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.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 |
