OWASP, открытый проект безопасности приложений, накануне представил для обсуждения новую версию списка десяти самых опасных угроз. В сравнении с OWASP Top 10 2007 изменениям подверглись четыре позиции. Меня удивило, что инклуд-баг Malicious File Execution был исключен из списка якобы в силу того, что PHP стал более безопасным по умолчанию. Видимо Jeremiah Grossman и компания не учли, что LFI (local file include) по степени риска теперь можно практически приравнять к RFI (remote file include). Возможно к 2010 бажных версий PHP будет намного меньше, но, несмотря на это, косячить в коде будут всегда. А может обнаружатся еще какие-нибудь новые уязвимости 🙂
Итак, сама десятка самых опасных угроз:
- A1 Injection (всякого рода инъекции, в т.ч. SQL, LDAP и т.д.)
- A2 Cross Site Scripting (не потерявший актуальности XSS)
- A3 Broken Authentication and Session Management (ошибки в архитектуре аутентификации и управления сессиями)
- A4 Insecure Direct Object References (незащищенные ресурсы и объекты, можно вспомнить случай с SVN)
- A5 Cross Site Request Forgery (CSRF)
- A6 Security Misconfiguration (небезопасная конфигурация окружения, различных фреймворков, платформы)
- A7 Failure to Restrict URL Access (несанкционированный доступ к функционалу, требующему особых привилегий – например обход проверки c помощью двойного слэша “//” в URL для получения доступа к управлению блогом в WordPress)
- A8 Unvalidated Redirects and Forwards (открытые редиректы, которые ведут к фишингу, HTTP Response Splitting и XSS)
- A9 Insecure Cryptographic Storage (небезопасное хранение важных данных)
- A10 Insufficient Transport Layer Protection (недостаточная защита данных при их передаче на транспортном уровне, например по HTTP вместо HTTPS).
Надеюсь, это неокончательная версия Top 10, ждем следующий релиз-кандидат.
9 replies on “Опубликован OWASP Top 10 2010 (RC1)”
>> Видимо Jeremiah Grossman и компания не учли, что LFI (local file include) по степени риска теперь можно практически приравнять к RFI (remote file include)
поясните пожалуйста по-подробнее, если не сложно
Я имел в виду, что, если раньше успех при lfi во многом зависел от местоположения логов, то теперь знать точно, где они находятся, в большинстве случаев необязательно (/proc/self/fd/…). Плюс к этому инклуд сессий, аваторов, логов webalizer и т.д., также альтернатива нулл-байту. В конкретно взятом случае есть масса вариантов выжать из lfi по-максимуму.
Raz0r, спасибо за интересный пост! Я вот только не понял насчет двойного слеша и WordPress’a – что это такое (в поиске не нашел)?
Информация об этой уязвимости проскакивала не только в багтреках, но и в новостях с заголовками “Массовые взломы блогов на wordpress”. Разработчики несколько раз выпускали патчи, и в последних версиях wp эту уязвимость наконец-то удалось нейтрализовать. Но до сих пор в публичном доступе нет ни единого рабочего эксплоита, так как остаются подверженными множество блогов. А в чем корень уязвимости можно понять по коммитам на core.trac.wordpress.org
Raz0r, спасибо, понял теперь про что это.
Хммм, про RFI – действительно странное решение.
Raz0r, ты помнишь? Про вп потише =\
ок, я молчок 🙂
1 UNI/**/ON SELECT ALL FROM WHERE