Terapkan validasi skema API untuk blokir request tidak sesuai - Edge Security Acceleration

Setelah Anda mengunggah skema API (seperti spesifikasi OpenAPI), sistem secara otomatis memetakan skema tersebut ke API yang dikelola. Sistem kemudian memvalidasi permintaan masuk terhadap skema ini dan menerapkan kebijakan keamanan yang telah dikonfigurasi pada lalu lintas yang tidak sesuai.

Cara kerjanya

Setelah API Anda ditemukan dan dikelola, Anda dapat mengaktifkan validasi skema di seluruh permukaan API Anda.

Ketika sebuah permintaan mencapai titik kehadiran (POP), ESA pertama-tama memeriksa apakah permintaan tersebut menargetkan API yang dikelola dengan skema terkait.
- Jika tidak, permintaan dilanjutkan ke pemeriksaan keamanan lainnya.
- Jika ya, ESA melanjutkan ke langkah berikutnya.
ESA memeriksa apakah permintaan sesuai dengan skema:
- Jika tidak sesuai, sistem menerapkan aksi yang telah dikonfigurasi (misalnya, Blokir) dan mencatat peristiwa tersebut.
- Jika sesuai, permintaan diizinkan untuk lewat.

Atur validasi skema

Untuk memulai, unggah skema API dan aktifkan validasi.

Di konsol ESA, pilih Websites, lalu klik situs target di kolom Website.
Di panel navigasi kiri, pilih Security > API Security.
Di halaman API Security, pilih tab Schema Validation, dan klik Schema Validation Settings.
Di halaman pengaturan, klik Upload Schema untuk mengunggah file skema Anda.
ESA secara otomatis mencocokkan API yang didefinisikan dalam file skema Anda dengan API yang dikelola. Tinjau kecocokannya dan klik OK.
Setelah skema diunggah, konfigurasikan Actions untuk permintaan yang tidak sesuai. Kami sangat menyarankan untuk memulai dengan aksi Monitor untuk mengamati dan mencatat positif palsu tanpa memengaruhi lalu lintas sah. Nyalakan sakelar Status untuk mengaktifkan validasi.
Kembali ke tab Schema Validation untuk melihat API yang telah dikonfigurasi dan status validasinya.

Analisis permintaan yang tidak sesuai

Setelah diaktifkan, Keamanan API terus memantau permintaan untuk kepatuhan skema. Di tab Schema Validation, Anda dapat menyaring berdasarkan skema untuk melihat jumlah permintaan yang tidak sesuai untuk setiap API dalam 24 jam terakhir.

Peningkatan permintaan yang tidak sesuai dapat menunjukkan dua masalah utama:

Kesalahan sisi klien: Klien sah mungkin mengirimkan permintaan yang salah format. Hal ini dapat disebabkan oleh bug dalam kode antarmuka depan, format parameter yang salah (misalnya, data formulir alih-alih JSON), parameter yang diperlukan hilang, atau ketidaksesuaian tipe data (misalnya, string alih-alih boolean). Tinjau implementasi sisi klien Anda dan pertimbangkan untuk menambahkan validasi input yang lebih ketat.
Perilaku serangan: Penyerang sering mengirimkan permintaan yang salah format untuk mencari celah seperti injeksi SQL, skrip lintas situs (XSS), atau kontrol akses rusak. Lonjakan mendadak dalam permintaan yang tidak sesuai dapat menjadi tanda serangan. Jika Anda mencurigai adanya serangan, Ubah aksi menjadi Blokir dan konfigurasikan aturan WAF yang lebih ketat.

Analisis detail permintaan

Untuk mendiagnosis penyebab utama permintaan yang tidak sesuai, Anda dapat memeriksa log sampel di Peristiwa atau Analitik Keamanan.

Di tab Schema Validation, identifikasi API dengan jumlah permintaan yang tidak sesuai yang tidak biasa.
Pilih alat yang sesuai berdasarkan aksi yang dikonfigurasi:
- Aksi adalah Tidak ada: Karena tidak ada tindakan keamanan yang dipicu, permintaan ini paling baik dilihat di log yang lebih luas yang tersedia di Analitik Keamanan.
- Aksi adalah Monitor/Blokir: Karena peristiwa keamanan dipicu, log mudah diakses dan berkorelasi di Peristiwa.
Berikut ini menggunakan Peristiwa sebagai contoh. Di panel navigasi kiri, pilih Security > Events.
Untuk menggunakan Analitik Keamanan, pilih Security > Security Analytics di panel navigasi kiri.
Di halaman Events, gulir ke bawah ke area Sampling Logs. Saring untuk peristiwa yang dipicu oleh Keamanan API. Klik ikon perluasan untuk entri log untuk melihat detailnya. Analisis permintaan berdasarkan fitur dalam detail tersebut. Anda juga dapat beralih ke Log Real-time untuk lebih banyak detail.

Ubah aksi

Anda dapat mengatur aksi default global untuk semua API atau menimpanya untuk API tertentu.

