Bagaimana saya bisa membuat programmer berhenti menulis kode rentan terhadap injeksi SQL?

11

Terkadang Anda sibuk dan mendelegasikan tugas-tugas kecil ke programmer junior. Tetapi jika Anda tidak menaruh perhatian cukup dekat Anda menemukan diri Anda dengan kode semacam ini dalam produksi:

class DivtoggleController extends Zend_Controller_Action {

    public function closeAction() {
        /* ... code removed for brevity ... */

        $req = $this->getRequest();
        $formData = $req->getPost();

        $d = $formData['div'];
        $i = $formData['id'];

        $dm = new Model_DivtoggleManager();
        $rs = $dm->setDivToggleById($d, $i);

    }

}


class Model_DivtoggleManager extends Zend_Db_Table {

    public function setDivToggleById($div, $id) {
        $result = $this->getAdapter()->query(
           "update div_toggle set " . $div . "=1 where id=" . $id
        );
    }

}

Jadi, mengingat saya telah menghapus logika manajemen otentikasi / sesi untuk singkatnya, siapa yang dapat memberi tahu saya masalah apa yang mungkin ada dengan sampel ini?

php sql training

— Roger Halliburton
sumber

Mengapa ini tidak disimpan dalam cookie sederhana?

— Darknight

1

@Darknight, Anda mengasumsikan ada sesi untuk menyimpan cookie. Apakah ada atau tidak tidak relevan dengan masalah keamanan yang lebih besar.

— Roger Halliburton

24

Anda bisa mengajari mereka. Setiap orang melakukan ini pada awalnya, bahkan Anda. Jika jenis kode ini membuatnya menjadi produksi, itu adalah kesalahan orang tua; bukan junior.

Edit:

Salah satu hal yang telah saya lakukan adalah saya secara pribadi telah mengambil secara proaktif meminta orang untuk meninjau kode saya (termasuk junior) sebelum rilis. Kode ditinjau, orang-orang junior melihatnya sebagai pengalaman belajar, orang-orang kehilangan rasa takut akan peninjauan kode sebagai hukuman, dan mereka mulai melakukan hal yang sama.

— John Kraft
sumber

2

+1 Harus setuju. Anda tidak dapat menyalahkan seorang programmer junior (mungkin) karena Anda telah mengasumsikan tingkat pengetahuan yang mungkin tidak mereka miliki. (Yang mengatakan, Anda akan suka berpikir masalah tersebut sangat terkenal di hari ini dan usia Kemudian lagi, aku akan. Suka berpikir bahwa saya berbakat dan tampan, dll) :-)

— John Parker

Pernyataan yang cukup adil. Saya kira saya harus mengajukan pertanyaan lanjutan yang menanyakan mengapa manajemen berkeras meluncurkan kode ke dalam produksi yang belum disetujui oleh programmer senior. Apakah saya mempertaruhkan pekerjaan saya karena masalah keamanan kecil?

— Roger Halliburton

1

@ Roger Halliburton: Ya, jika masalah keamanan itu entah bagaimana dieksploitasi, apa hal terburuk yang bisa terjadi? Dan mengapa menunjukkan masalah keamanan membebani pekerjaan Anda? Apakah manajemen tidak mau berurusan dengan ini?

— FrustratedWithFormsDesigner

1

@Roger - hanya minor sampai Anda diretas. :) Saya pikir menempatkan kode ke dalam produksi tanpa ulasan (tidak peduli tingkat pengembang) adalah kegagalan. Sayangnya, ini adalah praktik yang sangat umum di banyak perusahaan; dan, sebelum itu, biasanya dibutuhkan waktu yang sangat lama sebelum manajemen mulai menilai hal-hal seperti ulasan kode.

— John Kraft

1

@Roger: Semua kode harus ditinjau, bukan hanya kode yang ditulis oleh programmer "junior". Bahkan programmer senior melakukan kesalahan.

— Dean Harding

20

Retas kode mereka di depan mata mereka lalu tunjukkan pada mereka cara memperbaikinya. Berulang-ulang sampai mereka mengerti.

— Joe Phillips
sumber

4

Kirim email kepada mereka setiap pagi: "Ngomong-ngomong, saya menjatuhkan database Anda lagi tadi malam melalui kerentanan injeksi SQL lain yang Anda tinggalkan di kode Anda. Saya tahu seberapa besar Anda suka memulihkan cadangan basis data!: D"

— Ant

2

@ Tidak: Bersikap baik. Lakukan sesaat setelah cadangan yang dijadwalkan, tidak lama sebelumnya.

— Donal Fellows

@ Donal: lakukan sesaat setelah pencadangan, kemudian beri tahu mereka pencadangan gagal dan biarkan mereka berkeringat untuk sisa hari sebelum mengembalikan cadangan semalam.

— jwenting

8

Anda dapat memberi mandat kepada mereka untuk mengambil kelas segera setelah mereka bergabung dengan perusahaan Anda, sebelum mereka memiliki akses kontrol sumber, yang memperkenalkan mereka pada suntikan SQL, skrip lintas situs, pemalsuan permintaan lintas situs, dan kerentanan umum lainnya. Tutupi contoh-contoh secara langsung, pecahkan kode buruk di depan mereka, minta mereka pecahkan kode buruk, dan arahkan ke situs OWASP untuk info lebih lanjut begitu mereka "lulus".

Anda juga dapat mengamanatkan penggunaan pustaka kustom yang menangani ini untuk Anda, tapi itu hanya solusi sekunder karena mereka akan yakin untuk menjalankan kueri khusus saat itu menjadi lebih nyaman.

