Чтение логов в рамках тестирования безопасности

При тестировании защищенности приложений, в том числе и веб-ориентированных, уделяют внимание защите от всяческих красивых аббревиатурных приемов типа xss, csrf , mitm и еще куча всяких красивых сокращений и еще более красивых расшифровок... Но порой частенько забывают о такой банальщине как логи.
Чем же они могут навредить приложению, честным пользователям, владельцам бизнеса?
Недавно один мой коллега столкнулся с реальным примером вывода (видимо, дебаг) в логах одного веб-портала системы дампы авторизационных данных пользователей системы... пароли в чистом виде в логах, при том, что в бд только хеши... ужас.
Само по себе наличие в логах таких данных никому не вредит.. до них ведь еще добраться надо.
Но кто помещает, например, недобросовестному админу, обиженному на всех и вся, слить налево такие данные , абсолютно не рискуя навлечь на себя подозрения ?
А про сценарий, когда на сервер проник злоумышленник извне (например, пробив какой-нибудь давно не патченный сетевой сервис) .. В этой ситуации , ему надо только уметь читать и ничего более ) Понятно, что ребята, которые могут легко пробивать "непропатченные сетевые сервисы" пробьются затем и в БД, и еще куда захотят, но зачем им облегчать жизнь? В общем, к логам хорошо бы относиться повнимательнее. Как разработчикам и тестировщикам , так и админам с их пермишенами :)

virtualenv в помощь

В этой статье хочу поделиться опытом того, как можно без лишней головной боли организовать тестирование web-приложения , написанного на python c различными версиями этого языка. И даже с различными версиями того или иного фреймворка (django, pylons etc)...если, конечно , фреймворк используется.
Итак , есть сервер , для определенности : на нем установлен linux.. для еще большей определенности - debian )
Любой linux - дистрибутив уже включает в себя ту или иную версию python. Допустим "из коробки" имеем python v2.5. Мы же хотим протестировать наше гипотетическое приложение на совместимость с python 2.5, 2.6 и 2.7 (на совместимость с версией 3 лучше не тестировать - под нее надо писать отдельно =), чтобы быть уверенным, что наше приложение будет работать на большинстве python-хостингов.

1. доставляем отсутствующие версии python. Для этого wget-ом, например, выкачиваем соответствующие исходники, распаковываем (tar), конфигурируем НЕ ЗАБЫВАЯ УКАЗЫВАТЬ ПРЕФИКС установки отдельно для каждой версии python, затем make и make install. В итоге получаем:
   • /usr/bin/python - дефолтный
   • /usr/python2.6/bin/python
   • /usr/python2.7/bin/python
2. теперь самое интересное - у нас три одинаковых бинаря python в трех разных местах. Если вызвать python из командной строки, то будет дернут тот, чей путь левее всего в PATH. Как быть? каждый раз руками менять PATH? мучаться с симлинками? Слава Богу нет. Нам на помощь приходит замечательная штукенция - virtualenv !

   
   sudo apt-get install virtualenv
   mkdir ~/projects/
   cd projects
   virtualenv --no-site-packages -p /usr/bin/python app_test_python2.5
   virtualenv --no-site-packages -p /usr/python2.6/bin/python app_test_python2.6
   virtualenv --no-site-packages -p /usr/python2.7/bin/python app_test_python2.7
   

   В результате мы имеем три директории - по одной для каждой версии питона. Интересное внутри этих директорий. Внутри же создается окружение - бинари, инсталляторы библиотек (pip , easy_install) - сюда же надо помещать и код тестируемого приложения, отсюда же и деплоить с локальным web-сервером (apache, nginx..)
3. еще не все. Чтобы работать в окружении , надо его активировать:

   
   cd ~projects/app_test_python2.6
   . env/bin/activate
   
   

   теперь можно не боясь вызвать python, pip, easy_install - будет вызвана именно версия 2.6, будут использованы именно библиотеки для версии 2.6 и ставиться будут они не в /usr/lib/python , а в ~projects/app_test_python2.6/lib !
   

Полная изоляция, никакой мороки и путаницы.
Таким образом, создавая для каждой тестовой конфигурации свое виртуальное окружение, мы не засираем систему хаотичными симлинками, конфликтующими версиями библиотек и т.д. и т.п. В общем сплошные плюсы.
Расписал, конечно, не все максимально детально. Но, думаю, тому , кто решить освоить эту технику организации тестовых стендов помогут гугл, здравый смысл и прямые руки )
p.s. только python к сожалению ( Пока писал стало интересно есть ли аналоги для perl, php ... )

Вы уверены , что хотите выполнить операцию?

На тему о том, как делать удобные приложения написано немало статей, howto, "стандартов" и так далее. С каждым днем все больше действительно качественно продуманных приложений, по-настоящему дружественных и "обходительных" пользовательских интерфейсов. Развиваемся. Радует.
Но иногда встречаются просто умопомрачительные косяки.
Чтобы не быть голословным приведу пример.
Многие, наверное, знают о нашумевшей криптовалюте bitcoin. Одной из ее особенностью является принципиальная невозможность отмены транзакции. Например , если вы переводите монеты с одного кошелька на другой и при этом ошибаетесь в номере целевого кошелька , то отменить перевод невозможно. Вы можете ошибиться так, что укажете реально существующий кошелек и тогда, маловероятно, но есть шанс вернуть , уговорив его владельца сделать обратный перевод (найти владельца будет посложнее чем иголку в стоге сена). Если ошибетесь так , что такого кошелька просто нет - то монеты просто исчезают.
При всем при этом описанное именно особенность, связанная с изначальными архитектурными принципами этой по-настоящему безопасной криптовалюты. Зная об этой особенности , разработчикам стоит проектировать и реализовывать интерфейсы для работы с этой валютой, а тестировщикам , соответственно, тестировать. Но так ли думают разработчики авторы guiminer ? Это питоновский фронтенд над питоновским же майнером криптовалюты. Занимается он тем, что "добывает золото" . Кроме того , есть у него кнопочка "withdraw", по нажатию на которую все наработанное улетает на некий кошелек. Нет предложения ввести адрес перевода, нет предупреждения о том, что монеты уйдут на такой-то кошелек (чтобы юзер мог сверить лишний раз), нет предупреждения о невозможности отменить транзакцию. Есть только обработка сабмита кнопки в виде списания монет с баланса ))
Сколько же новичков майнинга тут "полегло" ! )) Наиболее распространенные сценарии потери с трудом намайненных монет такие:

• пользователь недавно переставил винду и потерял свой кошелек, сгенерировал новый, а в настройки адресата переводов в учетной записи пула (например deepbit.net) новый адрес своего не внес, в итого withdraw на кошелек, который никогда нигде не увидеть больше
• пользователь отправлял биткойны в биржу , где для получения средств каждый раз генерируется новый адрес..Соответственно, при очередном переводе, забывает указать новый адрес. Результат тот же - видеокарта жгла мазут зря.

В общем..если абстрагироваться от этого печального примера, то на ответ "выводить окно подтверждения или нет" можно так:

1. если совершаемое действие может быть легко и без последствий отменено, то можно и не предупреждать
2. если совершаемое действие не может быть отменено, то предупреждать
3. если речь идет о финансах и клавиатура, которая может быть разбита, то ПРЕДУПРЕЖДАТЬ да еще и с описанием всех ньюансов)

"Сыпятся" диски - "валятся" тесты

Все мы привыкли к провалам автотестов из-за ошибок в тестируемом коде, в самих тестах , в конфигурации и т.д.
Но иногда случаются действительно редкие вещи. Как, например, сегодня в моей практике.
На одном из серверов автоматического тестирования часть тестов провалилась без видимых на то причин. Изменений, способных привести к провалам, не было ни в коде, ни в самих тестах , ни в тестовом окружении. Тесты имели длинную историю успешного прохождения - скучно даже было. И вот провалились.
После поверхностного анализа стало ясно, что не были созданы все тестовые данные - Oracle ругнулся так, что я никогда такого раньше не видел ) А точнее - не смог добавить extent в один из TABLESPACE-ов.
Смотрю в субд - инстанс в RO-режиме.
При попытке перезапустить бд получаю ошибку:

ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/u02/oradata/index01.dbf'

Пробую рекавери файла данных не помогает - из ругани Oracle становится ясно, что файловая система, где располагается том для файлов данных, находится также в RO-режиме. Сервер никто не трогал. Свет не отрубали (uptime сервака 52 дня). Лезу в /var/log/messages и вижу, что возникла проблема с ФС из-за проблемных блоков харда и ядро само перемонтировало раздел в RO-режиме. Теперь все встало на свои места. Далее лечение последствий в виде последовательных вызовов: umount, fsck, mount Ну и перезапуск oracle. В общем, мораль , железо тоже не выдерживает иногда :)

"Везет" мне на IE в последнее время..

Буквально за пару последних дней дважды наткнулся на сообщения типа "Ваш броузер не поддерживается. Используйте IE..". Причем в приложениях довольно нужных: одно - важный интранет-портал (сделан на asp), другое - банковская веб-ориентированная система (написанная на jsp).
Если в случае ASP-шного портала запуск IE действительно помог, то банкиры удивили не на шутку.. Дословно "Ошибка: работа возможна только в IE5 и выше".
Хорошо, думаю, будет вам IE. Windows 7, думаю, IE 9. Хватит? Запускаю. Вижу "Ошибка: работа возможна только в IE5 и выше" Не смешно. На этот раз я выступал в роли не тестировщика, а обычного пользователя. Мне нужен был этот софт!)
Вот так вот. В обоих случаях, наверняка, разработка стоила кучу денег. Живо представляю себе пункт в требованиях к программно-аппаратному "Допускается работа только в IE5 и выше")) Толстые дяди с умным видом месяц согласовывали, потом подписывали, потом денежки перечисляли, потом в конверте часть назад приносили... А на дворе 21 век, а сайт работает только в IE5 , и не никак выше )))
p.s. вот найду на досуге ie5 иль эмулятор и затестирую изделие до... )

Офтопы на software-testing

Хорошо, когда твой профессиональный блог транслируется на такой посещаемый и авторитетный ресурс как, например, software-testing. Ты пишешь, делишься мыслями, рецептами - люди практически сразу это видят и могут дать отзыв о твоей записи, дельный совет и т.д.

Но иногда то, что ты планируешь написать не совсем походит для аудитории, куда транслируется твой блог. Иногда ты просто не хочешь флудить непрофильными темами и засорять ленту не относящимися к "делу" публикациями.. То есть,  с одной стороны "блог мой , что хочу  то и пишу", а с другой "лента публикаций должна содержать по возможности только ценное для данной конкретной аудитории"...

В общем к чему это я..  Хорошо бы иметь механизм автора влиять на то , будет ли данная конкретная статья опубликована или нет. Сейчас я имею в виду конкретно трансляцию  на software-testing ... Думаю, можно сравнительно легко решить такую задачу. Например, автор добавляет некий код <!--DONTTRANSLATE--> в тело материала, если не хочет данной статьей флудить в ленте, а разрабочики сайта , немного "допиливают" свой транслятор, небольшим парсингом поступающего материала... Если знать точно, как именно происходит трансляция на S-T , то было бы легче "предлагать" и "советовать" и даже "приложить патч", но пока идея лишь в такой форме..

Если кто знает о "велосипеде" , который уже изобретен - буду рад совету )