Antipola: Menggunakan penghitung rakus dalam kebijakan RegularExpressionProtection

Anda melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Kebijakan RegularExpressionProtection menentukan ekspresi reguler yang dievaluasi saat runtime pada parameter input atau variabel alur. Biasanya, Anda menggunakan kebijakan ini untuk melindungi dari ancaman konten seperti injeksi SQL atau JavaScript, atau untuk memeriksa parameter permintaan yang salah format 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

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

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

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

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

Pengukur yang tidak serakah (seperti X*?, X+?, X??) mulai dengan mencoba mencocokkan satu karakter dari awal payload dan secara bertahap menambahkan karakter. Pengukur posesif (seperti X?+, X*+, X++) mencoba mencocokkan seluruh payload hanya sekali.

Dengan teks contoh berikut untuk pola di atas:

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

Penggunaan .* yang serakah tidak berperforma dalam hal ini. Pola .*Exception in thread.* memerlukan 141 langkah untuk dicocokkan. Jika Anda menggunakan pola .*?Exception in thread.* (yang menggunakan pengukur yang tidak serakah), hasilnya hanya 55 langkah.

Dampak

Penggunaan pengukur serakah seperti karakter pengganti (*) dengan kebijakan RegularExpressionProtection dapat menyebabkan:

  • Peningkatan latensi keseluruhan untuk permintaan API untuk 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 Gateway Timeout 504 jika periode waktu tunggu yang telah ditentukan sebelumnya berakhir di Edge Router
  • Penggunaan CPU yang tinggi pada Message Processor karena jumlah pemrosesan yang besar yang dapat memengaruhi permintaan API lainnya lebih lanjut

Praktik terbaik

  • Hindari penggunaan pengukur serakah seperti .* dalam ekspresi reguler dengan kebijakan RegularExpressionProtection. Sebagai gantinya, gunakan pengukur yang tidak serakah seperti .*? atau pengukur posesif seperti .*+ (kurang umum) jika memungkinkan.

Bacaan lebih lanjut