Forum
Aktif konular
Üyeler
Kurallar
Arama
Tahribat.com Forumları 
C#, Asp.Net, .Net Core 
Güvenlik Açığı WCF SERVİCES (ANDROİD/WCF/HTTP RESTFULL) Güvenlik Açığı WCF SERVİCES (ANDROİD/WCF/HTTP RESTFULL)
-
hocam "SOAP header" nedir onu bi araştır. işini çözücektir.
sakın url'den bu tarz bilgiler gönderme. kullanıcı adı ve şifre gibi bilgileri header üzerinden post bile yapsan güvenli değil.
birde paketlerinin havada yakalanıp çözülmesini engellemek için ssl kullan. + tabi şifre encrypt şart.
-
attackatak bunu yazdı
hocam "SOAP header" nedir onu bi araştır. işini çözücektir.
sakın url'den bu tarz bilgiler gönderme. kullanıcı adı ve şifre gibi bilgileri header üzerinden post bile yapsan güvenli değil.
birde paketlerinin havada yakalanıp çözülmesini engellemek için ssl kullan. + tabi şifre encrypt şart.
Javanın açık kaynak olmasının dez avantajı da bu sanırım bakayım abi dediklerine zaten az bucuk birşeyler öğrendim soap header hakkında biraz daha detaya inmeliyim sanırım
-
MhmdAlmz bunu yazdıYeniHarman bunu yazdı
Hayır, get ile göndersen de post ile göndersen de aşağı yukarı aynı şeydir. Güvenlik açığı olarak neden bahsediyorsunuz? Biz nasıl tahribata giriyorsak aynı şey kısacası.
Nasıl bir güvenlik lazım? DoS falan ise yapmanız gereken donanım tabanlı çözümler ve ip filtreleme.
Tek seferlik bir servis değilse (örneğin ilk kimlik doğrulamadan sonraki diğer kimlik doğrulaması gerektiren işlemler için oturum sağlanıyorsa) kimlik doğrulaması için bir token göndermeniz daha iyi olur.
Hocam Örneğin burdan kullanıcı giriş yapacak ya ... giriş yaparken bu postu yapacak adam sıra sıra kullanıcıları karakter cinsinden gönderip bütün kullanıcı adı şifreyi çekmez mi ? yani dönüş değerine göre kullanıcı var yok diyip giriş yapacak adam Get post yaparak kullanıcı adı ve şifreleri çekebilir birde bu şekilde veritabanına sınırsız veri ekleyebilir... ondan bahsediyorum :/
İşte bu risk her yerde var. Aynı mantıkla her sitede bruteforce uygulanabilir. Bu yüzden ip filtreleme lazım dedim. X ip'sinden üç defa yanlış parola girdiğinde sistemin bir müddet ip'yi yasaklaması lazım. SSL ile de göndersen sonuçta bu şekilde gittiği biliniyor verinin. Şifreleme de tam çözüm olmaz tabi public-private iki farklı anahtar kullanılan bir algoritma kullanırsanız başka. Bu bir android uygulaması mı? O zaman ek önlemler getirmelisiniz. En kolayı google, facebook vs. başka bir şeyle oturum açtırmanız.
-
MhmdAlmz bunu yazdıYeniHarman bunu yazdı
Hayır, get ile göndersen de post ile göndersen de aşağı yukarı aynı şeydir. Güvenlik açığı olarak neden bahsediyorsunuz? Biz nasıl tahribata giriyorsak aynı şey kısacası.
Nasıl bir güvenlik lazım? DoS falan ise yapmanız gereken donanım tabanlı çözümler ve ip filtreleme.
Tek seferlik bir servis değilse (örneğin ilk kimlik doğrulamadan sonraki diğer kimlik doğrulaması gerektiren işlemler için oturum sağlanıyorsa) kimlik doğrulaması için bir token göndermeniz daha iyi olur.
Hocam Örneğin burdan kullanıcı giriş yapacak ya ... giriş yaparken bu postu yapacak adam sıra sıra kullanıcıları karakter cinsinden gönderip bütün kullanıcı adı şifreyi çekmez mi ? yani dönüş değerine göre kullanıcı var yok diyip giriş yapacak adam Get post yaparak kullanıcı adı ve şifreleri çekebilir birde bu şekilde veritabanına sınırsız veri ekleyebilir... ondan bahsediyorum :/
Hocam database de sifrenin kac defa yanlis girildigini tutup (dogru giriste sayaci sifirliyip) 3 denemeden sonra mail ile veya sms ile aktivasyon yapilmadan login olmaz diyebilirsin.
Edit filtreleme hemip hem username ustunden olmali. Sifresi 123456 olan kullanicilarida taraya bilir. Adminin sifresinide. Admin 3 denemede dogrulamaya gider toplamda 10 defa yanlis denemede ip gider.
undefined-01 tarafından 23/Ara/15 13:35 tarihinde düzenlenmiştir -
YeniHarman bunu yazdıMhmdAlmz bunu yazdıYeniHarman bunu yazdı
Hayır, get ile göndersen de post ile göndersen de aşağı yukarı aynı şeydir. Güvenlik açığı olarak neden bahsediyorsunuz? Biz nasıl tahribata giriyorsak aynı şey kısacası.
Nasıl bir güvenlik lazım? DoS falan ise yapmanız gereken donanım tabanlı çözümler ve ip filtreleme.
Tek seferlik bir servis değilse (örneğin ilk kimlik doğrulamadan sonraki diğer kimlik doğrulaması gerektiren işlemler için oturum sağlanıyorsa) kimlik doğrulaması için bir token göndermeniz daha iyi olur.
Hocam Örneğin burdan kullanıcı giriş yapacak ya ... giriş yaparken bu postu yapacak adam sıra sıra kullanıcıları karakter cinsinden gönderip bütün kullanıcı adı şifreyi çekmez mi ? yani dönüş değerine göre kullanıcı var yok diyip giriş yapacak adam Get post yaparak kullanıcı adı ve şifreleri çekebilir birde bu şekilde veritabanına sınırsız veri ekleyebilir... ondan bahsediyorum :/
İşte bu risk her yerde var. Aynı mantıkla her sitede bruteforce uygulanabilir. Bu yüzden ip filtreleme lazım dedim. X ip'sinden üç defa yanlış parola girdiğinde sistemin bir müddet ip'yi yasaklaması lazım. SSL ile de göndersen sonuçta bu şekilde gittiği biliniyor verinin. Şifreleme de tam çözüm olmaz tabi public-private iki farklı anahtar kullanılan bir algoritma kullanırsanız başka. Bu bir android uygulaması mı? O zaman ek önlemler getirmelisiniz. En kolayı google, facebook vs. başka bir şeyle oturum açtırmanız.
Son zamanlarda Son kullanıcıların Virüs diye adlandırdığı uygulama apileri ile Twit-Durum atma- Fotoğraf paylaşma-Mesaj atma gibi şeyler çıktığı için bu tür önlemler program ilerleyince alınabilir yani bir ismi olduktan sonra insanların güvenini kazandıktan sonra o yüzden bu sıkıntım var yani uygulamamı kullanacak kişi 50 iken 20 ye düşebilir misall.. Birde bu Ip filtreleme denilen şeyi şu şekilde yapsam bi log tablosu oluştursam Telefonun mac adresi vs artık hangi ayrı özelliği varsa onu çekip loglasam ? o mac e ayit yanlış deneme sayısı saatte 3 den fazla ise engelleme gibi mi yoksa sizin dediğiniz farklı birşey mi ? Ip derken neyi kastediyorsunuz ? Normal İnternet IP Si ise türkiyede modem resetlenince değişiyor diye biliyorum bunu yapacak adam bunu da yapar IP değiştirmeyi 2. yanlış denemeden sonra ?
-
rakkoc bunu yazdıMhmdAlmz bunu yazdıYeniHarman bunu yazdı
Hayır, get ile göndersen de post ile göndersen de aşağı yukarı aynı şeydir. Güvenlik açığı olarak neden bahsediyorsunuz? Biz nasıl tahribata giriyorsak aynı şey kısacası.
Nasıl bir güvenlik lazım? DoS falan ise yapmanız gereken donanım tabanlı çözümler ve ip filtreleme.
Tek seferlik bir servis değilse (örneğin ilk kimlik doğrulamadan sonraki diğer kimlik doğrulaması gerektiren işlemler için oturum sağlanıyorsa) kimlik doğrulaması için bir token göndermeniz daha iyi olur.
Hocam Örneğin burdan kullanıcı giriş yapacak ya ... giriş yaparken bu postu yapacak adam sıra sıra kullanıcıları karakter cinsinden gönderip bütün kullanıcı adı şifreyi çekmez mi ? yani dönüş değerine göre kullanıcı var yok diyip giriş yapacak adam Get post yaparak kullanıcı adı ve şifreleri çekebilir birde bu şekilde veritabanına sınırsız veri ekleyebilir... ondan bahsediyorum :/
Hocam database de sifrenin kac defa yanlis girildigini tutup (dogru giriste sayaci sifirliyip) 3 denemeden sonra mail ile veya sms ile aktivasyon yapilmadan login olmaz diyebilirsin.
Edit filtreleme hemip hem username ustunden olmali. Sifresi 123456 olan kullanicilarida taraya bilir. Adminin sifresinide. Admin 3 denemede dogrulamaya gider toplamda 10 defa yanlis denemede ip gider.
Ohh Ohh bu anlattıklarına göre bu insanlar nasıl önlemler alıyor ya yoksa bu Basit programcıların yaptığı uygulamalarda bu tür açıklar mı var acaba çok merak ediyorum çünkü birsürü bunun gibi şey mevcut ..
-
Şimdi web servis diyorsak zaten ilk yaptığınız şekilde olmalı. Aksi durumda başka bir protokol oluşturmuş olursunuz.
Eğer sunucu size aitse fail2ban gibi bir çözüm kullanabilirsiniz: http://www.fail2ban.org/wiki/index.php/Main_Page
Şu makaleye göz atmanız iyi olabilir: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
İşin özü, bruteforce'dan korunmak için saldırgan ip'sini web serverdaki yazılımınızda (servisinizde) değil firewall tarafından engellemelisiniz. Hatta kullanıcının imei'sine ulaşmış olmak (imei'nin de mac gibi benzersizliğinden dolayı) ekstra güvenlik sağlayacaktır. En azından imei ile uyuşmayan kullanıcı adlarını doğrudan engelleyebilirsiniz.
Misal bizim kullandığımız birkaç web servisinde kimlik doğrulama sadece application id (kullanıcı adı) ve api key (şifre) ile sağlanıyor. Doğru bilgileri post ettiğimizde bize bir token veriliyor (session id gibi). Biz sonraki web servisini kullandığımız her işlemde bu token'i header kısmına gömüyoruz.
Ekleme: Unutmuşum. Evet kullanıcı ipsini değiştirebilir fakat bu işlemi ne kadar sıklıkla tekrarlayabilecek? En azından dos'a maruz kalmış olmazsınız.
YeniHarman tarafından 23/Ara/15 19:35 tarihinde düzenlenmiştir -
YeniHarman bunu yazdı
Şimdi web servis diyorsak zaten ilk yaptığınız şekilde olmalı. Aksi durumda başka bir protokol oluşturmuş olursunuz.
Eğer sunucu size aitse fail2ban gibi bir çözüm kullanabilirsiniz: http://www.fail2ban.org/wiki/index.php/Main_Page
Şu makaleye göz atmanız iyi olabilir: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
İşin özü, bruteforce'dan korunmak için saldırgan ip'sini web serverdaki yazılımınızda (servisinizde) değil firewall tarafından engellemelisiniz. Hatta kullanıcının imei'sine ulaşmış olmak (imei'nin de mac gibi benzersizliğinden dolayı) ekstra güvenlik sağlayacaktır. En azından imei ile uyuşmayan kullanıcı adlarını doğrudan engelleyebilirsiniz.
Misal bizim kullandığımız birkaç web servisinde kimlik doğrulama sadece application id (kullanıcı adı) ve api key (şifre) ile sağlanıyor. Doğru bilgileri post ettiğimizde bize bir token veriliyor (session id gibi). Biz sonraki web servisini kullandığımız her işlemde bu token'i header kısmına gömüyoruz.
Ekleme: Unutmuşum. Evet kullanıcı ipsini değiştirebilir fakat bu işlemi ne kadar sıklıkla tekrarlayabilecek? En azından dos'a maruz kalmış olmazsınız.
Sunucu bana ait değil Firewall kısmı beni ilgilendirmez diye düşünüyorum şirket düşünsün bana o güvenceyi sağlayacak olanlar onlar ben sadece bu url den veri gönderme muhabbetine kafam takıldı tehlikeli sonuçta adam url ile sonsuz defa post yapabilir Bunu engellemenin yolu dediğiniz gibi i-mei mac adresi gibi benzersiz şeylerden gelen tekrarlı sorguları engellemek . Siz sanırım 2 Servis kullanıyorsunuz ? Aslında C# falan olsa Kodları decompile yapmak yasal olmadığı için sorun olmazdı Uygulama içerisinde önlem alırım ama android de bu sorun var dediğinizi yapacağım gibi Session mantığı hiç yoktan güvenliği az da olsa sağlamış olurum ... Yapacağım uygulamayı 1000 kişi kullacak belki ama ilerde belki referans olacak o yüzden yapmışken adam gibi yapayım diyorum :/ O yüzden bu sorgu bu araştırma bu heves
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla