Güvenlik Testi - Hızlı Kılavuz

Sistemin web'deki kötü niyetli faaliyetlerden korunmasını sağlamak için güvenlik testi çok önemlidir.

Güvenlik Testi nedir?

Güvenlik testi, bir bilgi sisteminin verileri koruyup korumadığını ve işlevselliği amaçlandığı gibi sürdürüp sürdürmediğini belirlemek için kullanılan bir test tekniğidir. Güvenlik testi, sistemin tam güvenliğini garanti etmez, ancak güvenlik testini test sürecinin bir parçası olarak dahil etmek önemlidir.

Güvenlik testi, güvenli bir ortam sağlamak için aşağıdaki altı önlemi alır:

• Confidentiality - Bilgilerin istenmeyen alıcılara ifşa edilmesine karşı koruma sağlar.

• Integrity - Göndericilerden istenilen alıcılara doğru ve doğru bilgilerin aktarılmasına olanak sağlar.

• Authentication - Kullanıcının kimliğini doğrular ve onaylar.

• Authorization - Kullanıcılara ve kaynaklara erişim haklarını belirtir.

• Availability - İhtiyaca ilişkin bilgilerin hazır olmasını sağlar.

• Non-repudiation - Gönderen veya alıcının mesajı gönderdiği veya aldığı için herhangi bir reddetme olmamasını sağlar.

Misal

Web tabanlı bir uygulamadaki bir güvenlik açığını tespit etmek, karmaşık adımlar ve yaratıcı düşünme gerektirir. Bazen basit bir test, en ciddi güvenlik riskini ortaya çıkarabilir. Bu çok basit testi herhangi bir web uygulamasında deneyebilirsiniz -

• Geçerli kimlik bilgilerini kullanarak web uygulamasında oturum açın.

• Web uygulamasından çıkın.

• Tarayıcının GERİ düğmesine tıklayın.

• Tekrar oturum açmanızın istenip istenmediğini veya oturum açma sayfasına tekrar dönüp dönemeyeceğinizi doğrulayın.

Güvenlik testi, güvenlik açıklarını gerçekçi bir şekilde ortaya çıkaran sisteme yapılan kontrollü bir saldırı olarak görülebilir. Amacı, bir BT sisteminin mevcut durumunu değerlendirmektir. Olarak da bilinirpenetration test veya daha popüler olarak ethical hacking.

Sızma testi aşamalı olarak yapılır ve burada bu bölümde tüm süreci tartışacağız. Saldırıyı yeniden oluşturmak için gerekli tüm adımların hazır olması için her aşamada uygun dokümantasyon yapılmalıdır. Dokümantasyon ayrıca müşterilerin bir sızma testinin sonunda aldıkları ayrıntılı rapor için temel teşkil eder.

Penetrasyon Testi - İş Akışı

Sızma testi dört ana aşama içerir -

• Ayak Baskısı
• Scanning
• Enumeration
• Exploitation

Bu dört adım, normal SDLC ile el ele giden birden çok kez tekrarlanır.

Kötü amaçlı yazılım (kötü amaçlı yazılım), saldırgan / kötü amaçlı yazılım oluşturucuya sistemin tam kontrolünü kısmen veya tamamen veren herhangi bir yazılımdır.

Malwares

Aşağıda çeşitli kötü amaçlı yazılım türleri listelenmiştir -

• Virus- Virüs, kendisinin kopyalarını oluşturan ve bu kopyaları diğer bilgisayar programlarına, veri dosyalarına veya sabit diskin önyükleme sektörüne ekleyen bir programdır. Başarılı bir çoğaltmanın ardından virüsler, virüslü ana bilgisayarlarda sabit disk alanını veya CPU zamanını çalmak gibi zararlı faaliyetlere neden olur.

• Worm - Solucan, yolundaki her bilgisayarın belleğinde kendisinin bir kopyasını bırakan bir kötü amaçlı yazılım türüdür.

• Trojan - Truva atı, yürütüldüğünde veri kaybına veya çalınmasına veya olası sistem hasarına neden olan kötü amaçlı kod içeren, kendi kendini kopyalayan bir kötü amaçlı yazılım türüdür.

• Adware- Ücretsiz yazılım veya adım yazılımı olarak da bilinen reklam yazılımı, oyunların, masaüstü araç çubuklarının ve yardımcı programların ticari reklamlarını içeren ücretsiz bir bilgisayar yazılımıdır. Web tabanlı bir uygulamadır ve reklamları, özellikle pop-up'ları hedeflemek için web tarayıcısı verilerini toplar.

• Spyware- Casus yazılım, kullanıcıları anonim olarak izleyen ve bir bilgisayar korsanının kullanıcının bilgisayarından hassas bilgiler elde etmesini sağlayan sızma yazılımıdır. Casus yazılım, genellikle ücretsiz çevrimiçi yazılım yüklemelerine veya kullanıcılar tarafından tıklanan bağlantılara eklenen kullanıcıları ve uygulama güvenlik açıklarını kullanır.

• Rootkit - Rootkit, bir bilgisayar korsanı tarafından, çalınan bir parola aracılığıyla veya kurbanın bilgisi olmadan bir sistem güvenlik açığından yararlanılarak kurulan bir bilgisayara / ağa yönetici düzeyinde erişim sağlamak için kullanılan bir yazılımdır.

Önleyici tedbirler

Bir sistemde kötü amaçlı yazılım varlığını önlemek için aşağıdaki önlemler alınabilir -

• İşletim sistemi ve uygulamaların yamalar / güncellemelerle güncel olduğundan emin olun.

• Asla garip e-postaları, özellikle ekleri olanları açmayın.

• İnternetten indirirken her zaman ne yüklediğinizi kontrol edin. Açılır pencereleri kapatmak için Tamam'a tıklamayın. Uygulamayı yüklemeden önce yayıncıyı doğrulayın.

• Anti-virüs yazılımı yükleyin.

• Virüsten koruma programlarını düzenli olarak taradığınızdan ve güncellediğinizden emin olun.

• Güvenlik duvarı kurun.

• Tarayıcılar ve uygulamalar tarafından sağlanan güvenlik özelliklerini her zaman etkinleştirin ve kullanın.

Kötü Amaçlı Yazılım Önleme Yazılımı

Aşağıdaki yazılım, kötü amaçlı yazılımların bir sistemden kaldırılmasına yardımcı olur -

