Показаны сообщения с ярлыком хакер. Показать все сообщения
Показаны сообщения с ярлыком хакер. Показать все сообщения

понедельник, 15 апреля 2019 г.

Обратная совместимость

Регрессионное тестирование для каждого продукта проводится в своём направлении. В случае обнаружения критичного бага у пользователя должна быть возможность отката до предыдущей версии. Но если в результате такого отката данным будет нанесён урон больший, нежели неудобства новой версии, то считайте такую проблему не просто регрессией, но и фатальной.
Очередной пример вышеописанной регрессии предоставила компания ConquestSS сразу в двух продуктах ClearSQL ver#7.1 и SQLDetective ver#5. Когда в 2015 году для ClearDB персональные данные (пароль к БД) стали шифроваться, то моё замечание о невозможности восстановления паролей через возврат к предыдущей версии восприняли как негативный и нежелательный тест. Разработчик в новой версии добавил кодирование пароля, но не делал конвертацию старых данных. Тогда не было владельцев продукта, готовых обновиться до новой версии. На стороне пользователя потеря паролей не проявилась. Да, соглашусь с мнением, что пароль - это не те данные, которые стоит хранить даже в зашифрованном виде, но у разработчиков ConquestSS и к любым другим настройкам аналогичное отношение. Старые, привычные установки не конвертируются в новую версию, а затираются значениями по-умолчанию без предупреждения. О чём не раз жаловались юзеры. Алгоритм перевода на новые настройки давно известен (сохранить старые, добавить новые параметры, предупредить о новых возможностях и вариантах восстановления прежних), но в среде программистов ConquestSS им напрочь пренебрегают.
Поскольку ни в Online Help, ни в Release Notes ничего не сказано о том, что после апгрейда пропадут данные, то считаю своим долгом тестировщика предупредить текущих пользователей ClearSQL ver#7.0 и SQLDetective ver#4 о необходимости сохранить прямо сейчас ветки реестра "HKEY_CURRENT_USER\Software\ClearSQL\DB Connect" и "HKEY_CURRENT_USER\Software\SQLDetective\Splash\ConnectionHistory" соответственно продуктам или Preferences в файл. Это позволит вам вручную восстановить в предыдущей версии утерянные при апгрейде пароли. Напоминаю, что в ClearSQL ver#7.1 (and higher) и SQLDetective ver#5 пароли к БД, сохранённые в предыдущих версиях, обнуляются при первом же запуске без какой бы то ни было возможности восстановления.
О простоте кодирования паролей в ClearSQL ver#7.0 и SQLDetective ver#4 уже говорилось в статье "Telegram in application with DB connection". Команде разработки потребовалось полтора года после моего напоминания для перенесения алгоритма более серьёзного кодирования паролей из ClearDB ver#4 в ClearSQL ver#7.1 и в SQLDetective ver#5. Так что, перед обновлением до сегодняшних версий не поленитесь и сделайте себе памятку, ведь столь удобная галка "сохранить пароль" может сыграть с вами очень злую шутку - не восстановит значения в новой версии, и даже механическая память рук ничем не поможет.
А всем тестировщикам ПО рекомендую не только проводить тест на обратную совместимость, но и вести профилактическую работу по предотвращению багов. Вроде бы удобство - опция для сохранения и авто-восстановления данных, но не для всех значений она может поддерживать законы безопасности приложения. Ещё одним примером такой юзерской прихоти является отдельная возможность выгрузки в XML файл всех сохранённых на машине коннектов к базе. В своё время мне пришлось потратить немало усилий, чтобы из прикреплений к OSD сообщению удаляли эти записи, потому что они несут персональную информацию, зачастую бесполезную для техподдержки ConquestSS. Но полагаю, что тот же юзер, который предложил сохранять пароли, сам и предложил экспортировать коннекты. А ведь это первый путь к хакерству. Если пользователь меняет комп, то в Online Help есть подробная инструкция по переносу настроек. Насколько часто нужна фича экспорта-импорта всего списка коннектов и кому? Ответ очевиден - только тому, кому временно стал доступен чужой ПК. Да, через сохранение всех настроек (Preferences) в файл тоже быстро можно скопировать все коннекты, но при этом ещё много локальных параметров (ключ лицензии, опции анализатора) придётся корректировать после импорта. Так что, считаю фичу экспорта-импорта коннектов вредной, а не полезной. И рекомендую подобные им новшества пресекать на первоначальном этапе разработки. Тогда не придётся выдумывать "защиту от дурака" в виде излишних шифрований или подтверждений опасных шагов. А владельцы продуктов и особенно администраторы баз должны перестать использовать опцию сохранения паролей, дабы хоть малость усложнить нежелательным элементам доступ к данным. Хотя, подобрать пароль, зная имена схем и баз, можно довольно просто. О чём немало говорили и Pete Finnegan, и Александр Поляков.

