Siteler arası komut dosyası çalıştırma güvenlik açıkları, şüphesiz uygulamaların uzun süre aklını başından alacak güvenlik açığı türlerinden biridir. Bu kesintisiz ekleme hatası genellikle saldırganların kurban adına kötü niyetli eylemler gerçekleştirmesine veya daha da kötüsü, şifreler veya e-postalar gibi hesap bilgilerini okumak ve değiştirmekten yalnızca dahili kaynaklara erişmeye ve hatta yerel dosyaları okumaya kadar, savunmasız bir sunucu tarafı bileşeni adına kötü niyetli eylemler gerçekleştirmesine olanak tanıyacak şekilde daha da ilerleyebilir.
Bu makalede, yansıtıcı XSS güvenlik açıklarını belirlemek için kanıtlanmış bir metodolojiye bakacağız ve aynı zamanda bazı gelişmiş yararlanma yöntemlerini daha derinlemesine inceleyeceğiz.
Hadi dalalım!
Siteler arası komut dosyası çalıştırma (XSS), saldırganların diğer kullanıcılar tarafından görüntülenen web sayfalarına kötü amaçlı komut dosyaları eklemesine olanak tanıyan bir enjeksiyon güvenlik açığıdır. Yetersiz giriş doğrulamasından ve bu kullanıcı girişinin herhangi bir yansımasının kodlama eksikliğinden yararlanarak çalışır ve saldırganların, tehlikeye atılan sayfayı ziyaret ettikten sonra kurbanların tarayıcılarında çalışan HTML veya JavaScript kodunu eklemesine olanak tanır.
Güvenlik açığı bulunan bileşene bağlı olarak XSS, hem istemci tarafında hem de sunucu tarafında meydana gelebilir. İstemci tarafı XSS yalnızca kurbanın web tarayıcısında gerçekleşir ve saldırganların kurbanın oturumunu ele geçirmesine olanak tanır.
Sunucu tarafı XSS (veya kör XSS olarak da bilinir), güvenlik açığı bulunan bileşen, sterilize edilmemiş girişinizi kullandığında ve bunu örneğin başsız bir web tarayıcısı aracılığıyla sunucu tarafındaki DOM içinde değerlendirdiğinde ortaya çıkar. Bu, saldırganların sunucu adına giden istekleri başlatmak için rastgele JavaScript kodu kullanmasına ve ciddi durumlarda yerel dosyaları bile okumasına (başsız web tarayıcısının dağıtım yapılandırmasına bağlı olarak) olanak tanır.
Şimdi farklı XSS güvenlik açıklarına bir göz atalım.
Yansıyan XSS
Yansıyan XSS (veya bazen yansıtıcı XSS olarak da adlandırılır), kötü niyetli kullanıcı girişinin bir istek özelliği (URL yolu, parça, sorgu/gövde parametresi veya HTTP başlığı gibi) aracılığıyla enjekte edilmesi ve uygun şekilde arındırılmadan hemen kullanıcıya geri yansıtılmasıyla oluşur.
Sunucu, kullanıcı girişini işler ve herhangi bir kodlama olmadan HTTP yanıtına dahil ederek kurbanın tarayıcısının, özel hazırlanmış bir bağlantıyı tıklattığında saldırganın komut dosyasını yürütmesine neden olur.
Saklanan XSS
Saklanan XSS (veya bazen kalıcı XSS olarak da adlandırılır), bir saldırganın kötü amaçlı komut dosyasının hedefin veritabanına, dosya sistemine veya başka herhangi bir depolama hizmeti türüne (AWS S3 gibi) kaydedilmesi durumunda gerçekleşir. Diğer kullanıcılar daha sonra depolanan bu verileri aldığında (örneğin bir yorum bölümünü, genel profili veya forum gönderisini görüntülerken), kötü amaçlı komut dosyası tarayıcılarında çalıştırılır.
Saklanan XSS, yansıtılan XSS’nin aksine, belirli bir bağlantıya tıklamalarına gerek kalmadan birden fazla kurbanı etkileyebileceğinden özellikle tehlikelidir.
DOM tabanlı XSS
DOM tabanlı XSS, güvenli olmayan JavaScript kodu kullanıcı tarafından kontrol edilebilen verileri (DOM kaynağından) işlediğinde ve bunu bir DOM havuzuna aktardığında ortaya çıkar. Bu, saldırganların güvenlik açığı bulunan uygulama tarafından değerlendirilecek JavaScript verileri oluşturmasına olanak tanır.
DOM tabanlı XSS’nin tespit edilmesi, kötü niyetli kullanıcı girişinin hemen HTTP yanıtına yansıtılmaması, bunun yerine bir DOM havuzuna aktarılması nedeniyle daha zordur. DOM tabanlı XSS güvenlik açıklarının tanımlanması ve kullanılması gelecek bir makalede tartışılacaktır.
Bu makale boyunca yalnızca yansıtılmış (veya yansıtıcı) ve depolanmış (kalıcı) XSS’yi ele alacağız çünkü bu türlerin her ikisi de aynı özellikleri paylaşıyor.
Kendi kendine XSS nedir?
Self-XSS, bir saldırganın kurbanı kendi tarayıcısında kötü amaçlı JavaScript çalıştırması için kandırması ve genellikle kurbanı tarayıcının geliştirici konsoluna veya yalnızca kendisinin erişebildiği meşru bir web sitesindeki bir metin alanına (örneğin profilinizdeki adres alanına) kod yapıştırmaya ikna etmesiyle oluşur.
Bu, teknik olarak komut dosyası yürütülmesine neden olsa da, çoğu hata ödül programı ve güvenlik araştırmacısı, self XSS’nin bir güvenlik riski teşkil ettiğini düşünmüyor çünkü bu, kurbanın saldırıyı kendisine karşı aktif olarak gerçekleştirmesini gerektiriyor; bu da, güvenlik açıklarının kapsamlı sosyal mühendislik olmadan kullanılabilir olması gerektiği yönündeki temel güvenlik ilkesini ihlal ediyor.
Self-XSS güvenlik açıklarının zincirlenebileceği ve daha da artırılabileceği durumlar olduğunu unutmayın, ancak bu, gelecek bir makalede daha kapsamlı bir şekilde ele alacağımız bir konudur.
Eğer yeni başlıyorsanız bu kısım çok önemlidir. Bir XSS güvenlik açığı mı bulduğunuzu yoksa basit bir içerik yerleştirmeyle mi uğraştığınızı belirlerken saatlerce tasarruf etmenize yardımcı olabilir. Yansıtılan veya depolanan bir XSS güvenlik açığını tanımlamamıza yardımcı olması için bu 3 adımlı metodolojiyi inceleyelim.
Adım 1: Yansıma
İlk adım, girişinizin uygulamanın yanıtına nereye yansıyacağını belirlemektir. Benzersiz bir dize ekleyin (örneğin intigriti1337test) çeşitli giriş alanlarına, URL parametrelerine, başlıklara veya kullanıcı tarafından kontrol edilebilen diğer veri noktalarına.
Daha sonra, HTTP yanıtında bu dizeyi arayın. Bu, tüm yansıma noktalarının haritasını çıkarmanıza ve girdinizin nerede bittiğini anlamanıza yardımcı olur; bu, istismarın mümkün olup olmadığını ve ne tür bir enjeksiyonla uğraştığınızı belirlemek için çok önemlidir.
Siteler arası komut dosyası çalıştırma (XSS) yansıma noktası aranıyor
Gizli giriş parametrelerini bulma
(Gizli) parametreleri numaralandırmak, XSS dahil her türlü enjeksiyon güvenlik açığını keşfetmenize yardımcı olabilir! Ayrıntılı kılavuzumuzda gizli parametreleri keşfetmenin 5 yolunu özetledik. Bugün makaleyi okuyun.
https://www.intigriti.com/researchers/blog/hacking-tools/finding-hidden-input-parameters
Adım 2: Enjeksiyon
Bir yansıma noktası bulduğunuzda, aşağıdaki gibi basit bir HTML etiketi enjekte ederek mevcut bağlamdan çıkıp çıkamayacağınızı test edin: intigriti1337test
JavaScript bağlamındaki yansımalar için (içinde herhangi bir yer) tag, the injection string will look slightly different. We will discuss this case more in-depth shortly.
Input reflected with no injection
Your input likely got HTML-encoded. In this instance, XSS is often not possible since your arbitrary input got sanitized. However, keep in mind that there are caveats whereby applications can show different behavior based on your user-agent (mobile vs desktop) or whenever you inject special characters, such as null bytes, CR/LF characters, etc.Example of a non-vulnerable cross-site scripting (XSS) case
Input reflected with injection
When your input is reflected and injected, meaning no special characters are encoded, you have a strong indication that XSS is possible. All we have to do right now is inject a special HTML tag or event handler to transform our simple HTML injection into an XSS vulnerability.Searching for cross-site scripting (XSS) injection point
Step 3: Payload (proof of concept)
Now it’s time to craft a working proof of concept that executes JavaScript in the victim’s browser. To do so, your payload depends on 2 factors: 1) the context in which your input is reflected, and 2) any existing filters preventing you from injecting malicious XSS payloads. Let’s take a look at several contexts in which your unsanitized input can appear, and also go through a few payloads that can help us break out of it and achieve code execution.Generic (HTML context)
When your input is directly reflected in the HTML body without being wrapped in any specific tags or attributes, you have the most flexibility for exploitation. Start simple with payloads like:Veya:
Yukarıda bahsedilen her iki yük de herhangi bir etiketin dışına çıkmaya gerek kalmadan çalışacaktır. Bu, yeni başlayanlar için en kolay senaryodur; JavaScript yürütmeyi destekleyen hemen hemen her HTML etiketini kullanabilirsiniz. , , , or event handler attributes on self-closing tags.
Cross-site scripting (XSS) in HTML page (generic)
HTML attribute (inline HTML)
When your reflection appears inside an HTML attribute (like veya ), you’ll need to break out of the attribute context first before injecting your payload.
You can either close the attribute with a quote, close the entire tag with >ve ardından aşağıdaki gibi yeni bir kötü amaçlı etiket enjekte edin: ">gibi bir olay işleyicisi ekleyerek aynı etikette kalın " onload=alert(1) x=".
Önemli olan, özelliği sarmak için hangi alıntı türünün (tek veya çift) kullanıldığını ve uygulamanın bağlamdan kaçmamızı engelleyebilecek diğer karakterleri filtreleyip filtrelemediğini anlamaktır.
Bir HTML özelliğinde (satır içi HTML) siteler arası komut dosyası oluşturma (XSS)
JavaScript bloğu
Girişiniz içeriye yansıdığında etiketler, genellikle aşağıdaki gibi bir JavaScript değişken atamasının parçası olarak var data = "REFLECTION"; veya var config = {"key": "REFLECTION"};kodunuzu yürütmek için JavaScript sözdiziminin dışına çıkmanız gerekir.
Normal dizeler için kaçış "; alert(document.domain); // dizeyi kapatmak, kodunuzu yürütmek ve gerisini yorumlamak için.
Şablon değişmezleri (geri tıklamalar) için şunları kullanabilirsiniz: ${alert(document.domain)} sözdizimini bozmadan kodu doğrudan şablonun içinde yürütmek için.
Buradaki zor kısım, JavaScript’in enjeksiyonunuzdan sonra sözdizimsel olarak geçerli kalmasını sağlamaktır; bu nedenle hatalara neden olabilecek ve yürütmeyi engelleyebilecek kapatılmamış parantezlere, tırnaklara veya parantezlere dikkat edin.
JavaScript bloğunda siteler arası komut dosyası çalıştırma (XSS)
XSS güvenlik açıklarının neler olduğunu ve olası enjeksiyon noktalarını metodik olarak nasıl inceleyip tanımlayabileceğimizi ele aldık. Şimdi yeni edindiğimiz becerilerimizi test etme zamanı. Yüklerimizi oluşturmamıza daha iyi yardımcı olması için gerçek dünyadan birkaç örneğe göz atalım.
Filtrelemesiz XSS
Nadir durumlarda, XSS güvenlik açıklarını önlemek için hiçbir filtreleme veya doğrulamanın yapılmadığı senaryolarla karşılaşırsınız. Bunlar genellikle geliştiricilerin kullanıcı girişini temizlemeyi unutması nedeniyle ortaya çıkar.
Bu durumlarda XSS’nin varlığını kanıtlamak için istediğimiz herhangi bir veri yükünü kullanabiliriz:
Örnek 1: Giriş temizliği olmadan temel siteler arası komut dosyası çalıştırma (XSS)
Satır içi HTML’de XSS (öznitelikler)
Başka bir önemsiz senaryo, girişinizin bir HTML özelliğinin değerine yansıtıldığı yerdir. Bu durumda aşağıdakilerden birini yapabilirsiniz:
-
HTML özelliğinden çıkın ve isteğe bağlı JS kodunu yürütmek için bir olay işleyicisi ekleyin
-
Veya HTML özelliğinden çıkın, etiketi kapatın ve isteğe bağlı JS kodunu yürütmek için yeni bir etiket açın.
Bağlama bağlı olarak yeni bir olay işleyicisi eklemek genellikle çok daha kolaydır. Diğer durumlarda, HTML etiketlerini açmak ve kapatmak için kullanılan karakterler açıkça filtrelendiğinden, bu mümkün olan tek çözüm olabilir.
Örnek 2: Satır içi HTML verisi ile temel siteler arası komut dosyası oluşturma (XSS)
JavaScript bağlamında XSS
Uygulamalar karmaşıklaştıkça, geliştiriciler XSS güvenlik açıkları da dahil olmak üzere daha fazla güvenlik zayıflığı sunma eğiliminde oluyor. Bu bağlam çok daha az oluşsa da bazen geliştiriciler, temizlenmemiş kullanıcı girişini doğrudan JavaScript bağlamının içine yansıtır. Çoğu zaman sonuçlarının farkında olmadan, bu fırsatı bağlamdan kaçmak ve herhangi bir HTML kullanmadan rastgele JavaScript kodumuzu enjekte etmek için kullanabiliriz.
Yansıma noktasına bağlı olarak genellikle şunları yapmanız gerekir:
-
Geçerli bağlamdan kaçış (genellikle değişken bir değer veya işlev parametresi)
-
Yükünüzü enjekte edin
-
Sözdiziminin eşleşmesini sağlamak için yükünüzü kapatın
Örnek 3: Bir JavaScript kod bloğu içinde temel siteler arası komut dosyası oluşturma (XSS)
Textarea alanı içindeki XSS
Tarayıcılar, bazı HTML etiketleriyle, örneğin HTML etiketi, içeriği korumak için değerlerini oluşturmayı reddeder. Yeni başlayan biriyseniz, ilk başta bu senaryonun yararlanılamaz olduğunu düşünebilirsiniz. Ancak girişiniz bu etiketlerden herhangi birine yansıtılırsa yükümüzü eklemeden önce etiketi kapatmak zorunda kalacağız.
Örnek 4: Textarea bağlamında temel siteler arası komut dosyası çalıştırma (XSS)
Örnek 4: Textarea bağlamında temel siteler arası komut dosyası çalıştırma (XSS)
Sınırlı HTML ve özelliklere izin verilen XSS
Karşılaşacağınız yaygın bir senaryo, belirli bir model eşleştiğinde girdinin sınırlandığı, filtrelendiği veya tamamen engellendiği senaryodur. Bu, geliştiricilerin güvenme eğiliminde olduğu en çok kullanılan filtreleme yöntemlerinden biridir.
Neyse ki çoğu durumda, filtre veya web uygulaması güvenlik duvarı (WAF) bloğundan kurtulmamıza yardımcı olacak izin verilen tüm HTML etiketlerini, olay işleyicilerini ve karakterleri kolayca bulabiliriz.
Örnek 5: Sınırlı HTML etiketleri ve nitelikleriyle temel siteler arası komut dosyası oluşturma (XSS)
XSS için bulanıklaştırma
Hedefin XSS yükünüzü yürütmesini sağlamak için savunmanızda her şeyi denediniz ancak filtreden kaçmayı başaramadınız mı? Endişeye gerek yok, bu XSS için fuzz yapılmasının güçlü bir göstergesi!
PortSwigger Araştırma Akademisi, mevcut tüm HTML etiketlerini ve özelliklerini içeren bir kopya sayfası sağlar. Bu listeyi, enjeksiyon noktamızı inceleyerek kabul edilen tüm etiketleri ve olay işleyicilerini pratik olarak numaralandırmak için kullanabiliriz. Daha sonra tek yapmamız gereken, izin verilen bir HTML etiketini ve yükümüzü oluşturmamıza yardımcı olacak bir özelliği enjekte ederek yapboz parçalarımızı eşleştirmek!
https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
Bu makaleden çıkarılacak en önemli sonuç, enjeksiyon noktanızın bağlamını belirlemek ve hedefinizin kötü niyetli karakterlere nasıl davrandığını anlamaktır. Katı filtre kuralları uygulayan hedefleri test ederken, yansıma noktalarınızı manuel olarak test etmek için zaman ayırmanız önerilir. Bazı araçlar bunları kolayca tespit edemeyebilir ve bu nedenle onlara her zaman güvenilemez.
Yani, yansıyan XSS güvenlik açıklarını arama konusunda yeni bir şey öğrendiniz… Şu anda becerilerinizi test etme zamanı! Savunmasız laboratuvarlar ve CTF’ler üzerinde pratik yaparak başlayabilir veya… Intigriti’deki 70’ten fazla genel hata ödül programımıza göz atabilirsiniz ve kim bilir, belki bir sonraki gönderiminizde bir ödül kazanabilirsiniz!