Apakah lima kelemahan umum API?

API memudahkan untuk menjalankan perniagaan dan penggodam juga berfikir demikian. Hari ini, apabila transformasi digital perusahaan sedang giat dijalankan, API telah melampaui skop teknologi inovasi perniagaan Internet dan transformasi digital perusahaan tradisional tidak dapat dipisahkan daripada ekonomi API atau strategi API. API menghubungkan bukan sahaja sistem dan data, tetapi juga jabatan berfungsi korporat, pelanggan dan rakan kongsi, malah keseluruhan ekosistem perniagaan. Pada masa yang sama, dengan ancaman keselamatan yang semakin teruk, API menjadi sempadan seterusnya keselamatan rangkaian. Kami telah mengumpulkan lima kelemahan utama keselamatan API dan cadangan menampal yang dicadangkan oleh pakar keselamatan kepada perusahaan.

API menjadikan segala-galanya lebih mudah, daripada perkongsian data kepada ketersambungan sistem kepada penyampaian fungsi kritikal, tetapi API juga memudahkan penyerang, termasuk bot berniat jahat. Percambahan aplikasi API merangsang penjenayah siber untuk semakin mengeksploitasi kelemahan keselamatan API untuk melakukan penipuan dan mencuri data.

Di bawah, kami akan membincangkan lima kerentanan API yang mudah dieksploitasi oleh penggodam, dan berkongsi cadangan mitigasi dan pengukuhan yang diberikan oleh pakar keselamatan.

1 Terlalu mudah untuk ditemui

Jika anda seorang penggodam dan akan menyerang syarikat, perkara pertama yang perlu anda lakukan ialah mengenal pasti seberapa banyak API seboleh mungkin. Saya mula-mula menggunakan aplikasi sasaran dengan cara biasa, membuka aplikasi web dalam penyemak imbas atau memuat turun dan memasang aplikasi mudah alih pada telefon, dan kemudian menggunakan proksi pemintasan untuk memantau komunikasi.

Proksi pemintasan mampu menangkap semua permintaan yang dibuat oleh penyemak imbas atau aplikasi mudah alih ke pelayan web hujung belakang, membenarkan penyerang mengkatalogkan semua titik akhir API yang tersedia. Sebagai contoh, kebanyakan API mempunyai API/V1/log masuk sebagai titik akhir pengesahan.

Jika sasaran juga ialah apl mudah alih, kemudian buka pek apl itu dan lihat panggilan API yang tersedia di dalam apl itu. Dengan mengambil kira semua aktiviti yang mungkin, penyerang boleh mencari ralat konfigurasi biasa atau API yang gagal melindungi data pengguna dengan betul.

Akhir sekali, penyerang mencari dokumentasi API. Sesetengah organisasi menerbitkan dokumentasi API untuk pihak ketiga tetapi menggunakan titik akhir API yang sama untuk semua pengguna.

Dengan senarai titik akhir yang baik, penyerang boleh menguji kedua-dua tingkah laku pengguna standard dan ujian tingkah laku tidak normal, kedua-dua cara untuk mencari kelemahan yang menarik.

Penyelesaian: Untuk menjadikan API lebih sukar ditemui oleh penyerang, pastikan anda mengawal akses kepada dokumentasi API melalui pengurusan kebenaran yang hanya membenarkan pengguna yang sah mengaksesnya. Walaupun menyematkan sijil pada apl mudah alih tidak sepenuhnya menyembunyikan titik akhir API, dan ia tidak sempurna, ia menambah langkah tambahan kepada serangan. Permintaan API kepada pelayan web harus dikaburkan dan dikawal sebaik mungkin.

2. Mesej ralat yang terlalu terperinci

Baru-baru ini, percubaan penyerang untuk mengambil alih akaun semakin meningkat. Mesej ralat yang terlalu "terperinci" cenderung untuk membuat serangan sedemikian lebih mudah. Mesej ralat yang panjang membimbing penyerang tentang perubahan yang perlu mereka lakukan untuk muncul sebagai permintaan yang sah. API direka bentuk untuk transaksi berkelajuan tinggi di bawah beban rendah, membenarkan penyerang menggunakan sistem berprestasi tinggi untuk mengenal pasti akaun yang sah dan kemudian cuba log masuk dan menukar kata laluan untuk eksploitasi.

Penyelesaian: Jangan gunakan pengalaman pengguna sebagai perisai Sesetengah amalan yang kelihatan baik untuk pengalaman pengguna mungkin tidak baik untuk keselamatan. Mesej ralat yang dikembalikan oleh sistem tidak seharusnya memasukkan nama pengguna yang salah atau kata laluan yang salah, malah kategori mesej ralat (nama pengguna atau kata laluan yang salah). Perkara yang sama berlaku untuk mesej ralat yang digunakan untuk menanyakan data, jika pertanyaan/carian salah bentuk atau tidak dapat dilaksanakan atas sebab tertentu, ia harus mengembalikan mesej ralat yang paling "tidak berkhasiat": "Op, ada masalah".

