Тестирование на уязвимости системы обеспечения безопасности на веб-приложениях
Много компаний использует программное обеспечение CMS, которое обновляет на постоянном клиенте, часто они - исправления безопасности, подразумевая, что предыдущая версия имеет уязвимости системы обеспечения безопасности. Но большинство клиентов никогда не обновляет это, или даже CMS был изменен так, чтобы обновление повредило сайт. Есть ли сайты, которые документируют это использование и сообщают, как протестировать на них? Или эта информация даже не становится опубликованной? (чтобы не сделать, чтобы люди попытались использовать их),
Также существует ли базирующийся контрольный список универсального php/js для предотвращения попыток взлома? Я знаю о Внедрениях SQL и XSS, но я уверен, что существует больше угроз там.
Мир
2 ответа
Сайты, которые каталогизируют все эти уязвимости, например
- SecurityFocus
- milW0rm
- packetstormsecurity
Основной контрольный список для webapps можно найти на OWASP, это очень общий контрольный список.
SQL Injections и XSS атаки решаются разбором всей информации, которая попадает в ваш код (добавление слэшей, удаление тегов "" и так далее); эмуляция магических кавычек и отключение register_globals решили проблемы с моей точки зрения. Будьте осторожны, не знаю точно когда, но magic_quotes будет устаревшим, так что не рассчитывайте на это.
Так какие еще угрозы существуют? По моему опыту, самые распространенные человеческие ошибки связаны с аутентификацией. Это не означает, что пользователь не входит в систему, но это означает, что пользователь может читать/писать информацию для других пользователей. Поэтому, всякий раз, когда вы видите ссылку на удаление, например, такую: index.php?page=images&action=delete&id=2, попробуйте использовать другой id, изображения другого пользователя. Вы должны получить ошибку, говорящую "не ваше изображение" или что-то в этом роде. Это очень трудно проверить, поэтому вы должны полагаться на опыт разработчика.
Вторая самая большая проблема, с которой я столкнулся, была связана не с кодом, а с сервером. FTP-пароли были украдены вирусами (IFrame virus и другие), или сервер был взломан с помощью различных методов грубой силы.
Вывод таков: если вы уверены, что проверили SQL-инъекции и XSS-атаки, последнее, что вы должны сделать, это решить проблему аутентификации (еще раз, аутентификация означает, что информация, которую вы получаете/изменяете, является ВАШЕЙ). Люди склонны быть немного параноиками в вопросах безопасности, но наиболее распространенные взломы не являются виной разработчика.
Надеюсь, это поможет;
С наилучшими пожеланиями, Габриэль