Bagaimana cara menghindari penggunaan API yang tidak sah?

Saya harus merancang "widget", sebuah skrip yang akan dimasukkan oleh mitra di situs web mereka untuk menampilkan beberapa UI dan membuat panggilan ke API kami.

Pada dasarnya itu akan menampilkan data kami di situs-situs ini berdasarkan pada beberapa ID yang mereka berikan dalam panggilan API kami. Yang ingin kami hindari adalah seseorang yang menyalahgunakan API dan menggunakannya untuk mengikis keseluruhan katalog kami.

Setiap mitra yang menyematkan skrip kami akan diberikan kunci publik yang harus disediakan saat memanggil API. Suatu gagasan adalah meminta mereka untuk menambahkan kunci ini saat memuat skrip, misalnya:

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

Dengan cara itu permintaan untuk skrip dapat digunakan untuk mendaftarkan pasangan IP kunci / sumber, dan menjawab panggilan API berikutnya hanya jika pasangan kunci / IP cocok dengan yang terdaftar (dengan masa pakai terbatas, dan batas permintaan per hari).

Saya tidak yakin itu ide yang bagus karena itu jelas keamanan melalui kebingungan (seseorang yang memuat ulang skrip akan benar-benar memotongnya); tapi saya tidak melihat cara lain untuk membatasi akses. Saya tidak dapat memberikan kunci unik untuk setiap pengguna, hanya untuk mitra. Saya tidak dapat menggunakan sistem kunci pribadi karena semua kode akan tersedia untuk siapa saja. Ini pada dasarnya membatasi akses ke API publik, yaitu bertentangan dalam definisi.

Apa pendapat Anda tentang solusi ini, dan apa yang akan Anda lakukan dengan kendala-kendala ini?

security api-design web-api

— Antoine
sumber

Bisakah Anda membuat kunci dinamis? Hash MD5 dari pengidentifikasi mitra ditambah waktu UTC dibulatkan ke 10 menit terdekat?

— Dan Pichelman

Saya bisa, tetapi itu akan dihitung dalam naskah, dan dengan demikian tersedia secara bebas bagi siapa saja untuk memperbanyaknya. Saya tidak melihat bagaimana itu meningkatkan keamanan.

— Antoine

Saya berpikir untuk meminta mitra menghitung sisi servernya. Jika itu bukan pilihan, maka saya curiga satu-satunya pilihan nyata Anda adalah melakukan pembatasan yang Anda sebutkan (masa hidup terbatas, batas permintaan / hari). Jangan lupa bahwa IP yang Anda lihat belum tentu dipetakan ke satu komputer.

— Dan Pichelman

Saya perlu memeriksa dengan bisnis apakah untuk menghitungnya sisi server layak. Kalau tidak, itu yang saya takutkan, hanya solusi yang mencekik.

— Antoine

Jawaban:

Anda memerlukan beberapa jenis perlindungan.

Pertama , Anda perlu mencegah kunci Situs A digunakan di Situs B.

Secara teori, jika kunci terikat ke domain, Anda tidak dapat bergantung pada referertajuk, tetapi karena Anda klien sedang menyematkan skrip secara langsung, Anda dapat mengandalkannya document.locationdi sisi klien. Mengirim lokasi itu (atau sebagiannya) ke server secara langsung tidak dapat diandalkan; tetapi Anda dapat menggunakannya untuk membuat kunci sesi:

Klien menyematkan client_keypermintaan untuk pustaka API.
Server menentukan host yang memiliki akses ke API, jika ada.
Server mengambil "garam" untuk kunci sesi dan mengirimkannya ke klien dengan perpustakaan [atau sebagai bagian dari pertukaran pra-auth lain].
Klien menghitung session_keymenggunakan hash(document.location.host + session_salt).
Klien menggunakan session_key+ client_keyuntuk panggilan API.
Server memvalidasi panggilan dengan mencari client_keyhost dan "garam" di sesi, menghitung hash, dan membandingkan dengan yang disediakan client_key.

Kedua , Anda perlu menghalangi Hacker Hank dari membuka konsol debug atau menggunakan klien yang dimodifikasi di Situs A untuk melakukan apa pun yang dia inginkan dengan API Anda.

Perhatikan bahwa sangat sulit, jika bukan tidak mungkin, untuk sepenuhnya mencegah Hacker Hank menyalahgunakan API. Tapi, Anda bisa membuatnya lebih sulit. Dan cara paling masuk akal untuk menghalangi Hank, yang saya tahu, adalah pembatasan suku bunga.

Batasi jumlah permintaan / detik / sesi dan permintaan / jam / sesi. (Lonjakan aktivitas mungkin masuk akal, tetapi tidak mendukung lalu lintas di atas rata-rata dari satu klien.)
Batasi jumlah sesi / IP / jam.
Batasi jumlah permintaan / IP / jam. Izinkan paku, tetapi tidak mendukung lalu lintas yang padat dari satu IP.

Ketiga , karena Anda mungkin sudah melakukan: mengenkripsi lalu lintas. Tentu, NSA akan melihatnya; tapi Hacker Hank kecil kemungkinannya.

— svidgen
sumber

Sepertinya yang Anda lakukan di sini menjadikan file javascript Anda menjadi sumber daya yang dilindungi. Dan menggabungkannya dengan semacam token generation pada saat yang bersamaan. Itu menarik.

Orang-orang keamanan saya bekerja dengan biasanya mengabaikan alamat IP karena IP spoofable. Tetapi jika Anda menggunakan batasan IP yang dikombinasikan dengan SSL, itu biasanya berhasil.

Tetapi Anda harus "memasukkan daftar putih" ke alamat IP, jika tidak, peretas apa saja bisa datang di pintu depan.

Saya skeptis, tetapi saya benar-benar berpikir skema Anda bekerja dengan sangat baik. Jika 1) file .js dan panggilan API berikutnya dibuat dengan TLS (yaitu SSL atau https), dan 2) IP dimasukkan dalam daftar putih. Lalu saya akan membuat pernyataan berani dan mengatakan saya pikir Anda akan lulus tinjauan keamanan, bahkan untuk interaksi PCI (kartu kredit).

IMHO ... Tetapi jika Anda hanya mencoba melindungi informasi hak milik perusahaan alih-alih kartu kredit (PCI) atau informasi pribadi / pribadi (PII), maka ini mungkin baik bahkan tanpa SSL, tergantung pada seberapa banyak Anda bersedia mengambil risiko mengekspos katalog Anda.

Atau begini: Dengan SSL, peretas yang berdedikasi tidak bisa mendapatkan katalog Anda. (Kecuali jika mereka melanggar SSL, tetapi kemudian mereka bisa merusak Amazon juga). Tanpa SSL, peretas yang berdedikasi dapat mengendus panggilan Anda, menipu IP dan menarik katalog Anda. Jadi itu semacam penilaian panggilan pada risiko.

Saya mencoba memikirkan cara untuk membuang daftar putih IP karena itu biasanya menyusahkan;) tanpa pergi ke OAuth sepenuhnya. Saya akan mie itu.

— rampok
sumber