Безопасность веб-приложений: Какие есть наиболее распространенные способы атак/взлома сайтов?

Написал веб-приложение. По части безопасности там реализован XSS-фильтр и сделано кое-что для предотвращения SQL-инъекций, куки HttpOnly. Интересует вопрос: какие еще существуют распространенные атаки на веб-приложения и, если возможно, что необходимо реализовать для их предотвращения?

Так же будет интересно узнать, как следует настраивать HTTP сервер(в моем случае Apache) для того, чтобы свести к минимуму возможность взлома приложения посредтвом его.

Спасибо.

PS: Безусловно, многие взломы/атаки индивидуальны и многое зависит от специфики самого сайта и того, на чем реализовано приложение. Но существуют же и широко распространенные способы, вот про них и речь… Проще говоря, спрашивается о базовом уровне.

PS2: Разумеется, что в сети достаточно информации по этой части. Мне бы просто хотелось помимо улучшения безопастности собственного сайта, помочь и другим людям, собрав актуальную информацию в одном месте. Я уповаю на Хабралюдей, среди которых много таких, кто проверил на собственной шкуре сабж данного вопроса. Ни в каком другом месте в Рунете просто нет такого скопления знаний.
  • Вопрос задан
  • 8061 просмотр
Пригласить эксперта
Ответы на вопрос 12
@shr
Начните с азов
1. классификация от WASC
2. Owasp top ten

И правильно замечено — уже года 3 вплоть до данного момента большинство WAF почему-то пренебрегает защитой файлов веб-приложения и банально не мониторят их.

