Тестирование безопасности - Краткое руководство

Тестирование безопасности очень важно для защиты системы от вредоносных действий в Интернете.

Что такое тестирование безопасности?

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

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

• Confidentiality - Он защищает от раскрытия информации непреднамеренным получателям.

• Integrity - Это позволяет передавать точную и правильную желаемую информацию от отправителей к предполагаемым получателям.

• Authentication - Он проверяет и подтверждает личность пользователя.

• Authorization - Он определяет права доступа к пользователям и ресурсам.

• Availability - Обеспечивает готовность информации по запросу.

• Non-repudiation - Это гарантирует отсутствие отказа со стороны отправителя или получателя в отправке или получении сообщения.

пример

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

• Войдите в веб-приложение, используя действительные учетные данные.

• Выйдите из веб-приложения.

• Нажмите в браузере кнопку НАЗАД.

• Убедитесь, что вас снова просят войти в систему или вы можете снова вернуться на страницу входа.

Тестирование безопасности можно рассматривать как управляемую атаку на систему, которая реалистично выявляет недостатки безопасности. Его цель - оценить текущее состояние ИТ-системы. Он также известен какpenetration test или более популярно как ethical hacking.

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

Тест на проникновение - Рабочий процесс

Тест на проникновение включает четыре основных этапа -

• Печать стопы
• Scanning
• Enumeration
• Exploitation

Эти четыре шага повторяются несколько раз, что идет рука об руку с обычным SDLC.

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

Вредоносное ПО

Различные формы вредоносных программ перечислены ниже -

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

• Worm - Червь - это тип вредоносного ПО, которое оставляет свою копию в памяти каждого компьютера на своем пути.

• Trojan - Троянец - это несамовоспроизводящееся вредоносное ПО, которое содержит вредоносный код, выполнение которого приводит к потере или краже данных или возможному повреждению системы.

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

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

• Rootkit - Руткит - это программное обеспечение, используемое хакером для получения доступа на уровне администратора к компьютеру / сети, которое устанавливается с помощью украденного пароля или путем использования уязвимости системы без ведома жертвы.

Предупредительные меры

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

• Убедитесь, что операционная система и приложения обновлены с помощью исправлений / обновлений.

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

• Когда вы загружаете из Интернета, всегда проверяйте, что вы устанавливаете. Не нажимайте просто ОК, чтобы закрыть всплывающие окна. Перед установкой приложения проверьте издателя.

• Установите антивирусное программное обеспечение.

• Убедитесь, что вы регулярно сканируете и обновляете антивирусные программы.

• Установите брандмауэр.

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

Программное обеспечение для защиты от вредоносных программ

Следующее программное обеспечение помогает удалить вредоносные программы из системы -

• Microsoft Security Essentials
• Защитник Microsoft Windows
• AVG Internet Security
• Spybot - поиск и уничтожение
• Avast! Домашняя версия для личного пользования
• Панда Интернет-безопасность
• MacScan для Mac OS и Mac OS X

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

Протокол HTTP

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

По сути, HTTP - это протокол связи на основе TCP / IP, который используется для доставки данных, таких как файлы HTML, файлы изображений, результаты запросов и т. Д., Через Интернет. Он обеспечивает стандартизированный способ взаимодействия компьютеров друг с другом. Спецификация HTTP определяет, как запрашиваемые данные клиентов отправляются на сервер и как серверы отвечают на эти запросы.

Основные характеристики

Следующие три основные функции делают HTTP простым, но мощным протоколом:

• HTTP is connectionless- HTTP-клиент, то есть браузер инициирует HTTP-запрос. После отправки запроса клиент отключается от сервера и ждет ответа. Сервер обрабатывает запрос и повторно устанавливает соединение с клиентом, чтобы отправить ответ обратно.

• HTTP is media independent- Любой тип данных может быть отправлен по HTTP, если и клиент, и сервер знают, как обрабатывать содержимое данных. Это необходимо для клиента и сервера, чтобы указать тип контента с использованием соответствующего MIME-типа.

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

HTTP / 1.0 использует новое соединение для каждого обмена запрос / ответ, тогда как соединение HTTP / 1.1 может использоваться для одного или нескольких обменов запрос / ответ.

Архитектура

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

Протокол HTTP - это протокол запроса / ответа, основанный на архитектуре клиент / сервер, где веб-браузер, роботы, поисковые системы и т. Д. Действуют как HTTP-клиенты, а веб-сервер действует как сервер.

• Client - HTTP-клиент отправляет запрос на сервер в форме метода запроса, URI и версии протокола, за которым следует MIME-подобное сообщение, содержащее модификаторы запроса, информацию о клиенте и возможное содержимое тела через соединение TCP / IP.

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

HTTP - Недостатки

• HTTP не является полностью защищенным протоколом.

• HTTP использует порт 80 как порт по умолчанию для связи.

• HTTP работает на уровне приложения. Для передачи данных необходимо создать несколько соединений, что увеличивает накладные расходы на администрирование.

• Для использования HTTP не требуется шифрования / цифровых сертификатов.

Сведения о протоколе HTTP

Чтобы лучше понять протокол HTTP, щелкните каждую из следующих ссылок.

• HTTP Parameters

• HTTP Messages

• HTTP Requests

• HTTP Responses

• HTTP Methods

• HTTP Status Codes

• HTTP Header Fields

• HTTP Security

HTTPS (протокол передачи гипертекста через Secure Socket Layer) или HTTP через SSL - это веб-протокол, разработанный Netscape. Это не протокол, это просто результат наложения HTTP поверх SSL / TLS (Secure Socket Layer / Transport Layer Security).

Короче говоря, HTTPS = HTTP + SSL.

Когда требуется HTTPS?

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

Протокол Https используется в следующих сценариях -

• Банковские сайты
• Платежный шлюз
• Сайты покупок
• Все страницы входа
• Электронная почта

Базовая работа HTTPS

• Для сервера по протоколу HTTPS требуются открытый ключ и подписанные сертификаты.

• Клиентские запросы для страницы https: //

• При использовании https-соединения сервер отвечает на начальное соединение, предлагая список методов шифрования, которые поддерживает веб-сервер.

• В ответ клиент выбирает метод подключения, а клиент и сервер обмениваются сертификатами для подтверждения своей личности.

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

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

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

Что такое кодирование и декодирование?

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

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

Кодирование и декодирование используются при передаче и хранении данных. Кодирование НЕ должно использоваться для передачи конфиденциальной информации.

Кодировка URL

URL-адреса могут быть отправлены через Интернет только с использованием набора символов ASCII, и есть случаи, когда URL-адрес содержит специальные символы, кроме символов ASCII, его необходимо закодировать. URL-адреса не содержат пробелов и заменяются знаком плюс (+) или% 20.

Кодирование ASCII

Браузер (на стороне клиента) будет кодировать ввод в соответствии с набором символов, используемым на веб-странице, а набор символов по умолчанию в HTML5 - UTF-8.

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

ASCII	Условное обозначение	Замена
<32		Кодировать с помощью% xx, где xx - шестнадцатеричное представление символа.
32	пространство	+ или% 20
33	!	% 21
34	"	% 22
35 год	#	% 23
36	$	% 24
37	%	% 25
38	&	% 26
39	'	% 27
40	(	% 28
41 год	)	% 29
42	*	*
43 год	+	% 2B
44	,	% 2C
45	-	-
46	.	.
47	/	% 2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	% 3A
59	;	% 3B
60	>	% 3C
61	знак равно	% 3D
62	>	% 3E
63	?	% 3F
64	@	% 40
65	А	А
66	B	B
67	C	C
68	D	D
69	E	E
70	F	F
71	г	г
72	ЧАС	ЧАС
73	я	я
74	J	J
75	K	K
76	L	L
77	M	M
78	N	N
79	О	О
80	п	п
81 год	Q	Q
82	р	р
83	S	S
84	Т	Т
85	U	U
86	V	V
87	W	W
88	Икс	Икс
89	Y	Y
90	Z	Z
91	[	% 5B
92	\	% 5C
93	]	% 5D
94	^	% 5E
95	_	_
96	`	% 60
97	а	а
98	б	б
99	c	c
100	d	d
101	е	е
102	ж	ж
103	г	г
104	час	час
105	я	я
106	j	j
107	k	k
108	л	л
109	м	м
110	п	п
111	о	о
112	п	п
113	q	q
114	р	р
115	s	s
116	т	т
117	ты	ты
118	v	v
119	ш	ш
120	Икс	Икс
121	y	y
122	z	z
123	{	% 7B
124	|	% 7C
125	}	% 7D
126	~	% 7E
127		% 7F
> 127		Кодировать с помощью% xx, где xx - шестнадцатеричное представление символа.

Что такое криптография?

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

Данные, которые можно прочитать и понять без каких-либо специальных мер, называются plaintext, а метод маскировки открытого текста для сокрытия его сути называется encryption.

Зашифрованный открытый текст известен как зашифрованный текст, а процесс возврата зашифрованных данных обратно в обычный текст известен как decryption.

• Наука анализа и взлома защищенной связи известна как криптоанализ. Люди, которые делают то же самое, также называются злоумышленниками.

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

• Следовательно, для расшифровки надежно зашифрованных сообщений требуется соответствующий инструмент декодирования.

• Существуют некоторые криптографические методы, с помощью которых даже миллиард компьютеров, выполняющих миллиард проверок в секунду, не может расшифровать текст.

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

Как работает шифрование?

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

Следовательно, зашифрованные данные полностью зависят от пары параметров, таких как сила криптографического алгоритма и секретность ключа.

Методы криптографии

Symmetric Encryption- Обычная криптография, также известная как обычное шифрование, - это метод, в котором для шифрования и дешифрования используется только один ключ. Например, DES, алгоритмы Triple DES, MARS от IBM, RC2, RC4, RC5, RC6.

Asymmetric Encryption- Это криптография с открытым ключом, которая использует пару ключей для шифрования: открытый ключ для шифрования данных и закрытый ключ для дешифрования. Открытый ключ публикуется для людей, а закрытый ключ сохраняется в секрете. Например, RSA, алгоритм цифровой подписи (DSA), Elgamal.

Hashing- Хеширование - это ОДНОСТОРОННЕЕ шифрование, которое создает скремблированный вывод, который нельзя отменить или, по крайней мере, нельзя легко отменить. Например, алгоритм MD5. Он используется для создания цифровых сертификатов, цифровых подписей, хранения паролей, проверки связи и т. Д.

Политика одинакового происхождения (SOP) - важная концепция в модели безопасности веб-приложений.

Что такое политика одинакового происхождения?

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

• Domain
• Protocol
• Port

пример

Причина такого поведения - безопасность. Если у вас есть try.com в одном окне и gmail.com в другом, то вы НЕ хотите, чтобы сценарий с try.com имел доступ к содержимому gmail.com или изменял его содержимое или выполнял действия в контексте gmail от вашего имени.

Ниже приведены веб-страницы того же происхождения. Как объяснялось ранее, один и тот же источник принимает во внимание домен / протокол / порт.

• http://website.com
• http://website.com/
• http://website.com/my/contact.html

Ниже приведены веб-страницы из другого источника.

• http://www.site.co.uk (другой домен)
• http://site.org (другой домен)
• https://site.com (другой протокол)
• http://site.com:8080 (другой порт)

Исключения из политики одинакового происхождения для IE

В Internet Explorer есть два основных исключения из SOP.

• Первый относится к «Надежным зонам». Если оба домена находятся в зоне с высоким уровнем доверия, политика одного источника не применима полностью.

• Второе исключение в IE связано с портом. IE не включает порт в политику одного источника, поэтому http://website.com и http://wesite.com:4444 считаются из одного источника и никаких ограничений не применяется.

Что такое cookie?

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

Свойства файлов cookie

Вот некоторые важные свойства файлов cookie -

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

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

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

• Файлы cookie неизбежны для веб-сайтов, которые имеют огромные базы данных, требуют входа в систему и имеют настраиваемые темы.

Содержание файлов cookie

Файл cookie содержит следующую информацию -

• Имя сервера, с которого был отправлен файл cookie.
• Время жизни куки.
• Значение - обычно это случайно сгенерированный уникальный номер.

Типы файлов cookie

• Session Cookies- Эти файлы cookie являются временными и стираются, когда пользователь закрывает браузер. Даже если пользователь снова входит в систему, создается новый файл cookie для этого сеанса.

• Persistent cookies- Эти файлы cookie остаются на жестком диске, пока пользователь не сотрет их или срок их действия не истечет. Срок действия файлов cookie зависит от того, как долго они могут длиться.

Тестирование файлов cookie

Вот способы проверить файлы cookie -

• Disabling Cookies- Как тестировщик, нам необходимо проверить доступ к веб-сайту после отключения файлов cookie и проверить, правильно ли работают страницы. Переходить на все страницы сайта и следить за сбоями приложений. Также необходимо сообщить пользователю, что для использования сайта необходимы файлы cookie.

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

• Removing Cookies - Удалите все файлы cookie для веб-сайта и проверьте, как веб-сайт на них реагирует.

• Cross-Browser Compatibility - Также важно убедиться, что файлы cookie записываются правильно во всех поддерживаемых браузерах с любой страницы, которая записывает файлы cookie.

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

Просмотр и редактирование файлов cookie

Современные браузеры поддерживают просмотр / редактирование файлов cookie в самом браузере. Существуют плагины для mozilla / chrome, с помощью которых мы можем успешно выполнить редактирование.

• Плагин редактирования файлов cookie для Firefox

• Изменить этот плагин cookie для Chrome

Для редактирования файла cookie необходимо выполнить следующие действия:

• Загрузите плагин для Chrome отсюда

• Измените значение файла cookie, просто открыв плагин редактирования этого файла cookie из Chrome, как показано ниже.

Существуют различные методологии / подходы, которые мы можем использовать в качестве справочника для выполнения атаки.

Веб-приложение - Методологии PenTesting

При разработке модели атаки можно учитывать следующие стандарты.

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

• PTES - Стандарт выполнения тестирования на проникновение

• OSSTMM - Руководство по методологии тестирования безопасности с открытым исходным кодом

• Методы тестирования OWASP - протокол безопасности открытого веб-приложения

OWASP Top 10

Команда Open Web Application Security Protocol опубликовала 10 основных уязвимостей, которые в последние годы более распространены в сети. Ниже приведен список недостатков безопасности, которые чаще встречаются в веб-приложениях.

Применение - Практика

Чтобы понять каждый из методов, давайте поработаем с примером приложения. Мы проведем атаку на WebGoat, приложение J2EE, которое явно разработано с учетом недостатков безопасности в учебных целях.

Полную информацию о проекте webgoat можно найти https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. Чтобы загрузить приложение WebGoat, перейдите кhttps://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) и перейти в раздел загрузок.

Чтобы установить загруженное приложение, сначала убедитесь, что у вас нет приложений, работающих на порту 8080. Его можно установить с помощью одной команды - java -jar WebGoat-6.0.1-war-exec.jar. Для более подробной информации посетите WebGoat Installation.

После установки мы сможем получить доступ к приложению, перейдя в http://localhost:8080/WebGoat/attack и страница будет отображаться, как показано ниже.

Мы можем использовать учетные данные гостя или администратора, как показано на странице входа.

Веб-прокси

Чтобы перехватить трафик между клиентом (браузером) и сервером (система, в которой размещено приложение Webgoat в нашем случае), нам необходимо использовать веб-прокси. Мы будем использовать Burp Proxy, который можно скачать сhttps://portswigger.net/burp/download.html

Достаточно загрузить бесплатную версию пакета burp, как показано ниже.

Настройка Burp Suite

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

Step 1- Приложение установлено на порт 8080, а Burp - на порт 8181, как показано ниже. Запустите пакет Burp и выполните следующие настройки, чтобы подключить его к порту 8181, как показано ниже.

Step 2- Мы должны убедиться, что Burp прослушивает порт №8080, на котором установлено приложение, чтобы пакет Burp мог перехватывать трафик. Эти настройки должны быть выполнены на вкладке объема в Burp Suite, как показано ниже.

Step 3- Затем настройте прокси-сервер в браузере на прослушивание порта 8181 (порт Burp Suite). Таким образом, мы настроили веб-прокси для перехвата трафика между клиентом (браузером) и сервером (веб-сервером), как показано ниже -

Step 4 - Снимок конфигурации показан ниже с помощью простой схемы рабочего процесса, как показано ниже.

Техника внедрения состоит из введения SQL-запроса или команды с использованием полей ввода приложения.

Веб-приложение - Внедрение

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

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

Примеры

Приложение использует ненадежные данные при построении следующего уязвимого вызова SQL:

String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";

Руки вверх

Step 1 - Перейдите в область приложения SQL Injection, как показано ниже.

Step 2- Как указано в упражнении, мы используем String SQL Injection для обхода аутентификации. Используйте SQL-инъекцию, чтобы войти в систему как босс («Невилл») без использования правильного пароля. Убедитесь, что профиль Невилла доступен для просмотра и доступны все функции (включая поиск, создание и удаление).

Step 3 - Мы внедрим SQL, чтобы мы могли обойти пароль, отправив параметр как 'a' = 'a' или 1 = 1

Step 4 - После эксплуатации мы можем войти в систему как Невилл, который является администратором, как показано ниже.

Предотвращение внедрения SQL

Есть много способов предотвратить SQL-инъекцию. Когда разработчики пишут код, они должны убедиться, что обрабатывают специальные символы соответствующим образом. OWASP предлагает чит-листы / методы предотвращения, которые определенно являются руководством для разработчиков.

• Использование параметризованных запросов
• Экранирование всех вводимых пользователем данных
• Включить наименьшие привилегии для базы данных для конечных пользователей

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

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

пример

An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

Авторизованный пользователь сайта пересылает URL своим друзьям, чтобы узнать о скидках. Он отправляет указанную выше ссылку по электронной почте, не зная, что пользователь также передает идентификаторы сеанса. Когда его друзья используют ссылку, они используют его сеанс и кредитную карту.

Руки вверх

Step 1- Войдите в Webgoat и перейдите в раздел «Недостатки управления сеансом». Давайте обойдем аутентификацию, подделав cookie. Ниже приведен снимок сценария.

Step 2 - Когда мы авторизуемся с использованием учетных данных webgoat / webgoat, мы находим из Burp Suite, что идентификатор JSESSION - C8F3177CCAFF380441ABF71090748F2E, а AuthCookie = 65432ubphcfx после успешной аутентификации.

Step 3 - Когда мы авторизуемся с использованием аспекта / аспекта учетных данных, мы обнаруживаем из Burp Suite, что идентификатор JSESSION - C8F3177CCAFF380441ABF71090748F2E, а AuthCookie = 65432udfqtb после успешной аутентификации.

Step 4- Теперь нам нужно проанализировать шаблоны AuthCookie. Первая половина «65432» является общей для обеих аутентификаций. Следовательно, теперь мы заинтересованы в анализе последней части значений authcookie, таких как - ubphcfx для пользователя webgoat и udfqtb для пользователя аспекта соответственно.

Step 5- Если мы внимательно посмотрим на значения AuthCookie, последняя часть имеет ту же длину, что и имя пользователя. Следовательно, очевидно, что имя пользователя используется с некоторым методом шифрования. С помощью механизмов проб и ошибок / перебора мы обнаруживаем, что после изменения имени пользователя webgoat; мы получаем taogbew, а затем перед алфавитным символом используется как AuthCookie. т.е. ubphcfx.

Step 6- Если мы передадим это значение cookie и посмотрим, что произойдет. После аутентификации в качестве пользователя webgoat измените значение AuthCookie, чтобы имитировать пользователя Алису, найдя AuthCookie для того же пользователя, выполнив шаги №4 и №5.

Предотвращающие механизмы

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

• Разработчики должны убедиться, что они избегают ошибок XSS, которые могут быть использованы для кражи идентификаторов сеансов.

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

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

Типы XSS

• Stored XSS - Сохраненный XSS, также известный как постоянный XSS, возникает, когда вводимые пользователем данные хранятся на целевом сервере, таком как база данных / форум сообщений / поле комментариев и т. Д. Затем жертва может получить сохраненные данные из веб-приложения.

• Reflected XSS - Отраженный XSS, также известный как непостоянный XSS, возникает, когда пользовательский ввод немедленно возвращается веб-приложением в сообщении об ошибке / результате поиска или вводится пользователем как часть запроса и без постоянного хранения данных, предоставленных пользователем.

• DOM Based XSS - XSS на основе DOM - это форма XSS, когда источник данных находится в DOM, приемник также находится в DOM, а поток данных никогда не покидает браузер.

пример

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

http://www.webpage.org/task/Rule1?query=try

Злоумышленник изменяет параметр запроса в своем браузере на -

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

Руки вверх

Step 1- Войдите в Webgoat и перейдите в раздел межсайтового скриптинга (XSS). Давайте выполним атаку с использованием хранимых межсайтовых сценариев (XSS). Ниже приведен снимок сценария.

Step 2- В соответствии со сценарием, давайте войдем в систему как Том с паролем «Том», как указано в самом сценарии. Нажмите «просмотреть профиль» и войдите в режим редактирования. Поскольку злоумышленник является томом, давайте внедрим сценарий Java в эти поля редактирования.

<script> 
   alert("HACKED")
</script>

Step 3 - Как только обновление закончится, Том получит предупреждение с сообщением «взломано», что означает, что приложение уязвимо.

Step 4 - Теперь, согласно сценарию, нам нужно войти в систему как jerry (HR) и проверить, влияет ли внедренный скрипт на jerry.

Step 5 - После входа в систему как Джерри выберите «Том» и нажмите «просмотреть профиль», как показано ниже.

При просмотре профиля Тома из учетной записи Джерри он может получить такое же окно сообщения.

Step 6 - Это окно сообщения является лишь примером, но злоумышленник может сделать гораздо больше, чем просто отобразить окно сообщения.

Профилактические механизмы

• Разработчики должны убедиться, что они избегают всех ненадежных данных на основе контекста HTML, такого как тело, атрибут, JavaScript, CSS или URL-адрес, в который помещаются данные.

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

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

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

пример

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

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

Злоумышленник изменяет параметр запроса в своем браузере так, чтобы он указывал на Admin.

http://webapp.com/app/accountInfo?acct=admin

Руки вверх

Step 1- Войдите в Webgoat и перейдите в раздел недостатков контроля доступа. Цель состоит в том, чтобы получить tomcat-users.xml, перейдя по пути, по которому он расположен. Ниже приведен снимок сценария.

Step 2 - Путь к файлу отображается в поле 'текущий каталог' - C: \ Users \ userName $ \. Extract \ webapps \ WebGoat \ lesson_plans \ en, и мы также знаем, что файл tomcat-users.xml хранится в C: \ xampp \ tomcat \ conf

Step 3- Нам нужно полностью выйти из текущего каталога и перейти из C: \ Drive. Мы можем сделать то же самое, перехватив трафик с помощью Burp Suite.

Step 4 - Если попытка успешна, отображается файл tomcat-users.xml с сообщением «Поздравляем. Вы успешно завершили этот урок».

Профилактические механизмы

Разработчики могут использовать следующие ресурсы / пункты в качестве руководства для предотвращения небезопасных прямых ссылок на объекты на этапе разработки.

• Разработчики должны использовать только одного пользователя или сеанс для косвенных ссылок на объекты.

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

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

пример

Вот некоторые классические примеры неправильной конфигурации безопасности:

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

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

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

Руки вверх

Step 1- Запустите Webgoat, перейдите в раздел небезопасной конфигурации и позвольте нам попытаться решить эту проблему. Снимок того же приведен ниже -

Step 2- Мы можем опробовать столько вариантов, сколько сможем. Все, что нам нужно, это найти URL-адрес файла конфигурации, и мы знаем, что разработчики следуют соглашению об именах для файлов конфигурации. Это может быть все, что указано ниже. Обычно это делается по технике BRUTE force.

• web.config
• config
• appname.config
• conf

Step 3 - Пробуя разные варианты, мы находим, что 'http://localhost:8080/WebGoat/conf'успешно. Следующая страница отображается, если попытка успешна -

Профилактические механизмы

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

• Убедитесь, что внедряется сильная архитектура приложения, обеспечивающая эффективное и безопасное разделение компонентов.

• Он также может минимизировать вероятность этой атаки, периодически выполняя автоматическое сканирование и аудит.

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

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

пример

Вот некоторые из классических примеров неправильной конфигурации безопасности:

• Сайт просто не использует SSL для всех аутентифицированных страниц. Это позволяет злоумышленнику отслеживать сетевой трафик и украсть cookie сеанса пользователя, чтобы захватить сеанс пользователя или получить доступ к его личным данным.

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

Руки вверх

Step 1- Запустите WebGoat и перейдите в раздел «Небезопасное хранилище». Снимок того же показан ниже.

Step 2- Введите имя пользователя и пароль. Пришло время изучить различные методы кодирования и шифрования, которые мы обсуждали ранее.

Профилактические механизмы

• Рекомендуется не хранить конфиденциальные данные без необходимости и их следует как можно скорее очистить, если они больше не нужны.

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

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

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

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

пример

Вот классический пример контроля доступа на уровне отсутствующей функции -

Хакер просто заставляет целевые URL-адреса. Обычно для доступа администратора требуется проверка подлинности, однако, если доступ к приложению не подтвержден, пользователь, не прошедший проверку подлинности, может получить доступ к странице администратора.

' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage

' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page

Руки вверх

Step 1 - Давайте войдем в систему как менеджер аккаунта, сначала просмотрев список пользователей и их права доступа.

Step 2 - Попробовав различные комбинации, мы можем узнать, что у Ларри есть доступ к менеджеру аккаунта ресурсов.

Профилактические механизмы

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

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

Атака CSRF вынуждает аутентифицированного пользователя (жертву) отправить поддельный HTTP-запрос, включая cookie сеанса жертвы, в уязвимое веб-приложение, что позволяет злоумышленнику заставить браузер жертвы генерировать запрос, который уязвимое приложение воспринимает как законные запросы от жертва.

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

пример

Вот классический пример CSRF -

Step 1 - Допустим, уязвимое приложение отправляет запрос на изменение состояния в виде простого текста без какого-либо шифрования.

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

Step 2 - Теперь хакер создает запрос, который переводит деньги со счета жертвы на счет злоумышленника, встраивая запрос в образ, который хранится на различных сайтах под контролем злоумышленника -

<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#" 
   width = "0" height = "0" />

Руки вверх

Step 1- Давайте выполним подделку CSRF, встроив Java-скрипт в изображение. Снимок проблемы приведен ниже.

Step 2 - Теперь нам нужно смоделировать передачу в изображение 1x1 и заставить жертву щелкнуть по нему.

Step 3 - После отправки сообщения оно отображается, как выделено ниже.

Step 4- Теперь, если жертва щелкает следующий URL-адрес, выполняется передача, которую можно обнаружить, перехватывая действия пользователя с помощью пакета burp. Мы можем увидеть перевод, заметив его в сообщении Get, как показано ниже -

Step 5 - Теперь при нажатии кнопки «Обновить» отображается отметка о завершении урока.

Профилактические механизмы

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

• Принуждение пользователя к повторной аутентификации или доказательство того, что он является пользователем, для защиты CSRF. Например, CAPTCHA.

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

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

пример

Следующие примеры используют компоненты с известными уязвимостями:

• Злоумышленники могут вызвать любую веб-службу с полным разрешением, не предоставив токен идентификации.

• Удаленное выполнение кода с уязвимостью внедрения языка выражений вводится через Spring Framework для приложений на основе Java.

Профилактические механизмы

• Определите все компоненты и версии, которые используются в веб-приложениях, а не только в базе данных / фреймворках.

• Поддерживайте все компоненты, такие как общедоступные базы данных, списки рассылки проектов и т. Д. В актуальном состоянии.

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

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

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

пример

Вот некоторые классические примеры непроверенных перенаправлений и переадресации:

• Допустим, у приложения есть страница - redirect.jsp, которая принимает параметр redirectrul . Хакер добавляет вредоносный URL-адрес, который перенаправляет пользователей, выполняющих фишинг / установку вредоносных программ.

http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com

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

http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp

Профилактические механизмы

• Лучше избегать использования редиректов и переадресации.

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

Асинхронный Javascript и XML (AJAX) - один из последних методов, используемых для разработки веб-приложений, чтобы обеспечить удобство работы пользователей. Поскольку это новая технология, существует множество проблем безопасности, которые еще предстоит решить, и ниже приведены несколько проблем безопасности в AJAX.

• Поверхность атаки больше, поскольку есть больше входов, которые нужно защитить.

• Он также раскрывает внутренние функции приложений.

• Неспособность защитить информацию и сеансы аутентификации.

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

пример

Вот пример для безопасности AJAX -

В 2006 году червь заразил почтовый сервис Yahoo с помощью XSS и AJAX, который воспользовался уязвимостью в обработке событий загрузки Yahoo Mail. При открытии зараженного письма червь запускал свой JavaScript, отправляя копию всем контактам Yahoo зараженного пользователя.

Руки вверх

Step 1- Нам нужно попытаться добавить больше вознаграждений к разрешенному набору вознаграждений с помощью внедрения XML. Ниже приведен снимок сценария.

Step 2- Убедитесь, что мы перехватываем и запрос, и ответ с помощью Burp Suite. Настройки такие же, как показано ниже.

Step 3- Введите номер счета, как указано в сценарии. Мы сможем получить список всех наград, на которые мы имеем право. Мы имеем право на получение 3 наград из 5.

Step 4- Теперь давайте нажмем «Отправить» и посмотрим, что мы получим в ответном XML. Как показано ниже, три награды, на которые мы имеем право, передаются нам в виде XML.

Step 5 - Теперь давайте отредактируем эти XML и добавим еще две награды.

Step 6- Теперь все награды будут отображаться пользователю для выбора. Выберите те, которые мы добавили, и нажмите «Отправить».

Step 7 - Появляется следующее сообщение: «* Поздравляем. Вы успешно завершили этот урок».

Профилактические механизмы

Клиентская сторона -

• Используйте .innerText вместо .innerHtml.
• Не используйте eval.
• Не полагайтесь на клиентскую логику для обеспечения безопасности.
• Избегайте написания кода сериализации.
• Избегайте динамического построения XML.
• Никогда не передавайте секреты клиенту.
• Не выполняйте шифрование в коде на стороне клиента.
• Не выполняйте логику, влияющую на безопасность, на стороне клиента.

Сторона сервера -

• Используйте защиту CSRF.
• Избегайте написания кода сериализации.
• Пользователи могут вызывать службы напрямую.
• Избегайте создания XML вручную, используйте фреймворк.
• Избегайте создания JSON вручную, используйте существующую структуру.

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

Руки вверх

Step 1- Перейдите в область веб-служб Webgoat и перейдите к сканированию WSDL. Теперь нам нужно получить данные кредитной карты для другого номера счета. Снимок сценария приведен ниже.

Step 2 - Если мы выберем первое имя, вызов функции getFirstName выполняется через запрос SOAP xml.

Step 3- Открыв WSDL, мы видим, что есть метод для получения информации о кредитной карте, а также getCreditCard. Теперь давайте изменим входы с помощью набора Burp, как показано ниже -

Step 4 - Теперь давайте изменим входные данные с помощью набора Burp, как показано ниже -

Step 5 - Мы можем получить информацию о кредитных картах других пользователей.

Профилактические механизмы

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

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

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

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

пример

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

...
   char bufr[BUFSIZE]; 
   gets(bufr);
   ...

Руки вверх

Step 1- Нам нужно войти в систему с именем и номером комнаты, чтобы получить доступ в Интернет. Вот снимок сценария.

Step 2 - Мы также включим «Показывать скрытые поля формы» в Burp Suite, как показано ниже -

Step 3- Теперь отправляем ввод в поле имени и номера комнаты. Мы также пытаемся ввести довольно большое число в поле номера комнаты.

Step 4- Скрытые поля отображаются, как показано ниже. Нажимаем принять условия.

Step 5 - Атака успешна, так что в результате переполнения буфера она начала считывать соседние ячейки памяти и отображалась для пользователя, как показано ниже.

Step 6- Теперь давайте авторизуемся, используя отображаемые данные. После регистрации отображается следующее сообщение -

Профилактические механизмы

• Проверка кода
• Обучение разработчиков
• Инструменты компилятора
• Разработка безопасных функций
• Периодическое сканирование

Атака отказа в обслуживании (DoS) - это попытка хакеров сделать сетевой ресурс недоступным. Обычно он прерывает работу хоста, временно или на неопределенный срок, который подключен к Интернету. Эти атаки обычно нацелены на службы, размещенные на критически важных веб-серверах, таких как банки, платежные шлюзы кредитных карт.

Симптомы DoS

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

Руки вверх

Step 1- Запустите WebGoat и перейдите в раздел «Отказ в обслуживании». Снимок сценария приведен ниже. Нам нужно несколько раз войти в систему, нарушив максимальный размер пула потоков БД.

Step 2- Для начала нам нужно получить список допустимых логинов. В этом случае мы используем SQL-инъекцию.

Step 3 - Если попытка успешна, пользователю отображаются все действительные учетные данные.

Step 4- Теперь войдите с каждым из этих пользователей как минимум в 3 разных сеанса, чтобы сделать DoS-атаку успешной. Поскольку мы знаем, что соединение с БД может обрабатывать только два потока, при использовании всех логинов будет создано три потока, что сделает атаку успешной.

Профилактические механизмы

• Выполните тщательную проверку входных данных.

• Избегайте операций с высокой загрузкой ЦП.

• Диски с данными лучше отделить от системных дисков.

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

пример

Некоторые из классических примеров включают -

• Загрузите файл .jsp в веб-дерево.
• Загрузите .gif, чтобы изменить размер.
• Загружайте огромные файлы.
• Загрузите файл, содержащий теги.
• Загрузите файл .exe в веб-дерево.

Руки вверх

Step 1- Запустите WebGoat и перейдите в раздел «Выполнение вредоносных файлов». Снимок сценария приведен ниже -

Step 2 - Чтобы завершить этот урок, нам нужно загрузить файл guest.txt в указанное выше место.

Step 3- Давайте создадим файл jsp, чтобы файл guest.txt создавался при выполнении jsp. Именование jsp не играет никакой роли в этом контексте, поскольку мы выполняем содержимое файла jsp.

<HTML> 
   <% java.io.File file = new 
      java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt"); 
      file.createNewFile(); %> 
</HTML>

Step 4- Теперь загрузите файл jsp и скопируйте ссылку на него после загрузки. При загрузке ожидается изображение, но мы загружаем файл jsp.

Step 5 - При переходе к файлу jsp пользователю не будет никаких сообщений.

Step 6 - Теперь обновите сеанс, в который вы загрузили файл jsp, и получите сообщение «* Поздравляем. Вы успешно завершили урок».

Профилактические механизмы

• Защищайте веб-сайты с помощью разрешений веб-сайтов.
• Принять контрмеры для безопасности веб-приложений.
• Общие сведения о встроенных учетных записях пользователей и групп в IIS 7.0.

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

Инструменты с открытым исходным кодом

Некоторые инструменты тестирования безопасности с открытым исходным кодом приведены ниже -

S.No.	Название инструмента
1	Zed Attack Proxy Предоставляет автоматизированные сканеры и другие инструменты для обнаружения недостатков безопасности. https://www.owasp.org
2	OWASP WebScarab Разработан на Java для анализа запросов Http и Https. https://www.owasp.org/index.php
3	OWASP Mantra Поддерживает многоязычную среду тестирования безопасности https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework
4	Burp Proxy Инструмент для перехвата и изменения трафика и работает с пользовательскими сертификатами SSL. https://www.portswigger.net/Burp/
5	Firefox Tamper Data Используйте tamperdata для просмотра и изменения заголовков HTTP / HTTPS и параметров публикации https://addons.mozilla.org/en-US
6	Firefox Web Developer Tools Расширение Web Developer добавляет в браузер различные инструменты веб-разработчика. https://addons.mozilla.org/en-US/firefox
7	Cookie Editor Позволяет пользователю добавлять, удалять, редактировать, искать, защищать и блокировать файлы cookie https://chrome.google.com/webstore

Специальные наборы инструментов

Следующие инструменты могут помочь нам определить определенный тип уязвимости в системе:

S.No.	Ссылка
1	DOMinator Pro − Testing for DOM XSS https://dominator.mindedsecurity.com/
2	OWASP SQLiX − SQL Injection https://www.owasp.org/index.php
3	Sqlninja − SQL Injection http://sqlninja.sourceforge.net/
4	SQLInjector − SQL Injection https://sourceforge.net/projects/safe3si/
5	sqlpowerinjector − SQL Injection http://www.sqlpowerinjector.com/
6	SSL Digger − Testing SSL https://www.mcafee.com/us/downloads/free-tools
7	THC-Hydra − Brute Force Password https://www.thc.org/thc-hydra/
8	Brutus − Brute Force Password http://www.hoobie.net/brutus/
9	Ncat − Brute Force Password https://nmap.org/ncat/
10	OllyDbg − Testing Buffer Overflow http://www.ollydbg.de/
11	Spike − Testing Buffer Overflow https://www.immunitysec.com/downloads/SPIKE2.9.tgz
12	Metasploit − Testing Buffer Overflow https://www.metasploit.com/

Коммерческие инструменты тестирования черного ящика

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

S.No	Инструмент
1	NGSSQuirreL https://www.nccgroup.com/en/our-services
2	IBM AppScan https://www-01.ibm.com/software/awdtools/appscan/
3	Acunetix Web Vulnerability Scanner https://www.acunetix.com/
4	NTOSpider https://www.ntobjectives.com/products/ntospider.php
5	SOAP UI https://www.soapui.org/Security/getting-started.html
6	Netsparker https://www.mavitunasecurity.com/netsparker/
7	HP WebInspect http://www.hpenterprisesecurity.com/products

Бесплатные анализаторы исходного кода

S.No	Инструмент
1	OWASP Orizon https://www.owasp.org/index.php
2	OWASP O2 https://www.owasp.org/index.php/OWASP_O2_Platform
3	SearchDiggity https://www.bishopfox.com/resources/tools
4	FXCOP https://www.owasp.org/index.php/FxCop
5	Splint http://splint.org/
6	Boon https://www.cs.berkeley.edu/~daw/boon/
7	W3af http://w3af.org/
8	FlawFinder https://www.dwheeler.com/flawfinder/
9	FindBugs http://findbugs.sourceforge.net/

Коммерческие анализаторы исходного кода

Эти анализаторы исследуют, обнаруживают и сообщают о слабостях в исходном коде, которые подвержены уязвимостям:

S.No	Инструмент
1	Parasoft C/C++ test https://www.parasoft.com/cpptest/
2	HP Fortify http://www.hpenterprisesecurity.com/products
3	Appscan http://www-01.ibm.com/software/rational/products
4	Veracode https://www.veracode.com
5	Armorize CodeSecure http://www.armorize.com/codesecure/
6	GrammaTech https://www.grammatech.com/