Kullanıcılar ile ilgili bir sorunum var, hangi aşamada çözsem daha mantıklı olur?

[Sypro]

şimdi diyelim ki X Y ve Z diye üç yetkili kullanıcım var, bunların her birinin de altında A1 A2 A3, B1 B2 B3 ve C1 C2 C3 diye üçer normal kullanıcı daha var.
sistem X kullanıcısı dropdown'dan A1'i seçtiği zaman server'a id=1 gibi bir şey yollayıp kullanıcı bilgilerinin ekrana gelmesini sağlıyor, tabi değişiklik yapıp kaydetmesi durumunda da o anda hidden olan bir input'a id değeri yazılıyor. sorun şu ki şimdi zıpır bir kullanıcı gidip id'yi 5 yaparsa B2'ye denk gelen ve Y'ye ait olan bir kullanıcının verilerini update'lemeye çalışacak sistem.
bunun dışında aynı şekilde atıyorum C1 kullanıcısı girip kendi bilgilerini düzenlemek isterse yine id yerine 7 yazılacak, kalkar da başka bir şey yaparsa hiç alakası olmayan yerlere bulaşmış olacak.

bunu hangi aşamada ne şekilde çözmek en mantıklısı? neticede database'de bunun bilgisi var, kim kimle ilişkili diye. her seferinde en başta bir sorgu yapıp, bu id bu işi yapmak istiyor, acaba bu id'nin yetki alanı içerisinde mi gibi bir şeyi mi kontrol etmek gerek? halp.

[riglous]

Update ve select sorgularına doğrudan bu filtreleri de koy..?

update kullanici set name='yeni isim' 

	where id = $id

yerine

update kullanici set name='yeni isim' 

	where id = $id

	and parent_id = $my_id

[di]

Bir de sadece hidden field'lara, cookie'lere guvenmeyip session kullaniyoruz tabi.

[Memphis7]

ben soruyu tam anlamadım,
anladığım session acmadan herhangi birinin database müdahele etmesine izin verip müdahale etmesini nası engellerimmi soru?
öyleyse session acmadan adamın hangi kullanıcıları editleyebilecegini bilmezsin cunku adamın kimligini bilmiyosun
eger adamın kimligini biliyorsan evet if check yapmak zorundasın

yönteme gelince kodunu gösterirsen daha güzel seçenekler sunarız kanımca

ama ben kabaca
db de user tablomda user_type ve user_group(opsiyonel) tutuyorum
user_type atıyorum 1 plat 2 gold 3 silver
platin alt grubları varsa 12,13,14 gibi tutuyorum(bunlarda cogu zaman dinamik oluo)
sql e gelmeden once adama dropdown sunarken sadece editleyebilecegi user_type ları göstermen lazım
ve
sanırım yukardaki sitenin linkinde xxx.com?id=1 i 7 yaparsa die korkuyorsun
get yerine post methodu kullanırsan formunda bu sorunuda halledersin
ama biraz kod göster :S

[di]

Iyi ki anlamamissin sen de, yarim A4 yazi var orda. hehe

[Memphis7]

hehe soruyu anladımda yapıyı anlamadım

[zgrw]

di said:

Bir de sadece hidden field'lara, cookie'lere guvenmeyip session kullaniyoruz tabi.

sessiona da tek basina guvenmeyip, session icine de degistirilmediginden emin olmak icin ozel kontrol datalari ekliyoruz ayrica :)

Memphis7 said:

sanırım yukardaki sitenin linkinde xxx.com?id=1 i 7 yaparsa die korkuyorsun
get yerine post methodu kullanırsan formunda bu sorunuda halledersin
ama biraz kod göster :S

post data da guvenilir degil tam olarak, degistirilebilir, gelen her datanin kontrol edilmesi lazim tekrardan :)

not: evet hafif paranoyagim PHP konusunda :)

[Memphis7]

bilmedigimden soruyorum..
post dataya nasıl ulasılıo?
ssl bunun için var deilmi?

[reyou]

session olayi cloud da sikintili biraz, database server da saklamak gerekiyo oda performans acisindan kotu eger data cok fazla onemli degilse.

[Gladmir]

Memphis7 said:

bilmedigimden soruyorum..
post dataya nasıl ulasılıo?
ssl bunun için var deilmi?

Evet bunun icin var, Post data da degistirilebilir deki kasit http icin soylenmistir tahminim.

Session caching icin backend lerin birden fazla olacagini on gorerek distributed in-memory cache kullaniliyor, envai cesit secenek mevcut piyasada.

[Sypro]

öncelikle tişikkürler. beklediğim türde oldu cevaplar, zaten daha mantıklı bir çözüm benim de gelmemişti aklıma. her seferinde kontrol etmekten kaçmanın yollarını arıyordum sadece.

kod gösteremiyorum, bunun iki sebebi var: birincisi ticari bir proje, dolayısıyla şirket ile sorun yaşamak gibi bir isteğim yok. ikincisi zaten bu kısmın kodu daha bitmiş değil, sadece üst katmandaki üyenin alt katmandaki üyelerin listesine erişmesi ve seçtiği kişinin forma doldurulması kısmı mevcut, yani kod anlamında tam olarak sorduğum kısım daha yazılmadı. haftasonuna kadar yapacağım işler arasında.

php konusunda ben de paranoyaklaşabiliyorum, session'a login sırasında token koyup zaten tüm işlemlerden önce kullanıcının token'ı doğru mu değil mi falan filan sorgularını yapıyorum. dolayısıyla giriş yapmadan kimse bir yere erişemiyor. sıkıntı işte girişten sonraki aşamada başlayacaktı, şimdi o konu da çözüme kavuştu. gerçi neyin derdindeyim onu da bilmiyorum, öyle aynı anda onyüzmilyonbin kişinin aktif olacağı bir şey de değil. en yoğun anda 50 kişi işlem yapar ya da yapmaz, yük bincek diye korktuğuma değmiyor resmen.

[Gladmir]

Murphy nin ne zaman gelecegi belli olmaz, dogru yoldasin.

[di]

zgrw said:

di said:

Bir de sadece hidden field'lara, cookie'lere guvenmeyip session kullaniyoruz tabi.

sessiona da tek basina guvenmeyip, session icine de degistirilmediginden emin olmak icin ozel kontrol datalari ekliyoruz ayrica :)

Script'in vulnerable olmadigi surece nasil degistiriyorsun abi attacker olarak session'i ?

[zgrw]

di mesaj kutun dolmus :)

session datasi her ne kadar server side olsa da session-hijacking diye bir olay var en basitinden :)

session security konusunda kaynak vereyim;

http://phpsec.org/projects/guide/4.html

[zgrw]

hatta en iyisi roota bakmak :)

http://phpsec.org/projects/guide/

[Eralpb]

En asagida anlattigi olay cok yalan gibi, session id'yi capture eden adam user-agentini da degistirir bir zahmet :)

Bunun cozumu public wifidan login olmamak hicbiyere heralde.