• Microsoft Güvenlik Araçları
• Microsoft Windows Defender
• AVG İnternet Güvenliği
• Spybot - Ara ve Yok Et
• Dur! Kişisel kullanım için Home Edition
• Panda İnternet Güvenliği
• Mac OS ve Mac OS X için MacScan

Protokolü anlamak, güvenlik testlerini iyi anlamak için çok önemlidir. Web sunucusu ile istemci arasındaki paket verilerini yakaladığımızda protokolün önemini anlayacaksınız.

HTTP Protokolü

Köprü Metni Aktarım Protokolü (HTTP), dağıtılmış, işbirliğine dayalı, hiper ortam bilgi sistemleri için uygulama düzeyinde bir protokoldür. Bu, 1990'dan beri World Wide Web için veri iletişiminin temelidir. HTTP, başka amaçlar için ve istek yöntemlerinin, hata kodlarının ve başlıklarının uzantısını kullanarak kullanılabilen genel ve durumsuz bir protokoldür.

Temel olarak HTTP, web üzerinden HTML dosyaları, görüntü dosyaları, sorgu sonuçları vb. Gibi verileri iletmek için kullanılan TCP / IP tabanlı bir iletişim protokolüdür. Bilgisayarların birbirleriyle iletişim kurması için standart bir yol sağlar. HTTP belirtimi, istemcilerin istenen verilerinin sunucuya nasıl gönderileceğini ve sunucuların bu isteklere nasıl yanıt vereceğini belirtir.

Temel özellikler

HTTP'yi basit ama güçlü bir protokol yapan aşağıdaki üç temel özellik vardır:

• HTTP is connectionless- HTTP istemcisi, yani tarayıcı bir HTTP isteği başlatır. İstemci bir istekte bulunduktan sonra sunucuyla bağlantısını keser ve bir yanıt bekler. Sunucu isteği işler ve yanıtı geri göndermek için istemciyle bağlantıyı yeniden kurar.

• HTTP is media independent- Hem istemci hem de sunucu veri içeriğini nasıl kullanacağını bildiği sürece her tür veri HTTP tarafından gönderilebilir. Bu, istemcinin ve sunucunun uygun MIME türünü kullanarak içerik türünü belirtmesi için gereklidir.

• HTTP is stateless- HTTP, bağlantısızdır ve bu, HTTP'nin durumsuz bir protokol olmasının doğrudan bir sonucudur. Sunucu ve istemci, yalnızca geçerli bir istek sırasında birbirlerinden haberdar olur. Daha sonra ikisi de birbirini unutur. Protokolün bu niteliği nedeniyle, ne istemci ne de tarayıcı, web sayfalarındaki farklı istekler arasında bilgi tutamaz.

HTTP / 1.0, her istek / yanıt alışverişi için yeni bir bağlantı kullanırken, HTTP / 1.1 bağlantısı bir veya daha fazla istek / yanıt alışverişi için kullanılabilir.

Mimari

Aşağıdaki şema, bir web uygulamasının çok temel bir mimarisini gösterir ve HTTP'nin nerede bulunduğunu gösterir -

HTTP protokolü, web tarayıcısının, robotların ve arama motorlarının vb. HTTP istemcileri olarak davrandığı ve web sunucusunun bir sunucu olarak davrandığı istemci / sunucu mimarisine dayalı bir istek / yanıt protokolüdür.

• Client - HTTP istemcisi, sunucuya bir istek yöntemi, URI ve protokol sürümü biçiminde bir istek gönderir ve ardından bir TCP / IP bağlantısı üzerinden istek değiştiricileri, istemci bilgileri ve olası gövde içeriğini içeren MIME benzeri bir ileti izler.

• Server - HTTP sunucusu, mesajın protokol sürümü ve bir başarı veya hata kodu dahil olmak üzere bir durum satırı ile yanıt verir, ardından sunucu bilgilerini, varlık meta bilgilerini ve olası varlık-gövde içeriğini içeren MIME benzeri bir mesaj gelir.

HTTP - Dezavantajları

• HTTP, tamamen güvenli bir protokol değildir.

• HTTP, iletişim için varsayılan bağlantı noktası olarak bağlantı noktası 80'i kullanır.

• HTTP, uygulama Katmanında çalışır. Veri aktarımı için birden fazla bağlantı oluşturması gerekir, bu da yönetim giderlerini artırır.

• HTTP kullanmak için şifreleme / dijital sertifika gerekmez.

Http Protokolü Ayrıntıları

HTTP Protokolünü derinlemesine anlamak için aşağıdaki bağlantıların her birine tıklayın.

• HTTP Parameters

• HTTP Messages

• HTTP Requests

• HTTP Responses

• HTTP Methods

• HTTP Status Codes

• HTTP Header Fields

• HTTP Security

HTTPS (Güvenli Yuva Katmanı üzerinden Köprü Metni Aktarım Protokolü) veya SSL üzerinden HTTP, Netscape tarafından geliştirilen bir web protokolüdür. Bu bir protokol değildir, ancak HTTP'nin SSL / TLS (Güvenli Yuva Katmanı / Taşıma Katmanı Güvenliği) üzerine katmanlandırılmasının sonucudur.

Kısacası, HTTPS = HTTP + SSL

HTTPS ne zaman gereklidir?

Göz attığımızda, normalde HTTP protokolünü kullanarak bilgi gönderip alırız. Bu, herkesin bilgisayarımız ile web sunucusu arasındaki konuşmayı dinlemesine yol açar. Çoğu zaman, güvenlik altına alınması gereken ve yetkisiz erişimi önlemek için hassas bilgileri paylaşmamız gerekir.

Aşağıdaki senaryolarda kullanılan Https protokolü -

• Bankacılık Web Siteleri
• Ödeme Sağlayıcı
• Alışveriş Web Siteleri
• Tüm Giriş Sayfaları
• E-posta Uygulamaları

HTTPS'nin Temel Çalışması

• HTTPS Protokolünde sunucu için genel anahtar ve imzalı sertifikalar gereklidir.

• Https: // sayfası için müşteri istekleri

• Bir https bağlantısı kullanıldığında, sunucu, web sunucusunun desteklediği şifreleme yöntemlerinin bir listesini sunarak ilk bağlantıya yanıt verir.

• Yanıt olarak, istemci bir bağlantı yöntemi seçer ve istemci ile sunucu, kimliklerini doğrulamak için sertifika alışverişi yapar.

