В этой статье мы сегодня рассмотрим профессиональные советы по оптимизации безопасности вашего сайта и предотвращению хакерских атак.
Вы можете думать, что на вашем сайте нет ничего, ради чего стоит взламывать его, но сайты постоянно подвергаются взлому. Большинство нарушений безопасности веб-сайтов не связаны с тем, чтобы украсть ваши данные или испортить макет вашего веб-сайта.
Вместо этого хакеры пытаются использовать ваш сервер в качестве ретранслятора электронной почты для спама или настроить временный веб-сервер, обычно для обслуживания файлов незаконного характера.
Другие очень распространенные способы злоупотребления скомпрометированными машинами включают использование ваших серверов как части ботнета или майнинг биткойнов. Вы также можете быть поражены программами-вымогателями.
Взлом регулярно выполняется автоматическими сценариями, написанными для поиска в Интернете в попытке использовать известные проблемы безопасности веб-сайтов в программном обеспечении. Вот наши десять лучших советов, которые помогут обеспечить безопасность вас и вашего сайта в Интернете.
1. Обновляйте программное обеспечение
Это может показаться очевидным, но поддержание всего программного обеспечения в актуальном состоянии жизненно важно для обеспечения безопасности вашего сайта. Это относится как к операционной системе сервера, так и к любому программному обеспечению, которое вы можете использовать на своем веб-сайте, например, к CMS или форуму. Когда в программном обеспечении обнаруживаются дыры в безопасности веб-сайта, хакеры быстро пытаются ими воспользоваться.
Если вы используете решение на основе виртуального хостинга, вам не нужно так сильно беспокоиться об установке обновлений безопасности для операционной системы, так как хостинговая компания должна позаботиться об этом.
Если вы используете стороннее программное обеспечение на своем веб-сайте, такое как CMS или форум, вы должны убедиться, что вы быстро применяете все исправления безопасности. У большинства поставщиков есть список рассылки или RSS-канал, в котором подробно описываются любые проблемы безопасности веб-сайтов. Вордпресс и многие другие CMS уведомляют вас о доступных системных обновлениях при входе в систему.
Многие разработчики используют такие инструменты, как Composer, npm или другие, для управления зависимостями своего программного обеспечения, и уязвимости безопасности, появляющиеся в пакете, от которого вы зависите, но на который не обращаете никакого внимания, — это один из самых простых способов быть пойманным. Убедитесь, что вы обновляете свои зависимости и используете такие инструменты, которые позволяют получать автоматические уведомления, когда в одном из ваших компонентов объявляется об уязвимости.
2. Остерегайтесь SQL-инъекций
Атаки с внедрением SQL — это когда злоумышленник использует поле веб-формы или параметр URL-адреса, чтобы получить доступ к вашей базе данных или манипулировать ею. При использовании стандартного Transact SQL легко неосознанно вставить мошеннический код в запрос, который можно использовать для изменения таблиц, получения информации и удаления данных. Вы можете легко предотвратить это, всегда используя параметризованные запросы, большинство веб-языков имеют эту функцию, и ее легко реализовать.
3. Остерегайтесь XSS-атак
Атаки с использованием межсайтовых сценариев (XSS) внедряют на ваши страницы вредоносный код JavaScript, который затем запускается в браузерах ваших пользователей и может изменить содержимое страницы или украсть информацию для отправки злоумышленнику. Например, если вы показываете комментарии на странице без проверки, злоумышленник может отправить комментарии, содержащие теги сценария и JavaScript, которые могут работать в браузере любого другого пользователя и украсть их куки для входа, что позволит атаке получить контроль над учетной записью каждого пользователя, просмотревшего комментарий. Вы должны убедиться, что пользователи не могут внедрять активный контент JavaScript на ваши страницы.
Это вызывает особую озабоченность в современных веб-приложениях, где страницы теперь создаются в основном из пользовательского контента и во многих случаях генерируют HTML, который затем также интерпретируется интерфейсными фреймворками, такими как Angular и Ember. Эти фреймворки обеспечивают множество средств защиты от XSS, но смешивание серверного и клиентского рендеринга также создает новые и более сложные возможности для атак: не только эффективное внедрение JavaScript в HTML, но вы также можете внедрить контент, который будет запускать код, вставив директивы Angular или используя Ember помощники.
Ключевым моментом здесь является сосредоточение внимания на том, как ваш пользовательский контент может выйти за рамки, которые вы ожидаете, и быть интерпретирован браузером как нечто отличное от того, что вы ожидали. Это похоже на защиту от SQL-инъекций. При динамической генерации HTML используйте функции, которые явно вносят нужные вам изменения (например, используйте element.setAttribute и element.textContent, которые будут автоматически экранированы браузером, а не устанавливайте element.innerHTML вручную), или используйте функции в вашем инструменте для создания шаблонов, который автоматически выполняет соответствующее экранирование, а не объединяет строки или устанавливает необработанный HTML-контент.
Еще одним мощным инструментом в наборе инструментов защиты от XSS является Content Security Policy (CSP). CSP — это заголовок, который может вернуть ваш сервер, который сообщает браузеру, что нужно ограничить то, как и какой JavaScript выполняется на странице, например запретить выполнение любых скриптов, не размещенных в вашем домене, запретить встроенный JavaScript или отключить eval(). У Mozilla есть отличное руководство с некоторыми примерами конфигураций. Это усложняет работу скриптов злоумышленника, даже если они могут получить доступ к вашей странице.
4. Остерегайтесь сообщений об ошибках
Будьте осторожны с тем, сколько информации вы даете в своих сообщениях об ошибках. Предоставляйте своим пользователям только минимальные ошибки, чтобы гарантировать, что они не позволят украсть секреты, присутствующие на вашем сервере (например, ключи API или пароли базы данных). Также не указывайте полную информацию об исключении, так как это может значительно упростить сложные атаки, такие как SQL-инъекция. Сохраняйте подробные ошибки в журналах вашего сервера и показывайте пользователям только ту информацию, которая им нужна.
5. Проверка с обеих сторон
Проверка всегда должна выполняться как на стороне браузера, так и на стороне сервера. Браузер может обнаруживать простые сбои, такие как пустые обязательные поля и ввод текста в числовое поле. Однако их можно обойти, и вы должны убедиться, что вы проверяете эту проверку и более глубокую проверку на стороне сервера, поскольку невыполнение этого может привести к вставке вредоносного кода или кода сценария в базу данных или вызвать нежелательные результаты на вашем веб-сайте.
6. Проверьте свои пароли
Все знают, что нужно использовать сложные пароли, но это не значит, что они всегда так делают. Крайне важно использовать надежные пароли для вашего сервера и области администрирования веб-сайта, но не менее важно настаивать на использовании надежных паролей для ваших пользователей для защиты безопасности их учетных записей.
Как бы пользователям это ни нравилось, соблюдение требований к паролю, таких как минимум около восьми символов, включая заглавную букву и цифру, поможет защитить их информацию в долгосрочной перспективе.
Пароли всегда должны храниться в зашифрованном виде, предпочтительно с использованием одностороннего алгоритма хеширования, такого как SHA. Использование этого метода означает, что при аутентификации пользователей вы сравниваете только зашифрованные значения. Для дополнительной безопасности веб-сайта рекомендуется использовать соль для паролей, используя новую соль для каждого пароля.
В случае, если кто-то взломает и украдет ваши пароли, использование хешированных паролей может помочь нарушить планы преступников, поскольку их расшифровка невозможна. Лучшее, что кто-то может сделать, — это атака по словарю или атака грубой силы, по сути угадывая каждую комбинацию, пока не будет найдено совпадение. При использовании соленых паролей процесс взлома большого количества паролей происходит еще медленнее, поскольку каждое предположение должно хешироваться отдельно для каждого пароля, что очень затратно в вычислительном отношении.
К счастью, многие CMS предоставляют управление пользователями из коробки с множеством встроенных функций безопасности веб-сайтов, хотя может потребоваться некоторая конфигурация или дополнительные модули для использования соленых паролей или для установки минимальной надежности пароля. Если вы используете .NET, то стоит использовать провайдеров членства, поскольку они легко настраиваются, обеспечивают встроенную безопасность веб-сайта и включают готовые элементы управления для входа в систему и сброса пароля.
7. Избегайте загрузки файлов
Разрешение пользователям загружать файлы на ваш веб-сайт может быть большой угрозой безопасности веб-сайта, даже если это просто изменение их аватара. Риск заключается в том, что любой загруженный файл, каким бы невинным он ни выглядел, может содержать скрипт, который при выполнении на вашем сервере полностью открывает ваш сайт.
Если у вас есть форма загрузки файлов, то вам нужно относиться ко всем файлам с большим подозрением. Если вы разрешаете пользователям загружать изображения, вы не можете полагаться на расширение файла или тип MIME, чтобы убедиться, что файл является изображением, поскольку их легко подделать. Даже открытие файла и чтение заголовка или использование функций для проверки размера изображения не являются надежными. Большинство форматов изображений позволяют хранить раздел комментариев, который может содержать PHP-код, который может быть выполнен сервером.
Итак, что вы можете сделать, чтобы предотвратить это? В конечном итоге вы хотите, чтобы пользователи не могли запускать любой файл, который они загружают. По умолчанию веб-серверы не будут пытаться выполнять файлы с расширениями изображений, но не полагайтесь исключительно на проверку расширения файла, поскольку известно, что файл может иметь имя image.jpg.php.
Некоторые варианты — переименовать файл при загрузке, чтобы обеспечить правильное расширение файла, или изменить права доступа к файлу, например, chmod 0666, чтобы его нельзя было выполнить. Если вы используете *nix, вы можете создать файл .htaccess, который будет разрешать доступ только к установленным файлам, предотвращающим атаку с двойным расширением, упомянутую ранее.
В конечном счете, рекомендуемое решение — вообще запретить прямой доступ к загруженным файлам. Таким образом, любые файлы, загруженные на ваш веб-сайт, сохраняются в папке за пределами веб-корня или в базе данных в виде большого двоичного объекта. Если ваши файлы недоступны напрямую, вам нужно будет создать сценарий для извлечения файлов из личной папки (или обработчика HTTP в .NET) и доставки их в браузер. Теги изображений поддерживают атрибут src, который не является прямым URL-адресом изображения, поэтому ваш атрибут src может указывать на ваш сценарий доставки файлов, если вы установите правильный тип содержимого в заголовке HTTP.
Большинство хостинг-провайдеров занимаются настройкой сервера за вас, но если вы размещаете свой веб-сайт на собственном сервере, вам нужно будет проверить несколько вещей.
Убедитесь, что у вас настроен брандмауэр и блокируются все второстепенные порты. Если возможно, установите DMZ (демилитаризованную зону), разрешающую доступ только к портам 80 и 443 из внешнего мира. Хотя это может быть невозможно, если у вас нет доступа к вашему серверу из внутренней сети, поскольку вам нужно будет открыть порты, чтобы разрешить загрузку файлов и удаленный вход на ваш сервер через SSH или RDP.
Если вы разрешаете загружать файлы из Интернета, используйте только безопасные методы передачи на ваш сервер, такие как SFTP или SSH.
Если возможно, ваша база данных должна работать на сервере, отличном от вашего веб-сервера. Это означает, что сервер базы данных не может быть доступен напрямую из внешнего мира, только ваш веб-сервер может получить к нему доступ, что сводит к минимуму риск раскрытия ваших данных.
Наконец, не забывайте об ограничении физического доступа к вашему серверу.
8. Используйте HTTPS
HTTPS — это протокол, используемый для обеспечения безопасности в Интернете. HTTPS гарантирует, что пользователи общаются с тем сервером, на который они рассчитывают, и что никто другой не сможет перехватить или изменить контент, который они видят в процессе передачи.
Если у вас есть что-то, что ваши пользователи могут захотеть сделать конфиденциальным, настоятельно рекомендуется использовать для доставки только HTTPS. Это, конечно, означает кредитную карту и страницы входа (и URL-адреса, на которые они отправляются), но, как правило, не только это. Например, форма входа часто устанавливает файл cookie, который отправляется с каждым другим запросом на ваш сайт, который делает вошедший в систему пользователь, и используется для аутентификации этих запросов. Злоумышленник, крадущий это, сможет идеально имитировать пользователя и захватить его сеанс входа в систему. Чтобы противостоять такого рода атакам, вы должны использовать HTTPS для всего своего сайта.
Это уже не так сложно и дорого, как раньше. Let's Encrypt предоставляет совершенно бесплатные и автоматизированные сертификаты, которые вам понадобятся для включения HTTPS, и существуют инструменты сообщества, доступные для широкого спектра распространенных платформ и фреймворков, чтобы автоматически настроить это для вас.
Примечательно, что Google объявил, что они поднимут вас в поисковом рейтинге, если вы используете HTTPS, что также дает преимущество SEO. Небезопасный HTTP уходит в прошлое, и сейчас самое время его обновить.
Уже везде используете HTTPS? Идите дальше и посмотрите на настройку HTTP Strict Transport Security (HSTS) — простой заголовок, который вы можете добавить к ответам вашего сервера, чтобы запретить небезопасный HTTP для всего вашего домена.
9. Контролируйте доступность сайта
Порой результатом успешно проведенной кибератаки является неработающий сайт. Стоит ли говорить о том, что вы должны быть первым из тех, кто это заметит, чтобы как можно быстрее начать восстановление.
Важно отметить то, что не только кибератаки влияют на работу сайта, а и многие другие факторы. Но, какова бы ни была причина, по которой страница сайта не открывается, например проблемы с базой данных, DDoS-атаки или вирусы, важно контролировать доступность сайта для посетителя. Ситуация, при которой пользователь не может открыть страницу вашего сайта, отрицательно влияет на поднятие сайта в поиске (поисковой выдаче) и оставляет негативное впечатление о вашем сайте у посетителя. Вы теряете потенциальных клиентов, а значит и деньги. Используйте хороший сервис, например BAILRY для постоянного контроля (проверки) доступности сайта. Сервис предоставляет как бесплатную регулярную (периодическую) проверку доступности сайта, так и платную услугу - для постоянного контроля доступности сайта.
10. Используйте инструменты безопасности веб-сайта
Если вы думаете, что сделали все, что можно для своего сайта, не спешите - самое время проверить безопасность вашего сайта. Наиболее эффективный способ сделать это — использовать разные инструменты безопасности веб-сайтов, часто называемые тестированием на проникновение или ручным тестированием для краткости.
Есть много коммерческих и бесплатных продуктов, которые помогут вам в этом. Они работают по тому же принципу, что и хакеры-скрипторы, в том смысле, что они проверяют все известные эксплойты и пытаются скомпрометировать ваш сайт, используя некоторые из ранее упомянутых методов, таких как SQL-инъекция.
Результаты автоматических тестов могут быть обескураживающими, поскольку они представляют множество потенциальных проблем. Важно сначала сосредоточиться на критических проблемах. Каждая сообщаемая проблема обычно сопровождается хорошим объяснением потенциальной уязвимости. Вероятно, вы обнаружите, что некоторые из проблем среднего/низкого уровня не беспокоят ваш сайт.
Есть еще несколько шагов, которые вы можете предпринять, чтобы вручную попытаться скомпрометировать ваш сайт, изменив значения POST/GET. Прокси-сервер отладки может помочь вам в этом, поскольку он позволяет перехватывать значения HTTP-запроса между вашим браузером и сервером.
Итак, что вы должны пытаться изменить в запросе? Если у вас есть страницы, которые должны быть видны только вошедшему в систему пользователю, попробуйте изменить параметры URL, такие как идентификатор пользователя или значения файлов cookie, чтобы попытаться просмотреть сведения о другом пользователе. Еще одна область, которую стоит протестировать, — это формы, изменение значений POST для попытки отправки кода для выполнения XSS или загрузка скрипта на стороне сервера.
Компания Mainton - разработка и тестирование программного обеспечения под заказ, SEO и реклама в интернете с 2004 года.