Что такое эта ваша поддержка? На диджитал-рынке постоянно звучит услуга «поддержка сайта». Но на практике под словом «поддержка» подразумевают совершенно разные вещи. Сюда попадает гарантийная и постгарантийная поддержка, контентно-техническое сопровождение, ретейнер команды разработки. Сюда же иногда относят ответственность за то, чтобы сайт вообще работал.

Путаница возникает потому, что одним словом называют три принципиально разные зоны ответственности: Первая — исправлять возникшие проблемы. Это поломки и качество самого программного обеспечения: устранение багов, обучение и помощь пользователям. Сюда не входит развитие продукта и добавление новых функций. Именно к этому слою обычно относятся гарантийная и постгарантийная поддержка. Вторая — выполнять входящие задачи. Есть команда или специалист, которые берут в работу всё, что связано с сайтом: меняют контент, создают страницы, дорабатывают функциональность, занимаются вебмастерингом или развивают сайт по согласованному плану. По сути, клиент покупает гарантированную возможность регулярно ставить задачи и получать результат. Это может быть контентно-техническая поддержка или работа команды разработки. Третья — отвечать за состояние и работоспособность системы. Здесь речь уже не про отдельные задачи, а про то, чтобы продукт оставался доступным, стабильным и выдерживал реальную нагрузку. Этим занимаются DevOps, системные администраторы, инженеры по надёжности: настраивают мониторинг, следят за инфраструктурой, реагируют на аварии и восстанавливают систему после сбоев.

Почему всё это называют одним словом? Во-первых, так говорят клиенты. У них основная деятельность находится в другой области, поэтому практически любые работы с сайтом, кроме полноценного редизайна или новой разработки, они склонны называть поддержкой. Во-вторых, это пошло от самих веб-студий. Их основной продукт — создание сайтов, а всё, что происходит после запуска, автоматически отправляется в категорию «поддержка». Необязательно срочно придумывать для каждой услуги новое название. Но при обсуждении поддержки нужно четко зафиксировать, что именно вы делаете, а что не делаете. За что отвечаете, в какие сроки реагируете, какие задачи принимаете и что оплачивается отдельно. Тогда у клиента не будет ожидания, что в рамках гарантии вы бесплатно разработаете новую функцию или будете дежурить и решать падение сайта под нагрузкой в выходные. Называть разные услуги одним словом можно. Главное — чтобы все одинаково понимали, какая именно услуга была куплена. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵

Большие языковые модели хорошо распознают изображения. Могут подробно описать, что они там видят и даже где оно примерно находится на листе. Но с точным позиционированием элементов на картинке всё ещё справляются не идеально. Для этого существует отдельный класс моделей. Нашёл на Hugging Face маленькую узкоспециализированную модель для разметки скриншотов веб-страниц. Называется ScreenParser. По факту, это YOLO, дообученный на вот этом датасете из 1,45 миллионов веб-страниц. Модель крошечная (25 миллионов параметров), поэтому без проблем запустится на вашем рабочем ноутбуке. Размечает на bbox-ы и класс элемента. Всего есть 55 классов, которые могут существовать на веб-странице. В JSON складывает также уверенность в том, что элемент распознан верно. Если уверенность низкая, то всегда можно сделать кроп нужной области и отправить на распознание ещё раз. Я уже попробовал модель в качестве одного из инструментов при вёрстке макетов по картинке. Пример разметки можете увидеть в медиа поста. Ставьте 🔥 , если хотите скилл по вёрстке из картинки/скриншота с помощью ScreenParser. Думаю, её также можно добавить к какой-нибудь мелкой on-prem-модели для того, чтобы улучшить навык browser-use.

Файлы куки Разные сайты пишут, мол, «мы используем файлы куки». Да это не файлы куки, а просто куки! Ну да, на диске куки хранятся в файлах, — ну так на диске всё хранится в файлах, даже сам браузер — это тоже файлы! Вы же не пишете «обновите ваши файлы браузер до последней версии». Куки при этом могут храниться в отдельных файлах каждая, в одном файле все, в кастомной базе данных или как угодно ещё, и это вообще не важно. Более того, даже если вы точно знаете, что конкретный браузер, с которым я к вам зашёл, хранит куки в виде отдельных файлов, всё равно вы не «используем файлы куки». Файлы на моём диске-то вы всё равно не видите и не используете никак. Это мой файлы браузер читает свои файлы куки и отправляет вам сами эти куки, а не файлы, чтобы ваши файлы веб-сервер могли что-то с ними сделать.

📚 Продолжаем развивать модуль «WEB-БАЗА» В посте я спросил, какие темы стоит добавить или разобрать подробнее. И практически сразу в комментариях появилось предложение:

OWASP

Отличная тема 👍 OWASP постоянно встречается в вакансиях, отчётах по пентесту, обучающих материалах и требованиях к специалистам по безопасности веб-приложений. Но у новичков часто возникает путаница: — OWASP — это программа? — стандарт? — список уязвимостей? — методика тестирования? — или организация? Поэтому ниже попробуем разобрать: 🌐 что такое OWASP; 📋 какие проекты входят в OWASP; 🔥 что такое OWASP Top 10; 🧪 как OWASP помогает пентестеру; 🛡 зачем OWASP нужен разработчикам и специалистам AppSec. Спасибо подписчику за хорошее предложение. Именно благодаря вашим комментариям база знаний становится полезнее и ближе к реальным вопросам аудитории. Поехали разбираться 👇

