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

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

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

Спасибо.

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

PS2: Разумеется, что в сети достаточно информации по этой части. Мне бы просто хотелось помимо улучшения безопастности собственного сайта, помочь и другим людям, собрав актуальную информацию в одном месте. Я уповаю на Хабралюдей, среди которых много таких, кто проверил на собственной шкуре сабж данного вопроса. Ни в каком другом месте в Рунете просто нет такого скопления знаний.
  • Вопрос задан
  • 7819 просмотров
Пригласить эксперта
Ответы на вопрос 11
@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/

Сегодня уже третий раз приходится лезть за этой ссылкой, представляете?
Ответ написан
Ваш ответ на вопрос

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

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