четверг, 10 января 2019 г.

Про-хак

Одной из профессиональных черт тестировщика является хакерство, направленное на выявление слабых мест продукта. Любой производитель стремится выгодно продать свой товар. А чтобы получить наибольшую прибыль, предложение должно соответствовать запрашиваемому качеству. Обязательная или добровольная сертификация позволяет устанавливать высокую цену. Но современные бизнесмены, стартаперы чаще пытаются сыграть на раскрученных брендах, чтобы быстро разбогатеть. Поэтому давним поставщикам приходится защищаться, в том числе и лицензированием своего труда. И этот этап производства тоже должен быть протестирован, хотя не все уделяют ему должное внимание, сваливая его только на тестировщиков по безопасности.
Давайте рассмотрим несколько приложений, являющихся платными для постоянного использования тестировщиком. Но поскольку "бизнес по-русски" любит халяву, то любой из ниже перечисленных продуктов можно применять бесплатно неограниченное количество времени или раз, если взглянуть на них глазами истого тестировщика. Да, профессия обязывает нас обладать способностями хакера, и именно это качество помогает выявить злостные негативные тесты. Не буду вдаваться в юридические тонкости лицензионных соглашений, пусть эти тексты останутся на совести владельцев продукта. Нашей технической направленности вполне достаточно, чтобы показать несовершенство функционала, а значит и возможные пути потери прибыли.
WINDOWS
Операционная система, наиболее популярная у тестировщиков десктопных продуктов, вполне может обойтись без Интернета. И это является основополагающей причиной "украсть" лицензию.
Подтверждение серийного ключа происходит обычно в автоматическом режиме или индивидуальном через интернет, телефон. Да, лицензия ставится на одну машину, но может быть и переставлена на другую, более (менее) новую с точки зрения оборудования. Этот обходной манёвр чаще всего используют завхозы (сисадмины, девопсеры). Степень защиты, завязанная на "железо", в век быстро меняющихся технологий нельзя считать высокой. Компания Microsoft, понимая тенденции рынка компьютеров, сама отказалась от некоторой части прибыли, видимо посчитав её незначительной. Конечно, обновить такую версию можно только на одной из машин, но для отдела тестирования парк устройств чаще всего выстраивается именно в стиле разнообразия и надолго.
TestComplete
Среда тестирования десктопных, web- и мобильных приложений имеет пробный бесплатный период, длиною в месяц. Цена продукта самая низкая в линейке ему подобных, но и это не всегда по карману стартапам. Поэтому основные пользователи TestComplete чаще вынуждены извращаться и ограничиваться триалом. Даже триальный ключ имеет три стадии защиты: временной, привязка к оборудованию и операционной системе, генерация ключа на сайте компании. Но все эти уровни тоже можно обойти. Персональная информация для триального ключа не завязана на факте существования e-mail - хотя поле и обязательное для заполнения, но вводить можно не существующий адрес, например "aa@aa.aa". Персональную инфу собирают только для статистики, а не в целях уникального использования ключа. Наличие доступа в интернет на компе тоже не обязательное, ключ можно получить через соседнюю машину, да и существующий коннект не контролирует триальщика. Поскольку операционная система позволяет не закрывать сеанс годами, то это позволяет работать в одной запущенной сессии приложения более одного месяца. На моей памяти 7 месяцев на виртуальной машине без перезагрузки, поскольку однажды запущенное приложение не замечает регулярной смены дат. Но когда виртуальную машину пришлось перезапустить, а не остановить с открытым TestComplete, то только переустановка виртуалки и приложения позволила продолжить тестирование. Опасно, конечно, переводить дату на компах виртуальном и основном, это  "сжигает" триал, даже если вы не вышли за рамки периода. Моим выходом из ситуации стало следующее: на основной машине ставилась чистая виртуальная машина, копия файла виртуальной машины откладывалась в запасник, на виртуалку ставился TestComplete, запускалась среда тестирования и по возможности не закрывалась (если тесты не валили среду) длительное время, виртуальная машина тоже не гасилась, а только сеанс с самой виртуалкой закрывался. Поскольку запуск тестов никогда не проверял триальный период, то работать можно бесконечно долго, если тесты не требуют ручного перевода дат на компе. 
Продукты компании Atlassian (Jira, Confuence,..)
Почему из двух вариаций (облачной и серверной) русские бизнесмены выбирают серверную? Думаете, чтобы сохранить конфиденциальность разработок? Отнюдь нет. В серверном варианте доступно мелкое перепрограммирование, и минимальная версия на 10 пользователей вырастает в безлимитную. А ведь для небольших команд в 15-20 человек вполне достаточно работать в двух честно купленных 10-пользовательских приложениях, потому что работает импорт-экспорт задач, а команда тестировщиков вполне может пользоваться отдельной системой трекинга задач. Тестировщик не имеет права менять техзадание, нам достаточно только описания задачи. И программистам не важны шаги тестов, кроме новых локализованных багов и утверждённых лидом на правку. Халявщики-бизнесмены даже из фичи синхронизации могут извлечь собственную выгоду.
TOAD
Самая популярная среда разработки и тестирования базы данных Oracle хоть и имеет бесплатный триальный период, но его давно научились переводить в бесконечный и неограниченный. Не могу придумать причину, почему такой большой спектр пользователей-халявщиков не принимается во внимание. Программулька генерит ключ на персональной машине, как минимум до 12 версии. Запуск TOAD и весь его функционал не проверяет лицензию через сайт компании Quest ни в прямом, ни в скрытом режимах. Ключ теоретически имеет лишь две ступени защиты: реестр и файловая система. На мой взгляд - это слишком слабая охрана для столь распространённого приложения, которая не приносит прибыли ни Quest, ни альтернативным компаниям. Зачем создавать новый клон и пытаться на нём заработать, если оригинал в свободном доступе знают и используют давно?
Продукты компании Conquest Software Solutions
Излишество наворотов лицензионных ключей SQLDetective, ClearSQL и ClearDB не спасает от утечек. Любой из уровней защиты имеет способ обхода.  Двойной щит из реестра и файловой системы сам себя обходит единым IP-адресом машины с несколькими внутренними пользователями и подвиртуалками. Отключение интернета на момент старта приложения и выключение опций для скрытой отправки на сайт статистики пользователя охраняет нелегальных владельцев от разоблачения. Впрочем, сама инфа о владельце (количество и срок лицензий, AMS) компания Conquest автоматически отслеживает только по дате, а не уникальности пользователей, чем пользуются временные сотрудники, забирая домой или в иную организацию купленный ключ. На предоставленные мной факты незаконного использования лицензий CEO никогда не предъявлял претензии пользователям. Так что, как бы ни был лицензионный ключ  уникален по времени покупки в рамках данных по продукту и покупателю, и как бы не контролировала MySQL база одновременно-уникальные транзакции собственными средствами, но элементарный вывод компа с продуктом Conquest из локальной сети или перевод даты в рамках триального/арендуемого срока позволяют работать с продуктами многим и долго. Да, ограничение по дате контролируется стартом внутреннего функционала, но при этом не выполняется никакая синхронизация дат. Поскольку триальный ключ входит в инсталлятор, то он никак не зависит от данных пользователя и компа, только операционная система подсказывает дату окончания триала.

Что и на каких этапах обязан проверять тестировщик для подтверждения устойчивости лицензий и сертификатов?
Перечислю стандартный минимум, доступный тестировщику даже без стажа. Пропуск какой-либо нижеописанной проверки ведёт к проблемам с несанкционированным использованием вашего продукта, а иногда к отказу продолжать оплачивать лицензию. Своеобразный cheat-sheet для проверки лицензионного ключа:
- юридическое обоснование лицензионного соглашения, наличие и полнота системных требований для использования продукта в описательном документе, точность описания инструкции пользователя в хелпе и иных подсказках, полнота описания нового функционала и возможных проблем с вариантами решения в Release Notes;
- способы и места ввода персональной информации, влияющей на ключ продукта: sql-инъекции, региональные языки, спец-символы и тэги, размер данных (пустые-нулевые, максимум-минимум, переполнение, граничные,..), формат (текст, число, дата,..) и маска (разделители дробей, времени, имя с большой буквы,..), полнота заполненности и  обязательность полей;
- объём и содержание переданной информации для генерации ключа: необходимые и достаточные данные, поддержка региональных языков на сервере генерации ключа;
- объём и содержание переданного ключа пользователю: соответствие функционального набора оплаченным/заявленным опциям и полнота функционирования ограничений, защищённость передачи (файл прикреплён к e-mail письму, заархивирован с паролем, скачан с сайта производителя, код продиктован по телефону,..), поддержка в системе пользователя;
- техподдержка лицензии: автоматическая, регулярная, скрытая, ручной режим, оплата, база клиентов.

Как часто проводить тестирование лицензии?
- смена версии платной части (мажор, минор, релиз,..);
- смена условий оплаты всего продукта, его части или обслуживания;
- появление нового функционала, ограничиваемого ключом;
- изменение функционала, позволяющее несанкционированное использование;
- при обнаружении хакерских атак, подозрений на несанкционированное использование по результатам анализа обращений в техподдержку вашего и чужих продуктов.