среда, 4 апреля 2012 г.

Конспект семинара по основам безопасности веб-приложений

Сегодня у нас на работе прошёл семинар. Это уже второй семинар, первый провёл Толик (acidjazz.livejournal.com) на прошлой неделе по IDEF-диаграммам. Сегодняшний семинар кое-как провёл я.

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

Я подготовил тестовый стенд на основе одного из наших проектов (на основе «Авточмо»), где специально убрал кое-где защиту, чтоб показать кое-что.

Самым безобидным способом помешать работе сайта будет обычная или распределённая DoS-атака, когда сам сайт толком не страдает, данные не компрометируются, просто сайт работает очень тухло, посещаемость падает, конверсия падает, прибыль падает. Битрикс устроен таким образом, что завалить любой портал ддосом несложно, потому как битрикс и высокая нагрузка — вещи несовместимые.

Более опасными вещами являются как раз те, которые я хотел показать. Относительно легко обнаруживаемым и трудно эксплуатируемым является уязвимость, при которой в запрос к базе данных подставляются пришедшие от пользователя данные, не прошедшие обработку и валидацию. Обнаружить подобную вещь очень просто — достаточно подставлять везде в URL, в поля форм всякие кавычки и бэкслеши. Вывалится ошибка запроса к БД — ага, вот оно есть. Однако, не зная, каким образом формируется запрос, очень сложно догадаться, что именно следует вписать в уязвимое поле, чтоб, вместо того, чтоб выдавать ошибку, запрос начал работать по-другому.

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

Хэширование — это отбражение всего множества любых строк на ограниченное множество строк. Например, алгоритм md5 превращает что угодно в строку из 32 букв латинского алфавита и цифр, sha1 — в строку из сорока. Причём хэширование — операция необратимая. То есть, зная строку, из неё можно легко получить хэш, а из хэша строку — только перебором. Существуют так называемые радужные таблицы, в которых можно по хэшу найти искомую строку или строку, у которой хэш точно такой же. В интернете полным-полно онлайн-сервисов расшифровки паролей.

Поэтому рекомендуют хэш солить. Ввёл человек пароль, состоящий, например, из одних цифр, а мы возьмём и добавим туда ещё буковок разного размера, цифирок, да и спецсимволов парочку. Злоумышленнику придётся здорово попотеть, подбирая такой пароль. Фактически, ему придётся строить свои радужные таблицы заново для такой соли. А если мы выберем случайную соль для каждого пароля, то осуществить массовый взлом украденных паролей будет очень и очень затратно. Соль, кстати, можно хранить прямо вместе с хэшем, например, добавив её к хэшу или по известному алгоритму перемешав символы, чтоб точно сбить с толку злоумышленника. В битриксе реализован механизм хранения паролей в подсолёном хэше, сама соль там хранится в одной строке перед хэшем и имеет фиксированную длину.

Более простой в эксплуатации, но более действенный способ — это кроссайтовый скриптинг, или XSS. Уязвимости такого рода возникают, когда кто-то, чаще всего программисты фронт-эндов и верстальщики шаблонов забывают сделать обработку выводимой на сайте информации, загруженной пользователями. То есть когда выводится именно то, слово в слово и символ в символ, что пользователь написал. В посте ли, в комментарии, даже в имени пользователя или логине. Был, помнится, забавный случай, когда один человек назвал своё приложение для твиттера <script>alert('pwn!')</script>, а в твиттере это не фильтровалось, ха-ха-ха.

Обрабатывать надо всё и всегда, даже то, что, казалось бы, не может быть неблагонадёжным. На всякий случай. Самый простой способ навредить с использованием этой уязвимости — это написать кусок HTML или JS такой, чтоб он до неузнаваемости уродовал внешний вид сайта. И наиболее опасный способ — это воровство кукисов. Предложенный мною метод, когда злоумышленник открывает попап с адресом, где лежит заранее подготовленный логгер, разумеется, не будет работать в том случае, когда браузер блокирует попапы.

Итак, открывается некий адрес, в который в качестве параметров подставлены cookie пользователя. Логгер это всё записывает. Потом выбираем значения каких-нибудь приглянувшихся кукисов, открываем мегабраузер Опера, в котором по умолчанию есть возможность редактировать свои кукисы, и подставляем значения этих кукисов вместо своих.

Проведения атак такого рода можно избежать, просто проводя обработку данных при выводе. Не надо лениться это делать, так как сами видите, к чему это может привести. Сам сайт, в смысое его ядро, работающее с БД, может быть защищёнл хорошо, но данные пользователей скомпрометированы. Кстати, привязка кукиса к ip-адресу помогает против угона кукисов не только этим, но и любым другим способом, за исключением того случая, когда злоумышленник сидит в той же подсети с одним внешним адресом, что и вы.

Итак, две функции, всего две — addlashes и htmlspecialchars — закрывают львиную долю уязвимостей начального уровня и делают ваш сайт практически неуязвимым против школоло. Однако, стоит помнить о том, что вышеописанные уязвимости — только самые массово встречающиеся, и не стоит думать, что экранирование спецсимволов и замена хтмл — это панацея. Думать мозгами всё равно надо.

Комментариев нет:

Отправить комментарий

Ублюдочный Гугл поломал форму комментариев. Извините.