Какие уязвимости нужно закрыть кроме иньекций и шелл?

[verfaa]

Имеется небольшой сервис, который я написал полностью сам.
Очень хочется максимально защитить его от возможного взлома и хаков.
На сайте пользователи заливают картинки и фотки, поэтому вот что сделано к данному моменту:

- макcимально защитился от шеллов, я ранее уже создавал тему Для просмотра ссылки Войди или Зарегистрируйся
- в sql запросах все переменные закрыты в зависимости от типа - числовые ф-цией intval(), остальные mysql_real_escape_string()
- естественно явных уязвимостей вида eval($_GET[cmd]); нет
- используется выделенный сервер, соседей в виде ломанных cms древних версий нет.
- PHP 5.4.12 вреде не старая

Вопрос в том, какие ещё уязвимости проверить и закрыть? Через что ещё можно сломать сайт, кроме как шеллом и иньекцией?
Как защитить сервер, там CentOS release 6.3 (Final) может какой софт необходимо поставить? Вот думаю на днях ssh порт поменять, что ещё можно сделать?

 

[latteo]

Защита системы - это не статичное состояние, но динамический апдейт в соответствии с текущим положением дел.
Основные угрозы в самом общем виде - Для просмотра ссылки Войди или Зарегистрируйся
Например, около года назад с btc-e успешно сливали балансы слишком доверчивых пользователей с помошью простейшей XSS (url реальной странички btc-e + js код в этом же url`е) - Для просмотра ссылки Войди или Зарегистрируйся (рекомендации по защите php-приложений от XSS-атак)

Для выявления протестируй свой сервис локально (на лайве это может создать излишнюю нагрузку) популярными сканерами - Для просмотра ссылки Войди или Зарегистрируйся может что-то всплывёт

 

[Simply]

- в sql запросах все переменные закрыты в зависимости от типа - числовые ф-цией intval(), остальные mysql_real_escape_string()

Кстати, лучше в таких целях все же использовать именно Для просмотра ссылки Войди или Зарегистрируйся, у эскейпа есть свои нюансы...

В дополнение к ссылкам предидущего автора я бы еще добавил свежую Для просмотра ссылки Войди или Зарегистрируйся там как раз и про порт SSH и про FTP(S) упомянуто...

 

[denverkurt]

желательно фильтровать все $_POST, $_GET переменные. если переменная должна быть числом то и объявлять переменную числовым форматом, а не пускать на самотек
в папках загрузок файлов и фоток через .htaccess запретить выполнение php скриптов
ну и регулярное чтение логов доступа и ошибок

 

[verfaa]

Кстати, лучше в таких целях все же использовать именно Для просмотра ссылки Войди или Зарегистрируйся, у эскейпа есть свои нюансы...

Какие именно нюансы? Пишут что при современной версии mysql фукция mysql_real_escape_string() абсолютно на 100% защищает БД. Там пара сотен запросов точно наберется, не буду же я их переписывать все, у меня на это + отладка долгие недели уйдут, т.к. я с prepared statements не работал никогда.

Для просмотра ссылки Войди или Зарегистрируйся, я писал в теме, что все переменные обработаны ф-ями intval() и mysql_real_escape_string()

 

[Q_BASIC]

Я еще себе проверку IP поставил у капчу. Капчу от брута, тк вот Для просмотра ссылки Войди или Зарегистрируйся На первом месте словарные пароли, а это все сводится к бруту. Берешь сотню логинов, пять сотен паролей ( словарные чаще подходят ), и проверяешь все пары. А проверку IP на всякий случай. $ip = explode( '.', $_SERVER['REMOTE_ADDR'] ); $ip = $ip[0] .'.' . $ip[1]; Сделал капчку как тут Для просмотра ссылки Войди или Зарегистрируйся, но там можно её обойти. Надо еще if( isset( $_POST['captcha_code'] ) ), тк можно все куки удалить и в POST captcha_code не отправлять. Там нету кода и тут -> true -> капча введена верно

 

[audit-saitov001]

Например, авторизация в админке может быть с дырой.
Или если файл заливается без обработки (ресайз, ватермарк) и есть проверка только по расширению - то при некоторых настройках сервера можно этот фильтр обойти....
Еще не упомянуты XSS, произвольное чтение файлов т. п.
Вообще-лучше доверить аудит кода профессионалу и спать спокойно.