• Bu yapıldıktan sonra, hem web sunucusu hem de istemci, her ikisinin de aynı anahtarı kullandığından ve bağlantının kapalı olduğundan emin olduktan sonra şifrelenmiş bilgileri değiştirir.

• Https bağlantılarını barındırmak için, bir sunucunun, anahtar sahibinin kimliğinin doğrulanmasıyla anahtar bilgilerini yerleştiren bir genel anahtar sertifikasına sahip olması gerekir.

• Neredeyse tüm sertifikalar üçüncü bir tarafça doğrulanır, böylece istemciler anahtarın her zaman güvende olduğundan emin olur.

Kodlama ve Kod Çözme nedir?

Kodlama, harfler, sayılar ve diğer özel karakterler gibi bir dizi karakterin verimli aktarım için özel bir biçime yerleştirilmesi işlemidir.

Kod çözme, kodlanmış bir formatı orijinal karakter dizisine geri dönüştürme işlemidir. Genellikle yanlış yorumladığımız Şifreleme'den tamamen farklıdır.

Veri iletişiminde ve depolamada kodlama ve kod çözme kullanılır. Kodlama, hassas bilgilerin taşınması için KULLANILMAMALIDIR.

URL Kodlama

URL'ler yalnızca ASCII karakter kümesi kullanılarak İnternet üzerinden gönderilebilir ve URL'nin ASCII karakterleri dışında özel karakterler içerdiği durumlar vardır, kodlanması gerekir. URL'ler boşluk içermez ve bir artı (+) işaretiyle veya% 20 ile değiştirilir.

ASCII Kodlama

Tarayıcı (istemci tarafı) girdiyi web sayfasında kullanılan karakter kümesine göre kodlayacaktır ve HTML5'teki varsayılan karakter kümesi UTF-8'dir.

Aşağıdaki tablo, karakterin ASCII sembolünü ve ona eşit Sembolünü ve son olarak, sunucuya geçmeden önce URL'de kullanılabilen yerini göstermektedir -

ASCII	Sembol	Değiştirme
<32		% Xx ile kodlayın; burada xx, karakterin onaltılık gösterimidir.
32	Uzay	+ veya% 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	:	%3 A
59	;	% 3B
60	>	% 3C
61	=	%3 BOYUTLU
62	>	% 3E
63	?	% 3F
64	@	% 40
65	Bir	Bir
66	B	B
67	C	C
68	D	D
69	E	E
70	F	F
71	G	G
72	H	H
73	ben	ben
74	J	J
75	K	K
76	L	L
77	M	M
78	N	N
79	Ö	Ö
80	P	P
81	Q	Q
82	R	R
83	S	S
84	T	T
85	U	U
86	V	V
87	W	W
88	X	X
89	Y	Y
90	Z	Z
91	[	% 5B
92	\	% 5C
93	]	% 5G
94	^	% 5E
95	_	_
96	'	% 60
97	a	a
98	b	b
99	c	c
100	d	d
101	e	e
102	f	f
103	g	g
104	h	h
105	ben	ben
106	j	j
107	k	k
108	l	l
109	m	m
110	n	n
111	Ö	Ö
112	p	p
113	q	q
114	r	r
115	s	s
116	t	t
117	u	u
118	v	v
119	w	w
120	x	x
121	y	y
122	z	z
123	{	%7B
124	|	%7C
125	}	%7D
126	~	%7E
127		%7F
> 127		Encode with %xx where xx is the hexadecimal representation of the character

What is Cryptography?

Cryptography is the science to encrypt and decrypt data that enables the users to store sensitive information or transmit it across insecure networks so that it can be read only by the intended recipient.

Data which can be read and understood without any special measures is called plaintext, while the method of disguising plaintext in order to hide its substance is called encryption.

Encrypted plaintext is known as cipher text and process of reverting the encrypted data back to plain text is known as decryption.

• The science of analyzing and breaking secure communication is known as cryptanalysis. The people who perform the same also known as attackers.

• Cryptography can be either strong or weak and the strength is measured by the time and resources it would require to recover the actual plaintext.

• Hence an appropriate decoding tool is required to decipher the strong encrypted messages.

• There are some cryptographic techniques available with which even a billion computers doing a billion checks a second, it is not possible to decipher the text.

• As the computing power is increasing day by day, one has to make the encryption algorithms very strong in order to protect data and critical information from the attackers.

How Encryption Works?

A cryptographic algorithm works in combination with a key (can be a word, number, or phrase) to encrypt the plaintext and the same plaintext encrypts to different cipher text with different keys.

Hence, the encrypted data is completely dependent couple of parameters such as the strength of the cryptographic algorithm and the secrecy of the key.

Cryptography Techniques

Symmetric Encryption − Conventional cryptography, also known as conventional encryption, is the technique in which only one key is used for both encryption and decryption. For example, DES, Triple DES algorithms, MARS by IBM, RC2, RC4, RC5, RC6.

Asymmetric Encryption − It is Public key cryptography that uses a pair of keys for encryption: a public key to encrypt data and a private key for decryption. Public key is published to the people while keeping the private key secret. For example, RSA, Digital Signature Algorithm (DSA), Elgamal.

Hashing − Hashing is ONE-WAY encryption, which creates a scrambled output that cannot be reversed or at least cannot be reversed easily. For example, MD5 algorithm. It is used to create Digital Certificates, Digital signatures, Storage of passwords, Verification of communications, etc.

Same Origin Policy (SOP) is an important concept in the web application security model.

What is Same Origin Policy?

As per this policy, it permits scripts running on pages originating from the same site which can be a combination of the following −

• Domain
• Protocol
• Port

Example

The reason behind this behavior is security. If you have try.com in one window and gmail.com in another window, then you DO NOT want a script from try.com to access or modify the contents of gmail.com or run actions in context of gmail on your behalf.

Below are webpages from the same origin. As explained before, the same origin takes domain/protocol/port into consideration.

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

Below are webpages from a different origin.

• http://www.site.co.uk(another domain)
• http://site.org (another domain)
• https://site.com (another protocol)
• http://site.com:8080 (another port)

Same Origin policy Exceptions for IE

Internet Explorer has two major exceptions to SOP.

• The first one is related to 'Trusted Zones'. If both domains are in highly trusted zone then the Same Origin policy is not applicable completely.

• The second exception in IE is related to port. IE does not include port into Same Origin policy, hence the http://website.com and http://wesite.com:4444 are considered from the same origin and no restrictions are applied.

What is a Cookie?

