Catatan terbitan Django 1.4.11

April 21, 2014

Django 1.4.11 memperbaiki tiga masalah keamanan di 1.4.10. Selain itu, Versi penjaja Django dari enam, django.utils.six, telah ditingkatkan ke terbitan terakhir (1.6.1).

Mengerjakan kode tidak diharapkan menggunakan reverse()

Penangangan URL Django berdasarkan pada pemetaan dari pola reggex (mewakili URL) pada tampilan callable, dan pengolahan sendiri Django terdiri dari mencocokkan URL diminta terhadap pola tersebut untuk menentukan tampilan sesuai untuk diminta.

Django juga menyediakan fungsi nyaman – reverse() – yang melakukan pengolahan ini di arah berlawanan. Fungsi reverse() mengambil informasi tentang sebuah tampilan dan mengembalikan sebuah URL yang akan memohon tampilan itu. Penggunaan reverse() adalah didorong untuk pengembang aplikasi, sebagai keluaran dari reverse() selalu berdasarkan pada pola URL saat ini, berarti pengembang tidak butuh merubah kode lain ketika membuat perubahan pada URL.

Satu tanda tangan argumen untuk reverse() adalah melewatkan jalur Python bertitik untuk tampilan yang diinginkan. Dalam keadaan ini, Django akan mengimpor modul yang diarahkan oleh jalur bertitik itu sebagai bagian dari membangkitkan URL dihasilkan. Jika modul tersebut mempunyai efek samping waktu-impor, efek samping tersebut akan muncul.

Dengan demikian itu sangat mungkin untuk seorang penyerang menyebabkan pengerjaan kode tidak diharapkan, memberikan kondisi berikut:

  1. Satu atau lebih tampilan hadir yang membangun URL berdasarkan pada masukan pengguna (umumnya, parameter “next” dalam querystring mengindikasikan dimana untuk mengarahkan keberhasilan pelengkapan dari sebuah tindakan).

  2. Satu atau lebih modul diketahui penyerang untuk ada di jalur impor Python peladen, yang melakukan pengerjaan kode dengan efek samping pada pengimporan.

Untuk memperbaiki ini, reverse() sekarang akan hanya menerima dan mengimpor jalur bertitik berdasarkan pada tampilan mengandung modul terdaftar di URL pattern configuration proyek, sehingga untuk memastikan hanya modul pengembang yang diharapkan untuk diimpor di gaya ini atau akan diimpor.

Menyimpan sementara dari halaman anonim dapat mengunggap token CSRF

Django menyertakan kedua caching framework dan sistem untuk preventing cross-site request forgery (CSRF) attacks. Sistem perlindungan-CSRF berdasarkan pada nonce acak dikirim ke klien di kue yang harus dikirim oleh klien di permintaan masa depan dan, di formulir, nilai tersembunyi yang harus diajukan kembali dengan formulir.

Kerangka kerja penyimpanan sementara menyertkan sebuah pilihan untuk menyimpan sementara tanggapan pada anonim (yaitu, tidak sah) klien

Ketika permintaan anonim pertama pada halaman yang diberikan adalah oleh seorang klien tidak mempunyai kue CSRF, kerangka kerja penyimpanan sementara akan juga menyimpan sementara kue CSRF dan melayani nonce sama pada klien anonim lain yang tidak mempunyai kue CSRF. Ini dapat mengizinkan seorang penyerang untuk mendapatkan nilai kue CSRF sah dan melakukan serangan yang melewatkan pemeriksaan untuk kue.

Untuk memperbaiki ini, kerangka kerja penyimpanan sementara tidak akan lagi menyimpan sementara tanggapan tersebut. Penyelidikan sendiri untuk ini menjadi:

  1. Jika permintaan datang tidak mengajukan setiap kue, dan

  2. Jika tanggapan melakukan pengiriman satu atau lebih kue, dan

  3. Jika kepala Vary: Cookie disetel pada tanggapan, kemudian tanggapan tidak akan disimpan sementara.

Typecast MySQL

Basisdata MySQL dikenal “typecast” pada permintaan tertentu; sebagai contoh, ketika meminta sebuah tabel yang mengandung nilai deretan karakter, tetapi menggunakan permintaan yang menyaring berdasarkan pada nilai integer, MySQL akan pertama diam memaksa deretan karakter menjadi integer dan mengembalikan hasil berdasarkan itu.

Jika sebuah permintaan dilakukan tanpa merubah nilai dahulu ke jenis yang sesuai, ini dapat menghasilkan nilai yang tidak diharapkan, mirip pada apa akan muncul jika permintaan itu sendiri telah dirubah.

Kelas-kelas bidang model Django menyadari jenis mereka sendiri dan kebanyakan kelas-kelas itu melakukan perubahan eksplisit dari permintaan argumen untuk memperbaiki kenis tingkat-basisdata sebelum meminta. Bagaimanapun, tiga kelas bidang model tidak dengan benar merubah argumen mereka:

Ketiga bidang ini telah diperbaharui untuk merubah argumen mereka ke jenis yang benar sebelum meminta.

Selain itu, pengembang dari penyesuaian bidang model sekarang diperingati melalui dokumentasi untuk memastikan kelas-kelas penyesuaian bidang mereka akan melakukan perubahan jenis yang sesuai, dan pengguna dari metode permintaan raw() dan extra() – yang mengizinkan pengembang untuk memasok SQL mentah atau fragmen SQL – akan disarankan untuk memastikan mereka melakukan perubahan jenis manual sesuai sebelum menjalankan permintaan.

Back to Top