Уязвимости и атаки в вебе?

Question

[TheHorse]

Доброго времени суток.



Я использую CodeIgniter c фильтрами от XSS, фильтрованные запросы к БД, не доверяю входным данным; знаю о / верю что защищен от: XSS, php/sql-inject, HTTP Response Splitting, CSRF. Сайт работает по HTTPS.



Но мне нужна чуть более параноидальная защита. И поэтому спрашиваю:

1. Какие еще есть популярные типы уязвимостей в контексте веб-сайтов?

2. Какие есть приколы с безопасностью у самого php?

3. Где бы обо всем этом почитать?

Answer 1

[Сергей Озеранский]

Полномочия на директорию… Раскрытие путей…

Comments

[TheHorse]

Выставлены, аккуратно с правами пользователя/групп.
От раскрытия путей защищался, интуитивно подозревал там что-то неладное. Буду перепроверять, спасибо. Что-то еще назвать можете?

[Сергей Озеранский]

LFI и RFI

[Сергей Озеранский]

еще посмотрите в сторону отказоустойчивости сервера, DDoS никто не отменял… и флуд атаки разного рода…

[TheHorse]

File Inclusion — защищен. От DDoS — в меру скромных возможностей убер сервера, модуля nginx, зеркалирования. Еще раз спасибо, еще уязвимости?

Answer 2

[FurryCat]

Посмотрите сайт www.owasp.org

Он создан для ответов именно на такие вопросы. Правда, он на английском языке.

Answer 3

[stan_jeremy]

Легче было бы если бы вы показали сайт, а люди бы его посмотрели %)

Comments

[TheHorse]

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

[Иван Журавлев]

Согласен с blackybr. Есть такая вещь как опыт и смекалка, которые одним видом атаки не опишешь. Например, скажу вам ошибка бизнес-логики или слабое хэширование — вы поймёте где исправлять? А это может быть абсолютно где угодно включая генерацию csrf ключа.

Answer 4

[Глеб Старков]

display_errors не упоминали

Comments

[TheHorse]

вырубил)

[Сергей Озеранский]

уже на уровне подсознания)))

[TheHorse]

?? Ну то было очевидно. вырубил при залитии на боевой сервер.

Answer 5

[B@rmaley.e><e]

Clickjacking

Comments

[TheHorse]

А это разве уязвимость? Если, верить что code-inject на сайте мне не устроят.

[B@rmaley.e><e]

Ну вот, допустим, пришлют Вам ссылку на онлайн-игрушку, которая по совместительству будет всех пользователей группу админов переводить в процессе «игры».
Об успешных атаках с использованием такой штуки я не слышал, но защититься от него, думаю, стоит.

[TheHorse]

Куда пришлют? Можно чуть подробней?

[Сергей Озеранский]

имхо больше эзотерика, реалистичнее тогда CSRF, но от него уже есть защита…

[B@rmaley.e><e]

В каком-нибудь чатике, например.
Представляемый мною сценарий таков:
Злоумышленник оформляет специальную страничку, содержащую фрейм с нужной страницей Вашего сайта и специальным образом спозиционированный на этой страничке.
Каким-то образом (социальная инженерия) он подкидываем эту ссылку Вам (или пользователям Вашего сайта).
Вы (или пользователь Вашего сайта) заходите на страничку, начинаете с ней взаимодействовать (играть в игру, например). В то же время Ваши действия «проваливаются» внутрь фрейма (не знаю, возможно ли реагировать на них также и на самой странице), в результате чего Вы (или пользователь Вашего сайта) нажимаете какие-то кнопки, что-то куда-то вводите и т.д. уже на своём сайте (при условии, что Вы там авторизованы, конечно). Защита от CSRF не поможет, т.к. действия ведутся на Вашем сайте, но Вы этого не осознаете.

[B@rmaley.e><e]

Насчёт эзотерики согласен, но в любом случае ничего хорошего от подгрузки сайта во фрейме ожидать не стоит. Гугл, например, вроде как, сразу пресекает такое.

[Сергей Озеранский]

нельзя с одного домена управлять содержимым другого, межсайтовый скриптинг… браузер не разрешит…

[B@rmaley.e><e]

Скриптами нельзя, пользователем — можно.

Answer 6

[lubezniy]

Может быть, исполняемый файл, загруженный как картинка? Правда, это атака, скорее, на клиентский браузер, чем на сервер,

Comments

[TheHorse]

В случае HTTPS не может. Все файлы исключительно на родном домене. Впрочем, задача защитить пользователей сайта, а не только сайт.

Answer 7

[Mike_Bazhenov]

ajax есть? Проверьте тоже чтобы без авторизации не делал лишнего…

Comments

[TheHorse]

есть. Логин проверятся в конструкторе класса, который содержит функции для работы с профилями и прочим. Уверен контроль доступа сделан на высшем уровне.

Answer 8

[Pushkind]

Clickjacking (X-Frame-Options header), DOM XSS, посмотрите на Content Security Policy, полезная вещь.

Comments

[TheHorse]

Спасибо, сейчас посмотрю.

Answer 9

[Лука Сафонов]

Credential/Session Prediction
XML External Entity Attacks
LFI over PHPinfo
Weak passwords