A cookie is a small piece of information sent by a web server to store on a web browser so that it can later be read by the browser. This way, the browser remembers some specific personal information. If a Hacker gets hold of the cookie information, it can lead to security issues.

Properties of Cookies

Here are some important properties of cookies −

• They are usually small text files, given ID tags that are stored on your computer's browser directory.

• They are used by web developers to help users navigate their websites efficiently and perform certain functions.

• When the user browses the same website again, the data stored in the cookie is sent back to the web server to notify the website of the user’s previous activities.

• Cookies are unavoidable for websites that have huge databases, need logins, have customizable themes.

Cookie Contents

The cookie contains the following information −

• The name of the server the cookie was sent from.
• The lifetime of the cookie.
• A value - usually a randomly generated unique number.

Types of Cookies

• Session Cookies − These cookies are temporary which are erased when the user closes the browser. Even if the user logs in again, a new cookie for that session is created.

• Persistent cookies − These cookies remain on the hard disk drive unless user wipes them off or they expire. The Cookie's expiry is dependent on how long they can last.

Testing Cookies

Here are the ways to test the cookies −

• Disabling Cookies − As a tester, we need to verify the access of the website after disabling cookies and to check if the pages are working properly. Navigating to all the pages of the website and watch for app crashes. It is also required to inform the user that cookies are required to use the site.

• Corrupting Cookies − Another testing to be performed is by corrupting the cookies. In order to do the same, one has to find the location of the site's cookie and manually edit it with fake / invalid data which can be used access internal information from the domain which in turn can then be used to hack the site.

• Removing Cookies − Remove all the cookies for the website and check how the website reacts to it.

• Cross-Browser Compatibility − It is also important to check that cookies are being written properly on all supported browsers from any page that writes cookies.

• Editing Cookies − If the application uses cookies to store login information then as a tester we should try changing the user in the cookie or address bar to another valid user. Editing the cookie should not let you log in to a different users account.

Viewing and Editing Cookies

Modern browsers support viewing/editing of the cookies inform within the Browser itself. There are plugins for mozilla/chrome using which we are able to perform the edit successfully.

• Edit cookies plugin for Firefox

• Edit This cookie plugin for chrome

The steps should be performed to Edit a cookie −

• Download the plugin for Chrome from here

• Edit the cookie value just by accessing the 'edit this cookie' plugin from chrome as shown below.

There are various methodologies/approaches which we can make use of as a reference for performing an attack.

Web Application - PenTesting Methodologies

One can take into account the following standards while developing an attack model.

Among the following list, OWASP is the most active and there are a number of contributors. We will focus on OWASP Techniques which each development team takes into consideration before designing a web app.

• PTES − Penetration Testing Execution Standard

• OSSTMM − Open Source Security Testing Methodology Manual

• OWASP Testing Techniques − Open Web Application Security Protocol

OWASP Top 10

The Open Web Application Security Protocol team released the top 10 vulnerabilities that are more prevalent in web in the recent years. Below is the list of security flaws that are more prevalent in a web based application.

Application - Hands On

In order to understand each one of the techniques, let us work with a sample application. We will perform the attack on 'WebGoat', the J2EE application which is developed explicitly with security flaws for learning purposes.

The complete details about the webgoat project can be located https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. To Download the WebGoat Application, Navigate to https://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) and goto downloads section.

To install the downloaded application, first ensure that you do not have any application running on Port 8080. It can be installed just using a single command - java -jar WebGoat-6.0.1-war-exec.jar. For more details, visit WebGoat Installation

Post Installation, we should be able to access the application by navigating to http://localhost:8080/WebGoat/attack and the page would be displayed as shown below.

We can use the credentials of guest or admin as displayed in the login page.

Web Proxy

In order to intercept the traffic between client (Browser) and Server (System where Webgoat Application is hosted in our case), we need to use a web proxy. We will use Burp Proxy that can be downloaded from https://portswigger.net/burp/download.html

It is sufficient if you download the free version of burp suite as shown below.

Configuring Burp Suite

Burp Suite is a web proxy which can intercept each packet of information sent and received by the browser and webserver. This helps us to modify the contents before the client sends the information to the Web-Server.

Step 1 − The App is installed on port 8080 and Burp is installed on port 8181 as shown below. Launch Burp suite and make the following settings in order to bring it up in port 8181 as shown below.

Step 2 − We should ensure that the Burp is listening to Port#8080 where the application is installed so that Burp suite can intercept the traffic. This settings should be done on the scope tab of the Burp Suite as shown below.

Step 3 − Then make your browser proxy settings to listen to the port 8181 (Burp Suite port). Thus we have configured the Web proxy to intercept the traffic between the client (browser) and the server (Webserver) as shown below −

Step 4 − The snapshot of the configuration is shown below with a help of a simple workflow diagram as shown below

Injection technique consists of injecting a SQL query or a command using the input fields of the application.

Web Application - Injection

A successful SQL injection can read, modify sensitive data from the database, and can also delete data from a database. It also enables the hacker to perform administrative operations on the database such as shutdown the DBMS/dropping databases.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Examples

The application uses untrusted data in the construction of the following vulnerable SQL call −

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

Hands On

Step 1 − Navigate to the SQL Injection area of the application as shown below.

Step 2 − As given in the exercise, we use String SQL Injection to bypass authentication. Use SQL injection to log in as the boss ('Neville') without using the correct password. Verify that Neville's profile can be viewed and that all functions are available (including Search, Create, and Delete).

Step 3 − We will Inject a SQL such that we are able to bypass the password by sending the parameter as 'a' = 'a' or 1 = 1

Step 4 − Post Exploitation, we are able to login as Neville who is the Admin as shown below.

Preventing SQL Injection

There are plenty of ways to prevent SQL injection. When developers write the code, they should ensure that they handle special characters accordingly. There are cheat sheets/prevention techniques available from OWASP which is definitely a guide for developers.

• Using Parameterized Queries
• Escaping all User Supplied Input
• Enable Least Privilege for the database for the end users

When authentication functions related to the application are not implemented correctly, it allows hackers to compromise passwords or session ID's or to exploit other implementation flaws using other users credentials.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

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

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

An authenticated user of the site forwards the URL to their friends to know about the discounted sales. He e-mails the above link without knowing that the user is also giving away the session IDs. When his friends use the link, they use his session and credit card.

Hands ON

Step 1 − Login to Webgoat and navigate to 'Session Management Flaws' Section. Let us bypass the authetication by spoofing the cookie. Below is the snapshot of the scenario.

