Дмитрий Сергеевич (axshavan) wrote,
Дмитрий Сергеевич
axshavan

  • Location:
  • Mood:
  • Music:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оригинал записи http://blog.axshavan.ru/2012/04/web-information-security-basics.html
Tags: web, работа, хабр
Subscribe

  • Коуты над Десной, часть 1

    Первого августа, перекрыв дома воду и выключив интренет, мы приехали в городочек Коуты над Десной. Это конечная станция железной дороги вообще,…

  • Плёнка №202

    Плёнка: Fomapan profi line action 400 Фотоаппарат и объектив: Zenit-E + Helios 44-3 2/58 Проявитель: Fomadon LQN Сканер: FilmScan35 II 1 2 3…

  • Плёнка №199

    Всякая нудная техническая информация - что это за плёнка, чего фотографии такие контрастные, и так далее - расположена после снимка номер шесть. 1…

  • Post a new comment

    Error

    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments