G\u00fcn\u00fcm\u00fcz\u00fcn dijital d\u00fcnyas\u0131nda, web uygulamalar\u0131 ve API’ler (Uygulama Programlama Aray\u00fczleri) i\u015f s\u00fcre\u00e7lerinin bel kemi\u011fini olu\u015fturuyor. Kullan\u0131c\u0131 deneyimini zenginle\u015ftiren, sistemler aras\u0131 ileti\u015fimi sa\u011flayan bu yap\u0131lar, ne yaz\u0131k ki siber sald\u0131rganlar i\u00e7in de cazip hedefler haline gelmi\u015ftir. \u00d6zellikle HTTP parametreleri \u00fczerinden ger\u00e7ekle\u015ftirilen sald\u0131r\u0131lar, basit g\u00f6r\u00fcnseler de ciddi g\u00fcvenlik a\u00e7\u0131klar\u0131na yol a\u00e7abilir. Peki, bir Web Uygulama G\u00fcvenlik Duvar\u0131 (WAF) ayn\u0131 parametrenin tek bir de\u011ferini alg\u0131larken, arka u\u00e7taki uygulama \u00e7er\u00e7evesi (framework) farkl\u0131 bir de\u011ferle mi \u00e7al\u0131\u015f\u0131yor? \u0130\u015fte bu ince fark, HTTP Parametre Kirlili\u011fi (HPP) sald\u0131r\u0131lar\u0131n\u0131n temelini olu\u015fturur ve API g\u00fcvenli\u011fini derinden sarsar.<\/p>\n
HTTP Parametre Kirlili\u011fi (HTTP Parameter Pollution – HPP), bir web uygulamas\u0131n\u0131n veya API’nin, ayn\u0131 HTTP iste\u011fi i\u00e7inde birden fazla kez tekrarlanan bir parametreyi nas\u0131l i\u015fledi\u011findeki farkl\u0131l\u0131klardan kaynaklanan bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131d\u0131r. Bu sald\u0131r\u0131 t\u00fcr\u00fc, \u00f6zellikle Web Uygulama G\u00fcvenlik Duvarlar\u0131 (WAF’lar) ve arka u\u00e7taki uygulama \u00e7er\u00e7evelerinin (framework) ayn\u0131 parametrenin birden fazla de\u011ferini farkl\u0131 \u015fekillerde yorumlamas\u0131 durumunda ortaya \u00e7\u0131kar. Kula\u011fa karma\u015f\u0131k gelse de, temel mant\u0131\u011f\u0131 olduk\u00e7a basittir: Sald\u0131rgan, bir parametreyi birden fazla kez g\u00f6ndererek, WAF’\u0131n “temiz” g\u00f6rd\u00fc\u011f\u00fc bir de\u011feri, uygulaman\u0131n ise “k\u00f6t\u00fc niyetli” bir de\u011feri i\u015flemesini sa\u011flamaya \u00e7al\u0131\u015f\u0131r.<\/p>\n
Bu sald\u0131r\u0131 vekt\u00f6r\u00fcn\u00fcn \u00f6nemi, modern web mimarilerinde yatmaktad\u0131r. \u00c7o\u011fu uygulama, kullan\u0131c\u0131 girdilerini HTTP parametreleri arac\u0131l\u0131\u011f\u0131yla al\u0131r; bu parametreler URL sorgu dizisinde (query string) veya POST g\u00f6vdesinde bulunabilir. \u00d6rne\u011fin, bir al\u0131\u015fveri\u015f sitesinde \u00fcr\u00fcn ID’si, bir arama motorunda arama terimi ya da bir bankac\u0131l\u0131k uygulamas\u0131nda i\u015flem tutar\u0131 gibi kritik bilgiler parametreler \u00fczerinden ta\u015f\u0131n\u0131r. HPP sald\u0131r\u0131lar\u0131, bu parametrelerin i\u015flenme \u015feklindeki tutars\u0131zl\u0131klar\u0131 hedef alarak kimlik do\u011frulama atlatma, veri s\u0131zd\u0131rma, SQL enjeksiyonu (SQL injection) veya i\u015f mant\u0131\u011f\u0131 hatalar\u0131na yol a\u00e7abilir. Bir WAF, genellikle bilinen sald\u0131r\u0131 kal\u0131plar\u0131n\u0131 veya anormal girdileri tespit etmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Ancak HPP durumunda, WAF belirli bir parametrenin yaln\u0131zca ilk veya son de\u011ferini kontrol edebilirken, uygulama \u00e7er\u00e7evesi tamamen farkl\u0131 bir de\u011fer k\u00fcmesini veya birle\u015fimini ele alabilir. Bu “k\u00f6r nokta”, sald\u0131rganlara g\u00fcvenlik kontrollerini a\u015fmak i\u00e7in e\u015fsiz bir f\u0131rsat sunar.<\/p>\n
\u00d6rne\u011fin, bir API’ye g\u00f6nderilen bir istekte Web Uygulama G\u00fcvenlik Duvarlar\u0131 (WAF’lar) ve arka u\u00e7ta \u00e7al\u0131\u015fan uygulama \u00e7er\u00e7eveleri (framework), gelen HTTP isteklerini farkl\u0131 \u015fekillerde \u00e7\u00f6z\u00fcmler. Bu farkl\u0131l\u0131k, HTTP Parametre Kirlili\u011fi (HPP) sald\u0131r\u0131lar\u0131n\u0131n temelini olu\u015fturan kritik bir g\u00fcvenlik zafiyetidir. WAF’lar\u0131n ana g\u00f6revi, k\u00f6t\u00fc niyetli istekleri daha uygulamaya ula\u015fmadan tespit edip engellemektir. Bu ama\u00e7la, HTTP isteklerinin ba\u015fl\u0131klar\u0131n\u0131, g\u00f6vdelerini ve \u00f6zellikle parametrelerini analiz ederler. Ancak bu analiz, \u00e7o\u011fu zaman performans kayg\u0131lar\u0131 veya belirli g\u00fcvenlik kurallar\u0131n\u0131n \u00f6ncelikleri nedeniyle, uygulama \u00e7er\u00e7evesinin yapt\u0131\u011f\u0131 detayl\u0131 \u00e7\u00f6z\u00fcmlemeden farkl\u0131l\u0131k g\u00f6sterebilir.<\/p>\n \u00d6rne\u011fin, bir HTTP iste\u011finde ayn\u0131 parametre ad\u0131n\u0131n birden fazla kez ge\u00e7ti\u011fi bir senaryoyu ele alal\u0131m: Bu farkl\u0131l\u0131k, sald\u0131rganlar i\u00e7in bir “bo\u015fluk” yarat\u0131r. E\u011fer sald\u0131rgan, WAF’\u0131n kontrol etti\u011fi de\u011feri zarars\u0131z (beyaz liste) tutarken, uygulaman\u0131n i\u015fleyece\u011fi ikinci de\u011feri k\u00f6t\u00fc niyetli (kara liste) olarak ayarlayabilirse, WAF’\u0131 atlatarak uygulamada istedi\u011fi etkiyi yaratabilir. \u00d6rne\u011fin, bir WAF, Bu tutars\u0131zl\u0131k, WAF’lar\u0131n genellikle statik kurallar veya bilinen imzalara dayal\u0131 \u00e7al\u0131\u015fmas\u0131, uygulama \u00e7er\u00e7evelerinin ise daha dinamik ve esnek girdi i\u015fleme mekanizmalar\u0131na sahip olmas\u0131yla da ili\u015fkilidir. WAF’lar, milyarlarca iste\u011fi h\u0131zl\u0131ca i\u015flemek zorunda olduklar\u0131ndan, her bir parametrenin her bir tekrar\u0131n\u0131 derinlemesine analiz etmek yerine, daha y\u00fczeysel bir kontrol yapabilirler. Ancak bu durum, HPP sald\u0131r\u0131lar\u0131 i\u00e7in zemin haz\u0131rlar ve API g\u00fcvenli\u011fi a\u00e7\u0131s\u0131ndan ciddi riskler bar\u0131nd\u0131r\u0131r. Geli\u015ftiricilerin ve g\u00fcvenlik uzmanlar\u0131n\u0131n, bu \u00e7\u00f6z\u00fcmleme farkl\u0131l\u0131klar\u0131n\u0131n fark\u0131nda olmas\u0131 ve hem WAF hem de uygulama taraf\u0131nda gerekli \u00f6nlemleri almas\u0131 hayati \u00f6nem ta\u015f\u0131r.<\/p>\n HTTP Parametre Kirlili\u011fi (HPP) sald\u0131r\u0131lar\u0131, teorik bir zay\u0131fl\u0131k olmaktan \u00f6te, bir\u00e7ok ger\u00e7ek d\u00fcnya uygulamas\u0131nda ciddi g\u00fcvenlik ihlallerine yol a\u00e7m\u0131\u015ft\u0131r. Bu sald\u0131r\u0131lar, uygulaman\u0131n i\u015f mant\u0131\u011f\u0131n\u0131 manip\u00fcle etme, kimlik do\u011frulama kontrollerini atlatma, yetkisiz veri eri\u015fimi sa\u011flama ve hatta sunucu taraf\u0131nda kod \u00e7al\u0131\u015ft\u0131rma gibi \u00e7e\u015fitli \u015fekillerde kendini g\u00f6sterebilir. \u0130\u015fte HPP’nin nas\u0131l kullan\u0131labilece\u011fine dair baz\u0131 \u00e7arp\u0131c\u0131 senaryolar ve vaka analizleri:<\/p>\n En yayg\u0131n HPP senaryolar\u0131ndan biri, kullan\u0131c\u0131 kimli\u011fini veya yetkisini manip\u00fcle etmektir. Bir uygulama, genellikle bir kullan\u0131c\u0131n\u0131n oturum a\u00e7m\u0131\u015f olup olmad\u0131\u011f\u0131n\u0131 veya belirli bir eylemi ger\u00e7ekle\u015ftirmeye yetkili olup olmad\u0131\u011f\u0131n\u0131 kontrol etmek i\u00e7in parametreleri kullan\u0131r. Sald\u0131rgan, bu parametreleri kirleterek g\u00fcvenlik kontrollerini atlatabilir.<\/p>\n HPP, SQL enjeksiyonu sald\u0131r\u0131lar\u0131nda WAF’lar\u0131 atlatmak i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7 olabilir. Sald\u0131rgan, WAF’\u0131n g\u00f6z\u00fcnden ka\u00e7acak bir “temiz” parametre ile birlikte, uygulaman\u0131n i\u015fleyece\u011fi k\u00f6t\u00fc niyetli bir SQL payload’u g\u00f6nderebilir.<\/p>\n HPP, bir uygulaman\u0131n i\u015f mant\u0131\u011f\u0131n\u0131 bozmak i\u00e7in de kullan\u0131labilir. Bu, genellikle fiyatland\u0131rma, indirimler veya sipari\u015f miktarlar\u0131 gibi finansal parametrelerin manip\u00fclasyonu \u015feklinde ortaya \u00e7\u0131kar.<\/p>\n Daha ileri d\u00fczey HPP sald\u0131r\u0131lar\u0131, dosya yolu manip\u00fclasyonu veya komut enjeksiyonu ile RCE’ye kadar gidebilir.<\/p>\n Bu senaryolar, HPP’nin sadece teorik bir risk olmad\u0131\u011f\u0131n\u0131, aksine \u00e7e\u015fitli uygulama katmanlar\u0131nda ciddi g\u00fcvenlik ihlallerine yol a\u00e7abilecek pratik bir sald\u0131r\u0131 vekt\u00f6r\u00fc oldu\u011funu g\u00f6stermektedir. Bu nedenle, geli\u015ftiricilerin ve g\u00fcvenlik uzmanlar\u0131n\u0131n bu t\u00fcr sald\u0131r\u0131lara kar\u015f\u0131 proaktif \u00f6nlemler almas\u0131 b\u00fcy\u00fck \u00f6nem ta\u015f\u0131maktad\u0131r.<\/p>\n HTTP Parametre Kirlili\u011fi (HPP) sald\u0131r\u0131lar\u0131, sinsi do\u011falar\u0131 gere\u011fi tespit edilmesi ve \u00f6nlenmesi zor olabilir. Ancak do\u011fru stratejiler ve en iyi uygulamalarla API’lerinizi ve web uygulamalar\u0131n\u0131z\u0131 bu t\u00fcr tehditlere kar\u015f\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirebilirsiniz. Korunma, hem uygulama katman\u0131nda hem de a\u011f katman\u0131nda \u00e7ok y\u00f6nl\u00fc bir yakla\u015f\u0131m gerektirir.<\/p>\n En temel ve en etkili savunma y\u00f6ntemi, uygulaman\u0131z\u0131n ayn\u0131 isimli parametreleri her zaman tutarl\u0131 bir \u015fekilde i\u015flemesini sa\u011flamakt\u0131r. Bu, WAF’\u0131n\u0131z\u0131n ve arka u\u00e7 uygulaman\u0131z\u0131n parametreleri ayn\u0131 mant\u0131kla yorumlamas\u0131 anlam\u0131na gelir. E\u011fer uygulaman\u0131z ayn\u0131 parametrenin birden fazla de\u011ferini bir dizi olarak bekliyorsa, bunu a\u00e7\u0131k\u00e7a belirtmeli ve WAF’\u0131n\u0131z\u0131 da buna g\u00f6re yap\u0131land\u0131rmal\u0131s\u0131n\u0131z. E\u011fer tek bir de\u011fer bekleniyorsa, fazladan gelen t\u00fcm de\u011ferler g\u00f6z ard\u0131 edilmeli veya bir hata mesaj\u0131 ile reddedilmelidir.<\/p>\n Yukar\u0131daki Node.js \u00f6rne\u011finde, T\u00fcm kullan\u0131c\u0131 girdilerini, \u00f6zellikle HTTP parametrelerini, beklenen veri t\u00fcr\u00fcne, bi\u00e7imine, uzunlu\u011funa ve izin verilen karakter setine g\u00f6re s\u0131k\u0131 bir \u015fekilde do\u011frulamak (validate) esast\u0131r. Bu, hem HPP hem de di\u011fer enjeksiyon sald\u0131r\u0131lar\u0131n\u0131 \u00f6nlemek i\u00e7in kritik bir ad\u0131md\u0131r. Beyaz liste (whitelist) yakla\u015f\u0131m\u0131, kara liste (blacklist) yakla\u015f\u0131m\u0131ndan \u00e7ok daha g\u00fcvenlidir.<\/p>\n WAF’\u0131n\u0131z\u0131, uygulaman\u0131z\u0131n parametre i\u015fleme mant\u0131\u011f\u0131yla uyumlu olacak \u015fekilde yap\u0131land\u0131r\u0131n. E\u011fer uygulaman\u0131z ayn\u0131 parametrenin ilk de\u011ferini i\u015fliyorsa, WAF’\u0131n\u0131z\u0131n da yaln\u0131zca ilk de\u011feri kontrol etti\u011finden emin olun. Ya da WAF’\u0131n\u0131z\u0131, ayn\u0131 parametrenin birden fazla kez g\u00f6nderildi\u011fi istekleri do\u011frudan engellemek \u00fczere yap\u0131land\u0131rabilirsiniz. ModSecurity gibi WAF \u00e7\u00f6z\u00fcmleri, bu t\u00fcr kurallar\u0131 tan\u0131mlaman\u0131za olanak tan\u0131r. \u00d6rne\u011fin, bir kural ile ayn\u0131 parametrenin birden fazla kez ge\u00e7mesini engelleyebilirsiniz.<\/p>\n WAF’\u0131n\u0131z\u0131n sald\u0131r\u0131 tespit motorlar\u0131n\u0131, HPP senaryolar\u0131n\u0131 kapsayacak \u015fekilde g\u00fcncel tuttu\u011funuzdan emin olun. D\u00fczenli olarak WAF g\u00fcnl\u00fcklerini inceleyerek HPP giri\u015fimlerini veya \u015f\u00fcpheli parametre manip\u00fclasyonlar\u0131n\u0131 tespit etmeye \u00e7al\u0131\u015f\u0131n.<\/p>\n API A\u011f Ge\u00e7itleri, API’leriniz i\u00e7in merkezi bir g\u00fcvenlik katman\u0131 sa\u011flayabilir. Bu a\u011f ge\u00e7itleri, gelen istekleri arka u\u00e7taki servislere y\u00f6nlendirmeden \u00f6nce kimlik do\u011frulama, yetkilendirme, h\u0131z s\u0131n\u0131rlama ve giri\u015f do\u011frulamas\u0131 gibi i\u015flemleri ger\u00e7ekle\u015ftirebilir. Bir API a\u011f ge\u00e7idi, HPP’ye kar\u015f\u0131 savunmada \u00f6nemli bir rol oynayabilir \u00e7\u00fcnk\u00fc parametreleri standartla\u015ft\u0131r\u0131lm\u0131\u015f bir \u015fekilde i\u015fleyebilir ve birden fazla parametre durumunda tek bir de\u011ferin ge\u00e7i\u015fini zorunlu k\u0131labilir.<\/p>\n Baz\u0131 durumlarda, parametre de\u011ferlerini URL kodlamak (URL encode) veya di\u011fer uygun kodlama y\u00f6ntemlerini kullanmak, parametre kirlili\u011fini \u00f6nlemeye yard\u0131mc\u0131 olabilir. Ancak bu, sald\u0131rgan\u0131n parametreleri nas\u0131l manip\u00fcle etti\u011fine ba\u011fl\u0131 olarak de\u011fi\u015fir. Temel savunma, uygulaman\u0131n parametreleri do\u011fru ve tutarl\u0131 bir \u015fekilde i\u015flemesini sa\u011flamakt\u0131r.<\/p>\n Bu korunma y\u00f6ntemlerini bir arada uygulayarak, API’lerinizin HPP sald\u0131r\u0131lar\u0131na kar\u015f\u0131 direncini art\u0131rabilir ve genel web g\u00fcvenli\u011finizi g\u00fc\u00e7lendirebilirsiniz. Unutmay\u0131n, g\u00fcvenlik s\u00fcrekli bir s\u00fcre\u00e7tir ve tehditler evrildik\u00e7e savunma mekanizmalar\u0131n\u0131z\u0131 da g\u00fcncellemeniz gerekmektedir.<\/p>\n HTTP Parametre Kirlili\u011fi (HPP) sald\u0131r\u0131lar\u0131, basit gibi g\u00f6r\u00fcnse de, modern ve karma\u015f\u0131k API mimarilerinde ciddi g\u00fcvenlik bo\u015fluklar\u0131 yaratabilen, sinsi bir tehdittir. Temel korunma y\u00f6ntemlerinin \u00f6tesine ge\u00e7erek, daha ileri d\u00fczey g\u00fcvenlik stratejileri benimsemek, bu t\u00fcr sald\u0131r\u0131lara kar\u015f\u0131 direnci art\u0131rmak i\u00e7in hayati \u00f6neme sahiptir. Gelecekteki tehditleri \u00f6ng\u00f6rerek, savunma mekanizmalar\u0131m\u0131z\u0131 s\u00fcrekli geli\u015ftirmeliyiz.<\/p>\n Geleneksel WAF’lar genellikle imza tabanl\u0131 veya kural tabanl\u0131 \u00e7al\u0131\u015f\u0131rken, HPP gibi daha incelikli sald\u0131r\u0131lar\u0131 tespit etmekte zorlanabilirler. Bu noktada, davran\u0131\u015fsal analiz ve anomali tespiti devreye girer. Bir sistem, normal kullan\u0131c\u0131 davran\u0131\u015flar\u0131n\u0131 \u00f6\u011frenir ve bu davran\u0131\u015flardan sapmalar\u0131 tespit etmeye \u00e7al\u0131\u015f\u0131r. \u00d6rne\u011fin:<\/p>\n Bu t\u00fcr anormallikler, bir HPP sald\u0131r\u0131s\u0131 veya ba\u015fka bir manip\u00fclasyon giri\u015fimi olabilece\u011fine dair bir uyar\u0131 i\u015fareti olabilir. Makine \u00f6\u011frenimi algoritmalar\u0131, bu t\u00fcr desenleri tespit etmede olduk\u00e7a etkilidir ve WAF’lar\u0131n veya API A\u011f Ge\u00e7itlerinin yeteneklerini geni\u015fletebilir.<\/p>\n RASP \u00e7\u00f6z\u00fcmleri, do\u011frudan uygulama i\u00e7inde \u00e7al\u0131\u015farak, geleneksel g\u00fcvenlik duvarlar\u0131n\u0131n eri\u015femedi\u011fi uygulama i\u00e7i ba\u011flam bilgilerini kullan\u0131r. Uygulaman\u0131n \u00e7al\u0131\u015fma zaman\u0131nda (runtime) kendini izlemesini ve sald\u0131r\u0131lar\u0131 ger\u00e7ek zamanl\u0131 olarak engellemesini sa\u011flar. HPP s\u00f6z konusu oldu\u011funda, RASP:<\/p>\n RASP, uygulaman\u0131n kendine \u00f6zg\u00fc davran\u0131\u015flar\u0131n\u0131 anlayarak daha do\u011fru ve ba\u011flama duyarl\u0131 g\u00fcvenlik kararlar\u0131 verebilir, bu da HPP gibi sald\u0131r\u0131lar\u0131n \u00f6nlenmesinde b\u00fcy\u00fck bir avantaj sa\u011flar.<\/p>\n Hi\u00e7bir g\u00fcvenlik \u00e7\u00f6z\u00fcm\u00fc kusursuz de\u011fildir. Bu nedenle, API’lerinizi d\u00fczenli ve kapsaml\u0131 g\u00fcvenlik testlerine tabi tutmak, potansiyel HPP zafiyetlerini ve di\u011fer g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 proaktif olarak tespit etmek i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n En iyi g\u00fcvenlik ara\u00e7lar\u0131 bile, onlar\u0131 kullanan veya kod yazan ki\u015filerin fark\u0131ndal\u0131\u011f\u0131 olmadan yetersiz kal\u0131r. Geli\u015ftiricilerin HPP gibi sald\u0131r\u0131 vekt\u00f6rleri hakk\u0131nda bilgi sahibi olmas\u0131, g\u00fcvenli kodlama pratiklerini benimsemesi ve g\u00fcvenlik testlerini rutin i\u015f ak\u0131\u015flar\u0131na dahil etmesi \u00e7ok \u00f6nemlidir. D\u00fczenli g\u00fcvenlik e\u011fitimleri, geli\u015ftiricilerin g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 erken a\u015famada tespit etmelerine ve \u00f6nlem almalar\u0131na yard\u0131mc\u0131 olur.<\/p>\n API’ler, giderek daha fazla mikroservis mimarisi ve sunucusuz (serverless) fonksiyonlar arac\u0131l\u0131\u011f\u0131yla geli\u015ftirilmekte. Bu da\u011f\u0131t\u0131k yap\u0131lar, parametre i\u015fleme ve g\u00fcvenlik politikalar\u0131n\u0131n daha da karma\u015f\u0131k hale gelmesine neden olabilir. Her bir mikroservisin veya fonksiyonun kendi parametre i\u015fleme mant\u0131\u011f\u0131 olabilece\u011finden, HPP riski daha da artabilir. Bu nedenle:<\/p>\n HPP, basit bir teknik gibi g\u00f6r\u00fcnse de, ard\u0131ndaki mant\u0131k modern web uygulamalar\u0131n\u0131n ve API’lerinin kar\u015f\u0131la\u015ft\u0131\u011f\u0131 daha geni\u015f g\u00fcvenlik zorluklar\u0131n\u0131 yans\u0131tmaktad\u0131r. Bu nedenle, g\u00fcvenlik stratejilerimizi s\u00fcrekli g\u00f6zden ge\u00e7irmeli, yeni teknolojileri ve yakla\u015f\u0131mlar\u0131 benimseyerek bir ad\u0131m \u00f6nde olmal\u0131y\u0131z.<\/p>\n HTTP Parametre Kirlili\u011fi (HPP) sald\u0131r\u0131lar\u0131, web uygulamalar\u0131 ve API’ler i\u00e7in g\u00f6z ard\u0131 edilmemesi gereken, sinsi bir tehdit olu\u015fturmaktad\u0131r. WAF’lar\u0131n ve arka u\u00e7taki uygulama \u00e7er\u00e7evelerinin HTTP parametrelerini farkl\u0131 \u015fekillerde yorumlamas\u0131 aras\u0131ndaki uyumsuzluk, sald\u0131rganlara g\u00fcvenlik kontrollerini atlatma ve uygulamalar\u0131n i\u015f mant\u0131\u011f\u0131n\u0131 manip\u00fcle etme f\u0131rsat\u0131 sunar. Kimlik do\u011frulama atlatma, SQL enjeksiyonu, i\u015f mant\u0131\u011f\u0131 hatalar\u0131 ve veri s\u0131zd\u0131rma gibi \u00e7e\u015fitli g\u00fcvenlik ihlallerine yol a\u00e7abilen HPP, geli\u015ftiricilerin ve g\u00fcvenlik uzmanlar\u0131n\u0131n \u00fczerinde durmas\u0131 gereken \u00f6nemli bir konudur.<\/p>\n Bu makalede, HPP’nin ne oldu\u011funu, WAF’lar ve uygulama \u00e7er\u00e7eveleri aras\u0131ndaki \u00e7\u00f6z\u00fcmleme farkl\u0131l\u0131klar\u0131n\u0131n nas\u0131l bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131 yaratt\u0131\u011f\u0131n\u0131 ve ger\u00e7ek d\u00fcnyadaki etkileyici senaryolar\u0131n\u0131 detayl\u0131 bir \u015fekilde inceledik. Ayr\u0131ca, bu t\u00fcr sald\u0131r\u0131lara kar\u015f\u0131 korunmak i\u00e7in tutarl\u0131 parametre i\u015fleme, s\u0131k\u0131 giri\u015f do\u011frulamas\u0131, do\u011fru WAF yap\u0131land\u0131rmas\u0131, API a\u011f ge\u00e7idi kullan\u0131m\u0131 ve kapsaml\u0131 g\u00fcvenlik testleri gibi bir dizi etkili y\u00f6ntem sunduk. Davran\u0131\u015fsal analiz, RASP ve geli\u015ftirici e\u011fitimleri gibi ileri d\u00fczey stratejilerle de g\u00fcvenli\u011finizi bir \u00fcst seviyeye ta\u015f\u0131yabilece\u011finizi vurgulad\u0131k. Unutulmamal\u0131d\u0131r ki, siber g\u00fcvenlik s\u00fcrekli bir m\u00fccadeledir ve tehditler evrildik\u00e7e savunma mekanizmalar\u0131m\u0131z\u0131 da s\u00fcrekli g\u00fcncellemek zorunday\u0131z. API’lerinizin ve uygulamalar\u0131n\u0131z\u0131n g\u00fcvenli\u011fini sa\u011flamak, kullan\u0131c\u0131lar\u0131n\u0131z\u0131n verilerini korumak ve i\u015f s\u00fcreklili\u011fini s\u00fcrd\u00fcrmek i\u00e7in HPP gibi sald\u0131r\u0131 vekt\u00f6rlerine kar\u015f\u0131 proaktif ve katmanl\u0131 bir savunma stratejisi benimsemek hayati \u00f6nem ta\u015f\u0131maktad\u0131r.<\/p>\n Hay\u0131r, HPP sald\u0131r\u0131lar\u0131 hem URL sorgu dizisinde (\u00f6rne\u011fin \u00c7o\u011fu modern web uygulama \u00e7er\u00e7evesi, ayn\u0131 parametrenin birden fazla kez g\u00f6nderilmesi durumunda varsay\u0131lan bir davran\u0131\u015fa sahiptir (\u00f6rne\u011fin, ilk de\u011feri almak, son de\u011feri almak veya bir dizi olarak toplamak). Savunmas\u0131zl\u0131k, bu varsay\u0131lan davran\u0131\u015f\u0131n g\u00fcvenlik gereksinimleriyle \u00e7eli\u015fmesi veya geli\u015ftiricinin bu durumu g\u00f6z ard\u0131 etmesiyle ortaya \u00e7\u0131kar. \u00c7er\u00e7evenin kendisi do\u011frudan bir “g\u00fcvenlik a\u00e7\u0131\u011f\u0131” olmasa da, parametreleri i\u015fleme mant\u0131\u011f\u0131ndaki tutars\u0131zl\u0131klar HPP riskini do\u011furur. Geli\u015ftiricinin bu durumu bilerek ve y\u00f6neterek g\u00fcvenli kod yazmas\u0131 \u00f6nemlidir.<\/p>\n<\/li>\n Hay\u0131r, WAF kullanmak HPP’ye kar\u015f\u0131 \u00f6nemli bir ilk savunma hatt\u0131 olsa da tek ba\u015f\u0131na yeterli de\u011fildir. WAF’lar, uygulaman\u0131n parametreleri nas\u0131l i\u015fledi\u011fini her zaman tam olarak bilemeyebilir ve bu nedenle HPP sald\u0131r\u0131lar\u0131n\u0131 atlatma potansiyeli ta\u015f\u0131r. En iyi savunma, hem WAF’\u0131 do\u011fru yap\u0131land\u0131rmak hem de uygulama katman\u0131nda s\u0131k\u0131 giri\u015f do\u011frulamas\u0131 ve tutarl\u0131 parametre i\u015fleme mekanizmalar\u0131 kullanmakt\u0131r. Katmanl\u0131 g\u00fcvenlik yakla\u015f\u0131m\u0131 esast\u0131r.<\/p>\n<\/li>\n Geli\u015ftiriciler, t\u00fcm HTTP parametrelerini s\u0131k\u0131 bir \u015fekilde do\u011frulamal\u0131 (beyaz liste yakla\u015f\u0131m\u0131yla), ayn\u0131 isimli parametrelerin birden fazla kez gelmesi durumunda uygulaman\u0131n nas\u0131l davranaca\u011f\u0131n\u0131 standartla\u015ft\u0131rmal\u0131 (\u00f6rne\u011fin her zaman ilk de\u011feri almak veya hata d\u00f6nd\u00fcrmek), hassas parametreler i\u00e7in \u00f6zel kontroller uygulamal\u0131 ve d\u00fczenli g\u00fcvenlik testleri yapmal\u0131d\u0131r. Ayr\u0131ca, kulland\u0131klar\u0131 web uygulama \u00e7er\u00e7evesinin parametre i\u015fleme mant\u0131\u011f\u0131n\u0131 iyi anlamal\u0131d\u0131rlar.<\/p>\n<\/li>\n API’ler, genellikle do\u011frudan veri al\u0131\u015fveri\u015fi ve i\u015f mant\u0131\u011f\u0131 i\u015flemleri i\u00e7in tasarland\u0131\u011f\u0131ndan, parametre manip\u00fclasyonlar\u0131 do\u011frudan hassas verilere veya kritik i\u015flevlere etki edebilir. Mikroservis mimarileri ve farkl\u0131 sistemler aras\u0131 yo\u011fun API ileti\u015fimi, HPP’nin farkl\u0131 servisler aras\u0131nda zincirleme etki yaratma potansiyelini art\u0131r\u0131r. Bu durum, API’leri HPP sald\u0131r\u0131lar\u0131 i\u00e7in cazip ve y\u00fcksek riskli hedefler haline getirir.<\/p>\n<\/li>\n<\/ol>\n #APIg\u00fcvenli\u011fi #WebG\u00fcvenli\u011fi #SiberSald\u0131r\u0131 #HTTPParameterPollution #WAF<\/p>\nkullanici=admin&kullanici=guest<\/code> \u015feklinde bir parametre dizisi oldu\u011funu varsayal\u0131m. WAF, bu iste\u011fi incelerken belki sadece ilk kullanici=admin<\/code> de\u011ferini g\u00f6r\u00fcr ve bu de\u011ferin potansiyel bir yetkilendirme atlatma giri\u015fimi oldu\u011funu fark eder. Ancak sald\u0131rgan\u0131n amac\u0131, uygulaman\u0131n kullanici=guest<\/code> de\u011ferini i\u015flemesini sa\u011flamakt\u0131r. E\u011fer WAF, admin<\/code> de\u011ferini engellerken, uygulama \u00e7er\u00e7evesi birden fazla ayn\u0131 isimli parametreyi kabul edip son de\u011feri (guest<\/code>) kullan\u0131yorsa, sald\u0131rgan WAF’\u0131 atlatm\u0131\u015f olur. Tam tersi bir senaryoda, WAF guest<\/code> de\u011ferini zarars\u0131z olarak g\u00f6r\u00fcp ge\u00e7i\u015f verirken, uygulaman\u0131n ilk de\u011feri (admin<\/code>) i\u015flemesi de bir problem yaratabilir. Bu t\u00fcr senaryolar, HPP’nin neden bu kadar sinsi ve etkili bir sald\u0131r\u0131 t\u00fcr\u00fc oldu\u011funu a\u00e7\u0131k\u00e7a ortaya koymaktad\u0131r. API’ler, mikroservis mimarileri ve tek sayfa uygulamalar\u0131 (SPA) gibi modern geli\u015ftirme paradigmalar\u0131yla birlikte HPP riskleri daha da artmaktad\u0131r, \u00e7\u00fcnk\u00fc bu yap\u0131lar genellikle farkl\u0131 sistemler ve \u00e7er\u00e7eveler aras\u0131nda yo\u011fun HTTP ileti\u015fimi kullan\u0131r.<\/p>\nWAF’lar ve Uygulama \u00c7er\u00e7eveleri Aras\u0131ndaki \u00c7\u00f6z\u00fcmleme Farkl\u0131l\u0131klar\u0131<\/h2>\n
GET \/api\/urun?id=123&id=456 HTTP\/1.1<\/code>. Bu istekte ‘id’ parametresi iki kez tekrar etmi\u015ftir. \u015eimdi bu iste\u011fin bir WAF ve ard\u0131ndan bir uygulama \u00e7er\u00e7evesi taraf\u0131ndan nas\u0131l i\u015flenebilece\u011fine bakal\u0131m:<\/p>\n\n
id=123<\/code> de\u011ferini al\u0131p g\u00fcvenlik kontrollerini buna g\u00f6re uygulayabilir. E\u011fer 123<\/code> zarars\u0131z bir de\u011ferse, istek WAF’tan sorunsuz bir \u015fekilde ge\u00e7ebilir.<\/li>\n\n
id=123<\/code>).<\/li>\nid=456<\/code>).<\/li>\nid = ['123', '456']<\/code>).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nid=123<\/code>‘\u00fc kontrol ederken, uygulaman\u0131n id=456 OR 1=1<\/code> gibi bir SQL enjeksiyonu payload’unu i\u015flemesini sa\u011flayabilir. Veya bir yetkilendirme parametresi i\u00e7in yetki=guest&yetki=admin<\/code> g\u00f6nderildi\u011finde, WAF guest<\/code>‘i g\u00f6r\u00fcp ge\u00e7i\u015f verirken, uygulaman\u0131n admin<\/code>‘i i\u015flemesi gibi senaryolar ortaya \u00e7\u0131kabilir.<\/p>\nHTTP Parametre Kirlili\u011fi Sald\u0131r\u0131lar\u0131n\u0131n Ger\u00e7ek D\u00fcnya Senaryolar\u0131<\/h2>\n
1. Kimlik Do\u011frulama ve Yetkilendirme Atlatma<\/h3>\n
\n
\/api\/profil?kullanici_id=123<\/code> \u015feklinde bir istek al\u0131yor. Normalde, uygulama oturum a\u00e7m\u0131\u015f kullan\u0131c\u0131n\u0131n ID’sini kontrol eder ve sadece kendi profiline eri\u015fmesine izin verir. Ancak HPP ile sald\u0131rgan, \/api\/profil?kullanici_id=benim_id&kullanici_id=yonetici_id<\/code> \u015feklinde bir istek g\u00f6nderebilir. E\u011fer WAF, benim_id<\/code>‘yi g\u00f6r\u00fcp zarars\u0131z bulurken, uygulama \u00e7er\u00e7evesi son parametre olan yonetici_id<\/code>‘yi i\u015flerse, sald\u0131rgan y\u00f6netici profiline yetkisiz eri\u015fim sa\u011flayabilir.<\/li>\nsession_id<\/code>, user_role<\/code>) sald\u0131rgan taraf\u0131ndan \u00e7iftlenmesiyle m\u00fcmk\u00fcn olmu\u015ftur.<\/li>\n<\/ul>\n2. SQL Enjeksiyonu (SQL Injection) ve Veri S\u0131zd\u0131rma<\/h3>\n
\n
\/api\/ara?kategori=elektronik<\/code> \u015feklinde \u00e7al\u0131\u015f\u0131yor. Sald\u0131rgan, \/api\/ara?kategori=elektronik&kategori=bilgisayar%27+OR+1%3D1--<\/code> gibi bir istek g\u00f6nderir. E\u011fer WAF ilk kategori=elektronik<\/code> de\u011ferini kontrol edip zarars\u0131z bulurken, arka u\u00e7taki veritaban\u0131 sorgusu ikinci kategori<\/code> parametresini i\u015flerse, SQL enjeksiyonu ger\u00e7ekle\u015febilir ve veritaban\u0131ndan hassas bilgiler s\u0131zd\u0131r\u0131labilir.<\/li>\n3. \u0130\u015f Mant\u0131\u011f\u0131 Hatalar\u0131 ve Fiyat Manip\u00fclasyonu<\/h3>\n
\n
\/api\/sepeteEkle?urun_id=123&fiyat=100<\/code> \u015feklinde bir istek al\u0131yor. Sald\u0131rgan, \/api\/sepeteEkle?urun_id=123&fiyat=100&fiyat=1<\/code> \u015feklinde bir istek g\u00f6nderebilir. E\u011fer WAF fiyat=100<\/code>‘\u00fc normal bulurken, uygulama \u00e7er\u00e7evesi son fiyat=1<\/code> de\u011ferini i\u015flerse, \u00fcr\u00fcn 1 TL’ye sepete eklenebilir.<\/li>\n4. Yerel Dosya Dahil Etme (Local File Inclusion – LFI) ve Uzaktan Kod \u00c7al\u0131\u015ft\u0131rma (Remote Code Execution – RCE)<\/h3>\n
\n
\/api\/yukle?dosya=anasayfa.html<\/code> gibi bir parametre kullan\u0131yor. Sald\u0131rgan, \/api\/yukle?dosya=anasayfa.html&dosya=..\/..\/..\/..\/etc\/passwd<\/code> \u015feklinde bir istek g\u00f6nderir. E\u011fer uygulama son parametreyi i\u015flerse, sunucunun hassas dosyalar\u0131na eri\u015fim sa\u011flanabilir. Benzer \u015fekilde, komut enjeksiyonu i\u00e7in komut=ls&komut=rm+-rf+\/<\/code> gibi payload’lar kullan\u0131labilir.<\/li>\n<\/ul>\nHPP Sald\u0131r\u0131lar\u0131na Kar\u015f\u0131 Korunma Y\u00f6ntemleri ve En \u0130yi Uygulamalar<\/h2>\n
1. Tutarl\u0131 Parametre \u0130\u015fleme Mekanizmalar\u0131<\/h3>\n
\n\/\/ \u00d6rnek: Node.js (Express) ile tekil parametre i\u015fleme\n\/\/ E\u011fer 'id' parametresinden birden fazla gelirse, sadece ilkini al.\napp.get('\/api\/urun', (req, res) => {\n const id = Array.isArray(req.query.id) ? req.query.id[0] : req.query.id;\n if (!id) {\n return res.status(400).send('ID parametresi gerekli.');\n }\n \/\/ ID ile ilgili i\u015flemler...\n res.send(\u00dcr\u00fcn ID: ${id}<\/code>);\n});\n\n\/\/ \u00d6rnek: Node.js (Express) ile sadece son de\u011feri alma (baz\u0131 \u00e7er\u00e7evelerin varsay\u0131lan\u0131)\n\/\/ app.use(express.urlencoded({ extended: true }));\n\/\/ app.use(express.json());\n\/\/ Yukar\u0131daki middleware'ler genellikle son de\u011feri al\u0131r.\n\/\/ Ancak a\u00e7\u0131k\u00e7a belirtmek daha g\u00fcvenlidir.\napp.get('\/api\/sorgu', (req, res) => {\n const param = req.query.param; \/\/ E\u011fer birden fazla 'param' varsa, Express varsay\u0131lan olarak sonuncuyu al\u0131r.\n res.send(Parametre de\u011feri: ${param}<\/code>);\n});\n <\/code><\/pre>\n<\/p><\/div>\nArray.isArray(req.query.id) ? req.query.id[0] : req.query.id;<\/code> ifadesi, id<\/code> parametresi bir dizi olarak gelirse ilk eleman\u0131 almay\u0131, tek bir de\u011fer olarak gelirse o de\u011feri almay\u0131 sa\u011flar. Bu, uygulaman\u0131n her zaman tek bir id<\/code> de\u011feriyle \u00e7al\u0131\u015fmas\u0131n\u0131 garanti eder.<\/p>\n2. S\u0131k\u0131 Giri\u015f Do\u011frulamas\u0131 (Strict Input Validation)<\/h3>\n
\n
\n\/\/ \u00d6rnek: Basit bir giri\u015f do\u011frulama (Node.js)\nconst Joi = require('joi'); \/\/ Joi gibi bir validasyon k\u00fct\u00fcphanesi kullan\u0131labilir\n\nconst schema = Joi.object({\n urunId: Joi.number().integer().min(1).required(),\n miktar: Joi.number().integer().min(1).max(100).required()\n});\n\napp.post('\/api\/sepeteEkle', (req, res) => {\n const { error, value } = schema.validate(req.body);\n\n if (error) {\n return res.status(400).send(error.details[0].message);\n }\n\n \/\/ Do\u011frulanm\u0131\u015f de\u011ferlerle i\u015flemler...\n res.send(Sepete eklendi: \u00dcr\u00fcn ID ${value.urunId}, Miktar: ${value.miktar}<\/code>);\n});\n <\/code><\/pre>\n<\/p><\/div>\n3. WAF Yap\u0131land\u0131rmas\u0131 ve Senkronizasyonu<\/h3>\n
\n# ModSecurity kural\u0131 \u00f6rne\u011fi: Ayn\u0131 parametrenin birden fazla kez kullan\u0131lmas\u0131n\u0131 engeller\n# Bu kural, belirli bir parametre ad\u0131n\u0131n istekte birden fazla kez g\u00f6r\u00fcnmesini engeller.\n# \u00d6rne\u011fin, \"id\" parametresi i\u00e7in:\n# SecRule ARGS:id \"@gt 1\" \"id:12345,deny,log,msg:'HTTP Parameter Pollution detected for id parameter'\"\n\n# Daha genel bir yakla\u015f\u0131m: T\u00fcm parametreler i\u00e7in tekrar edenleri yakala\n# Bu kural, istekteki t\u00fcm parametreleri d\u00f6ng\u00fcye alarak, herhangi bir parametrenin\n# birden fazla kez ge\u00e7ip ge\u00e7medi\u011fini kontrol eder.\n# SecRule ARGS_NAMES \"@rsub ^(.*?)&(.*)$\" \"id:12346,deny,log,msg:'HTTP Parameter Pollution detected (multiple parameter names)'\"\n <\/code><\/pre>\n<\/p><\/div>\n4. API A\u011f Ge\u00e7idi (API Gateway) Kullan\u0131m\u0131<\/h3>\n
5. G\u00fcvenli Kodlama Pratikleri ve G\u00fcvenlik Testleri<\/h3>\n
\n
6. HTTP Parametrelerini Kodlamak (Encode Etmek)<\/h3>\n
\u0130leri D\u00fczey G\u00fcvenlik Stratejileri ve Gelecek Perspektifi<\/h2>\n
1. Davran\u0131\u015fsal Analiz ve Anomali Tespiti<\/h3>\n
\n
2. \u00c7al\u0131\u015fma Zaman\u0131 Uygulama Kendi Kendini Koruma (RASP – Runtime Application Self-Protection)<\/h3>\n
\n
3. Kapsaml\u0131 API G\u00fcvenli\u011fi Testleri (DAST, SAST, IAST, Penetrasyon Testleri)<\/h3>\n
\n
4. G\u00fcvenlik Fark\u0131ndal\u0131\u011f\u0131 E\u011fitimi ve Geli\u015ftirici E\u011fitimi<\/h3>\n
Gelecek Perspektifi<\/h3>\n
\n
Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n
?param=val1¶m=val2<\/code>) hem de HTTP POST iste\u011finin g\u00f6vdesinde (body) ger\u00e7ekle\u015febilir. POST g\u00f6vdesindeki parametrelerin i\u015flenme \u015fekli de ayn\u0131 \u015fekilde uygulama \u00e7er\u00e7eveleri aras\u0131nda farkl\u0131l\u0131k g\u00f6sterebilir ve bu da HPP’ye zemin haz\u0131rlayabilir.<\/p>\n<\/li>\n