Jika Anda memiliki sumber daya, memastikan lebih banyak anggota tim senior memverifikasi perbedaan mereka sebelum melakukan dapat berguna juga.

Pengetahuan adalah kekuatan!

— yan
sumber

3

Menyingkirkan mereka sebelum mereka bergabung dengan perusahaan Anda lebih baik. Jika Anda mempekerjakan seseorang untuk menulis apa pun yang menggunakan SQL, jangan ajukan pertanyaan wawancara tentang batasan injeksi pada ketidakmampuan.

— Wooble

Secara umum saya setuju, tetapi mempekerjakan junior yang sangat cerdas dan ambisius jauh, jauh lebih murah daripada "pengembang PHP dengan pengalaman N tahun," yang tidak dijamin jauh lebih baik. Smart junior devs dapat mengambil barang-barang ini dengan sangat cepat dan menjadi aset.

— yan

3

Dengan asumsi bahwa itu adalah rasa tidak aman yang disebut orang lain, sebagai pengembang tingkat apa pun, mudah untuk melupakan bahwa getPost () tidak mengamankan data terlebih dahulu.

Salah satu cara mengatasi hal ini adalah dengan:

Tulis sebuah kelas yang mendapatkan semua data POST / GET dan tulislah sebagaimana adanya ke kelas Singleton yang disebut 'insecure_data'. Kemudian kosongkan array POST / GET.
Pengembang harus mengambil data POST / GET dari array 'insecure_data', bukan array POST / GET.

Setiap pengembang yang mengambil sesuatu dari array yang disebut 'insecure_data' dan tidak repot-repot mengamankannya adalah bodoh atau malas. Jika yang pertama, berikan pelatihan, setelah itu yang terakhir - dan kemudian Anda memiliki masalah disiplin, bukan masalah pemrograman.

— Dan Blows
sumber

Wow, itu tidak perlu berbelit-belit dan masih belum menyelesaikan masalah. Ini bukan masalah menggosok input hanya untuk bersenang-senang, tetapi menggosok data yang Anda masukkan ke dalam basis data, dan bahwa data secara teoritis dapat berasal dari mana saja, dari formulir web, atau email, atau dokumen XML yang seseorang mengunggah. Dalam semua kasus ini, Anda harus menggosok ketika masuk ke database.

— Roger Halliburton

@RogerHalliburton Tentu saja itu tidak menyelesaikan segalanya, tetapi ini adalah konsep (semacam pola desain, jika Anda mau) daripada tindakan keamanan yang sepenuhnya dilakukan untuk membuat data yang tidak aman terlihat tidak aman.

— Dan Blows

Ah, begitu. Tetapi Anda hanya melawan sifat manusia, jika Anda memberi tahu seseorang "Objek ini tidak aman kecuali ditandai sebagai aman" dan mereka mencoba menggunakannya untuk sesuatu, sebagian besar waktu mereka akan menandainya sebagai aman tanpa benar-benar memeriksa. Nah, nikmati peningkatan reputasi.

— Roger Halliburton

Dari sudut pandang pengembang junior, hanya dengan melihat $ insecure_data memunculkan flag dengan cara yang hanya melihat $ postdata (atau apa pun) tidak. Idenya datang dari Joel Spolsky's "Buat kode yang salah terlihat salah" . Jika sifat alami manusia dari pengembang Anda mengabaikan bendera merah itu, maka Anda perlu memberikan banyak pelatihan atau mendapatkan beberapa pengembang baru.

— Dan Blows

Saya tidak menyimpan Spolsky di atas alas. Ini adalah pengembang yang dengan mudah mengabaikan tabbing yang tidak konsisten, mereka tidak akan berpikir dua kali untuk menggunakan sesuatu yang dinamai "tidak aman".

— Roger Halliburton

1

Salah satu panduan terbaik yang saya baca tentang keamanan web adalah panduan keamanan Ruby on Rails ini . Meskipun Ruby on Rails, banyak konsep yang berlaku untuk pengembangan web apa pun. Saya akan mendorong siapa pun yang baru untuk membaca panduan itu.

— mistagrooves
sumber

2

Semua orang tahu Ruby tidak aman.

— Roger Halliburton

5

@Roger: “Semua orang tahu” segala macam hal yang mungkin atau mungkin tidak benar. Saya menganjurkan pendekatan berbasis realitas untuk pemrograman, bukan berbasis desas-desus.

— Donal Fellows

0

Kode yang Anda tautkan di atas rentan terhadap serangan injeksi SQL, karena input HTTP yang Anda gunakan dalam kueri belum dibersihkan dengan mysql_real_escape_stringatau cara lain apa pun.

— Ryan
sumber

1

oh, saya pikir kami menjawab ini seperti pertanyaan tes:]

— Ryan

Downvotes agak timpang, karena kata-kata dari pertanyaan itu diubah ex post: P

— Ryan

0

Dalam hal pertanyaan Anda (mungkin mengesampingkan) "bagaimana saya bisa membuat programmer berhenti melakukan ini", saya akan mengatakan bahwa membimbing mereka secara teratur, dengan hati-hati menjelaskan masalah yang dipermasalahkan (dan potensi kejatuhan, dll) dan menekankan pentingnya kerentanan kode (baik dalam hal injeksi SQL dan skrip lintas situs, dll.) mungkin merupakan solusi yang paling masuk akal.

Jika mereka terus mengacau terlepas dari semua hal di atas (Anda mungkin ingin mengawasi komitmen mereka, dll. Daripada mencari tahu "hidup"), maka masalahnya adalah apakah Anda gagal sebagai mentor, atau bahwa mereka mungkin perlu menemukan sesuatu yang lebih cocok untuk hidup.

— John Parker
sumber