Как верстали 15 лет назад Верстальщику попалась книга по вёрстке 2004 года, и он решил вспомнить, из чего складывался рабочий день до флексбоксов и гридов. Картина выходит дикая. Чтобы отцентрировать элемент по вертикали, ему приходилось притворяться ячейкой таблицы. Свойство table-cell честно сообщало браузеру, что перед ним ячейка, и только после этого срабатывало выравнивание. И это ещё щадящий пример. Сетку городили на float, где один лишний пиксель сдвигал все блоки разом, а пятый элемент уезжал под четвёртый. Зазор между колонками лечили обнулением шрифта у родителя. Градиент вырезали полоской в Фотошопе и размножали картинкой по ширине. Посмотрим, какими ещё заклинаниями держалась вёрстка, пока инструменты не повзрослели.

📄 Что такое XXE (XML External Entity)? Не все веб-приложения работают только с JSON. Во многих корпоративных системах, банковских сервисах и интеграционных решениях до сих пор используется XML. И если приложение неправильно обрабатывает XML-документы, может возникнуть опасная уязвимость — XXE. 📌 XXE (XML External Entity) — это уязвимость, при которой приложение обрабатывает внешние XML-сущности, позволяя злоумышленнику повлиять на работу XML-парсера. Проще говоря, сервер начинает выполнять действия, которые разработчик не предусматривал. 🧠 Где используется XML? XML до сих пор можно встретить: — в SOAP-сервисах; — API некоторых корпоративных систем; — при обмене данными между приложениями; — в конфигурационных файлах; — в устаревших веб-приложениях. Если приложение принимает XML от пользователя, стоит уделить этому особое внимание. 💀 Чем это опасно? При наличии XXE злоумышленник может: — получить доступ к конфиденциальным данным; — прочитать внутренние файлы сервера; — обращаться к внутренним сервисам от имени приложения; — раскрыть информацию об инфраструктуре. Последствия зависят от конфигурации XML-парсера и возможностей самого приложения. 🛡 Как защититься? Основные рекомендации: — отключить обработку внешних XML-сущностей; — использовать безопасные настройки XML-парсеров; — обновлять используемые библиотеки; — проверять и ограничивать входящие XML-документы. 📌 Сегодня XXE встречается значительно реже, чем несколько лет назад, поскольку многие современные API используют JSON вместо XML. Однако в корпоративной среде и интеграционных системах XML всё ещё широко применяется, поэтому знание XXE остаётся важной частью подготовки специалиста по веб-безопасности. #web #owasp #xxe #xml #pentest #websecurity

💉 Что такое NoSQL Injection? Когда говорят об инъекциях, большинство сразу вспоминает SQL Injection. Но сегодня многие современные приложения используют не SQL-базы данных, а NoSQL, например MongoDB. И вместе с этим появилась ещё одна опасная уязвимость — NoSQL Injection.

📌 NoSQL Injection — это уязвимость, при которой злоумышленник может повлиять на запрос к NoSQL-базе данных из-за некорректной обработки пользовательского ввода.

Другими словами, приложение начинает выполнять запрос не так, как задумал разработчик. 🧠 Где встречается NoSQL? Самые популярные NoSQL-базы: — MongoDB; — CouchDB; — Redis; — Cassandra. Их часто используют в современных веб-приложениях, REST API и облачных сервисах благодаря высокой производительности и гибкости. 💀 Чем это опасно? Если приложение недостаточно защищено, последствия могут быть серьёзными: — обход аутентификации; — получение доступа к чужим данным; — просмотр содержимого базы; — изменение или удаление информации. Конкретные последствия зависят от логики приложения и уровня защиты. 🛡 Как защититься? Основные рекомендации: — проверять и валидировать все входные данные; — использовать безопасные методы формирования запросов; — избегать передачи пользовательского ввода напрямую в запросы к базе данных; — ограничивать права пользователя базы данных по принципу минимальных привилегий. 📌 Хотя NoSQL Injection встречается реже, чем классическая SQL Injection, популярность NoSQL-баз продолжает расти, а вместе с ней возрастает и актуальность этой уязвимости. Поэтому специалисту по веб-безопасности важно понимать не только традиционные SQL-базы данных, но и особенности современных NoSQL-решений. #web #nosql #mongodb #owasp #injection

Решил я добавить в PersMarket возможность скачивать PDF вакансий и резюме. Задача звучит несложно, но оказалось, что не всё так банально. Как мы делали раньше такие вещи? На бэкенде с помощью сторонних библиотек (Dompdf, mPDF) генерили документ и отдавали клиенту сырые данные с указанием Content-Type = application/pdf Однако, такие документы плохо поддерживают современный CSS и имеют проблемы со шрифтами. Еще, кстати, был вариант использвать wkhtmltopdf, но это может блокировать выполнение скрипта надолго. Чтобы PDF был такой же красивый, как страница на фронтенде, лучше всего и генерировать браузером. Я провел консультативную сессию с несколькими нейросетями, и они отговорили меня от генерации чисто на фронтенде (jsPDF, html2pdf). Говорят, PDF будет "плыть", стили ломаться, и серверную логику не добавить. В итоге мы с ними нашли интересный вариант - генерация через headless-браузер. Как это работает? Поскольку у меня Docker-сонтейнеры, я добавил еще один контейнер, внутрь которого положил Node.js-скрипт. Он умеет отображать страницы сервиса у себя внутри в браузере Chromium без пользовательского интерфейса (headless). Работает через Puppeteer. По запросу фронтенда бэкенд идет в PDF-сервис и просит конкретную страницу. После рендера страницы она сохраняется в PDF и отдается бэкенду, а он пересылает ее клиенту. Страница получается точно такая же, как в браузере, со всеми стилями и даже эмоджи. В общем, всё получилось, и, на мой взгляд, вполне прилично. Пришлось повозиться с пробросом аутентификации, но все вопросы решились. Далее это всё можно обкладывать очередями, кэшами, rate-limiter-ами и т.д. А ведь headless-браузер можно использовать и в быту. Например: - автоматические e2e-тесты в CI/CD-пайплайнах - автоматический веб-скрейпинг - генерация скриншотов страниц и всякое такое #web #persmarket

💉 Что такое SQL Injection? SQL Injection — одна из самых известных веб-уязвимостей, о которой слышал практически каждый, кто начинает изучать пентест. Но что она означает на самом деле?

📌 SQL Injection (SQLi) — это уязвимость, которая возникает, когда приложение неправильно обрабатывает пользовательский ввод при обращении к базе данных.

Проще говоря, злоумышленник может повлиять на SQL-запрос, который приложение отправляет в базу данных. 🧠 Представьте обычную форму входа на сайте. Вы вводите: — логин — пароль После чего приложение обращается к базе данных и проверяет, существует ли такой пользователь. Если разработчик не проверяет входные данные должным образом, появляется риск SQL Injection. 💀 Почему это опасно? В зависимости от приложения и уровня защиты последствия могут быть разными: — получение данных пользователей; — просмотр информации из базы данных; — обход аутентификации; — изменение или удаление данных. Именно поэтому SQL Injection уже много лет входит в список самых опасных веб-уязвимостей. 🛡 Как защититься? Основные рекомендации: — использовать параметризованные запросы (Prepared Statements); — проверять и фильтровать пользовательский ввод; — не собирать SQL-запросы простой конкатенацией строк; — использовать принцип минимальных привилегий для доступа к базе данных. 📌 Несмотря на появление современных фреймворков и ORM, SQL Injection до сих пор регулярно встречается в реальных проектах. Именно поэтому понимание принципов её возникновения остаётся одним из базовых навыков для любого специалиста по веб-безопасности. #web #owasp #sqli #injection

Веб-разработчики прекрасно знают HTTP-методы для взаимодействия клиента с сервером. Через GET обычно данные с сервера получают. Через POST можно создать или обновить. Удалять логично через DELETE. А вот HEAD, например, мы используем для проверки соединения, чтобы сэкономить трафик а теле запроса. Так вот, кто-то сидел и скучал о методе, который бы объединил GET и POST. Чтобы слать для запроса извлечения данных дополнительные параметры, скажем, фильтры, не в строке запроса, а в теле. Ну, типа мутант - GET-запрос с телом от POST. И придумали новый метод - QUERY. На эту тему даже сформировали отдельный RFC 10008 - The HTTP QUERY Method. То есть это как раз и получается идемпотентная операция запроса данных, аналогичная GET, но с телом POST, где вы можете слать тот же JSON с фильтрами и пагинацией. Подробности - в статье. #web

Вам, фанаты Lovable, Vercel и прочих конструкторов сайтов, аппов и ботов под ключ, с использованием ИИ и, самое главное, с встроенным хостингом проектов. Только что разбирал кейс подруги, которая запустила лендинг через лавабл, а он у людей не открывается. бОльшая часть не отсекает, или отсекает не сразу, что подавляющее большинство модных облачных сервисов для создания всего, либо защищены Cloudflare, либо хостятся в OVH/Digital Ocean/Hetzner и других облачных провайдерах, существенная часть из которых в РФ заблокированы давным давно. Lovable тут идеальный пример. К нему еще и свой хостинг не прикрутить, только домен (а это никак не повлияет на доступность), и по сути единственный вариант — сделать экспорт кода, развернуть у себя и забыть про использование их конструктора. Недоступность ваших вайб-кодерских ресурсов в РФ может составлять до 60-80%. С ВПН еще можно зайти, а без него — никак. И люди даже не знают, что дело в нем — нет такой привычки, проверять, ни у кого, кроме совсем поехавших гиков. Так что для РФ только собственный хостинг, никаких западных облачных платформ, или отдельный сервер под РФ и так далее. Ну, если не хотите терять до 80% аудитории.