- 29 Eki 2018
- 2,702
- 569
Bu bölümde, HTTP istek kaçakçılığı güvenlik açıklarını bulmak için farklı teknikleri açıklayacağız.
Zamanlama tekniklerini kullanarak HTTP istek kaçakçılığı güvenlik açıklarını bulma
HTTP istek kaçakçılığı güvenlik açıklarını tespit etmenin genel olarak en etkili yolu, bir güvenlik açığı varsa uygulamanın yanıtlarında zaman gecikmesine neden olacak istekler göndermektir. Bu teknik, Burp Scanner tarafından istek kaçakçılığı güvenlik açıklarının tespitini otomatikleştirmek için kullanılır.
Zamanlama tekniklerini kullanarak CL.TE güvenlik açıklarını bulma
Bir uygulama istek kaçakçılığının CL.TE varyantına karşı savunmasızsa, aşağıdaki gibi bir istek göndermek genellikle bir zaman gecikmesine neden olacaktır:
Front-end sunucu Content-Length başlığını kullandığından, X'i atlayarak bu isteğin yalnızca bir kısmını iletecektir. Back-end sunucu Transfer-Encoding başlığını kullanır, ilk yığını işler ve ardından bir sonraki yığının gelmesini bekler. Bu, gözlemlenebilir bir zaman gecikmesine neden olacaktır.
Zamanlama tekniklerini kullanarak TE.CL güvenlik açıklarını bulma
Bir uygulama istek kaçakçılığının TE.CL varyantına karşı savunmasızsa, aşağıdaki gibi bir istek göndermek genellikle bir zaman gecikmesine neden olacaktır:
Front-end sunucu Transfer-Encoding başlığını kullandığından, bu isteğin yalnızca bir kısmını iletecek ve X'i atlayacaktır. Back-end sunucu Content-Length başlığını kullanır, mesaj gövdesinde daha fazla içerik bekler ve kalan içeriğin gelmesini bekler. Bu, gözlemlenebilir bir zaman gecikmesine neden olacaktır.
Not: TE.CL güvenlik açıkları için zamanlama tabanlı test, uygulama güvenlik açığının CL.TE varyantına karşı savunmasızsa diğer uygulama kullanıcılarını potansiyel olarak kesintiye uğratacaktır. Bu nedenle, gizli olmak ve kesintiyi en aza indirmek için, önce CL.TE testini kullanmalı ve yalnızca ilk test başarısız olursa TE.CL testine devam etmelisiniz.
Farklılaştırılmış müdahale yanıtları kullanarak HTTP istek kaçakçılığı güvenlik açıklarını doğrulama
Olası bir istek kaçakçılığı güvenlik açığı tespit edildiğinde, uygulamanın yanıtlarının içeriğindeki farklılıkları tetiklemek için güvenlik açığından yararlanarak güvenlik açığı için daha fazla kanıt elde edebilirsiniz. Bu, uygulamaya hızlı bir şekilde art arda iki istek göndermeyi içerir:
Bu istek normalde bazı arama sonuçlarını içeren 200 durum kodlu bir HTTP yanıtı alır. Bu talebe müdahale etmek için gereken saldırı talebi, mevcut olan talep kaçakçılığı varyantına bağlıdır: CL.TE vs TE.CL.
CL.TE güvenlik açıklarını farklılaştırılmış müdahale kullanarak doğrulama
Bir CL.TE güvenlik açığını doğrulamak için aşağıdaki gibi bir saldırı isteği gönderirsiniz:
Saldırı başarılı olursa, bu isteğin son iki satırı back-end sunucu tarafından alınan bir sonraki isteğe aitmiş gibi değerlendirilir. Bu, sonraki "normal" isteğin aşağıdaki gibi görünmesine neden olacaktır:
Bu istek artık geçersiz bir URL içerdiğinden, sunucu 404 durum koduyla yanıt vererek saldırı isteğinin gerçekten de kendisine müdahale ettiğini gösterir.
Bu bölümde 1. lab vardır, yorumlardan erişebilirsiniz.
TE.CL güvenlik açıklarını farklılaştırılmış müdahale kullanarak doğrulama
TE.CL güvenlik açığını doğrulamak için aşağıdaki gibi bir saldırı isteği gönderirsiniz:
Not: Bu isteği Burp Repeater kullanarak göndermek için öncelikle Repeater menüsüne gitmeniz ve "Update Content-Length" seçeneğinin işaretli olmadığından emin olmanız gerekir. Son 0'ın ardından gelen \r\n\r\n dizisini eklemeniz gerekir.
Saldırı başarılı olursa, GET /404'ten itibaren her şey back-end sunucu tarafından alınan bir sonraki talebe ait olarak değerlendirilir. Bu, sonraki "normal" isteğin şu şekilde görünmesine neden olacaktır:
Bu istek artık geçersiz bir URL içerdiğinden, sunucu 404 durum koduyla yanıt vererek saldırı isteğinin gerçekten de kendisine müdahale ettiğini gösterir.
Bu bölümde 2. lab vardır, yorumlardan erişebilirsiniz.
Not:
Zamanlama tekniklerini kullanarak HTTP istek kaçakçılığı güvenlik açıklarını bulma
HTTP istek kaçakçılığı güvenlik açıklarını tespit etmenin genel olarak en etkili yolu, bir güvenlik açığı varsa uygulamanın yanıtlarında zaman gecikmesine neden olacak istekler göndermektir. Bu teknik, Burp Scanner tarafından istek kaçakçılığı güvenlik açıklarının tespitini otomatikleştirmek için kullanılır.
Zamanlama tekniklerini kullanarak CL.TE güvenlik açıklarını bulma
Bir uygulama istek kaçakçılığının CL.TE varyantına karşı savunmasızsa, aşağıdaki gibi bir istek göndermek genellikle bir zaman gecikmesine neden olacaktır:
HTTP:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4
1
A
XFront-end sunucu Content-Length başlığını kullandığından, X'i atlayarak bu isteğin yalnızca bir kısmını iletecektir. Back-end sunucu Transfer-Encoding başlığını kullanır, ilk yığını işler ve ardından bir sonraki yığının gelmesini bekler. Bu, gözlemlenebilir bir zaman gecikmesine neden olacaktır.
Zamanlama tekniklerini kullanarak TE.CL güvenlik açıklarını bulma
Bir uygulama istek kaçakçılığının TE.CL varyantına karşı savunmasızsa, aşağıdaki gibi bir istek göndermek genellikle bir zaman gecikmesine neden olacaktır:
HTTP:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 6
0
XFront-end sunucu Transfer-Encoding başlığını kullandığından, bu isteğin yalnızca bir kısmını iletecek ve X'i atlayacaktır. Back-end sunucu Content-Length başlığını kullanır, mesaj gövdesinde daha fazla içerik bekler ve kalan içeriğin gelmesini bekler. Bu, gözlemlenebilir bir zaman gecikmesine neden olacaktır.
Not: TE.CL güvenlik açıkları için zamanlama tabanlı test, uygulama güvenlik açığının CL.TE varyantına karşı savunmasızsa diğer uygulama kullanıcılarını potansiyel olarak kesintiye uğratacaktır. Bu nedenle, gizli olmak ve kesintiyi en aza indirmek için, önce CL.TE testini kullanmalı ve yalnızca ilk test başarısız olursa TE.CL testine devam etmelisiniz.
Farklılaştırılmış müdahale yanıtları kullanarak HTTP istek kaçakçılığı güvenlik açıklarını doğrulama
Olası bir istek kaçakçılığı güvenlik açığı tespit edildiğinde, uygulamanın yanıtlarının içeriğindeki farklılıkları tetiklemek için güvenlik açığından yararlanarak güvenlik açığı için daha fazla kanıt elde edebilirsiniz. Bu, uygulamaya hızlı bir şekilde art arda iki istek göndermeyi içerir:
- Bir sonraki talebin işlenmesini engellemek için tasarlanmış bir "saldırı" isteği.
- "Normal" bir istek.
HTTP:
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smugglingBu istek normalde bazı arama sonuçlarını içeren 200 durum kodlu bir HTTP yanıtı alır. Bu talebe müdahale etmek için gereken saldırı talebi, mevcut olan talep kaçakçılığı varyantına bağlıdır: CL.TE vs TE.CL.
CL.TE güvenlik açıklarını farklılaştırılmış müdahale kullanarak doğrulama
Bir CL.TE güvenlik açığını doğrulamak için aşağıdaki gibi bir saldırı isteği gönderirsiniz:
HTTP:
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
Transfer-Encoding: chunked
e
q=smuggling&x=
0
GET /404 HTTP/1.1
Foo: xSaldırı başarılı olursa, bu isteğin son iki satırı back-end sunucu tarafından alınan bir sonraki isteğe aitmiş gibi değerlendirilir. Bu, sonraki "normal" isteğin aşağıdaki gibi görünmesine neden olacaktır:
HTTP:
GET /404 HTTP/1.1
Foo: xPOST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smugglingBu istek artık geçersiz bir URL içerdiğinden, sunucu 404 durum koduyla yanıt vererek saldırı isteğinin gerçekten de kendisine müdahale ettiğini gösterir.
Bu bölümde 1. lab vardır, yorumlardan erişebilirsiniz.
TE.CL güvenlik açıklarını farklılaştırılmış müdahale kullanarak doğrulama
TE.CL güvenlik açığını doğrulamak için aşağıdaki gibi bir saldırı isteği gönderirsiniz:
HTTP:
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
7c
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144
x=
0Not: Bu isteği Burp Repeater kullanarak göndermek için öncelikle Repeater menüsüne gitmeniz ve "Update Content-Length" seçeneğinin işaretli olmadığından emin olmanız gerekir. Son 0'ın ardından gelen \r\n\r\n dizisini eklemeniz gerekir.
Saldırı başarılı olursa, GET /404'ten itibaren her şey back-end sunucu tarafından alınan bir sonraki talebe ait olarak değerlendirilir. Bu, sonraki "normal" isteğin şu şekilde görünmesine neden olacaktır:
HTTP:
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 146
x=
0
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smugglingBu istek artık geçersiz bir URL içerdiğinden, sunucu 404 durum koduyla yanıt vererek saldırı isteğinin gerçekten de kendisine müdahale ettiğini gösterir.
Bu bölümde 2. lab vardır, yorumlardan erişebilirsiniz.
Not:
- "Saldırı" isteği ve "normal" istek sunucuya farklı ağ bağlantıları kullanılarak gönderilmelidir. Her iki isteğin de aynı bağlantı üzerinden gönderilmesi güvenlik açığının var olduğunu kanıtlamaz.
- "Saldırı" isteği ve "normal" istek mümkün olduğunca aynı URL ve parametre adlarını kullanmalıdır. Bunun nedeni, birçok modern uygulamanın front-end isteklerini URL ve parametrelere göre farklı back-end sunucularına yönlendirmesidir. Aynı URL ve parametrelerin kullanılması, isteklerin aynı arka uç sunucusu tarafından işlenme şansını artırır, bu da saldırının çalışması için gereklidir.
- "Saldırı" isteğinden kaynaklanan herhangi bir müdahaleyi tespit etmek için "normal" isteği test ederken, diğer kullanıcılardan gelenler de dahil olmak üzere uygulamanın aynı anda aldığı diğer tüm isteklerle bir yarış içindesinizdir. "Normal" isteği "saldırı" isteğinden hemen sonra göndermelisiniz. Uygulama meşgulse, güvenlik açığını doğrulamak için birden fazla deneme yapmanız gerekebilir.
- Bazı uygulamalarda, front-end sunucusu bir yük dengeleyici olarak işlev görür ve bazı yük dengeleme algoritmalarına göre istekleri farklı arka uç sistemlerine iletir. Eğer "saldırı" ve "normal" istekleriniz farklı back-end sistemlerine yönlendirilirse, saldırı başarısız olacaktır. Bu, bir güvenlik açığının doğrulanabilmesi için birkaç kez denemeniz gerekmesinin ek bir nedenidir.
- Saldırınız sonraki bir isteğe müdahale etmeyi başarırsa, ancak bu, müdahaleyi tespit etmek için gönderdiğiniz "normal" istek değilse, bu, başka bir uygulama kullanıcısının saldırınızdan etkilendiği anlamına gelir. Testi yapmaya devam ederseniz, bunun diğer kullanıcılar üzerinde yıkıcı bir etkisi olabilir ve dikkatli olmalısınız.