В дипломе своем как раз прикручивал файловый монитор и прочие плюшки к PHP-IDS $)
Ответ написан
slik
@slik
Например CSRF популярная. А то что вы описали «сделано кое-что» может быть очень малым. SQL-inject имеет кучу разновидностей, были случаи когда через sql blind раскручивали очень крупные сайты. Поэтому советую изучить тематические сайты и статьи.
Ответ написан
int03e
@int03e
«Ни в каком другом месте в Рунете просто нет такого скопления знаний.» Не хочу обидеть хабр, но такие вопросы имеет смысл задавать на специализированных сайтах (хотя бы форум ксакепа).
Большинство взломов происходит через SQL иньекции, XSS, небрежность разработчика (доступный svn, phpinfo.php, robots.txt со списком служебных директорий (этот файл не только роботы читают, вот-вот), уязвимости софта сервера (сканируем nmap'ом --> proftpd старой версии --> эксплоит), социальную инженерию (не стоит ее недооценивать, тут можно Кевина вспомнить).
«сделано кое-что для предотвращения SQL-инъекций» кое-что? Они и в хедерах бывают и в EXIF информации аватара, к примеру, :-) Разработчик делает «кое-что», а потом может наблюдать дефейс (в лучшем случае).
Ответ написан
@niakrisn
Очень часто заливают всякие shell'ки, поэтому особое внимание в приложении следует уделить именно тем местам где происходит upload контента на сервер.
Ответ написан
Palehin
@Palehin
Frontend
Вы просто обязаны прочитать книгу по безопасности web-приложений:

Низамутдинов М.Ф. — Тактика защиты и нападения Web-приложения

Моя настольная книга по безопасности.
Ответ написан
akalend
@akalend
программирую
НЕ ИСПОЛЬЗУЕМ ПОД СТРАХОМ СМЕРТИ
eval()
include $_GET['block']
fopen( $_GET['file'] );

НЕ ЗАБЫВАЕМ ДЛЯ ВСЕХ  GET/POST
делать htmlspecialchars, strip_tags и htmlentities
Ответ написан
@lesha_penguin
То, что выше писали про sql-injection это то, что называется «дыры фреймворка».

Однако, дыр в безопасности может быть масса, большинство из которых, самые незаметные, но при этом самые подлые, это «дыры администрирования» и «дыры конфигурации».

Простой, детский, пример:
Юзер может на твой сервер загружать какие-нибудь файлы (ну, например, картинки, аватарки, прочую фигню)? А чем отличается конфиг директории куда эти файлики загружаются от остальных директорий сервера? Если ничем, то для вас плохие новости: Первый же «малолетний ][аKeP», будет делать с твоим серваком все что заблогорассудится, если загрузит «в качестве аватарки» файл cmd.php следующего содержания:

<?php if(isset($_POST['cmd'])){eval($_POST['cmd']);} ?>


Еще пример «дыры конфигурации»: Есть ли разделение конфигурации на development и production? Если нет, то плохая новость номер два: Сыпать отладочную информацию на веб-вывод, для разработчиков может удобно, но всему интернету не обязательно знать, что скрипт не смог подсоединиться к mysql-серверу «mysql.mydomain.com» под юзером «pupkin» с паролем «123».

Пример «дыры администрирования»: Твой проект использует shared hosting и на одном физическом серваке с тобой находятся сотни дырявых говносайтов. Никто не будет ломать твой супер-пупер сайт, а просто взломает чей-то бложичек, лежащий от твоего сайта в соседней директории.
Ответ написан
bo2l
@bo2l
Интересно, а кто-то из ответчиков выше может сделать аудит ресурса на к-во изъянов?
На платной основе, конечно же.
Ответ написан
Советую прочитать журнал «ПРОграммист» №11 (http://procoder.info/index.php/articles/11/166-php-security) — коротко и понятно описаны уязвимости и методы защиты от них.
Ответ написан
akalend
@akalend
программирую
если речь о скриптах РНР:
— safe mode ON
— GLOBALS OFF
— при формировании SQL используем только placeholder (MySQLi, а лучше PDO)
НЕ ИСПОЛЬЗУЕМ: $sql = «SELECT * FROM list WHERE id={{$_GET['id']}}»

формы: двойная проверка — на клиенте и сервере
советую использовать securityToken (Hiden поле) для валидации форм
режем однозначно длинну полей для большей надежности.

ну и куча еще чего.
При отправке писем через форму обратной связи необходимо просканировать текст на наличие подозрительных заголовков, а лучше текст запихнуть в БД и отправить нотификацию.
Ответ написан
@Jazzist
Еще не упомянут основополагающий документ — phpsec.org/projects/guide/

Сегодня уже третий раз приходится лезть за этой ссылкой, представляете?
Ответ написан
@MrGroovy
Настройку безопасности сервера Apache можно посмотреть в документации на оф. сайте. https://httpd.apache.org/docs/2.4/misc/security_ti...

Веб-уязвимости разберем на примере OWASP Top 10.
1) Инъекции. SQL, NoSQL, OS и LDAP т.е. все что связано с выполнением команд и доступам к базам данных, без надлежащей авторизации, например:
SELECT id_news FROM news WHERE id_news = -1 UNION SELECT 1,username,password,1 FROM admin

Защититься от такого запроса можно созданием "Белого списка"
$sort    = isset($_GET['sort'])
$allowed = array("id_news,name"); //перечисляем разрешенные варианты
$key     = array_search($sort,$allowed); // ищем среди них переданный параметр
$orderby = $allowed[$key]; //выбираем найденный элемент. 
$query   = "SELECT * FROM `table` ORDER BY $orderby DESC"; //составляем безопасный запрос

2. Межсайтовый скриптинг (XSS). Например, формирование небезопасной ссылки:
http://example.com/search.php?q=<script>CookieStealer();</script>

Что позволит выполнять выполнить вредоносную функцию.
Защитится можно с помощью функции преобразования например:
<?php
$text = htmlspecialchars("<a href='test'>Test</a>", ENT_QUOTES);
echo $text;
?>

Ещё есть ошибки конфигурации прав доступа, ненадежные пароли, неправильная настройка сессии аутентификация, хранение данных в незашифрованном виде и использование компонентов с известными уязвимостями. Есть способы обхода фильтрации вводимых данных. Есть атаки на уровне прикладных протоколов.
Для выявления каждой отдельной уязвимости существуют различные утилиты для проверки.

Начать можно с Nmap и продолжить чтением OWASP Web Application Security Guide.

Есть специальные ресурсы, сканеры уязвимостей, которые могут проверить большинство уязвимостей, например:
https://metascan.ru
https: //acunetix.com/
https: //detectify.com/
И уже после нахождения уязвимостей можно начать их устранять.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы