Создание корпоративных сайтов

При разработке веб-приложений один из важных этапов его тестирования - это нагрузочное тестирование. Это позволяет не только выявить возможные узкие места в системе, но и убедиться, что приложение способно выдерживать ожидаемое количество пользователей и запросов. Содержание 1. Понимание нагрузочного тестирования 2. Ключевые методики нагрузочного тестирования 3. Инструменты для нагрузочного тестирования Java веб-приложений 4. Пример нагрузочного тестирования с использованием Apache JMeter 5. Лучшие практики нагрузочного тестирования 6. Вывод 7.Пример протокола нагрузочного тестирования веб-приложения или сайта Понимание нагрузочного тестирования Нагрузочное тестирование — это процесс моделирования различных уровней пользовательской активности на веб-приложение для оценки его производительности. Основная задача этого тестирования заключается в том, чтобы понять, насколько эффективно система справляется с увеличивающимся трафиком и где находятся ее пределы. В результате нагрузочного тестирования выявляются точки отказа и определяется максимальная пропускная способность приложения. В прошлом мы уже рассматривали тему нагрузочного тестирования в статье, где детально обсудили основные инструменты и подходы к проверке производительности приложений. Если вам интересна более широкая картина, рекомендуем ознакомиться с той статьей. А в этом материале мы сосредоточимся на специфике нагрузочного тестирования Java веб-приложений, рассмотрим основные методики, инструменты и лучшие практики для достижения оптимальных результатов. Ключевые методики нагрузочного тестирования Пиковая нагрузка (Spike Testing): Данный метод тестирования направлен на оценку реакции системы на резкое увеличение нагрузки. Он помогает выявить, как приложение справляется с внезапными всплесками пользовательской активности. Длительное тестирование (Soak Testing): Метод заключается в проверке системы на ее способность функционировать под стабильной нагрузкой в течение длительного времени. Это позволяет обнаружить долгосрочные проблемы, такие как утечки памяти или сбои в подключении к базе данных. Стресс-тестирование (Stress Testing): Этот вид тестирования позволяет оценить работу приложения при нагрузке, которая превышает ожидаемую. Цель состоит в том, чтобы определить, на каком этапе система начинает сбоить и как быстро она восстанавливается после перегрузки. Постепенное увеличение нагрузки (Ramp-Up Testing): Здесь нагрузка на систему увеличивается плавно, пока не достигает заданного уровня. Такой подход помогает определить порог, при котором начинаются проблемы с производительностью. Инструменты для нагрузочного тестирования Java веб-приложений Apache JMeter: Популярный инструмент для проведения нагрузочного тестирования, который поддерживает множество протоколов, включая HTTP, HTTPS, SOAP и JDBC. JMeter предлагает широкий спектр возможностей для создания сложных тестовых сценариев и анализа результатов, что делает его универсальным решением для нагрузочного тестирования. shell # Запуск теста в JMeter jmeter -n -t test_plan.jmx -l results.jtl -e -o /path/to/output/folder Gatling: Этот инструмент, разработанный на языке Scala, отличается высокой производительностью и возможностью масштабирования. Gatling предоставляет удобный DSL для создания тестовых сценариев и мощные средства анализа, что делает его идеальным для сложных нагрузочных тестов. scala class BasicSimulation extends Simulation { val httpProtocol = http.baseUrl("http://localhost:8080") val scn = scenario("Basic Scenario") .exec(http("request_1").get("/")) setUp(scn.inject(atOnceUsers(1000)).protocols(httpProtocol)) } Locust: Написанный на Python, этот инструмент позволяет разрабатывать тестовые сценарии, используя знакомый разработчикам язык. Locust легко интегрируется с другими системами и дает возможность гибко управлять нагрузкой, что делает его удобным для использования в различных проектах. python from locust import HttpUser, TaskSet, task class UserBehavior(TaskSet): @task def index(self): self.client.get("/") class WebsiteUser(HttpUser): tasks = [UserBehavior] min_wait = 5000 max_wait = 9000 Apache Benchmark (ab): Этот легковесный инструмент предназначен для быстрого выполнения базовых тестов производительности веб-серверов. Он прост в использовании и подходит для быстрой оценки производительности приложений в условиях базовой нагрузки. shell # Запуск теста с 1000 запросами и 100 параллельными пользователями ab -n 1000 -c 100 http://localhost:8080/ Пример нагрузочного тестирования с использованием Apache JMeter Рассмотрим более подробно пример проведения нагрузочного тестирования Java веб-приложения с использованием Apache JMeter. Установка Apache JMeter: Скачайте и установите Apache JMeter с официального сайта. Запустите JMeter, используя команду jmeter в командной строке. Создание тестового плана: Откройте JMeter и создайте новый тестовый план. Добавьте Thread Group (Группу потоков), которая определяет количество пользователей (потоков), период разгона и количество циклов. // Пример настройки Thread Group ThreadGroup threadGroup = new ThreadGroup(); threadGroup.setName("Example Thread Group"); threadGroup.setNumThreads(100); // Количество пользователей threadGroup.setRampUp(10); // Время разгона (в секундах) threadGroup.setLoopCount(1); // Количество циклов Добавление элементов к тестовому плану: Добавьте HTTP Request Sampler, чтобы определить запросы к вашему веб-приложению. Укажите сервер, путь и другие параметры запроса. // Пример настройки HTTP Request Sampler HTTPSampler httpSampler = new HTTPSampler(); httpSampler.setDomain("example.com"); httpSampler.setPort(80); httpSampler.setPath("/api/test"); httpSampler.setMethod("GET"); Добавление слушателей для анализа результатов: Добавьте View Results Tree и Summary Report для визуализации результатов тестирования. // Пример настройки View Results Tree ViewResultsTree resultsTree = new ViewResultsTree(); testPlan.add(resultsTree); // Пример настройки Summary Report SummaryReport summaryReport = new SummaryReport(); testPlan.add(summaryReport); Запуск теста и анализ результатов: Запустите тестовый план и проанализируйте результаты, чтобы определить узкие места и потенциальные точки отказа. // Запуск теста JMeterEngine jmeterEngine = new StandardJMeterEngine(); jmeterEngine.configure(testPlan); jmeterEngine.run(); // Анализ результатов for (SampleResult result : resultsTree.getResults()) { System.out.println("Response time: " + result.getTime()); System.out.println("Response code: " + result.getResponseCode()); } Преобразование нагрузки в RPS вместо количества пользователей Если тестовый план выполняет запросы к адресам параллельно, нагрузка на каждый адрес может разниться. Для такого случая удобнее перевести нагрузку в RPS и указывать лишь общую подаваемую нагрузку, выраженную в количестве запросах в секунду. Порядок действий: В Apache Jmeter кликнуть на корневой элемент с тестовым планом. Добавить новую переменную load_msg_sec (наименование переменной может быть любым). В качестве значения переменной можно установить как константное значение, так и параметризованное. Рассмотрим параметризованное. Для того чтобы добавить параметризованное значение нужно в столбце value добавить следующее: ${__P(load, 50)} , где load - наименование параметра. 50 - значение по умолчанию. Далее в группу потока (Thread group) нужно добавить Constant Throughput Timer (RBM - Add - Timer - Constant Throughput Timer) В поле Target throughput (in samples per minute) указывается следующая формула: ${__jexl3(${load_msg_sec} *60 * #percent#)}, где ${load_msg_sec} - количество запросов в секунду из переменной load_msg_sec, 60 - перевод из запросов в секунду в запросы в минуту (поскольку таймер принимает количество запросов в минуту), #percent# - процент от общего количества запросов (при проведении теста параллельно по всем адресам) указывается на основе методики нагрузочного тестирования. Указание basic auth в Apache JMeter Если нужно выполнить нагрузку на тестовых стендах, которые обычно закрыты Basic Auth, обычный запуск теста приведет к перманентным ответам с http кодом 403. Чтобы это исправить, нужно выполнить следующие действия. К группе потоков (Thread Group) добавляется BeanShell PreProcessor (RBM - add - Pre Processors - BeanShell PreProcessor) со следующим кодом: import org.apache.commons.codec.binary.Base64; byte[] encodedUsernamePassword = Base64.encodeBase64("login:password".getBytes()); vars.put("base64HeaderValue",new String(encodedUsernamePassword)); К этой же группе потоков добавить HTTP Header Manager c заголовком Name: Authorization Value: Basic ${base64HeaderValue}, где ${base64HeaderValue} - переменная назначенная в препроцессоре Лучшие практики нагрузочного тестирования Реалистичные сценарии: Тестовые сценарии должны максимально точно отражать реальные условия использования приложения. Это позволяет более точно прогнозировать его поведение при эксплуатации и заранее выявлять потенциальные проблемы. Мониторинг и анализ: Во время проведения тестов важно использовать инструменты мониторинга, которые помогут отслеживать состояние системы и своевременно реагировать на возможные проблемы. Анализ данных позволяет выявить узкие места и оптимизировать систему для улучшения производительности. Регулярность тестирования: Нагрузочные тесты должны проводиться на постоянной основе, особенно после внесения значительных изменений в код или инфраструктуру. Это позволяет своевременно обнаруживать проблемы и поддерживать стабильную работу приложения. Интеграция с CI/CD: Включение нагрузочного тестирования в процессы непрерывной интеграции и доставки (CI/CD) обеспечивает автоматическую проверку производительности после каждого изменения в коде, что позволяет избегать введения проблем с производительностью в рабочую среду. Комбинирование инструментов: Использование нескольких инструментов для нагрузочного тестирования позволяет получить более полное представление о производительности приложения. Это помогает выявить различные аспекты поведения системы под нагрузкой и предложить более комплексные решения. Многоуровневое тестирование: Проведение тестов при различных уровнях нагрузки — от минимального до предельного — позволяет лучше понять, как приложение ведет себя в разных условиях, и выявить его пределы. Документирование и отчеты: Ведение детальной документации результатов тестирования и создание отчетов позволяют анализировать проделанную работу, выявлять тенденции и планировать дальнейшие улучшения. Оптимизация и настройка: После проведения тестов необходимо проводить оптимизацию системы, основываясь на полученных результатах. Это может включать в себя настройку серверов, оптимизацию запросов к базе данных и улучшение самого кода приложения. Сотрудничество с командой: Постоянное взаимодействие с командой разработки и другими заинтересованными сторонами способствует оперативному решению выявленных проблем и повышению качества продукта. Вывод Нагрузочное тестирование — важный этап в разработке и поддержке Java веб-приложений, который позволяет обеспечить их надежную и эффективную работу при различных уровнях нагрузки. Использование инструментов, таких как Apache JMeter, Gatling, Locust и Apache Benchmark, в сочетании с лучшими практиками тестирования, помогает выявить и устранить узкие места в системе, что позволяет поддерживать высокую производительность и стабильность работы приложений. В компании «Цифровой элемент» мы регулярно проводим нагрузочное тестирование для крупных и сложных проектов, гарантируя их стабильность и высокую производительность даже в условиях значительных нагрузок. Наша команда включает в себя опытных специалистов, которые глубоко понимают все аспекты процесса тестирования — от разработки реалистичных сценариев до анализа результатов и оптимизации системы. Для удобства мы разработали четкие процессы, позволяющие нам интегрировать нагрузочное тестирование в общую цепочку разработки и доставки программного обеспечения. Если вам необходимо провести нагрузочное тестирование вашего веб-приложения, мы готовы предложить вам полный спектр услуг — от анализа текущей производительности до разработки и реализации рекомендаций по её улучшению. Обращайтесь к нам, и мы поможем вам достичь наилучших результатов, обеспечив надежную работу вашего приложения при любых нагрузках. Пример протокола нагрузочного тестирования веб-приложения или сайта Документ описывает результаты проведения нагрузочного тестирования системы. Объект испытаний Объектом испытаний нагрузочного тестирования является система. Цели испытаний Проверка соответствия разработанной системы предъявляемым требованиям. Определение максимальной и пиковой производительности системы. Проверка стабильности работы разработанной системы в течение длительного промежутка времени под нагрузкой. Базовый профиль Базовый профиль тестирования подразумевает собой набор исследуемых объектов. Количество запросов рассчитано на основе требований к производительности системы и предполагаемого базового пользовательского пути. Код Требование Значение 1 Общее количество запросов к системе в месяц 30 000 000 2 Пиковое количество запросов в месяц не менее 3 300 000 3 Пиковое количество запросов в неделю не менее 900 000 4 Пиковое количество запросов в день не менее 110 000 5 Количество пользователей в месяц 300 000 6 Количество пользователей в неделю 60 000 7 Количество пользователей в день 10 000 Расчетное количество запросов в час берется равным, исходя из расчета максимального количества запросов: N запросов/ч = 30 000 000 / 30 / 24 = 41666.(6) ~= 42 000 запросов в час На основе CJM (Customer journey map) выделяются объекты образующие основную нагрузку: Объект URI Процент запросов в час Количество запросов в час Название объекта / 27% 11 340 Название объекта /…/ 15% 6 300 Название объекта /…/ 11% 4 620 Название объекта /…/ 5% 2 100 Название объекта /…/ 16% 6 720 Название объекта /…/ 5% 2 100 Название объекта /…/ 6% 2 520 Название объекта /…/ 15% 6 300 Нагрузку на объекты распределили пропорционально целевой аудитории. Запросы распределяются равномерно в течении часа, что дает общее количество запросов в секунду N запросов/cек = 42 000 / 60 / 60 = 11,(6) ~= 12 запросов в секунду План тестирования План тестирования представляет из себя следующие пункты: Разработка профиля нагрузочного тестирования; Настройка систем мониторинга; Разработка скриптов генерации нагрузки; Подготовка тестовых данных (например, вариации значения поисковой строки) + скрипт наполнения базы тестовыми данными для теста и их удаления по завершению; Проведение нагрузочных тестов; Анализ результатов нагрузочных тестов. Типы проводимых тестов Методикой предусматривается проведение следующих тестов: Поиск пиковой производительности Нагрузка: ступенчатая Начальная нагрузка: 40% Шаг: + 30% от базового профиля Продолжительность ступени: 30 минут или отказ Системы Критерий завершения теста: отказ Системы Критерий успешности теста: максимальная производительность системы выше значений базового профиля. Проверка стабильности работы системы Нагрузка: равномерная с плавным разгоном Максимальная нагрузка: Базовый профиль Время разгона: 15 мин. Длительность основного этапа - 4 часа Критерий завершения теста: истечение времени или Отказ Системы Критерий успешности: окончание по истечении времени Требования к производительности системы Требования к утилизации ресурсов во время тестов Утилизация ресурсов севера должна соответствовать следующим показателям: Утилизация CPU не более 80%; Утилизация RAM не более 80%. Требование сформировано на основании экспертной оценки, требований к Системе не предъявлено. Требования к количеству неуспешных запросов Количество Неуспешных запросов не должно превышать следующие показатели от интенсивности входящей нагрузки: Тест поиска максимальной производительности (последняя ступень) – 0,1%; Тест подтверждения максимальной производительности (в ходе всего теста)– 0,1%; Тест стабильности (в ходе всего теста)– 0,1% Период агрегации соответствует периоду постоянной нагрузки в каждом из тестов. Требования ко времени отклика и интенсивности типовых шагов бизнес операций 90% — 50 мс, 99% — 1000 мс, 99,9% — 2500 мс, Конфигурация стенда для НТ Компонент Значение CPU Cores (количество ядер) XX RAM (Размер ОЗУ в Гб) XXX Поиск максимальной производительности Максимальная производительность - нагрузка, выраженная в количестве обращений в секунду, превышающие границы утилизации ресурсов, описанных в разделе “Требования по утилизации ресурсов” настоящего документа.. Поиск максимальной производительности проводится в рамках нескольких тестов с пошаговым увеличением нагрузки относительно базового профиля. Шаг рассчитывается как: Шаг = Значение базового профиля * 0,4 = 4.8 => 5 - значение шага для увеличения нагрузки Продолжительность шага составляет 30 минут Первый шаг RPS CPU RAM Average (response, ms) Min (response, ms) Max (response, ms) Error % Результат 12 q/s 31,5% 6% 853 342 2332 0,01% Соответствует График результатов теста из jMeter График использования ЦПУ (Grafana) График использования ОЗУ Второй шаг RPS CPU RAM Average (response, ms) Min (response, ms) Max (response, ms) Error % Результат 17 q/s 44,8% 6% 823 339 3132 0,00% Соответствует График результатов теста из jMeter График использования ЦПУ (Grafana) График использования ОЗУ Третий шаг RPS CPU RAM Average (response, ms) Min (response, ms) Max (response, ms) Error % Результат 22 q/s 58,6% 6% 851 353 2041 0,00% Соответствует График результатов теста из jMeter График использования ЦПУ (Grafana) График использования ОЗУ Четвертый шаг RPS CPU RAM Average (response, ms) Min (response, ms) Max (response, ms) Error % Результат 27 q/s 73,6% 7% 841 337 2652 0,00% Соответствует График результатов теста из jMeter График использования ЦПУ (Grafana) График использования ОЗУ Пятый шаг RPS CPU RAM Average (response, ms) Min (response, ms) Max (response, ms) Error % Результат 32 q/s 88,0% 7% 764 342 2332 0,00% Значение CPU превышает допустимый порог, при этом процент отказа равен 0. Определяем производительность как максимальную График результатов теста из jMeter График использования ЦПУ (Grafana) График использования ОЗУ Вывод Максимальная производительность системы после проведенного теста на поиск составляет XXX запросов в секунду, что больше чем ожидаемая нагрузка на XXXX%. Система удовлетворяет описанным показателям производительности. Тест на стабильность системы Тест на стабильность выполняется с нагрузкой базового профиля продолжительное время. Время теста составляет 4 часа. RPS CPU RAM Average (response, ms) Min (response, ms) Max (response, ms) Error % Результат 12 q/s 33,6% 7% 503 343 4116 0,00% Соответствует График результатов теста из jMeter График использования ЦПУ (Grafana) График использования ОЗУ Вывод На протяжении 4 часов тестирования стабильности системы процент отказа составил 0%, нагрузка равномерно распределена. Система удовлетворяет описанным показателям производительности.

Сегодня атаки злоумышленников и вредоносные программы стали неотъемлемой частью нашей повседневной жизни, а обеспечение безопасности данных и персональной информации становится приоритетом высшего порядка. Содержание Кто зарабатывает на вирусах? Взлом сайта Аудит безопасноти Как защититься от взлома? Вирус или взлом Вывод Кто зарабатывает на вирусах? Большинство считает, что заражение видно сразу – на главной странице появится баннер или начнёт всплывать навязчивая реклама. На самом деле, вирус может действовать незаметно. Сначала на ваш сайт загружается скрипт, который собственно и представляет собой «троян». Этот скрипт будет выполняет команды злоумышленника. Зачастую, внедрение вируса происходит не адресно – хакеры просто ищут уязвимости на сайте, а затем выставляют на форум, продавая уязвимость и скрипт, который там установлен.  Тот, кто приобрел эту уязвимость, начинает вставлять в код ссылки разных типов: для продвижения продукта или услуги; для переадресации пользователей на другой сайт (часто фишинговый); для получения личных данных пользователей. Цифровой Элемент предлагает комплексные решения для обеспечения безопасности вашего сайта, включая как реагирование на атаки и восстановление после них, так и проактивные меры, такие как организация защиты, аудит безопасности и проверка на вирусы, а также выявление внедрений постороннего кода. Взлом сайта Специалисты Цифрового Элемента всегда готова помочь клиентам, которые обеспокоены безопасностью своих сайтов и веб-сервисов. Мы регулярно проводим аудит безопасности инфраструктуры клиентов, выявляем вредоносный код и избавляемся от него, если он был найден. Как ломают сайт Процедура взлома состоит обычно из двух частей: Загрузка вредоносного кода в файлы сайта, при этом этот вредоносный код хорошо маскируется под ту платформу, на которой сделан сайт. Неопытному разработчику определить такой код очень трудно.  А далее происходит собственно атака - это может быть добавление на страницы сайта редиректов на другой сайт, размещение противоправного контента, или же размещение шлюза для атак на другие сайты или рассылку спама. Летом 2023 года мы уже писали о массовых атаках на сайты, разработанные на платформе 1С-Битрикс, и о том, как защититься от таких атак. Почему это происходит? Виртуальный хостинг. Низкая цена и отсутствие необходимости хранить данные на физическом жестком диске привлекает к выбору такого хостинга для проекта. Но он не предоставляет изоляцию данных клиентов – взлом одного сайта на таком хостинге ведёт к взлому соседних с ним. Проблема в том, что обеспечивать безопасность такого хостинга слишком дорого, поэтому этого не делается.  А иногда и взлома не надо – достаточно зарегистрировать тестовый аккаунт и можно получить доступ к администрированию соседних сайтов, а также полностью управлять их базой данных, загрузив такой скрипт и запустив его в браузере. Администрация хостингов реагирует на жалобы и устраняет уязвимости. Но таких прорех в их работе очень много. Поэтому шансов дать полный доступ к своему сайту злоумышленнику велик, если используется виртуальный хостинг. Старое ПО. Очень часто на этом же виртуальном хостинге (и не только) можно получить доступ к программному обеспечению (FCKeditor, joomla и пр.). Новые версии программного обеспечения учитывают опасности взлома и уязвимости в них устранены. Но тут работает психологический момент – если программа автоматически не обновляется сама, то её зачастую не обновляют. А мануалов по тому, как взломать старую версию на форумах хакеров очень много.  Мы недавно как раз писали о том, как важно обновлять программное обеспечение, а особенно платформу, на которой разработан сайт. Как сертифицированный разработчик на 1С-Битрикс специалисты Цифрового Элемента подготовили чеклист частых ошибок при переводе сайта с php 7.x на php 8.x. Заражение компьютера. Иногда заражается локальный компьютер на операционной системе семейства Windows. И тогда злоумышленник получает доступ к сохраненным паролям браузера.  Ненадёжные пароли. Собственно, сами пароли не всегда бывают надежны. Например, “111111” или “123456” и т.д. И многие ещё выключают у группы администраторов капчу.  Человеческий фактор. Ну и не будем сбрасывать со счетов человеческий фактор. В попытках экономии компании часто выбирают разработчиков по принципу – дешевле, быстрее и дают доступы к сайту непроверенным специалистам. Какой-нибудь обиженный или просто недобросовестный исполнитель на разовой работе может оставить на сайте трояны.  Кто ломает сайты? Среди хакеров на самом деле мало тех, кто способен взломать сайт. Чаще используются уже готовые инструкции и скрипты, написанные опытными взломщиками. Доказательством этого утверждения служит то, что сайты ломают одинаково.  С одной стороны это свидетельствует, что есть группа людей, любящих ломать, а с другой – что есть возможность принять простые меры по защите сайта. Аудит безопасности Современные киберпреступники постоянно ищут новые способы проникновения на сайт, используя различные методы взлома сайтов. Особенно часто хакеры эксплуатируют уязвимости CMS и веб-уязвимости для получения доступа к базе данных или взлома админ панели. Один из эффективных способов защиты своего сайта – проведение аудита безопасности. Поэтому давайте рассмотрим, как проходит это мероприятие. Тестирование на проникновение Чаще всего проверка защищенности ресурса проводится по методу «черного ящика» — специалист по безопасности начинает попытки взлома своей цели, как если бы он был реальным злоумышленником и преследовал какую-либо корыстную цель: хакнуть конкурента, атаковать посетителей сайта, в тайне от владельца монетизировать сайт или просто потешить свое честолюбие. Таким образом, специалист должен решить хотя бы одну из глобальных задач: Нарушить конфиденциальность информации заказчика. Ограничить доступ к ключевым данным. Изменить или уничтожить какие-либо сведения без возможности их восстановления. Внедрить вредоносный код. Как видно из этого перечня, нельзя просто так взять и провести аудит сайта. Нужна определенная подготовка к процедуре, без которого оно либо будет неэффективно, либо может стать настоящей хакерской атакой с печальными последствиями. Базово, следует сделать следующее: Подписание соглашения о неразглашении. Исследователь в ходе своей работы может получить доступ к очень ценной конфиденциальной информации. Солидные организации, занимающиеся тестированием безопасности, вряд ли будут пользоваться ею в своих целях, но не всегда есть возможность проверить честность исполнителя, поэтому договор лучше заключить. Проведение аудита на полной копии основного сайта. Тестировщик будет применять все методы хакеров, в том числе и приводящие к поломке веб-ресурса либо уничтожению данных на нем. Лучше не подвергать боевую версию проекта такому стрессу и ограничиться тестовой копией вашего сайта. Выбирать проверенного подрядчика с уже наработанной экспертизой в подобных тестах.  Digital-интегратор Цифровой элемент обладает всеми необходимыми компетенциями. Мы предоставляем комплексные решения для обеспечения безопасности вашего веб-сайта, которые включают в себя не только реакцию на атаки и восстановление после них, но и принятие проактивных мер, такие как организация защиты, аудит безопасности и проверка на вирусы, а также выявление внедрений постороннего кода. Методы тестирования на проникновение Поиск по открытым источникам. Так как используется способ «черного ящика», то тестировщик абсолютно не в курсе, как выглядит атакуемый объект изнутри, иначе взлом был бы крайне тривиальной задачей. Поэтому в ход идет предварительный сбор информации. Специалиста в первую очередь интересует техническая сторона веб-приложения – на каком языке оно написано, какую CMS использует и с какими расширениями. Узнать все это можно даже не прибегая к специальным средствам, иногда хватит только Google. Например, можно найти в LinkedIn сотрудников атакуемой компании, выделить среди них программистов и определить, на каком стеке они специализируются. Более того, при желании можно выяснить, и чем конкретно они занимались. Для этого достаточно поискать по их именам или никнеймам, и можно найти в выдаче много чего интересного. Это может быть, например, обсуждение от имени этого программиста какого-либо модуля для движка или заказ с корпоративного аккаунта у фрилансера-подрядчика нового плагина с подробным ТЗ. Определение защитных средств. Наличие какого-либо софта для безопасности – систем предотвращения вторжения, защиты от DDoS, межсетевого экрана — может серьезно усложнить задачу по взлому, поэтому его необходимо обнаружить. Обычно для этого применяются специальные программы. К примеру, обнаружить наличие фаервола можно с помощью сканера портов, а антиддос-сервисы определяются по DNS-записям домена. Использование стандартных уязвимостей. Прежде чем начинать искать неизвестные уязвимости нулевого дня, изучать логику работы веб-приложения и его архитектуру, тестировщик проверяет устойчивость сайта к обычным методам атаки. Например, это может быть использование известного эксплойта к старой версии движка. Именно на этом этапе и пострадали вышеупомянутые Interpark и форум Ubuntu. В общем виде на этом этапе обычно происходит следующее: Попытка удаленного выполнения кода. Попытка SQL-инъекции. Эксплуатирование XSS, RFI и LFI уязвимостей. Поиск мест хранения backup-ов и получение доступа к ним. Манипуляции с системой авторизации: брутфорс, поиск небезопасного восстановления пароля, обход аутентификации. Изучение файловой структуры сайта с целью обнаружения файлов, доступ к которым ограничен только отсутствием явной ссылки на него. Перехват трафика и его исследование. Поиск вариантов несанкционированного доступа к конфиденциальной информации. Нешаблонный подход Когда общеизвестные методы не помогают, специалист по безопасности с помощью комбинации всех вышеописанных способов и своего понимания систем безопасности пытается обойти существующую защиту, либо обнаружить неизвестную до сих пор уязвимость. Далеко не все аудиторы проводят данную процедуру, т.к. она достаточно сложна, требует очень высокой квалификации специалистов и стоит немало. Как показывает практика, очень часто уязвимости нулевого дня обнаруживаются сторонними исследователями. Однако и вознаграждение за их находку они получают соответствующее. На самом деле, если ваш сайт успешно проходит тестирование на все стандартные виды угроз, то проверку можно считать успешной. Более детальное и глубокое изучение методов взлома актуального только для очень крупных проектов, для взлома которых могут привлекать действительно высококлассных хакеров, способных обнаруживать новые бреши в защите. Как защититься от взлома? К сожалению, на обычном виртуальном хостинге рядовые пользователи не могут самостоятельно обеспечить защиту данных. Единственная доступная возможность – вовремя сообщить об уязвимости, чтобы администрация хостера приняла меры. Наши советы: Используйте только случайно сгенерированные пароли из набора символов в разных регистрах, цифр и спецсимволов длиной не менее 8 символов. Создавайте разные аккаунты для разных сайтов, систем, сервисов. Установите двухфакторную авторизацию там, где это возможно. Проверьте, чтобы учетные данные ваших сайтов, доменов, сервисов и так далее имеются у вас. Проверьте, чтобы домен сайта и хостинг был зарегистрирован на вас или вашу компанию во избежания хи потери. Обязательно побеспокойтесь о том, чтобы у вас регулярно создавались резервные копии ваших сайтов с различной глубиной - сутки, недели, месяцы. Откажитесь от услуг фрилансеров или неконтролируемой передачи различных учетных данных. Работайте только с проверенными и надежными контрагентами, бизнес-процессы которых настроены таким образом, что утечка данных сводится к минимуму. Специалисты компании Цифровой Элемент обладают большим опытом и высокой глубокой экспертизой в современных методах угроз и методах защиты, помогут защитить ваш сайт, ваши данные и данные ваших пользователей. Вирус или взлом Для большинства владельцев сайтов нет разницы между взломом сайта и заражением его вирусом. Однако это разные вещи.  Вирус изначально живет на вашем компьютере и использует ваши пароли, чтобы заменить файлы на сайте по прописанному скрипту. Хакер же действует более аккуратно и имеет точечную конкретную цель. С вирусом можно бороться: вылечить компьютер; удалить вирус с сайта или восстановить старую, не зараженную версию.  С хакером бороться сложнее – сначала надо понять, как злоумышленник попал на сайт, при этом зачастую точек доступа бывает несколько.  Впрочем, главное понимать – зачастую хакер использует уязвимости, которые создал вирус, поэтому нужно заботиться о чистоте своего компьютера, обновлять антивирус.  Вывод Ваш сайт — это ваш актив, ключевой инструмент вашего присутствия в интернете, предоставляющий множество возможностей для привлечения клиентов и продвижения вашего бренда. Однако, несмотря на все преимущества онлайн-пространства, полная гарантия защиты в интернете отсутствует. Сегодняшние вирусы, с которыми успешно справляются специалисты, могут изменяться, требуя постоянного поиска новых методов и инструментов для их выявления и устранения. Если у вас есть опасения относительно безопасности вашего сайта или данных, обратитесь к нам в Цифровой Элемент. Наши специалисты обладают высокой квалификацией для решения задач информационной безопасности. Услуга на Сопровождение и развития сайта Заказать услугу