3. Terlalu Banyak Parameter

Apabila penyerang melintasi sistem serangan melalui panggilan API, mereka mesti memikirkan perkara yang boleh mereka hantar untuk mendapatkan data. Penyerang "percaya" pada hakikat bahawa lebih kompleks sistem, lebih banyak perkara boleh menjadi salah. Setelah penyerang mengenal pasti API, mereka akan mengkatalogkan parameter dan kemudian cuba mengakses data pentadbir (peningkatan keistimewaan menegak) atau pengguna lain (peningkatan keistimewaan mendatar) untuk mengumpul data tambahan. Selalunya, terlalu banyak parameter yang tidak perlu didedahkan kepada pengguna.

Dalam projek penyelidikan baru-baru ini, panggilan API kami kepada perkhidmatan sasaran mengembalikan sejumlah besar data, yang kebanyakannya adalah maklumat data yang tidak diperlukan, seperti kunci pemproses gerbang pembayaran dan maklumat diskaun yang tersedia. "Maklumat ganjaran" ini membolehkan penyerang memahami dengan lebih baik konteks dan sintaks panggilan API ini. Ia tidak memerlukan banyak imaginasi untuk penyerang untuk memikirkan apa yang perlu dilakukan seterusnya. Parameter tambahan ini menyediakan penyerang dengan set data serangan yang kaya.

Penyelesaian: Jika anda mengehadkan skop pengguna kandungan melihat kepada perkara yang perlu, mengehadkan penghantaran data kritikal dan membuat struktur pertanyaan data tidak diketahui, ia akan menjadi sukar bagi penyerang untuk mengetahui tentang mereka parameter untuk keretakan kekerasan.

4. Terlalu banyak data

Sekali lagi, dengan begitu banyak parameter yang tersedia, pengumpulan data akan menjadi langkah seterusnya yang jelas. Banyak sistem perusahaan menyokong sambungan tanpa nama dan cenderung membocorkan data tambahan yang tidak diperlukan oleh pengguna biasa. Selain itu, banyak perniagaan memilih untuk menyimpan data yang boleh diakses secara langsung.

Para profesional keselamatan sedang bergelut dengan cabaran permintaan API yang sering mendedahkan tempat data disimpan. Contohnya, apabila saya melihat video daripada kamera keselamatan, saya dapat melihat bahawa maklumat itu datang daripada repositori Amazon S3. Selalunya, repositori S3 tersebut tidak dilindungi dengan baik dan data sesiapa sahaja boleh diambil semula.

Satu lagi cabaran data biasa ialah lebihan data Banyak perniagaan seperti chipmunks sebelum musim sejuk, menyimpan lebih banyak data daripada yang mereka perlukan. Banyak data pengguna yang telah tamat tempoh tidak mempunyai nilai komersial atau nilai pemeliharaan, tetapi jika dibocorkan, ia akan membawa risiko jenama dan pematuhan yang besar kepada perusahaan.

Penyelesaian: Untuk perniagaan yang menyimpan data pengguna, bukan sahaja PII atau PHI, semakan data yang teliti diperlukan. Selepas memeriksa data yang disimpan, peraturan capaian data harus dibangunkan dan diuji. Pastikan data yang boleh diakses tanpa nama tidak melibatkan sebarang data sensitif.

5. Reka bentuk keselamatan yang terlalu sedikit

Selama bertahun-tahun, reka bentuk aplikasi sentiasa mengutamakan fungsi dan kebolehgunaan, jarang mengambil kira keselamatan. Banyak CISO mengatakan bahawa keselamatan API khususnya tidak dipandang serius, malah dikecualikan sepenuhnya daripada proses reka bentuk keselamatan. Biasanya, selepas pembangun menyelesaikan pembangunan dan penggunaan, mereka hanya cuba mencari masalah selepas API dimasukkan ke dalam pengeluaran dan kerap diserang. Keselamatan (termasuk keselamatan API) perlu menjadi sebahagian daripada reka bentuk produk dan dilaksanakan sebagai salah satu pertimbangan pertama dan bukannya mengisi lubang selepas fakta itu.

Penyelesaian: Menyemak seni bina keselamatan aplikasi anda ialah langkah pertama yang penting ke arah sistem selamat. Ingat, API membolehkan penyerang menyerang atau mengeksploitasi sistem anda dengan lebih cekap. Matlamat mereka bentuk keselamatan adalah untuk menjadikan API sebagai alat yang cekap untuk pengguna dan bukannya penyerang.

Atas ialah kandungan terperinci Apakah lima kelemahan umum API?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!