Antipola: Menggunakan penghitung rakus dalam kebijakan RegularExpressionProtection

Anda sedang melihat dokumentasi Apigee dan Apigee hybrid.
Lihat dokumentasi Apigee Edge.

Kebijakan RegularExpressionProtection menentukan ekspresi reguler yang dievaluasi saat runtime pada parameter input atau variabel alur. Anda biasanya menggunakan kebijakan ini untuk melindungi dari ancaman konten seperti injeksi SQL atau JavaScript, atau untuk memeriksa parameter permintaan yang salah formatnya seperti alamat email atau URL.

Ekspresi reguler dapat ditentukan untuk jalur permintaan, parameter kueri, parameter formulir, header, elemen XML (dalam payload XML yang ditentukan menggunakan XPath), atribut objek JSON (dalam payload JSON yang ditentukan menggunakan JSONPath).

Contoh kebijakan RegularExpressionProtection berikut melindungi backend dari serangan injeksi SQL:

<!-- /antipatterns/examples/greedy-1.xml -->
<RegularExpressionProtection async="false" continueOnError="false" enabled="true"
  name="RegexProtection">
    <DisplayName>RegexProtection</DisplayName>
    <Properties/>
    <Source>request</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <QueryParam name="query">
      <Pattern>[\s]*(?i)((delete)|(exec)|(drop\s*table)|
        (insert)|(shutdown)|(update)|(\bor\b))</Pattern>
    </QueryParam>
</RegularExpressionProtection>

Antipola

Kuantifikasi default (*, +, dan ?) bersifat rakus: kuantifikasi mulai cocok dengan urutan yang mungkin terpanjang. Jika tidak ada kecocokan yang ditemukan, mereka akan mundur secara bertahap untuk mencoba mencocokkan pola. Jika string yang dihasilkan yang cocok dengan pola sangat pendek, penggunaan penghitung rakus dapat memerlukan waktu lebih lama dari yang diperlukan. Hal ini terutama berlaku jika payload besar (dalam puluhan atau ratusan KB).

Contoh ekspresi berikut menggunakan beberapa instance .*, yang merupakan operator rakus:

<Pattern>.*Exception in thread.*</Pattern>

Dalam contoh ini, kebijakan RegularExpressionProtection pertama-tama mencoba mencocokkan urutan terpanjang—seluruh string. Jika tidak ditemukan kecocokan, kebijakan akan mundur secara bertahap. Jika string yang cocok berada di dekat awal atau tengah payload, penggunaan kuantifikator rakus seperti .* dapat memerlukan lebih banyak waktu dan daya pemrosesan daripada penentu yang enggan seperti .*? atau (lebih jarang) kuantifikator posesif seperti .*+.

Kuantifikasi enggan (seperti X*?, X+?, X??) dimulai dengan mencoba mencocokkan satu karakter dari awal payload dan menambahkan karakter secara bertahap. Kuantitas posesif (seperti X?+, X*+, X++) mencoba mencocokkan seluruh payload hanya sekali.

Dengan contoh teks berikut untuk pola di atas:

Hello this is a sample text with Exception in thread
with lot of text after the Exception text.

Dalam hal ini, penggunaan .* yang rakus tidak berperforma baik. Pola .*Exception in thread.* memerlukan 141 langkah untuk dicocokkan. Jika Anda menggunakan pola .*?Exception in thread.* (yang menggunakan pengukur enggan), hasilnya hanya akan menjadi 55 langkah.

Dampak

Menggunakan penghitung rakus seperti karakter pengganti (*) dengan kebijakan RegularExpressionProtection dapat menyebabkan:

  • Peningkatan latensi keseluruhan untuk permintaan API dengan ukuran payload sedang (hingga 1 MB)
  • Waktu yang lebih lama untuk menyelesaikan eksekusi kebijakan RegularExpressionProtection
  • Permintaan API dengan payload besar (>1 MB) gagal dengan Error Waktu Tunggu Gateway 504 jika periode waktu tunggu yang telah ditentukan berlalu di Apigee Router
  • Pemakaian CPU yang tinggi pada Message Processor karena banyaknya pemrosesan yang dapat lebih lanjut memengaruhi permintaan API lainnya

Praktik terbaik

  • Hindari penggunaan kuantifiser rakus seperti .* dalam ekspresi reguler dengan kebijakan RegularExpressionProtection. Sebagai gantinya, gunakan penentu kuantitas enggan seperti .*? atau penentu kuantitas posesif seperti .*+ (lebih jarang) jika memungkinkan.

Bacaan lebih lanjut