Что такое инклюзивный дизайн сайта и на кого он ориентирован? Зачем нужна инклюзивность и какие параметры надо учитывать при создании цифрового проекта с универсальным дизайном? Подробности – в нашем материале. Содержание Что такое инклюзивный дизайн Сценарии ограничений Кому нужна инклюзивность Приемы универсального дизайна: визуальная доступность аудиодоступность доступный функционал Нормативные документы Вывод Что такое инклюзивный дизайн Дизайн, построенный на принципах инклюзивности (вовлеченности), должен учитывать особенности людей с временными или постоянными физическими ограничениями по здоровью, а также потребности обычных пользователей.  Главные принципы инклюзивности:  понятность – интерфейс и контент должны быть понятны всем пользователям. в том числе людям с инвалидностью; воспринимаемость – у пользователей должна быть возможность воспринимать контент удобным для них способом; управляемость – необходимо, чтобы управлять интерфейсом могли люди с ограничениями любого рода; надежность – интерфейс должен быть доступным при изменении операционной системы и версий цифрового продукта. Универсальный дизайн устраняет проблемы, которые мешают полноценно пользоваться веб-продуктом. За design-инклюзивность отвечают дизайнеры, разработчики, менеджеры. Сценарии ограничений Гайдлайн «Сбер» разделяет все ограничения на ситуативные, временные и постоянные. Так, если пользователь полностью лишен слуха или зрения – это постоянное ограничение. Если у человека заболевание, которое можно вылечить (травма глаза, воспаление уха, рука в гипсе и т.д.) – это временное ограничение. Ситуативные барьеры – например, человек находится в помещении с высоким уровнем шума, или за рулем автомобиля, или держит ребенка на руках и т.п. Дизайн в инклюзивном образовании должен учитывать все возможные препятствия для пользователей интернета. Сценарии ограничений по гайдлайну «Сбер» С какими проблемами сталкиваются люди, переживающие тот или иной сценарий ограничения? Основные препятствия для доступного взаимодействия с сайтом или приложением: Визуальные: нечитабельный шрифт, несоблюдение стандартов контрастности; сложный текст; неправильный межстрочный интервал; неструктурированные страницы и т.п. Слуховые: отсутствие скринридера – программы, которая переводит тексты в голосовые сообщения; отсутствие транскрипта – текстовой расшифровки видеоряда.  Технические: тяжелые и не адаптированные под разные носители сайты; проблемы с управлением интерфейсом и др.  Языковые барьеры, когда не учитывается геолокация и нет перевода страниц на язык местной аудитории. Возрастные и социальные ограничения: так, пенсионерам и людям с начальной компьютерной грамотностью трудно пользоваться приложениями со сложной навигацией и многое другое. Чем больше сценариев, мешающих доступности веб-проекта, вы проработаете, тем шире будет ваша аудитория. Подробно о методах design инклюзивности мы расскажем ниже. Помните, главная задача инклюзивного дизайна – создавать универсальный продукт, одинаково удобный для большинства пользователей. В процессе разработки наших решений, будь то веб-разработка или разработка мобильных приложений, мы всегда учитываем принципы инклюзивности. Ключевая задача инклюзивного дизайна – создавать универсальный продукт, удобный для широкого круга пользователей.    Кому нужна инклюзивность Не учитывать принципы инклюзивности при создании сайтов и приложений – значит игнорировать интересы немалого сегмента аудитории.  По данным ФРИ (Федерального реестра инвалидов), количество взрослых людей с ограниченными возможностями по здоровью в России в 2023 году составило более 10,2 млн граждан. Из них – инвалидов по зрению почти 500 тысяч. Также за последние годы выросло число пожилой аудитории цифрового пространства, особенно с появлением мобильных телефонов. Как сообщает Коммерсантъ, в 2021 году доля интернет-пользователей 55–64 лет увеличилась по сравнению с 2019 годом с 67 % до 81 %, в возрасте 65–74 лет – с 39 % до 53 %.  Сайты и приложения с доступным для восприятия дизайном положительно оценивают не только люди с проблемами по здоровью, но и обычные пользователи. А это многомиллиардная аудитория. Сегодня в мире насчитывается 5,44 млрд людей, которые пользуются мобильными телефонами, и 5,16 миллиардов имеют доступ в интернет, передает Global Digital 2023. Игнорировать требования инклюзивного дизайна – значит терять большой сегмент аудитории. Приемы универсального дизайна Выше мы назвали основные принципы инклюзивности: веб-продукт должен быть понятным, воспринимаемым, управляемым и надежным. Как достичь этого?  Инклюзивность включают множество параметров, которые необходимо учитывать при создании универсального дизайна веб-проектов. Все приемы инклюзивности можно разделить на три направления: визуальная, аудио- и функциональная доступность.  Все приемы инклюзивности сводятся к трем основным: визуальная, аудио- и функциональная доступность. Визуальная доступность Текст, размещенный на страницах сайта или приложения, должны легко читать не только люди с ослабленным зрением, но и пользователи без офтальмологических нарушений. С какими проблемами сталкиваются чаще всего? Неправильно выбранный шрифт Размеры шрифтов, которые желательно использовать для инклюзивного дизайна, трудно указать точно, так как в разных шрифтах при одинаковом кегле они будут отличаться. Например, шрифт Arial с кеглем 11 выглядит крупнее, чем шрифт Calibri 11. Поэтому размерность необходимо определять, исходя из вида шрифта.  При этом гайдлайны по доступности веб-проектов дают четкие указания. «Сбер», например, рекомендует использовать для основного текста шрифт размером не меньше 16 пикселей, а международные стандарты доступности WCAG указывают параметры минимального интерлиньяжа (расстояние между строками текста по вертикали) – выбранный кегль нужно увеличить не менее, чем в полтора раза (умножить на 1,5).  Кроме того, у интернет-пользователей есть возможность самостоятельно масштабировать текст с помощью комбинации клавиш Ctrl +-. Здесь важно, чтобы сайт/приложение имели адаптивную верстку и читателю не пришлось скроллить (прокручивать) текст по горизонтали. Декоративные (акцидентные) шрифты, несомненно, украшают дизайн, но совсем непригодны для чтения. Поэтому для текстов в электронных проектах их лучше не использовать, или применять выборочно, например, в заглавных буквах, когда нужно привлечь внимание или структурировать текст. Декоративные шрифты сложно воспринимать не только людям с дислексией (нарушениями в восприятии письменной речи), но и обычным пользователям. Мелкие и декоративные шрифты не стоит употреблять в электронных текстах. Контрастность По стандартам WCAG нормы контрастности между передним планом и фоном для текста, заголовков и изображений предлагаются следующие: Для основного текста хороший контраст – 7:1 и выше, приемлемый – 4,5:1 и выше. Для заголовков хороший контраст – 4,5:1 и выше, приемлемый – 3:1 и выше. Для изображений (иконок, логотипов, иллюстраций) рекомендуется использовать контраст 3:1. Параметры контрастности для текста и заголовков по WCAG, Skillbox Media Пример контрастности текста Высокая контрастность изображения Низкая контрастность изображения Оценить соответствие вашего сайта стандартам контрастности можно с помощью сервисов Coolors или WebAIM.  Цвет Выделяя цветом важные моменты в интерфейсе, помните, что есть люди, которые не различают цветовые оттенки. Для фиксирования какой-либо ошибки обычно используют красный цвет. Например, пользователь ввел неправильный пароль и рамка сразу окрашивается в красный цвет. Но люди-дальтоники этого не видят, поэтому ошибочные действия необходимо обозначать не только цветом, но и прописывать текстом. В нашем примере должна появиться надпись: «Неверный пароль».  Сложный текст В текстах используйте простые предложения, не злоупотребляйте сложноподчиненными и сложносочиненными конструкциями, профессиональными терминами. Так, людям с дислексией сложно воспринимать причастные и деепричастные обороты. Лексика должна быть понятной. В основном, эти требования выдвигаются к проектам, ориентированным на широкого потребителя. Если площадка адресована узко направленной аудитории, например, сайт для строителей или IT-специалистов, то без профессиональной терминологии не обойтись. Чтобы расширить круг читателей, делайте расшифровки особо сложных понятий. Лаконичные тексты удобно читать не только пользователям, но и экранным дикторам (скринридерам), о которых расскажем далее.  Людям с дислексией (нарушениями в восприятии письменной речи) трудно воспринимать сложные предложения. Неструктурированные страницы Неструктурированные страницы ухудшают восприятие материала.  Гайдлайн Google советует группировать смысловые блоки. Не стоит в угоду дизайнерским изыскам дробить связанные элементы. Например, начало абзаца разместить в верхней части страницы, а конец – далеко внизу. Такой разорванный текст читать неудобно.  Общие приемы структурирования известны: в повествовании должна быть логика, необходимо делить текст на абзацы, выделять заголовки и подзаголовки, применять жирный шрифт, маркированные и нумерованные списки и т.д. Межстрочный интервал Здесь важно соблюсти баланс. Если сделать маленький интервал, то строки сольются, если интерлиньяж будет большой, то текст распадется. И в том и другом случае читать неудобно.  Оптимальным размером интервала считается величина от 120 до 160 %: например, если для текста выбран кегль 10, то межстрочный интервал должен быть в пределах – 12-16 пунктов. Как правило, дизайнеры экспериментируют с интерлиньяжем, главное, при создании красивого дизайна не забывать об удобстве для читателей.   Транскрипты видеороликов Наличие транскриптов (титров) с расшифровкой видео- и аудиороликов помогает людям с врожденными и приобретенными нарушениями слуха. Также данная опция востребована в ситуативных ограничениях. Допустим, человек временно находится в помещении с высоким уровнем шума (промышленный цех) или, наоборот, в помещении, где нельзя шуметь (библиотека). Если наушников нет, то в этой ситуации поможет текстовое дублирование видеоряда.  Транскрипты с расшифровкой видео- и аудиороликов помогают людям с нарушениями слуха и в ситуативных ограничениях. Иллюстрация звуковых сигналов Звуковые сигналы, которые извещают, например, о приходе письма на почту или проведении платежа, должны визуализироваться. Причем сообщение должно отображаться на экране достаточно по времени, чтобы пользователь успел прочитать полученное уведомление. Хронометраж зависит от объема сообщения. Для короткого  текста хватит 1-2-х секунд, для длинного послания потребуется больше времени. Но помните, что «зависающие надолго» всплывающие окна могут помешать усвоению контента страницы, поэтому здесь важно соблюдать баланс.  Активная анимация Не стоит злоупотреблять активной анимацией. Слишком быстрое мелькание картинок вызывает раздражение у большинства пользователей, а у людей с эпилепсией может спровоцировать приступ. WCAG предусмотрел возможность отключения анимации, которая не имеет значения для понимания контента. Google рекомендует отключать анимацию автоматически через 5 секунд после начала просмотра страницы. Если смена слайдов необходима, то стоит ограничить мигание до трех кадров в секунду.  Активная анимация вызывает раздражение у большинства пользователей. Адаптивность Веб-продукт должен корректно отображаться на всех устройствах. Сайты, созданные для десктопных устройств и не адаптированные для просмотра на маленьких экранах телефонов и планшетов, будут создавать проблемы для пользователей.  Главные минусы отсутствия адаптивной верстки:  мелкий шрифт;  некорректная масштабируемость, например, при увеличении текста со 100 % до 200 %, он будет выходить за края экрана; чтобы посмотреть масштабированный текст придется скроллить (прокручивать) его по горизонтали; долгая загрузка из-за тяжелого веса сайта и т.д.  Проверить адаптивность веб-проекта можно с помощью специальных сервисов: Google Mobile-Friendly Test, Window Resizer, Adaptivator и др. Пример адаптивной страницы после увеличения масштаба Аудиодоступность Скринридеры (электронный диктор) Скринридеры созданы для людей с нарушениями зрения. Программы зачитывают вслух текст на экране. Чтобы опция работала корректно, необходимо сотрудничество дизайнера и разработчика. Типы элементов (кнопки, заголовки, изображения) должны быть прописаны в коде и нести информацию. Незрячий человек должен слышать, что изображено на фотографии или написано на иконке. Скринридеры (электронные дикторы) жизненно необходимы людям с нарушениями зрения. К иллюстрациям надо добавлять альтернативное словесное описание с помощью атрибута Alt, для иконок – достаточно обычного текстового описания, без использования Alt атрибута. Скринридер зачитывает названия всех элементов. Если стоит кнопка или заголовок, то необходимо подписать их соответствующим образом: «Кнопка», «Заголовок». Во время использования скринридера желательно отключать всплывающие окна, так как электронный диктор плохо реагирует на них и может ввести пользователя в заблуждение. Составляя тексты для страниц, следите за языковой раскладкой на клавиатуре. Буква С выглядит одинаково в английском и русском языке, но звучит по-разному. Если в русском тексте вы случайно написали С латиницей, то диктор озвучит ее, как «си», что может запутать слушателя. При использовании скринридера людям приходится слушать большие объемы информации, поэтому полезно сокращать тексты и писать краткие формулировки. Например, лучше написать «Заказать», а не «Оформить заказ», или «Корзина», а не «Перейти в корзину» и тому подобное. Декоративные элементы, которые не несут важной смысловой нагрузки, лучше не описывать, чтобы упростить подачу. Примеры альтернативного описания изображений Функциональная доступность Многообразие управления Инклюзивный проект предоставляет пользователям многообразие управления интерфейсом. В помощь различные опции: использование стандартной или брайлевской клавиатуры (для незрячих людей); комбинации клавиш; голосовое управление; альтернативные контроллеры, например, мышка с дополнительными кнопками; включение каких-либо функций с помощью свайпов (жестов). Например, чтобы включить голосового ассистента на сенсорном смартфоне, нужно провести пальцем по экрану от левого нижнего угла по диагонали вверх. Кликабельность  Попасть в мелкую кнопку трудно не только людям с двигательными и зрительными нарушениями, но и обычным пользователям, поэтому кнопки должны быть правильных размеров. Гайдлайны «Сбер» и Google рекомендуют увеличивать кликабельные кнопки до размеров не меньше 44х44 пикселя, а также масштабировать расстояния между ними (не меньше 8 пикселей). Если рядом с крупными элементами соседствуют мелкие, например, знаки + и -, то расстояние между ними должно быть еще больше. Пространство вокруг кнопки и мелкого элемента тоже должно быть кликабельным, так как попасть прицельно в кнопку трудно большинству. Правильные размеры кликабельных кнопок и расстояний между ними Правильные размеры мелких элементов и расстояний между ними Пространство вокруг кнопки и мелкого элемента тоже должно быть кликабельным. Нормативные документы Мы отразили основные моменты инклюзивности, более подробно с требованиями к универсальному инклюзивному дизайну можно ознакомиться в гайдлайнах и нормативных актах по доступности веб-продуктов. Их несколько. В 2008 году были разработаны международные стандарты WCAG, где даются конкретные рекомендации, рассматриваются ошибки и предлагаются методы оценки доступности интернет-продукта.  Есть американский стандарт инклюзивности цифровых проектов для госучреждений. Статья 508 Закона о реабилитации рассказывает о требованиях к сайтам, приложениям и устройствам. Есть европейские стандарты – EN 301 549 (англоязычная версия). В России за создание доступной среды в интернете отвечает ГОСТ Р 52872-2019. Нормативный акт контролирует все цифровые проекты: сайты, приложения, digital программы, стриминговые сервисы (платформы с фильмами, сериалами, играми, телеканалами). В основу документа положены стандарты WCAG, также российский ГОСТ содержит положения и критерии оценки доступности веб-проектов. Многие крупные компании, такие как Google, Microsoft, «Сбер», понимая важность проблемы, создали подробные гайдлайны по созданию доступной среды в интернете. Соблюдение стандартов инклюзивности во всех случаях носит рекомендательный характер – владельцы сайтов и приложений сами решают следовать им или нет. Но, как мы говорили ранее, игнорировать требования универсального дизайна – значит терять большой сегмент аудитории. Поэтому сегодня все передовые компании создают цифровые площадки с учетом принципов инклюзивности. Сегодня все передовые компании создают цифровые площадки с учетом принципов инклюзивности. Вывод Сделать интернет-продукт доступным наибольшему числу пользователей – задача номер один для создателей digital-проектов. Чтобы добиться этого, следуйте основным принципам инклюзивности: контент и интерфейс цифровой площадки должны быть понятными, воспринимаемыми, управляемыми и надежными.  Учитывайте потребности пользователей любого уровня подготовки и физических возможностей. Соблюдайте стандарты доступности при выборе шрифтов, контрастности, межстрочного интервала, использовании анимации, скринридера, адаптируйте продукт, применяйте титры для видеороликов и так далее.  Чем больше ограничивающих сценариев вы проработаете, тем больше шансов повысить лояльность и численность вашей аудитории. Узнать о стандартах и методах инклюзивного дизайна можно в специальных нормативных документах или гайдлайнах по доступности веб-проектов.   Если вам трудно самостоятельно разобраться в теме инклюзивности, и вы не знаете, как сделать сайт или приложение, согласно стандартам доступности, обращайтесь к профессионалам. Специалисты digital-агентства «Цифровой элемент» разработают для вас веб-проект с учетом всех требований инклюзивного дизайна. Услуга на Веб-разработку Заказать услугу