Sanitasi data: Praktik Terbaik dengan contoh kode


15

Saya mencoba memahami sanitasi data (bukan validasi data) untuk membantu saya menulis tema aman untuk WordPress. Saya telah mencari di internet mencoba menemukan panduan komprehensif untuk pengembang tema yang merinci praktik terbaik. Ada beberapa sumber yang saya temui termasuk halaman codex berjudul Validasi Data, meskipun tidak ada yang berguna bagi saya. Halaman codex mencantumkan fungsi sanitasi yang tersedia, penggunaannya dan apa yang mereka lakukan, tetapi gagal menjelaskan mengapa Anda akan menggunakan yang satu di atas yang lain atau dalam situasi apa Anda akan menggunakan fungsi sanitasi tertentu. Tujuan dari posting ini adalah untuk meminta setiap orang untuk berkontribusi contoh kode buruk / tidak bersih dan bagaimana itu harus ditulis ulang untuk sanitasi yang tepat. Ini bisa menjadi kode umum untuk membersihkan judul posting atau mengirim thumnails src atau kode yang lebih rumit yang menangani sanitasi$_POST data untuk permintaan Ajax.

Selain itu, saya ingin tahu apakah fungsi WordPress untuk menambah / memperbarui basis data (mis. Yang disebutkan dalam blok kode di bawah) secara otomatis menangani pekerjaan sanitasi untuk Anda? Jika ya, apakah ada pengecualian ketika Anda akan mengambil tindakan tambahan untuk membersihkan data yang dikirim ke fungsi WordPress ini?

add_user_meta
update_user_meta
add_post_meta
update_post_meta
//just to name a few

Juga, apakah sanitasi perlu dilakukan secara berbeda ketika menggemakan HTML dalam PHP dibandingkan dengan PHP inline HTML? Agar lebih jelas tentang apa yang saya minta, inilah kodenya:

<?php echo '<div class="some-div ' . $another_class . '" data-id="' . $id . '" >' . $text . '</div>'; ?>

<div class="some-div <?php echo $another_class; ?>" data-id="<?php echo $id; ?>"><?php echo $text; ?></div>

Kedua pernyataan di atas mencapai hal yang sama. Tetapi apakah mereka perlu diberkati secara berbeda?


1
Mungkin membantu jika kami tahu apa yang ingin Anda bersihkan. Tema adalah untuk menyajikan data ... Anda hanya perlu membersihkan data yang dikirimkan pengguna kepada Anda, dan pengiriman biasanya ditangani oleh plugin.
EAMann

@EAMann Fungsi pelarian seperti esc_attr, esc_html dll dibuat untuk menghindari output. Koreksi saya jika saya salah. Menyajikan data berarti Anda mengeluarkan data, jadi melarikan diri juga diperlukan dalam tema. Kalau tidak, tidak akan ada kebutuhan untuk fungsi esc. Saya ingin memahami sanitasi dalam tema WordPress secara keseluruhan dan tidak terbatas pada sanitasi satu atau dua fragmen kode.
John

"Menyajikan data berarti Anda mengeluarkan data, jadi melarikan diri juga diperlukan dalam tema" - tidak. Sekali lagi, Anda hanya perlu melarikan diri data yang tidak Anda percayai
onetrickpony

@OneTrickPony Sudah semakin jelas bagi saya. Hanya untuk benar-benar yakin bahwa saya memahami hal ini - saya akan melarikan diri dari konten komentar tetapi tidak akan melarikan diri dari ID komentar atau ID posting, jika saya ingin menampilkannya dalam HTML. Maaf, benar-benar mengganggumu dengan pertanyaan satu demi satu.
John

2
"Anda hanya perlu melarikan diri data yang tidak Anda percayai" - Saya sepenuhnya setuju. Satu-satunya hal yang saya tambahkan adalah Anda tidak boleh mempercayai data;)
Ian Dunn

Jawaban:


12

Halaman kodeks ini menjelaskannya dengan cukup baik menurut saya.

Mungkin fungsi yang paling penting dan umum digunakan esc_attr. Ambil contoh ini:

<a href="<?php print $author_url; ?>" title="<?php print $author_name; ?>"> 
  <?php print $author_name; ?>
</a>

Jika $author_nameberisi "karakter Anda mendapatkan atribut Anda ditutup, dan jika karakter itu diikuti oleh onclick="do_something();"itu bisa menjadi lebih buruk :)

Melakukan print esc_attr($author_name)memastikan bahwa karakter tersebut dikodekan, dan browser tidak melakukan hal-hal yang seharusnya tidak dilakukan.

Ada satu kasus di mana Anda tidak membutuhkannya: ketika Anda mengharapkan angka, dalam hal ini Anda bisa memasukkan data input ke integer, misalnya:

print (int)$_POST['some_number'];


Meta * fungsi yang Anda daftarkan di sana sudah berhati-hati dengan membersihkan input untuk penyimpanan basis data, jadi Anda tidak perlu khawatir tentang itu.

The wpdb->prepare()Metode perlu digunakan ketika Anda melakukan DB query sendiri. Ini sebuah contoh:

$sql = $wpdb->prepare('
    UPDATE wp_posts SET post_title = %s WHERE ID = %d', 
      $_POST['title'], $_POST['id']);

$wpdb->query($sql);

Kata kunci %sdan %dakan diganti dengan $ _POST nilai sanitasi Anda.

Kesalahan yang sangat umum yang saya lihat di banyak plugin di repositori WP.org adalah untuk melewatkan permintaan yang sudah disiapkan untuk itu (dan tidak siap), seperti:

$wpdb->prepare('UPDATE wp_posts SET post_title = \''.$_POST['title'].' WHERE ...

Jangan lakukan ini :)

Juga, apakah sanitasi perlu dilakukan secara berbeda ketika menggemakan HTML dalam PHP dibandingkan dengan PHP inline HTML?

Kedua pernyataan di atas mencapai hal yang sama. Tetapi apakah mereka perlu diberkati secara berbeda?

Tidak.


Terima kasih atas masukan Anda. Penjelasan Anda membuat segalanya menjadi lebih jelas bagi saya.
John

Klarifikasi kecil diperlukan lebih lanjut. Jika saya meneruskan sebuah string ke var (mis. $ Var = 'string';) dalam PHP dan menggemakannya sebagai atribut HTML, apakah saya membersihkan $ var saat menggema. Atau membersihkan hanya diperlukan jika saya telah menarik nilai $ var dari database.
John

Saat menggemakannya di layar, dengan satu atau lain cara
onetrickpony

Jadi, jika saya mengerti Anda dengan benar, apakah saya meneruskan string ke $ var dalam kode PHP atau menarik data dari database dan beralih ke $ var, keduanya mengharuskan saya untuk mengawal hasilnya. Benar?
John

Ya, jika data itu berasal dari input pengguna, seperti misalnya nama penulis komentar. Jika dengan "meneruskan string ke $ var dalam kode PHP" berarti Anda menetapkan nilai yang Anda ketahui ke suatu variabel, maka jelas - tidak, Anda tidak perlu membersihkan variabel itu
onetrickpony

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.