PostMessage Vulnerabilities
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
PostMessage, bir mesaj göndermek için aşağıdaki işlevi kullanır:
Not edin ki targetOrigin bir '*' veya https://company.com gibi bir URL olabilir. İkinci senaryoda, mesaj yalnızca o alana gönderilebilir (pencere nesnesinin kökeni farklı olsa bile). Eğer joker karakter kullanılıyorsa, mesajlar herhangi bir alana gönderilebilir ve Pencere nesnesinin kökenine gönderilecektir.
bu raporda açıklandığı gibi, iframelenebilen (hiçbir X-Frame-Header
koruması olmayan) ve duyarlı mesajı postMessage aracılığıyla joker karakter (*) kullanarak gönderen bir sayfa bulursanız, iframe'in kökenini değiştirebilir ve duyarlı mesajı sizin kontrolünüzdeki bir alana sızdırabilirsiniz.
Eğer sayfa iframelenebiliyorsa ancak targetOrigin bir URL'ye ayarlandıysa ve joker karaktere değilse, bu numara çalışmayacaktır.
addEventListener
JS tarafından postMessages
bekleyen fonksiyonu tanımlamak için kullanılan işlevdir.
Aşağıdaki gibi bir kod kullanılacaktır:
Not edin ki bu durumda kodun yaptığı ilk şey kaynağı kontrol etmek. Bu, alınan bilgilerle herhangi bir hassas şey yapılacaksa son derece önemlidir (örneğin bir şifre değiştirmek gibi). Eğer kaynağı kontrol etmezse, saldırganlar kurbanların bu uç noktalara rastgele veri göndermesini sağlayabilir ve kurbanların şifrelerini değiştirebilir (bu örnekte).
Mevcut sayfadaki olay dinleyicilerini bulmak için şunları yapabilirsiniz:
JS kodunda window.addEventListener
ve $(window).on
(JQuery versiyonu) için arama yapın
Geliştirici araçları konsolunda şunu çalıştırın: getEventListeners(window)
Tarayıcının geliştirici araçlarında Elements --> Event Listeners kısmına gidin
https://github.com/benso-io/posta veya https://github.com/fransr/postMessage-tracker gibi bir tarayıcı uzantısı kullanın. Bu tarayıcı uzantıları tüm mesajları yakalar ve size gösterir.
event.isTrusted
niteliği güvenli kabul edilir çünkü yalnızca gerçek kullanıcı eylemleri tarafından üretilen olaylar için True
döner. Doğru bir şekilde uygulanırsa atlatılması zor olsa da, güvenlik kontrollerindeki önemi dikkate değerdir.
PostMessage olaylarında kaynak doğrulaması için indexOf()
kullanımı atlatmaya karşı hassas olabilir. Bu zayıflığı gösteren bir örnek:
String.prototype.search()
'ten search()
metodu, düzenli ifadeler için tasarlanmıştır, dizeler için değil. Regexp dışında bir şey geçmek, metodun potansiyel olarak güvensiz hale gelmesine neden olan regex'e örtük dönüşüme yol açar. Bunun nedeni, regex'te bir noktanın (.) joker karakter olarak işlev görmesi ve özel olarak hazırlanmış alan adlarıyla doğrulamanın atlatılmasına olanak tanımasıdır. Örneğin:
match()
fonksiyonu, search()
ile benzer şekilde regex'i işler. Eğer regex yanlış yapılandırılmışsa, atlatmaya karşı hassas olabilir.
escapeHtml
fonksiyonu, karakterleri kaçırarak girdileri temizlemek için tasarlanmıştır. Ancak, yeni bir kaçırılmış nesne oluşturmaz, mevcut nesnenin özelliklerini üzerine yazar. Bu davranış istismar edilebilir. Özellikle, bir nesne, kontrol edilen özelliğinin hasOwnProperty
'yi tanımayacak şekilde manipüle edilebiliyorsa, escapeHtml
beklenildiği gibi çalışmayacaktır. Bu, aşağıdaki örneklerde gösterilmektedir:
Beklenen Hata:
Kaçırma:
Bu zayıflık bağlamında, File
nesnesi, yalnızca okunabilir name
özelliği nedeniyle özellikle istismar edilebilir. Bu özellik, şablonlarda kullanıldığında escapeHtml
fonksiyonu tarafından temizlenmez ve potansiyel güvenlik risklerine yol açar.
JavaScript'teki document.domain
özelliği, bir script tarafından alan adını kısaltmak için ayarlanabilir, bu da aynı üst alan adı içinde daha gevşek bir aynı köken politikası uygulanmasına olanak tanır.
Bir sandboxed iframe içinde bir web sayfası gömüldüğünde %%%%%%, iframe'in kaynağının null olarak ayarlanacağını anlamak önemlidir. Bu, sandbox nitelikleri ile güvenlik ve işlevsellik üzerindeki etkileriyle ilgilenirken özellikle önemlidir.
allow-popups
niteliklerini belirleyerek, iframe içinden açılan herhangi bir açılır pencere, üst öğesinin sandbox kısıtlamalarını miras alır. Bu, allow-popups-to-escape-sandbox
niteliği de dahil edilmediği sürece, açılır pencerenin kaynağının da null
olarak ayarlandığı anlamına gelir ve bu, iframe'in kaynağı ile uyumludur.
Sonuç olarak, bu koşullar altında bir açılır pencere açıldığında ve iframe'den açılır pencereye postMessage
kullanılarak bir mesaj gönderildiğinde, hem gönderim hem de alım uçlarının kaynakları null
olarak ayarlanır. Bu durum, e.origin == window.origin
ifadesinin doğru değerlendirilmesine yol açar (null == null
), çünkü hem iframe hem de açılır pencere aynı null
kaynak değerini paylaşır.
Daha fazla bilgi için okuyun:
Bypassing SOP with Iframes - 1Mesajın, scriptin dinlediği aynı pencereden gelip gelmediğini kontrol etmek mümkündür (özellikle tarayıcı uzantılarından içerik scriptleri için mesajın aynı sayfadan gönderilip gönderilmediğini kontrol etmek ilginçtir):
e.source
'un bir mesajın null olmasını sağlamak için, postMessage gönderen ve hemen silinen bir iframe oluşturabilirsiniz.
Daha fazla bilgi için şunu okuyun:
Bypassing SOP with Iframes - 2Bu saldırıları gerçekleştirmek için ideal olarak kurban web sayfasını bir iframe
içine alabilmeniz gerekir. Ancak X-Frame-Header
gibi bazı başlıklar bu davranışı engelleyebilir.
Bu senaryolarda, daha az gizli bir saldırı kullanmaya devam edebilirsiniz. Zayıf web uygulamasına yeni bir sekme açabilir ve onunla iletişim kurabilirsiniz:
Aşağıdaki sayfada, veriyi göndermeden önce ana sayfayı engelleyerek bir çocuk iframe'ine gönderilen hassas postmessage verisini nasıl çalabileceğinizi görebilirsiniz ve çocukta bir XSS kullanarak veriyi sızdırabilirsiniz:
Blocking main page to steal postmessageX-Frame-Header içermeyen bir web sayfasını iframe'leyebiliyorsanız ve bu sayfa başka bir iframe içeriyorsa, o çocuk iframe'in konumunu değiştirebilirsiniz, böylece eğer bir wildcard kullanılarak gönderilen bir postmessage alıyorsa, bir saldırgan o iframe'in kaynağını kendisinin kontrol ettiği bir sayfaya değiştirebilir ve mesajı çalabilir:
Steal postmessage modifying iframe locationpostMessage
ile gönderilen verilerin JS tarafından çalıştırıldığı senaryolarda, sayfayı iframe'leyebilir ve prototip kirliliği/XSS'yi postMessage aracılığıyla gönderilen istismar ile sömürebilirsiniz.
https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html adresinde postMessage aracılığıyla Prototip Kirliliği ve ardından XSS'yi istismar etmek için çok iyi açıklanmış birkaç XSS örneği bulunmaktadır.
Bir iframe
'e postMessage
aracılığıyla Prototip Kirliliği ve ardından XSS'yi istismar etmek için bir örnek:
For daha fazla bilgi:
prototip kirlenmesi hakkında sayfaya bağlantı
XSS hakkında sayfaya bağlantı
istemci tarafı prototip kirlenmesi ile XSS hakkında sayfaya bağlantı
Pratik yapmak için: https://github.com/yavolo/eventlistener-xss-recon
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Ekip Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Ekip Uzmanı (GRTE)