Ubah aksi default global: Di tab Schema Validation, klik Change di kolom Default Action, dan pilih aksi:
- Block: Memblokir permintaan yang tidak sesuai dan mencatat log blokir.
- Monitor: Mengizinkan permintaan yang tidak sesuai untuk lewat dan mencatat log.
- None: Tidak melakukan tindakan apa pun dan tidak mencatat.
Konfigurasikan aksi untuk API tertentu: Dalam daftar API dari Schema Validation, klik Change Action di sebelah kanan API, dan pilih aksi.
- Default: Menggunakan aksi default global.
- Block: Memblokir permintaan yang tidak sesuai dan mencatat log blokir.
- Monitor: Mengizinkan permintaan yang tidak sesuai untuk lewat dan mencatat log.
- None: Tidak melakukan tindakan apa pun dan tidak mencatat.

Tangani API tanpa skema

Setelah mengunggah skema, beberapa API mungkin tetap tidak terhubung. Di tab Schema Validation, klik nomor di kolom APIs Without a Schema untuk melihat daftar titik akhir ini.

Titik akhir tanpa skema tidak divalidasi, menciptakan potensi celah keamanan. API mungkin tidak cocok karena dua alasan utama:

Penghilangan dari skema: API secara tidak sengaja ditinggalkan dari file skema Anda. Verifikasi jalur, host, dan metode HTTP API dalam daftar, lalu perbarui file skema Anda dan unggah lagi.
Desain API non-standar: API yang ditemukan tidak mengikuti praktik RESTful standar dan oleh karena itu tidak cocok dengan definisi skema Anda. Anda mungkin perlu merombak ulang API. Masalah umum termasuk:
- Jalur non-standar: Misalnya, menggunakan /user alih-alih yang didefinisikan /users.
- Metode HTTP salah: Misalnya, menggunakan GET untuk tindakan destruktif seperti /users/delete/123 alih-alih DELETE.
- Penyalahgunaan kode status: Misalnya, selalu mengembalikan kode status 200 OK, bahkan untuk kesalahan, dan menempatkan kode status sebenarnya di badan respons (misalnya, { "status": "error", "code": 500 }).
- Struktur data yang membingungkan: Misalnya, menempatkan bidang di bagian yang salah dari permintaan atau respons (misalnya, mendefinisikan bidang email di skema respons ketika seharusnya berada di badan permintaan).

Spesifikasi skema

Format file dan ukuran

Format: File skema harus dalam format .yml, .yaml, atau .json.
Ukuran: Ukuran file maksimum adalah 58 KB. Untuk skema yang lebih besar, gunakan format .json dan kompres sebelum mengunggah.

Konten skema

Versi

ESA validasi arsitektur keamanan API saat ini hanya mendukung OpenAPI Specification (OAS) v3.0.x.

Bidang

Bidang yang diperlukan

openapi: String versi OAS (misalnya, 3.0.0).
info: Metadata tentang API, termasuk version (misalnya, 1.0.0).
paths: Informasi host tempat API disajikan.
servers: Informasi host tempat API disajikan:
- url: Hanya URL absolut yang didukung, seperti https://api.example.com.
- variables: Variabel server tidak didukung dan akan diabaikan selama penguraian.

Bidang opsional

schema: Definisi struktur data. Jenis berikut didukung:
- int32
- uint32
- int64
- uint64
- float
- double
- boolean
- email
reference: Menggunakan $ref untuk menunjuk ke objek yang telah ditentukan sebelumnya. Referensi eksternal dan relatif tidak didukung.
requestbody: Mendefinisikan badan permintaan. Hanya data dengan content-type application/json yang didukung.

Contoh

Berikut ini adalah contoh file skema .json.

{
    "openapi": "3.0.0",
    "info": {
        "title": "contoh",
        "description": "contoh",
        "version": "1.0"
    },
    "servers": [
    {
      "url": "https://example1.aliyun.com",
      "description": "url example1"
    },
    {
      "url": "https://example2.aliyun.com",
      "description": "url example2"
    }
    ],
    "components": {
        "schemas": {
            "ParamsObject": {
                "type": "object",
                "properties": {
                    "id": {
                        "type": "integer"
                    },
                    "value": {
                        "type": "string"
                    }
                },
                "required": [
                    "id",
                    "value"
                ]
            }
        }
    },
    "paths": {
        "/example/{param1}": {
            "get": {
                "operationId": "getexampleById",
                "parameters": [
                    {
                        "name": "param1",
                        "in": "path",
                        "required": true,
                        "description": "id",
                        "schema": {
                            "type": "integer",
                            "format": "int32"
                        }
                    }
                ]
            }
        },
        "/api1": {
            "post": {
                "operationId": "post_api1",
                "summary": "permintaan post api1",
                "parameters": [],
                "requestBody": {
                    "required": true,
                    "content": {
                        "application/json": {
                            "schema": {
                                "$ref": "#/components/schemas/ParamsObject"
                            }
                        }
                    }
                }
            },
            "get" :{
                "operationId": "get_api1",
                "summary": "permintaan get api1",
                "parameters": [
                    {
                        "name": "id",
                        "in": "query",
                        "required": true,
                        "schema": {
                            "type": "integer",
                            "format": "int32"
                        }
                    },
                    {
                        "name": "name",
                        "in": "query",
                        "required": false,
                        "schema": {
                            "type": "string"
                        }
                    }
                ]
            }
        }
    }
}