Serangan pengaturan waktu dalam PHP: Contoh praktis - mengapa `hash_equals()` penting

Banyak pengembang mengandalkan perbandingan sederhana menggunakan === atau == ketika memeriksa kunci API, token, atau string rahasia lainnya. Sekilas, hal ini terlihat masuk akal - tetapi ada masalah: perbedaan waktu dalam perbandingan dapat dieksploitasi oleh penyerang.

Artikel ini menjelaskan sebuah contoh realistis tentang bagaimana cara kerja serangan waktu secara konseptual.

Skenario nyata (contoh yang disederhanakan)

Bayangkan sebuah layanan mikro internal menerima permintaan dengan token parameter kueri dan membandingkannya dengan token API GitHub yang tersimpan di lingkungan.

Kode tidak aman (disederhanakan):

// insecure.php (contoh yang disederhanakan)$expected = getenv('GITHUB_API_TOKEN');// contoh 'V1cHt2S67DADJIm9sX9yzCc272EkSC'$provided = $_GET['token'] ?? '';if ($provided === $expected) { // berikan akses} PHP  

Saya akan menjelaskan mengapa hal ini menjadi masalah di bagian selanjutnya.

Bagaimana cara kerja serangan waktu?

Jika implementasi perbandingan token membandingkan karakter per karakter dan langsung membatalkan pada kesalahan pertama, maka permintaan dengan karakter pertama yang benar akan memakan waktu rata-rata sedikit lebih lama.

Oleh karena itu, karakter pertama yang benar akan menghasilkan waktu pemrosesan yang sedikit lebih lama daripada karakter pertama yang salah. Hal yang sama berlaku untuk karakter kedua dan seterusnya.

Seorang penyerang mengambil keuntungan dari hal ini dengan menguji semua karakter yang mungkin untuk setiap posisi, mengukur waktu respons yang sangat sering dan menganalisisnya secara statistik. Karakter dengan rata-rata terbesar / waktu yang lebih lama secara proporsional mungkin benar. Dengan cara ini, token direkonstruksi selangkah demi selangkah.

Mengapa hash_equals() adalah pilihan yang tepat

PHP menyediakan fungsi perbandingan string waktu konstan dengan hash_equals(). Fungsi ini memastikan bahwa waktu eksekusi perbandingan tidak bergantung pada awalan yang sama - selama kedua string memiliki panjang yang sama.

Alternatif yang aman (untuk Laravel, PHP, Wordpress):

// secure.php$expected = getenv('GITHUB_API_TOKEN'); $provided = $_GET['token'] ?? '';if (hash_equals($expected, $provided)) { // berikan akses} PHP  

Catatan: hash_equals() hanya "tidak bergantung pada waktu" jika panjangnya sama. Merupakan praktik yang baik untuk mendesain token agar panjangnya konstan (misalnya HMAC, UUID dengan panjang tetap, atau string Base64 dengan panjang tetap yang acak).

Tahukah Anda? Hanya UUID-V4 yang benar-benar dibuat secara acak dan oleh karena itu sering digunakan untuk token keamanan. Karena tidak mengandung informasi terkait waktu atau perangkat, UUID-V4 menawarkan tingkat ketidakpastian yang tinggi dan dengan demikian melindungi terhadap serangan berdasarkan pola atau prediksi. Inilah alasan mengapa UUID-V4 menjadi pilihan utama dalam hal pengidentifikasi yang aman dan sulit ditebak.

Langkah-langkah pertahanan tambahan - lebih dari sekadar hash_equals()

1. Panjang token yang konstan
   Gunakan token dengan panjang yang tetap, misalnya UUID-V4. Jika penyerang dapat menebak panjangnya, hal ini tidak terlalu membantu selama karakter itu sendiri aman.
2. Pembatasan nilai
   Batasi permintaan per IP atau per akun. Serangan pengaturan waktu membutuhkan banyak pengukuran; pembatasan laju secara signifikan meningkatkan usaha dan biaya bagi penyerang.
3. Pencatatan dan pemantauan
   Mengenali pola yang tidak biasa (banyak percobaan token, variasi sistematis dari parameter tertentu) dan bereaksi secara otomatis.
4. Garam / HMAC / Tanda Tangan
   Gunakan token yang ditandatangani (HMAC dengan kunci rahasia) atau token OAuth alih-alih membandingkan kunci statis mentah secara terbuka.
5. TLS/HTTPS
   Enkripsi melindungi saluran komunikasi - meskipun tidak mencegah serangan waktu pada internal server, ini adalah persyaratan dasar.
6. Rotasi token
   Umur token yang pendek mengurangi manfaat dari token yang disusupi.

Kesimpulan

Serangan pengaturan waktu bukanlah masalah teoritis semata - serangan ini telah diselidiki dalam praktiknya dan dapat memiliki konsekuensi yang serius, terutama untuk titik akhir yang dapat diakses publik. Kabar baiknya: Untuk para pengembang PHP/Laravel/Wordpress, penanggulangan pertama sangat sederhana:

• Ganti perbandingan langsung string sensitif dengan hash_equals().
• Pastikan panjang token yang konstan, pembatasan laju, pencatatan, dan manajemen token yang aman.