Тестирование и аудит безопасности. Вопрос

Добрый день.
Некоторое время назад стал меня интересовать вопрос качества того кода который я произвожу и собственно способы повышения этого самого качества. И по этой причине стал я задумываться - а как бы его этот код качественно и правильно тестировать? Чтобы получалось безопасно и качественно? Подумалось мне, что хорошо бы к этому процессу привлекать профессионального тестера, который и будет собственно тестировать и указывать на ошибки и уязвимости. Понятно, что я сам сколько-то багов ловлю, но не все же далеко. Все же профессионал должен отлавливать много больше, я правильно понимаю?

Вопрос в том где такого специалиста можно взять, у кого есть, откуда взял и все в таком же роде. Поделитесь кто как тестирует код. Фрилансеры, студии - интересно мнение всех. Кто сотрудничает с профессионалами, кто тестирует сам, если тестирует сам, то как? Какие применяет методики и подходы?
Спасибо за ответы.

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

Enkvist, составляете ли какой-то план тестирования или так - на глазок? Спасибо за ответ.

Ну клиент то понятно, но клиент же не производит глубокого тестирования. Так, потыкает в одном браузере по кнопочкам и ладно. А как оно будет потом - всплывает только потом

Цитата ("frig"):

Enkvist, составляете ли какой-то план тестирования или так - на глазок?

1) Составить список функционала. Продумать все возможные способы использования функционала.
2) Представить себя злостным вредителем и продумать все возможные атаки на этот функционал.

А вообще оно само как-то происходит . Рефлекс что-ли

Enkvist, спасибо.

А услуги профессиональных тестеров кто-то использует? Может быть кто-то этим сам занимается профессионально?

Ну тут все просто, гляньте по рейтингу тестирования)

>А услуги профессиональных тестеров кто-то использует? Может быть кто-то этим сам занимается профессионально?
Если проект будет того требовать, то-есть будет серьезная разработка - тестер нужен в любом случае ) Я когда работал в команде - тестер был и его наличие было реально оправданно.

Цитата ("MMM_Corp"):

гляньте по рейтингу тестирования

рейтинг очень жирный. Каталог начинается с отметки 3.6

MMM_Corp, Вы занимаетесь тестированием? Как это дело происходит? Чо почем?

Тестирование безопасности сильно отличается от тестирования функционала, тут всё много сложнее потому что классическими юнит тестами приложение бесполезно покрывать в этом случае, валидация данных дает свои результаты, но не всегда...
свой код тестирую сам, помогает богатый опыт поиска уязвимостей в опенсорс проектах, чутьё и хорошее понимание работы php, sql, работы браузера и unix

Цитата ("frig"):

MMM_Corp, Вы занимаетесь тестированием? Как это дело происходит? Чо почем?

Занимаюсь, тестинг прикладного и веб-софта и сайтов.

Тема очень обширная, для начала тестирования нужно определится что тестировать: крос, стресс, безопасность, юзабилити, опечатки, и т.д.,
в основном заказывают все сразу, что относится к вебу, то чаще всего подверженны атакам не сам скрипт а сам сервак, в общем задайте вопрос конкретней.

В отзывах есть выполненные проекты по САБЖу.

Цитата ("MMM_Corp"):

Тема очень обширная, для начала тестирования нужно определится что тестировать

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

e1it3, я почему еще спрашиваю - можно то и самому протестировать, но редко кто это делает. ИМХО если ты сам написал код, то тебе будет сложно его ломать и тестировать тоже. Так, поверхностное тестирование производится, но это не то о чем я говорю. Речь не о проверке работоспособности, а о полномасштабных тестах, чтобы можно было с уверенностью сказать, что вот этот код работает и он безопасен.

Я не претендую на звания профи по безопасности сайтов, но со своего опыта скажу, что в 90% случаев уже проверенные сайты и т.д. допускают не тех. а простейшие логические оплошности.
Сразу приведу пример, когдато давно на веблансере при входе надо было только вести логин и пароль, сколько угодно раз. Это грубая ошибка потому что нет припятсвый для брутфорса, еще в помощь сразу готовый логин юзера, который светится у каждого. Вот вам простой пример логической ошибки при планировании, я правда настоял на усложнении формы входа, теперь уже хоть не так то можно грубо перебирать комбинации. За что даже получил скромное вознаграждение)))

Еще простой пример: админка, почти всегда можно быть увереным что когда попали в админку, то логин будет Admin, ну думаю это уже итак класика) но вот мало кто делает простое усложнение для входа в эту форму, а делается это очень просто, в скрипт ввода логина и пароля добавляете как параметр какойто ключ, любой, а в скрипте проверяете его, если ключ неверный то делаете die, это заметьте всего 1 строчка кода! Но многие этого просто таки не делают.

В техническом плане бывает по разному, в одних слуаях это полный 3,14 здец..., напр:
1. Почти всегда когда смотрю на код многих веб-разработчиков, то прихожу в ужас от незнания основ работы с БД, даже не представляют что такое транзакция, хранимка и пр. вещи. эту болезнь наблюдал почти во всех 100% подопытных.
2. SQL-инекции, болезнь всех новичков, причем жуткое нежелание писать хранимки, этому способствует само веб-общество, напр. тем же Active Record и пр. вещи, когда выносят бизнес-логику в другой слой, почему то веб-разработчики смотрят на БД просто как на хранилище данных, а надо смотреть как на прослойку бизнес логики, всеголиш надо потратить 1 день на изучение SQL (имею вbду не уровень идиота первокурсника с операциями select, update, delete, insert, а намного шире, в идеале вся логика должна бить в БД, это выгодно всем кроме веб-разработчика, именно веб, потому что в прикладном ПО, разве что только разработчики под .Net Framework, будут вовсю использовать LINQ, по сути с него и делалось AR).

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

Unit-test:
В гугле масса инфи по теме, в крупных проектах для тестирования критических областей часто пишут простыми словами модули для проверки работы отдельных частей кода, проводят его профилирование, если еще проще - то моделируют определенную ситуацию, и проводят над ней тестирование. Средств для этого тьма, но вот беда в том что даже очень небедные и неглупые заказчики отказываются оплачивать подобную работу, не видят в этом смысла, ну и Бог с ними, но если вы намерены работать неодин год над большим проектом то делайте документацыю, заведите SVN, багтрекер, пишите кейс (юнит) тесты, в будущем оцените сколько времени это экономит. И здесь нет разницы какой язык, будь то делфи, пхп, или даже T-SQL, это можно делать на чем угодно.

Могу продолжать до бесконечности, руки боюсь сотру)))
П.С. Конечно многих моментов я раскрывать не буду, не хочу делать себе конкурентов, сами понимаете)

MMM_Corp, многое из того что вы говорите - вопросы архитектуры и аудита кода. Речь не о том. Речь о простом тестировании.

Немного по вашему посту.
Цитата ("MMM_Corp"):

а делается это очень просто, в скрипт ввода логина и пароля добавляете как параметр какойто ключ, любой, а в скрипте проверяете его

Если ключ есть в форме - я его прочитаю и передам. Брутфорс это усложняет слабо.

Цитата ("MMM_Corp"):

от незнания основ работы с БД, даже не представляют что такое транзакция, хранимка и пр. вещи.

Дело в том, что далеко не всегда это актуально. Можно хоть всю логику вынести в БД, но кто его такое будет поддерживать? А если надо будет сменить БД - все это переписывать заново? Это уж не говоря о том, что сервера баз данных масштабируются куда хуже, чем веб сервера. По этой, наверное, причине (я не уверен) Facebook не использует все эти прелести. В общем штуки крутые и местами удобные, да, но применять их везде без разбора - не айс. Скорее даже не так - надо трижды подумать, прежде чем применять. Это, можно считать, больше экзотика.

Цитата ("MMM_Corp"):

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

Это очень сложный архитектурный вопрос.

Цитата ("MMM_Corp"):

Здесь все просто - любую проверку крос, надо начинать с валидатора, здесь даже и думать ненадчем, верстка должна быть идеальной.

Верстка это мелочи. Как проверить работу javascript? Его сейчас много, он повсюду, а браузеры понимают его каждый по своему. Только ручками сидеть и тыкать в кнопочки. Хотя есть, конечно, методы автоматического тестирования этих вещей, но это уже вопрос к профессионалам. Не думаю, что это актуально на малых объемах. Проще и правильнее просто посидеть и потыкать в кнопочки.

Цитата:

Конечно многих моментов я раскрывать не буду, не хочу делать себе конкурентов, сами понимаете)

Ну вообще не очень понимаю . Если я хочу чему-то научиться, то я научусь. Ваши слова мне америки не открыли, правда. Вопрос все же несколько в другом

где найти тестера, который будет качественно именно тестировать, а не анализировать архитектуру и не проводить аудит кода? Просто тестер. Не знаю точно как это проиходит. Тест планы какие-то, тест кейсы - и вперед. Из релиза в релиз. На мой взгляд сугубо отдельная специализация. Я бы так может тоже мог, но быстро бы вскипел

Я когда работал в команде с тестером - просто время от времени в redmine появлялись баги) не думаю, что там был какой-то план... там скорее просто уже человек "надрессирован" до уровня рефлексов ) на автомате все возможные случаи тестит )

>где найти тестера, который будет качественно именно тестировать
Возьмите кусок кода и протестируйте его сами, попросите друзей/коллег. вот потратьте на это уйму времени и тестируйте до посинения. запишите все баги )
а потом претендентам дайте в качестве тестового задание )

сравните время и качество )

У... как все запущено, по пунктам:
Цитата ("frig"):

Если ключ есть в форме - я его прочитаю и передам. Брутфорс это усложняет слабо.

никакого ключа в форме ненадо, смотрите:
чтобы попасть в админку на веблансере напр. нужно зайти ссылка
и там уже форма ввода логина и пароля админа, но если сделать чтобы заход был примерно так:
ссылка
а в этом скрипте просто первой строкой пусть будет идти: if (key!=yy9gg9) die(404); (примерно так...)
то... думаю самы понимаете как это поможет, кстати это не защащает от брутфорса, это простое сокрытие формы, по поводу брутфорса там еще можно понаписывать всякого)

Цитата ("frig"):

Это, можно считать, больше экзотика.

Это не экзотика, это у вас просто говорит неопытность в разработке клиент-серверных приложений, веб-сайт это не клиент сервер, это просто приложение которое работает как терминал, где браузер просто средство терминала, у вас вся логика сосредоточена только в 1 месте, я поэтому и говорю что вебщики смотрят на БД просто как на хранилище, не более того, оно и так и есть, ведь при таком подходе нет разницы где логика в пхп или в БД, но! Если напр. написали сайт, а к нему программу, которая работает напрямую с БД, а потом еще и АПИ нужно приделать ко всему этому, то рано или поздно вы поймете как важно выносить логику по максимум именно в БД. Возможно просто никогда над этим не думали.

Цитата ("frig"):

Верстка это мелочи

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

Цитата ("frig"):

Ваши слова мне америки не открыли, правда

И мне никто Америки не открывал, всего не объяснить, все приходит с опытом.

Цитата ("frig"):

Просто тестер.

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

Цитата ("MMM_Corp"):

Это не экзотика, это у вас просто говорит неопытность в разработке клиент-серверных приложений

Наверное. Я веб программист и занимаюсь веб программированием. Кстати вопрос касается именно тестирования в вебе - именно того самого веб программирования которым я занимаюсь .

Цитата ("MMM_Corp"):

ведь при таком подходе нет разницы где логика в пхп или в БД

Разница есть как раз. И довольно приличная.
Цитата ("MMM_Corp"):

а к нему программу, которая работает напрямую с БД

А не надо писать программу которая работает напрямую с БД. Пускай работает с API которое реализует необходимый функционал. Прямой доступ к БД - нонсенс. При каждом изменении структуры мне все клиенты переписывать? Уж увольте. Лучше уж пускай будет уровень абстракции (API) который все это нивелирует.
Цитата ("MMM_Corp"):

Возможно просто никогда над этим не думали.

Ну вот выше только что подумал. На мой взгляд отличное решение. Без привязки к конкретной БД, без зависимости от схемы и типа БД - абстракция на сколько возможно. Четкий интерфейс и минимальная связанность компонентов. Отлично ведь!

Цитата ("MMM_Corp"):

это обличие вашего продукта

Про javascript прочитайте еще раз. Обличие это здорово, но это мелочи так как проверяется элементарно. Открыли страничку - посмотрели, промеряли рулеткой отступы и готово. А протестировать весь js для всех ситуаций во всех браузерах - проблему куда большая, на мой взгляд. Тут валидатор не поможет.

Цитата ("MMM_Corp"):

Помоему каждый участник сайта тестер в вашем понимании

Нет. Каждый участник не будет досконально проверять весь объем функционала, не будет проверять все состояния системы во множестве браузеров. Это со временем произойдет, но такое тестирование это как раз то, от чего хочется уйти. Хочется стабильный продукт, а не нечто, что потом надо будет в течении 3-х месяцев править по жалобам пользователей. Продукт хочется, а не поделку.

Цитата ("MMM_Corp"):

поймите простую вещь - тестер - не друг кодера, он его злейший враг

Я с этим категорически не согласен. Я программист и я хочу делать качественные и нужные вещи. Любой, кто мне в этом помогает - мой друг. Поделки на уровне "запустил - вроде работает" мне уже откровенно говоря надоели. Не тот этот уровень на котором я хочу работать.

Цитата ("MMM_Corp"):

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

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

Где взять то такого?

Цитата ("frig"):

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

Да, правильно понимаете.
Тестировщик (QA) необходим однозначно. Желательно — несколько разных тестировщиков, возможно, из разных команд.
Но этого мало. Дело в том, что тестировщики работают с проектом обычно по принципу черного ящика, а этого недостаточно.

Не менее важен контроль качества (QC), то есть анализ исходного кода и других проектных артефактов (схема БД, сверстанный HTML, документация, и т.д.). Это уже обычно далает не тестировщик, а эксперт со стороны. Ну что значит эксперт... он не обязательно должен быть крутым, хотя и желательно найти матерого спеца... обычно это просто программист, верстальщик, или менеджер/аналитик и т.д., смотря что проверяется, но, важно, чтобы он был со стороны, не из числа разработчиков. Так как важен свежий взгляд со стороны. И экспертов тоже жалательно иметь несколько разных, не знающих друг о друге.

Работает это так. Составляется план тестирования. Описывающий те кейсы, которые Вы хотите чтобы были протестированы. Затем план отдается тестировщикам или экспертам со стороны, они работают с вашим проектом по этому плану, и затем готовят отчет. При этом в рамках QA тестируется заявленный функционал (включая функциональные, нагрузочные и стресс тесты), а в рамках QC код проверяется на наличие ламерства (явных ляпов), избыточности, проверяется документированность, соответствие стилю, делается анализ производительности, безопасности и т.д.

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

tvv, спасибо за ответ. Ждал и надеялся, что вы появитесь в теме

Цитата ("tvv"):

Желательно — несколько разных тестировщиков, возможно, из разных команд.

Ну это конечно верх мечтаний

Цитата ("tvv"):

Составляется план тестирования. Описывающий те кейсы, которые Вы хотите чтобы были протестированы.

Не совсем понятно тут. Кто составляет план тестирования? Судя по тому, что он отдается потом тестерам/экспертам - это делают не они, верно? А кто? Это ж надо в этом деле понимать.



Цитата ("tvv"):

Но без подобного подхода шансы сделать качественный продукт стремятся к нулю.

Понимание этого собственно и подтолкнуло.

Цитата ("frig"):

Не совсем понятно тут. Кто составляет план тестирования? Судя по тому, что он отдается потом тестерам/экспертам - это делают не они, верно? А кто? Это ж надо в этом деле понимать.

Составление тест плана — это аналитическая работа, по важности уступающая разве что составлению спецификации проекта (ТЗ).

В чем именно важность тест плана? Допустим, Вы написали проект согласно ТЗ. Нужно сдавать его заказчику. А заказчик прицепился к какой-либо фиче, которая в ТЗ описана недостаточно четко, и всё, не принимает проект, требует доработки. А всего ведь никогда не получится описать... Например, может оказаться, что сайт ведет себя как-то не так, как ожидал для себя заказчик, при нажатии кнопки Back браузера. Или форма регистрации не сабмитится при очень быстром нажатии три раза подряд кнопки "регистрация", а заказчик ожидал что-то другого. Или что-то не грузится при установленных параноидальных опциях безопасности браузера. И т.д., такие вот как бы общие вещи, которые как бы должны быть сделаны по мнению заказчика по-умолчанию. Самое интересное, что такого заказчика нельзя назвать неправым. Нужно исправлять. Но за чей счет?

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

Этот документ полезен всем. Он защищает заказчика, так как он теперь более-менее четко понимает что получится на выходе и как принимать работу. Ведь непрохождение тестов приравнивается к несдаче проекта, что очень доступно для понимания даже далеким от разработки сайтов заказчикам. Также тест план защищает разработчиков, так как тест план практически однозначно, чуть ли не на пошаговом уровне, определяет порядок сдачи проекта (в отличии от ТЗ, где определяются функциональные и прочие требования). Тестировщиков тест план тоже защищает, так как при его наличии в случае найденного позже фатального дефекта им не выдвинут обвинения "недотестировали!", и их работа и ответственность будет сводиться лишь к добросовестному прохождению каждого тест кейса, описанного в тест плане.

В ряде случаев без тест плана сдать проект без конфликтов может просто не получиться.

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

Обычно тест план пишется на основании ТЗ, при этом лишний раз перепроверяются проектные требования.

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

Если по ходу разработки проекта изменяется понимание как и что должно быть сделано, и вносятся изменения в изначальное ТЗ, соответственно необходимо поддерживать в актуальном состоянии и тест план. Так как именно по тест плану будет осуществляться приемка проекта заказчиком.

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

Тест план имеет смысл разделять на несколько частей. Одна часть, общая, может включать в себя тест кейсы, которые актуальны для подавляющего большинства веб проектов, практически любых. Например, тестирование времени доступа к странице сайта (должно быть не более N секунд при M параллельных реквестов). И вплоть до мелочей, типа тестирования запроса к /robots.txt (он должен существовать и быть валидным), тестирование запроса к /favicon.ico (он олжен существовать и быть картинкой), и т.д. Другие части тест плана могут быть уже специфичными, в зависимости от того или иного функционала. Отдельно могут идти тест кейсы по тестированию интерфейса, включая для браузеров с выключенным CSS и/или JavaScript. Отдельно могут быть тест кейсы для тестирования безопасности. И т.д., затрагиваемых аспектов может быть много.

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

tvv, большое спасибо!