Step 2 − When we login using the credentials webgoat/webgoat, we find from Burp Suite that the JSESSION ID is C8F3177CCAFF380441ABF71090748F2E while the AuthCookie = 65432ubphcfx upon successful authentication.

Step 3 − When we login using the credentials aspect/aspect, we find from Burp Suite that the JSESSION ID is C8F3177CCAFF380441ABF71090748F2E while the AuthCookie = 65432udfqtb upon successful authentication.

Step 4 − Now we need to analyze the AuthCookie Patterns. The first half '65432' is common for both authentications. Hence we are now interested in analyzing the last part of the authcookie values such as - ubphcfx for webgoat user and udfqtb for aspect user respectively.

Step 5 − If we take a deep look at the AuthCookie values, the last part is having the same length as that of user name. Hence it is evident that the username is used with some encryption method. Upon trial and errors/brute force mechanisms, we find that after reversing the user name, webgoat; we end up with taogbew and then the before alphabet character is what being used as AuthCookie. i.e ubphcfx.

Step 6 − If we pass this cookie value and let us see what happens. Upon authenticating as user webgoat, change the AuthCookie value to mock the user Alice by finding the AuthCookie for the same by performing step#4 and step#5.

Preventing Mechanisms

• Develop a strong authentication and session management controls such that it meets all the authentication and session management requirements defined in OWASP's Application Security Verification Standard.

• Developers should ensure that they avoid XSS flaws that can be used to steal session IDs.

Cross-site Scripting (XSS) happens whenever an application takes untrusted data and sends it to the client (browser) without validation. This allows attackers to execute malicious scripts in the victim's browser which can result in user sessions hijack, defacing web sites or redirect the user to malicious sites.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Types of XSS

• Stored XSS − Stored XSS also known as persistent XSS occurs when user input is stored on the target server such as database/message forum/comment field etc. Then the victim is able to retrieve the stored data from the web application.

• Reflected XSS − Reflected XSS also known as non-persistent XSS occurs when user input is immediately returned by a web application in an error message/search result or the input provided by the user as part of the request and without permanently storing the user provided data.

• DOM Based XSS − DOM Based XSS is a form of XSS when the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser.

Example

The application uses untrusted data in the construction without validation. The special characters ought to be escaped.

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

The attacker modifies the query parameter in their browser to −

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

Hands ON

Step 1 − Login to Webgoat and navigate to cross-site scripting (XSS) Section. Let us execute a Stored Cross-site Scripting (XSS) attack. Below is the snapshot of the scenario.

Step 2 − As per the scenario, let us login as Tom with password 'tom' as mentioned in the scenario itself. Click 'view profile' and get into edit mode. Since tom is the attacker, let us inject Java script into those edit boxes.

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

Step 3 − As soon as the update is over, tom receives an alert box with the message "hacked" which means that the app is vulnerable.

Step 4 − Now as per the scenario, we need to login as jerry (HR) and check if jerry is affected by the injected script.

Step 5 − After logging in as Jerry, select 'Tom' and click 'view profile' as shown below.

While viewing tom's profile from Jerry's account, he is able to get the same message box.

Step 6 − This message box is just an example, but the actual attacker can perform much more than just displaying a message box.

Preventive Mechanisms

• Developers have to ensure that they escape all untrusted data based on the HTML context such as body, attribute, JavaScript, CSS, or URL that the data is placed into.

• For those applications that need special characters as input, there should be robust validation mechanisms in place before accepting them as valid inputs.

A direct object reference is likely to occur when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key without any validation mechanism which allows attackers to manipulate these references to access unauthorized data.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

The App uses unverified data in a SQL call that is accessing account information.

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

The attacker modifies the query parameter in their browser to point to Admin.

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

Hands ON

Step 1 − Login to Webgoat and navigate to access control flaws Section. The goal is to retrieve the tomcat-users.xml by navigating to the path where it is located. Below is the snapshot of the scenario.

Step 2 − The path of the file is displayed in 'the current directory is' field - C:\Users\userName$\.extract\webapps\WebGoat\lesson_plans\en and we also know that the tomcat-users.xml file is kept under C:\xampp\tomcat\conf

Step 3 − We need to traverse all the way out of the current directory and navigate from C:\ Drive. We can perform the same by intercepting the traffic using Burp Suite.

Step 4 − If the attempt is successful, it displays the tomcat-users.xml with the message "Congratulations. You have successfully completed this lesson."

Preventive Mechanisms

Developers can use the following resources/points as a guide to prevent insecure direct object reference during development phase itself.

• Developers should use only one user or session for indirect object references.

• It is also recommended to check the access before using a direct object reference from an untrusted source.

Security Misconfiguration arises when Security settings are defined, implemented, and maintained as defaults. Good security requires a secure configuration defined and deployed for the application, web server, database server, and platform. It is equally important to have the software up to date.

Example

Some classic examples of security misconfiguration are as given −

• If Directory listing is not disabled on the server and if attacker discovers the same then the attacker can simply list directories to find any file and execute it. It is also possible to get the actual code base which contains all your custom code and then to find a serious flaws in the application.

• App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers grab those extra information that the error messages provide which is enough for them to penetrate.

• App servers usually come with sample apps that are not well secured. If not removed from production server would result in compromising your server.

Hands ON

Step 1 − Launch Webgoat and navigate to insecure configuration section and let us try to solve that challenge. Snapshot of the same is provided below −

Step 2 − We can try out as many options as we can think of. All we need to find the URL of config file and we know that the developers follow kind of naming convention for config files. It can be anything that is listed below. It is usually done by BRUTE force technique.

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

Step 3 − Upon trying various options, we find that 'http://localhost:8080/WebGoat/conf' is successful. The following page is displayed if the attempt is successful −

Preventive Mechanisms

• All environments such Development, QA, and production environments should be configured identically using different passwords used in each environment that cannot be hacked easily.

• Ensure that a strong application architecture is being adopted that provides effective, secure separation between components.

• It can also minimize the possibility of this attack by running automated scans and doing audits periodically.

As the online applications keep flooding the internet in day by day, not all applications are secured. Many web applications do not properly protect sensitive user data such as credit cards information/Bank account info/authentication credentials. Hackers might end up stealing those weakly protected data to conduct credit card fraud, identity theft, or other crimes.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

Some of the classic examples of security misconfiguration are as given −

• A site simply does not use SSL for all authenticated pages. This enables an attacker to monitor network traffic and steal the user’s session cookie to hijack the users session or accessing their private data.

• An application stores the credit card numbers in an encrypted format in a database. Upon retrieval they are decrypted allowing the hacker to perform a SQL injection attack to retrieve all sensitive info in a clear text. This can be avoided by encrypting the credit card numbers using a public key and allowed back-end applications to decrypt them with the private key.

Hands ON

Step 1 − Launch WebGoat and navigate to "Insecure Storage" Section. Snapshot of the same is displayed below.

Step 2 − Enter the username and password. It is time to learn different kind of encoding and encryption methodologies that we discussed previously.

Preventive Mechanisms

• It is advised not to store sensitive data unnecessarily and should be scraped as soon as possible if it is no more required.

• It is important to ensure that we incorporate strong and standard encryption algorithms are used and proper key management is in place.

• It can also be avoided by disabling autocomplete on forms that collect sensitive data such as password and disable caching for pages that contain sensitive data.

Most of the web applications verify function level access rights before making that functionality accessible to the user. However, if the same access control checks are not performed on the server, hackers are able to penetrate into the application without proper authorization.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

Here is a classic example of Missing Function Level Access Control −

The hacker simply forces target URLs. Usually admin access requires authentication, however, if the application access is not verified, then an unauthenticated user can access admin page.

' 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

Hands ON

Step 1 − Let us login as account manager by first going through the list of users and their access privileges.

Step 2 − Upon trying various combinations we can find out that Larry has access to resource account manager.

Preventive Mechanisms

• The authentication mechanism should deny all access by default, and provide access to specific roles for every function.

• In a workflow based application, verify the users’ state before allowing them to access any resources.

A CSRF attack forces an authenticated user (victim) to send a forged HTTP request, including the victim's session cookie to a vulnerable web application, which allows the attacker to force the victim's browser to generate request such that the vulnerable app perceives as legitimate requests from the victim.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

Here is a classic example of CSRF −

Step 1 − Let us say, the vulnerable application sends a state changing request as a plain text without any encryption.

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

Step 2 − Now the hacker constructs a request that transfers money from the victim's account to the attacker's account by embedding the request in an image that is stored on various sites under the attacker's control −

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

Hands ON

Step 1 − Let us perform a CSRF forgery by embedding a Java script into an image. The snapshot of the problem is listed below.

Step 2 − Now we need to mock up the transfer into a 1x1 image and make the victim to click on the same.

Step 3 − Upon submitting the message, the message is displayed as highlighted below.

Step 4 − Now if the victim clicks the following URL, the transfer is executed, which can be found intercepting the user action using burp suite. We are able to see the transfer by spotting it in Get message as shown below −

Step 5 − Now upon clicking refresh, the lesson completion mark is shown.

Preventive Mechanisms

• CSRF can be avoided by creating a unique token in a hidden field which would be sent in the body of the HTTP request rather than in an URL, which is more prone to exposure.

• Forcing the user to re-authenticate or proving that they are users in order to protect CSRF. For example, CAPTCHA.

This kind of threat occurs when the components such as libraries and frameworks used within the app almost always execute with full privileges. If a vulnerable component is exploited, it makes the hacker’s job easier to cause a serious data loss or server takeover.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

The following examples are of using components with known vulnerabilities −

• Attackers can invoke any web service with full permission by failing to provide an identity token.

• Remote-code execution with Expression Language injection vulnerability is introduced through the Spring Framework for Java based apps.

Preventive Mechanisms

• Identify all components and the versions that are being used in the webapps not just restricted to database/frameworks.

• Keep all the components such as public databases, project mailing lists etc. up to date.

• Add security wrappers around components that are vulnerable in nature.

İnternetteki çoğu web uygulaması sık sık kullanıcıları başka sayfalara veya diğer harici web sitelerine yönlendirir ve yönlendirir. Bununla birlikte, bu sayfaların güvenilirliğini doğrulamadan, bilgisayar korsanları kurbanları kimlik avı veya kötü amaçlı yazılım sitelerine yönlendirebilir veya yetkisiz sayfalara erişmek için yönlendirmeleri kullanabilir.

Bu kusurun Tehdit Ajanlarını, Saldırı Vektörlerini, Güvenlik Zafiyetini, Teknik Etkisini ve İş Etkilerini basit bir şema yardımıyla anlayalım.

Misal

Doğrulanmamış Yönlendirmelerin ve Yönlendirmelerin bazı klasik örnekleri verildiği gibidir -

• Diyelim ki uygulamanın bir parametre redirectrul alan - redirect.jsp sayfası var . Bilgisayar korsanı, kimlik avı yapan / kötü amaçlı yazılım yükleyen kullanıcıları yeniden yönlendiren kötü amaçlı bir URL ekler.

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

• Kullanıcıları sitenin farklı bölümlerine yönlendirmek için kullanılan tüm web uygulamaları. Aynısını elde etmek için bazı sayfalar, bir işlem başarılı olursa kullanıcının nereye yönlendirilmesi gerektiğini belirten bir parametre kullanır. Saldırgan, uygulamanın erişim kontrol denetiminden geçen bir URL oluşturur ve ardından saldırganı, saldırganın erişiminin olmadığı yönetim işlevlerine yönlendirir.

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

Önleyici Mekanizmalar

• Yönlendirmeleri ve yönlendirmeleri kullanmaktan kaçınmak daha iyidir.

• Kaçınılmazsa, hedefin yeniden yönlendirilmesinde kullanıcı parametreleri dahil edilmeden yapılmalıdır.

Eşzamansız Javascript ve XML (AJAX), zengin bir kullanıcı deneyimi sağlamak amacıyla web uygulaması geliştirmek için kullanılan en son tekniklerden biridir. Yeni bir teknoloji olduğu için henüz tamamlanmamış pek çok güvenlik sorunu var ve aşağıda AJAX'taki birkaç güvenlik sorunu var.

• Korunacak daha fazla girdi olduğundan saldırı yüzeyi daha fazladır.

• Ayrıca uygulamaların dahili işlevlerini de ortaya çıkarır.

• Kimlik doğrulama bilgilerinin ve oturumların korunamaması.

• İstemci tarafı ile sunucu tarafı arasında çok dar bir çizgi vardır, bu nedenle güvenlik hataları yapma olasılıkları vardır.

Misal

İşte AJAX Güvenliği için bir örnek -

2006 yılında, bir solucan, Yahoo Mail'in onload olay işlemesindeki bir güvenlik açığından yararlanan XSS ve AJAX kullanarak yahoo posta hizmetine bulaştı. Virüs bulaşmış bir e-posta açıldığında, solucan JavaScript'ini çalıştırarak virüs bulaşmış kullanıcının tüm Yahoo kişilerine bir kopya gönderiyordu.

Eller AÇIK

Step 1- XML ​​enjeksiyonu kullanarak izin verilen ödül setinize daha fazla ödül eklemeye çalışmalıyız. Senaryonun anlık görüntüsü aşağıdadır.

Step 2- Burp Suite'i kullanarak hem isteği hem de yanıtı yakaladığımızdan emin olun. Aşağıda gösterilenle aynı ayarlar.

Step 3- Senaryoda verilen hesap numarasını girin. Uygun olduğumuz tüm ödüllerin bir listesini alabileceğiz. 5 üzerinden 3 ödül almaya hak kazandık.

Step 4- Şimdi 'Gönder'i tıklayalım ve XML yanıtında ne aldığımızı görelim. Aşağıda gösterildiği gibi, uygun olduğumuz üç ödül XML olarak bize iletilir.

Step 5 - Şimdi bu XML'leri düzenleyelim ve diğer iki ödülü de ekleyelim.

Step 6- Artık tüm ödüller, seçmeleri için kullanıcıya gösterilecek. Eklediklerimizi seçin ve 'Gönder'i tıklayın.

Step 7 - "* Tebrikler. Bu dersi başarıyla tamamladınız" diyen aşağıdaki mesaj görünür.

Önleyici Mekanizmalar

İstemci tarafı -

• .İnnerHtml yerine .innerText kullanın.
• Eval kullanmayın.
• Güvenlik için istemci mantığına güvenmeyin.
• Serileştirme kodu yazmaktan kaçının.
• XML'i dinamik olarak oluşturmaktan kaçının.
• Müşteriye asla sırları iletmeyin.
• İstemci tarafı kodunda şifreleme yapmayın.
• İstemci tarafında güvenliği etkileyen mantığı uygulamayın.

Sunucu tarafı -

• CSRF koruması kullanın.
• Serileştirme kodu yazmaktan kaçının.
• Hizmetler kullanıcılar tarafından doğrudan çağrılabilir.
• XML'yi elle oluşturmaktan kaçının, çerçeveyi kullanın.
• JSON'u elle derlemekten kaçının, mevcut bir çerçeveyi kullanın.

Modern web tabanlı uygulamalarda, web servislerinin kullanımı kaçınılmazdır ve bunlar da saldırılara açıktır. Web hizmetleri birden fazla web sitesinden getirme talebinde bulunduğundan, geliştiricilerin bilgisayar korsanlarının herhangi bir şekilde sızmasını önlemek için birkaç ek önlem alması gerekir.

Eller AÇIK

Step 1- Webgoat'ın web hizmetleri alanına gidin ve WSDL Taraması'na gidin. Şimdi başka bir hesap numarasının kredi kartı bilgilerini almamız gerekiyor. Senaryonun anlık görüntüsü aşağıda belirtildiği gibidir.

Step 2 - İlk adı seçersek, 'getFirstName' işlev çağrısı SOAP isteği xml aracılığıyla yapılır.

Step 3- WSDL'yi açarak, kredi kartı bilgilerini ve 'getCreditCard'ı almanın bir yöntemi olduğunu görebiliriz. Şimdi, aşağıda gösterildiği gibi Burp suite kullanarak girişleri değiştirelim -

Step 4 - Şimdi Burp suite kullanarak girişleri aşağıda gösterildiği gibi değiştirelim -

Step 5 - Diğer kullanıcıların kredi kartı bilgilerini alabiliriz.

Önleyici Mekanizmalar

• SOAP mesajları XML tabanlı olduğundan, geçirilen tüm kimlik bilgilerinin metin biçimine dönüştürülmesi gerekir. Bu nedenle, her zaman şifrelenmesi gereken hassas bilgileri iletirken çok dikkatli olmak gerekir.

• Paketin bütünlüğünü sağlamak için uygulanan sağlama toplamı gibi mekanizmaları uygulayarak mesaj bütünlüğünü korumak.

• Mesaj gizliliğinin korunması - Pek çok uygulamada yalnızca bir iletişim için geçerli olan ve daha sonra atılan simetrik oturum anahtarlarını korumak için asimetrik şifreleme uygulanır.

Bir program geçici bir veri saklama alanında (arabellek) tutması amaçlanandan daha fazla veri depolamaya çalıştığında bir arabellek taşması ortaya çıkar. Arabellekler sınırlı miktarda veri içerecek şekilde oluşturulduğundan, fazladan bilgiler bitişik arabelleklere taşabilir ve böylece içlerinde tutulan geçerli verileri bozabilir.

Misal

İşte klasik bir arabellek taşması örneği. Davranışını kontrol etmek için dış verilere dayanan ilk senaryonun neden olduğu basit bir arabellek taşması gösterir. Kullanıcının girdiği veri miktarını sınırlamanın bir yolu yoktur ve programın davranışı, kullanıcının içine kaç karakter koyduğuna bağlıdır.

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

Eller AÇIK

Step 1- İnternet erişimi için isim ve oda numarası ile giriş yapmamız gerekiyor. İşte senaryo anlık görüntüsü.

Step 2 - Aşağıda gösterildiği gibi Burp Suite'te "Gizli form alanlarını göster" seçeneğini de etkinleştireceğiz -

Step 3- Şimdi isim ve oda numarası alanına giriş gönderiyoruz. Ayrıca oda numarası alanına oldukça büyük bir sayı enjekte etmeye çalışıyoruz.

Step 4- Gizli alanlar aşağıda gösterildiği gibi görüntülenir. Şartları kabul et seçeneğine tıklıyoruz.

Step 5 - Saldırı, arabellek taşması sonucunda, bitişik bellek konumlarını okumaya başlayacak ve aşağıda gösterildiği gibi kullanıcıya görüntülenecek şekilde başarılı olmuştur.

Step 6- Şimdi görüntülenen verileri kullanarak giriş yapalım. Oturum açtıktan sonra aşağıdaki mesaj görüntülenir -

Önleyici Mekanizmalar

• Kod İnceleme
• Geliştirici eğitimi
• Derleyici araçları
• Güvenli işlevler geliştirme
• Periyodik Tarama

Hizmet Reddi (DoS) saldırısı, bilgisayar korsanlarının bir ağ kaynağını kullanılamaz hale getirme girişimidir. Genellikle, internete bağlı olan ana bilgisayarı geçici veya süresiz olarak kesintiye uğratır. Bu saldırılar genellikle bankalar, kredi kartı ödeme ağ geçitleri gibi kritik görev web sunucularında barındırılan hizmetleri hedef alır.

DoS Belirtileri

• Olağandışı yavaş ağ performansı.
• Belirli bir web sitesinin kullanılamaması.
• Herhangi bir web sitesine erişememe.
• Alınan spam e-postaların sayısında önemli artış.
• Web'e veya herhangi bir internet hizmetine erişimin uzun süreli engellenmesi.
• Belirli bir web sitesinin kullanılamaması.

Eller AÇIK

Step 1- WebGoat'ı başlatın ve 'Hizmet Reddi' bölümüne gidin. Senaryonun anlık görüntüsü aşağıda verilmiştir. Maksimum DB iş parçacığı havuzu boyutunu aşarak orada birden çok kez oturum açmamız gerekiyor.

Step 2- Önce geçerli girişlerin listesini almamız gerekiyor. Bu durumda SQL Injection kullanıyoruz.

Step 3 - Deneme başarılı olursa, kullanıcıya tüm geçerli kimlik bilgilerini görüntüler.

Step 4- Şimdi DoS saldırısını başarılı kılmak için bu kullanıcıların her biriyle en az 3 farklı oturumda oturum açın. DB bağlantısının yalnızca iki iş parçacığını idare edebileceğini bildiğimiz gibi, tüm oturumları kullanarak saldırıyı başarılı kılan üç iş parçacığı oluşturacaktır.

Önleyici Mekanizmalar

• Kapsamlı giriş doğrulamaları gerçekleştirin.

• Yüksek CPU tüketen işlemlerden kaçının.

• Veri disklerini sistem disklerinden ayırmak daha iyidir.

Geliştiriciler genellikle, potansiyel olarak savunmasız girdileri doğrudan kullanır veya dosya ile birleştirir veya girdi dosyalarının orijinal olduğunu varsayarlar. Veriler düzgün bir şekilde kontrol edilmediğinde, bu, savunmasız içeriğin web sunucusu tarafından işlenmesine veya çağrılmasına neden olabilir.

Misal

Klasik örneklerden bazıları şunlardır:

• .Jsp dosyasını web ağacına yükleyin.
• Yeniden boyutlandırılmak için .gif yükleyin.
• Büyük dosyalar yükleyin.
• Etiketleri içeren dosya yükleyin.
• .Exe dosyasını web ağacına yükleyin.

Eller AÇIK

Step 1- WebGoat'ı başlatın ve Kötü Amaçlı dosya yürütme bölümüne gidin. Senaryonun anlık görüntüsü aşağıda verilmiştir -

Step 2 - Bu dersi tamamlamak için yukarıda belirtilen konuma guest.txt dosyasını yüklememiz gerekiyor.

Step 3- jsp yürütülürken guest.txt dosyası oluşturulacak şekilde bir jsp dosyası oluşturalım. Biz jsp dosyasının içeriğini yürüttüğümüz için jsp'nin adlandırılmasının bu bağlamda oynayacağı bir rol yoktur.

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

Step 4- Şimdi jsp dosyasını yükleyin ve yüklemeden sonra aynı bağlantı konumunu kopyalayın. Yükleme bir resim bekliyor, ancak bir jsp yüklüyoruz.

Step 5 - jsp dosyasına gidildiğinde, kullanıcıya herhangi bir mesaj gelmeyecektir.

Step 6 - Şimdi jsp dosyasını yüklediğiniz oturumu yenileyin ve "* Tebrikler. Dersi başarıyla tamamladınız" mesajını alacaksınız.

Önleyici Mekanizmalar

• Web sitesi izinlerini kullanarak web sitelerini güvenli hale getirin.
• Web uygulaması güvenliği için karşı önlemler alın.
• IIS 7.0'daki Yerleşik kullanıcı ve grup hesaplarını anlayın.

Bir uygulamanın güvenlik testini gerçekleştirmek için çeşitli araçlar mevcuttur. Uçtan uca güvenlik testi yapabilen birkaç araç varken, bazıları sistemdeki belirli bir kusur türünü tespit etmeye adanmıştır.

Açık Kaynak Araçları

Bazı açık kaynak güvenlik test araçları verildiği gibidir -

S.No.	Araç Adı
1	Zed Attack Proxy Güvenlik açıklarını tespit etmek için Otomatik Tarayıcılar ve diğer araçları sağlar. https://www.owasp.org
2	OWASP WebScarab Http ve Https isteklerini analiz etmek için Java'da geliştirildi. https://www.owasp.org/index.php
3	OWASP Mantra Çok dilli güvenlik testi çerçevesini destekler https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework
4	Burp Proxy Trafiği Önlemek ve Değiştirmek için Araç ve özel SSL sertifikalarıyla çalışır. https://www.portswigger.net/Burp/
5	Firefox Tamper Data HTTP / HTTPS üstbilgilerini ve yayın parametrelerini görüntülemek ve değiştirmek için kurcalama verilerini kullanın https://addons.mozilla.org/en-US
6	Firefox Web Developer Tools Web Developer uzantısı, tarayıcıya çeşitli web geliştirici araçları ekler. https://addons.mozilla.org/en-US/firefox
7	Cookie Editor Kullanıcının çerezleri eklemesine, silmesine, düzenlemesine, aramasına, korumasına ve engellemesine izin verir https://chrome.google.com/webstore

Özel Alet Setleri

Aşağıdaki araçlar, sistemdeki belirli bir güvenlik açığını tespit etmemize yardımcı olabilir -

S.No.	Bağlantı
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/

Ticari Kara Kutu Test araçları

Geliştirdiğimiz uygulamalardaki güvenlik sorunlarını tespit etmemize yardımcı olan ticari kara kutu test araçlarından bazıları aşağıda verilmiştir.

S.No	Araç
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

Ücretsiz Kaynak Kod Analizörleri

S.No	Araç
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/

Ticari Kaynak Kod Analizörleri

Bu analizciler, kaynak kodundaki güvenlik açıklarına yatkın zayıflıkları inceler, tespit eder ve raporlar

S.No	Araç
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/