Анализ уязвимостей web-приложений и способы защиты с использованием Java-технологий на примере организации. Часть 3

1  2  3

---

2.3. Мероприятия по обеспечению защиты web-приложений с использованием Java-технологий в организации

 

Чтобы создать эффективную методику, предоставляющую возможность тестирования на проникновение веб-приложения по перечню угроз и уязвимостей, которые указаны в рейтинге рисков OWASP Top — 10 требуется:

• выработать требования к методике, которая разрабатывается для тестирования на проникновение веб-приложения на наличие каждого из десяти рисков из списка OWASP Top — 10;
• провести выбор необходимых этапов из имеющихся методик, которые позволяют проводить тестирование на проникновение веб-приложения;
• выработать методику по тестированию на проникновение веб-приложения с определением стадий тестирования и программных средств, позволяющих осуществлять проверку наличия каждого из десяти рисков перечня OWASP Top — 10.

Методика по тестированию на проникновение веб-приложений согласно рейтингу рисков и уязвимостей OWASP Top — 10 обязана соответствовать таким требованиям:

• методикой должна учитываться необходимость в начальном сборе информации об открытых портах на сервере, запущенных на сервере службах, версию и тип веб-сервера, тип операционной системы, тип межсетевого экрана;
• методикой должна учитываться необходимость в тестировании веб-приложения на наличие элементов, которые могут в себе содержать известные уязвимости;
• методикой должна учитываться необходимость в тестировании средств по проверке входных данных в веб-приложения на наличие уязвимостей, которые могут повлечь за собой вставку инструкций (вставку SQL, XML — инструкций, межсайтовое выполнение сценариев);
• методикой должна учитываться проверка средств аутентификации на возможность осуществления угроз некорректной аутентификации;
• методикой должна учитываться проверка веб-приложения на потенциальную утечку конфиденциальных данных;
• методикой должна предоставляться возможность проведения проверки корректности контроля доступа;
• методикой должна учитываться необходимость в проверке веб-приложения на наличие уязвимостей в элементах, которые отвечают за десериализацию объектов;
• методикой должна учитываться необходимость в проверке элементов приложения, которые отвечают за ведение журналов и мониторинг;
• необходимо после реализации необходимых этапов тестирования сформировать отчёт об итогах тестирования.

С учётом требований, которые методика обязана содержать и рекомендаций в имеющихся методиках, считается целесообразным разделить тестирование на проникновение на такие этапы:

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

Рассмотрим реализацию для расширения функциональных тестов веб-приложений с использованием Java-технологий в организации.

Данный этап служит для определения информации о веб-приложении, запущенных службах, открытых портах, версии веб — сервера. Собранная информация свидетельствует об объёме информации, к которой может иметь доступ злоумышленник, который ее может использовать для поиска записей о имеющихся уязвимости в базах данных уязвимостей и реализовать атаку на веб-приложение.

Для реализации этапа по сбору информации был избран сканер Metasploit Framework, который входит в состав ОС Kali Linux. Зависимо от заданных опций программой формируются соответственные выходные данные. Сканирование при помощи Metasploit Framework осуществляется после того, как заданы специальных команд, общий синтаксис которых можно представить таким образом: Metasploit Framework [<Тип сканирования> ] [<Опции> ] {<Веб — адрес цели сканирования> }

Metasploit Framework применяется для:

• определения типа операционной системы;
• определения типа межсетевого экрана;
• определения версии и типа веб-сервера;
• сканирования запущенных служб на сервере;
• проверки открытых портов на сервере.

На рисунке 2.4 показан пример работы Metasploit Framework.

 

После того, как информация собрана, необходимо осуществить проверку наличия эксплойтов для операционных систем и веб — серверов в соответствии с версиями, для чего предлагается применять утилиту searchsploit, которая входит в состав ОС Kali Linux. Данная утилита применяет базу данных эксплойтов Exploit Database, которую можно использовать в целях проверки вероятности атаки посредством имеющихся уязвимостей.

Обнаруженные эксплойты реализовываются программой Metasploit Framework, которая входит в состав Kali Linux и предоставляет возможность:

• имитирования сетевых атак;
• выявления уязвимостей системы;
• проверки эффективности работы систем по обнаружению вторжений;
• разработки новых эксплойтов;
• создания отчётов по итогам работы.

Запуск Metasploit Framework выполняется командой msfconsole. Важнейшими командами Metasploit Framework считаются:

• use — выбор конкретного эксплойта для работы;
• back – команда, предназначенная, чтобы прекратить работу с избранным модулем;
• show — вывести перечень модулей конкретного типа;
• set — установить значение конкретного объекта;
• run — запуск вспомогательного модуля после того, как установлены требуемые опции;
• info — вывод информации о модуле;
• search — найти конкретный модуль;
• check — проверить возможность целевой системы к уязвимости;
• sessions — вывод списка доступных сессий.

Пример поиска эксплойтов, которые касаются веб — серверов Apache реализовывается при помощи команды: searchsploit apache. На рисунке 2.5 показаны итоги работы утилиты searchsploit.

Рисунок 2.5 — Результат работы утилиты searchsploit

В качестве примера работы программы Metasploit Framework служит поиск и эксплуатация уязвимости при помощи эксплойта в системе по управлению контентом WordPress. Поиск следует начинать с запуска Metasploit Framework при помощи команды msfconsole, а поиск модулей, содержащих информацию об уязвимости WordPress, выполняют при помощи команды search wordpress. На рисунке 2.8 показан результат поиска модулей.

Рисунок 2.6 — Результат работы Metasploit Framework по поиску модулей, описывающих уязвимости WordPress

В соответствии с рисунком 2.6, для атаки на WordPress взят модуль auxiliary / scanner / http / wordpress_login_enum, отвечающий за взлом процесса аутентификации способом грубой силы.

Указанный модуль выбирается для работы при помощи команды:

use auxiliary/scanner/http/wordpress_login_enum.

Информацию о специфичностях применения данного модуля можно получить посредством команды:

info use auxiliary/scanner/http/wordpress_login_enum

Следующий этап состоит в указании адреса, на которой располагается веб – сайт, для чего применяется команда set RHOSTS <адреса_веб — сайта>. Помимо этого, требуется указать путь к файлу с паролями, перебор которых выполняется: set PASS_FILE /root710k-common-passwords.txt. Процесс перебора паролей по словарю при помощи Metasploit Framework представлен на рисунке 2.7.

Рисунок 2.7 — Процесс перебора паролей по словарю при помощи Metasploit Framework

После выполнения перебора паролей из словаря в случае нахождения совпадения, будет отображаться информация о завершившейся успехом аутентификации, которая показана на рисунке 2.8:

Рисунок 2.8 — Информация о найденном пароль способом перебора по словарю

Для тестирования средств по проверке входящих данных в веб-приложении необходимо выполнить такие действия:

• проверить параметры GET, POST в HTTP — запросах;
• проверить возможность переполнения буфера памяти, а также проверить препятствуют ли имеющиеся средства веб-приложения его переполнению;
• проверить, используется ли в веб-приложении единственный компонент управления проверкой ввода для любого из принятых типов данных.
• протестировать возможность регистрации ошибки проверки входных данных на стороне сервера
• протестировать возможность вставки SQL, XML — инструкций, межсайтовой реализации сценариев.

В первую очередь необходимо найти входные точки веб-приложения, которые могут считаться отправными точками для вероятных атак. В качестве точек входа данных могут служить части веб-приложения, выполняющие обработку HTTP — запросов (способы POST и GET), сокеты, порты. Необходимо также найти все параметры, которые передаются в HTTP — запросов, чтобы определить возможные места, где злоумышленник имеет возможность манипулировать данными. Чтобы провести тестирование на проникновение по этому этапу необходимо:

• выяснить, где применяются запросы GET и где применяются POST;
• найти все параметры, которые используются в запросе POST;
• найти все параметры, которые используются в запросе GET;
• найти все параметры строки запроса, многочисленные параметры могут находиться в одной строке и разделяться символами &, ~ ,: либо кодированием или каким-нибудь другим специальным символом.

В качестве примера GET и POST — запросов могут служить:

GET

https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100

&ITEM=z101a&PRICE=62.50&IP=x.x.x.x

POST https://x.x.x.x/Avv/authenticate.asy?service=login

Анализ GET и POST — запросов может выполняться модулем Burp Proxy, который является компонентом программы Burp Suite. Burp Proxy представляет собой прокси-элемент, предоставляющий возможность перехвата и проверки трафика между браузером и веб-приложением. Пример работы Burp Proxy, который перехватывает GET – запросы показан на рисунке 2.9.

Рисунок 2.9 — Пример работы Burp Proxy по анализу HTTP — запросов

Чтобы провести проверку возможности вставки SQL — инструкций, необходимо сначала определить тип URL. Имеется множество разнообразных шаблонов URL, к примеру:

nurl:item_id=

nurl:readnews.php?id=

inurl:news.php?id=

inurl:shopping.php?id =

URL веб-приложения может быть следующего вида:

http://www.example.com/page.php?id =28

В конец URL необходимо добавить символ «, чтобы строка имела такой вид:

http://www.example.com/rubrika.php?id=28′

Если выполнить переход по ссылке, то может появиться окно с сообщением, что такой страницы не существует и с информацией об ошибке, которая имеет вид:

java.sql.SQLException: ORA-00933: SQL command not properly ended at oracle.jdbc.dbaaccess.DBError.throwSqlException(DBError.java:180) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)

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

— поддержки БД: Microsoft Access, PostgreSQL, Oracle, MySQL, Firebird, SQLite, IBM DB2;

— поддержки 6-ти способов SQL — инструкций;

— поддержки подключения к БД;

— поддержки перечня пользователей, ролей, привилегий, хеш-паролей, БД, столбцов и таблиц.

Определяются существующие БД, которые применяются веб-приложением командой -u и —dbs:

onesql -u http://www.example.com/page.php?id=28—dbs .

На рисунке 2.10 представлен пример результата работы onesql.

Из рисунка 2.10 можно увидеть, что применяется СУБД MySQL 5, ОС веб — сервера FreeBSD, Apache 2.2.22, а также таблицы safecosmetics и information_schema. Последующие проверки могут состоять в проверке возможности доступа к записям в таблицах, а также в поиске эксплойтов для версий обнаруженного программного обеспечения. Остальные команды могут быть доступными по ссылке разработчика onesql. Поиск эксплойтов осуществляется посредством Metasploit Framework.

Рисунок 2.10 — Результата работы onesql

Проверка возможности межсайтовой реализации сценариев состоит в отправке в веб-приложение данных, которые должны или подвергаться проверке, или являться причиной нарушения логики работы веб-приложения. В качестве примера подобных данных могут послужить заполнение полей в форме регистрации, которую заполняет пользователь, а также их отправка на сервер. Данные для заполнения могут иметь такой вид: <script> alert (1) </ script>. Если имеются уязвимостей, которые приводят к межсайтовой реализации сценариев, то на стороне пользователя будет отображаться окно, показанное на рисунке 2.11.

Рисунок 2.11 — Результат ответа от сервера при наличии уязвимостей межсайтовой реализации сценариев

Тестирование на возможность межсайтовой реализации сценариев осуществляется при помощи Burp Suite. Из рисунка 2.12 можно увидеть, что с веб-сайта разработчика Burp Suite, программа предоставляет возможность задачи необходимых параметров для запроса, а также отправки запроса на сервер.

Рисунок 2.12 — Окно отображения параметров, передающихся в веб-приложение при помощи программы Burp Suite

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

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

Чтобы реализовать тестирование на проникновение на этом этапе необходимы такие средства: Burp Suite, Metasploit Framework.

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

Сначала следует определить порты, которые содержат SSL / TLS – службы, что можно сделать сканером Metasploit Framework и командой: Metasploit Framework -sV — reason -PN -n —top-ports 100 www.example.com, где -sV –это проверка сервисов портах, а —reason — метод подсоединения к порту -PN — проверка всех доступных хостов, —top-ports 100 — команда по сканированию портов и их число www.example.com – сканируемый веб–адрес.

На рисунке 2.13 показано, каким может быть результат работы программы Metasploit Framework по указанной команде.

Рисунок 2.13 — Пример сканирования портов

На рисунке 2.13 можно увидеть, что из просканированных 100 портов, фильтруются 89, а все остальные открыты, информация о службах, которые работают на таких портах считается доступной. Проверка информации об устойчивости алгоритмов по шифрованию, которые содержатся в SSL / HTTP — службе на порту 443 выполняется командой Metasploit Framework -sV — script ssl-enum-ciphers -p 443 <host>, где -sV

—script

ssl-enum-ciphers -p 443 <host>

На рисунке 2.14 показан результат работы программы Metasploit Framework по указанной команде.

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

Рисунок 2.14 — Фрагмент результата сканирования алгоритмов, поддерживаемых SSL / HTTP — службой на порту 443

Суть контроля доступа состоит в предоставлении доступа к ресурсам исключительно тем, у кого имеется право на их применение. Принимая это во внимание, необходимо выполнять тестирование, предусматривающее:

• тестирование наличия незащищённых ссылок на объекты;
• тестирование возможности эскалации привилегий.

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

POST/user/viewOrder.jsp HTTP/1.1

Host: www.example.com

groupID=grp001&orderID=0,001

В данном запросе применяется orderID и groupID. Необходимо выполнить проверку того, сможет ли пользователь с другим значением orderID и groupID получить доступ.

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

http://example.com/somepage?value=12345, где параметр value обладает значением 12345 как индекс записи в БД. Чтобы проверить возможность доступа к другой записи следует поменять значение value на другое значение. Вследствие чего запись будет или отсутствовать, или будет выводиться информация о новой записи.

Сериализация применяется в целях преобразования некоего объекта в формат данных, который в дальнейшем можно сохранять и восстанавливать. Десериализации реализовывается в целях обработки данных в конкретном формате и их перестройки в объект. Веб-приложения могут быть уязвимыми к атакам на базе наличия реализации незащищённой десериализации, если они выполняют десериализацию объекты, которые могут предоставляться злоумышленниками и пользователями. У злоумышленника имеется возможность изменения логики работы программы, выполняя десериализацию в приложении объекта, содержащего вредоносный код.

Перечислим элементы веб – приложения, которые необходимо протестировать на наличие уязвимостей механизмов десериализации:

• токены аутентификации;
• параметры HTML-формы;
• файловые системы;
• системы управления БД;
• веб-сервисы;
• протоколы.

Программные средства, применяющиеся для тестирования элементов веб-приложений: для сбора информации и в целях поиска эксплойтов для уязвимых модулей — Metasploit Framework.

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

• проверка веб-приложения на возможность предоставления пользователю сообщения об ошибках и переводе;
• Средства веб-приложения должны регистрировать:
• время и дата создания каждой из записей;
• время и дата события;
• веб-адрес приложения, номер порта;
• идентификаторы программ, их версия и название;
• запущенные службы;
• безуспешные проверки входных данных (недопустимые кодирования, протокольные нарушения, неверные параметры значений и имён);
• события исправления ошибок проверки исходных данных;
• случаи успешной аутентификации;
• случаи безуспешной аутентификации (контроль доступа);
• случаи модификации файлов программного кода;
• случаи модификации конфигурации;
• идентификатор машины/ устройства пользователя, его IP-адрес;
• случаи применения функций повышенного риска (сетевые соединения, изменение привилегий, удаление или добавление пользователей, доступ администраторов веб-приложений, применение системных административных привилегий, все действия пользователей, имеющих административные права, доступ к данным держателей платёжных карт, применение ключа шифрования данных, замены ключа, удаление и создание объектов системного уровня, экспорта и импорта данных, загрузки файлов);
• подробная информация о сообщениях в отношении системных ошибок, информация о процессе отладки, заголовки HTTP — запросов и основная их часть;
• организован контроль доступа к журналам событий.

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

В сообщениях об ошибках, отображающиеся пользователю, не должны содержаться данные, которые могут злоумышленнику помочь (идентификатор сеанса, версии и названия программ, которые применяются). Проверка по такому критерию реализовывается командой telnet, доступной в Kali Linux. Синтаксис команды обязан быть таким: telnet <веб_адрес> 80 GET <страница, что не существует> HTTP / 1.1. Ответ сервера о странице, которая не существует, может включать дополнительную информацию, к примеру:

HTTP / 1.1 404 Not Found

Date: Sat, 04 Nov 201715: 26: 48 GMT

Server: Apache / 2.2.3 (Unix) mod_ssl / 2.2.3 OpenSSL / 0.9.7g

Content-Length: 310

Connection: close

Content-Type: text / html; charset = iso-8859-1

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

В результате выполнения тестирования, рекомендуется в работе внедрение возможностей Burp Proxy и onesql в продукт Metasploit Framework для выполнения полноценного автоматизированного тестирования интегрированных средств разработки веб-приложений от уязвимостей.

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

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

 

ЗАКЛЮЧЕНИЕ

 

В результате выполнения работы проведено исследование методов расширяемости интегрированных сред тестирования веб-уязвимостей.

В результате выполнения первой главы рассмотрена проблема исследования интегрированных средств тестирования уязвимостей, разработаны критерии для анализа средств тестирования веб-уязвимостей и проведен обзор некоторых технологий тестирования. Как выяснилось, рассмотренные технологии не смогли показать стопроцентный результат.

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

Во второй главе работы были рассмотрены виды уязвимостей веб-сайта, которые по версии ресурса OWASP, встречаются больше всего. Установлено, что среди таких программных проблем, как СSRF, XSS или SQL инъекции, существуют и проблемы, затрагивающие настройку серверов, которые также часто приводят к проблемам. Зная какие уязвимости сайтов существуют, можно любой ресурс сделать более безопасным.

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

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

В результате выполнения тестирования, рекомендуется в работе внедрение возможностей Burp Proxy и onesql в продукт Metasploit Framework для выполнения полноценного автоматизированного тестирования интегрированных средств разработки веб-приложений от уязвимостей.

Предлагаемая в предоставленной работе методика учитывает мировые достижения в тестировании веб-приложений и предоставляет возможность проверки наличия уязвимостей из перечня OWASP Top-10. От имеющихся методик предлагаемая методика различается тем, что она затрагивает исключительно вопросы, которые относятся к поиску уязвимостей веб-приложений из OWASP Top-10, позволяя ускорить анализ количества требуемых проверок для тестирования.

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

В предложенной методике применяется ограниченное число этапов тестирования и средств по тестированию, предоставляющие возможность эффективного проведения тестирования на проникновение в соответствии со списком уязвимостей OWASP Top-10.

 

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

 

1. А. С. Марков, А. А. Фадин. Система уязвимостей и дефектов безопасности программах ресурсов. Защита информации. INSIDE №3`2013
2. А. С. Марков, С.В. Миронов, В.Л. Цирлов. Выявление уязвимостей в программном коде. Открытые системы. СУБД. 2005. №12 с.64-69.
3. Багаев Д. С., Коробкин Д. И., ОкрачковА.А., Рогозин Е. А. Таксономия угроз качеству функционирования компьютерных систем // Вестник Воронежского государственного технического университета. 2008, т. 4, №10, с.140–142.
4. И. В. Русских. Инкрементальный синтаксический анализ в средах разработки и текстовых редакторах / И. В. Русских // Вестник Нижегородского университета им. Н.И. Лобачевского. – 2007. – No1. – С. 189-196.
5. М. И. Глухих, В.М. Ицыксон. Программная инженерия. Обеспечение качества программных средств методами статического анализа. СПб.: Изд-во Политехн. ун-та, 2011.
6. Марков А. С. Анализ атак на сети Novell Netware, основанный на таксономии угроз информационной безопасности // Известия вузов. Приборостроение. 2000, т. 43, № 4, с. 30–34.
7. Марков А. С., Фадин А. А., Цирлов В. Л. Систематика дефектов и уязвимостей программного обеспечения // Сборник трудов Второй 75 всероссийской НТК «Безопасные информационные технологии» / под. ред. В. А. Матвеева. – М: НИИ РЛ МГТУ им. Н. Э. Баумана, 2011, с. 83–87
8. Мукминов В. А., Войнов Ю. В. Методика оценки реального уровня защищенности АСУ в условиях компьютерных атак // Известия Института инженерной физики. 2013, т. 1, № 27, с. 80–85.
9. Н. В. Медведев, А. С. Марков, А. А. Фадин. Применение метода статического сигнатурного анализа для выявления дефектов безопасности веб-приложений. Наука и образование. Научное издание МГТУ им. Н. Э. Баумана. 09.09.2012. стр. 297-316.
10. Программирование на языке JAVA. [Электронный ресурс]: А.В. Картузов. — 2013. — Режим доступа : http://www.mstu.edu.ru/study/materials/java/
11. С. П. Вартанов. Динамический анализ программ с целью поиска ошибок и уязвимостей при помощи целенаправленной генерации входных данных / 99 С. П. Вартанов, А. Ю. Герасимов // Труды ИСП РАН. – 2014. – Т. 26, No1. – С. 375-394
12. Савин. Р. Тестирование Дот Ком, или Пособие по жесткому обращению багами в интернет-стартапах / Р. Савин. — Дело, 2007. — 312 с.
13. Самойлов, В. Д. Модельное конструирование компьютерных приложений / В. Д. Самойлов. — К.: Наукова думка. — 2007. — 198 с.
14. Хабрахабр . Descriptive Programming в QuickTest Pro. [Электронный ресурс]: В.В. Ягилюк. — 2009. — Режим доступа : https://habrahabr.ru/post/69138/
15. Хабрахабр. CodedUI или Ranorex? Автоматизация функционального тестирования .NET приложений. [Электронный ресурс]: В.В. Джигда. — 2013. — Режим доступа: https://habrahabr.ru/company/2gis/blog/188302/
16. Хабрахабр. Composer — менеджер зависимостей для PHP. [Электронный ресурс]: Р.И. Ружков. — 2012. — Режим доступа: https://habrahabr.ru/post/145946/
17. A verifiable SSA program representation for aggressive compiler optimization V. Menon, N. Glew, B. Murphy and oth. // POPL ’06 Conference record of the 33rd ACM SIGPLAN-SIGACT symposium on Principles of programming languages. – 2006. – P. 397-408.
18. API testing. [Электронный ресурс] // guru99 — professional courses. — Режим доступа : http://www.guru99.com/api-testing.html
19. Automated Testing of Desktop. Web. Mobile. [Электронный ресурс] // Ranorex Company. — Режим доступа : http://www.ranorex.com/
20. Brusilovsky, P. Methods and techniques of adaptive hypermedia / Brusilovsky // User Modeling and User-Adapted Interaction. — 1996. — № 6 (2-3). — P. 87-129.
21. Bugs Catcher. Telerik WebUI Test Studio. [Электронный ресурс]: B.H. Лувин. — 2011. — Режим доступа : http://bugscatcher.net/archives/817
22. De Bra, P. Web-based educational hypermedia / De Bra // Book chapter in: Data Mining in E-Learning / [edited by C. Romero and S. Ventura]. — Universidad de Cordoba, Spain, WIT Press., 2006. — P. 3-17.- ISBN 1-84564-152-3.
23. DevColibri. Unit тестирование с JUnit. [Электронный ресурс]: А.Р. Шуляк. — 2013. — Режим доступа : http://devcolibri.com/864
24. Encyclopedia of Artificial Intelligence. 2nd ed. / [S. C. Shapiro editor.]. — New York: John Wiley & Sons, 1992. — Volume 1. — p. 434.
25. HP Unified Functional Testing software [Электронный ресурс] // Web-site of Hewlett-Packard Company. — Режим доступа: http://www8.hp.com/h20195/V2/GetPDF.aspx/4AA4-8360ENW.pdf
26. IEEE Guide to Software Engineering Body of Knowledge (SWEBOK) / IEEE Computer Society. — IEEE Computer Society Press, 2004. — 204p.
27. International Forum of Educational Technology & Society [Электронный ресурс]. — Режим доступа: http://ifets.ieee.org/.
28. International Journal of Artificial Intelligence in Education (IJAIED) [Электронный ресурс]. — Режим доступа: http://aied.inf.ed.ac.uk/.
29. ISO 8402:1994 Quality management and quality assurance. — International Organization for Standardization, 1994. — 39р.
30. Skybot Job Scheduler [Электронный ресурс] // HelpSystems issues. — Режим доступа: http://www.helpsystems.com/skybot/products/skybot-scheduler
31. Stanier J. Intermediate representations in imperative compilers: A survey / J. Stanier, D. Watson // ACM Computing Surveys (CSUR). – 2013. – V. 45 No 3. – Article No. 26.
32. Steven S. Muchnik «Advanced Compiler Design And Implementation», Morgan Kaufmann Publishers, July 1997. 880 pp.
33. Test Studio [Электронный ресурс] // Web-site of Telerik. — Режим доступа: http://www.telerik.com/teststudio
34. TestComplete Platform: Testing for Desktop, Mobile, & Web Applications [Электронный ресурс] // Web-site of Smartbear. — Режим доступа: http://smartbear.com/product/testcomplete/overview/
35. What is Selenium? [Электронный ресурс] // Selenium HQ. — Режим доступа: http://docs.seleniumhq.org/

---

1  2  3