Kötü bir normal ifadeyi nasıl tanıyabilirim?

Kısa bir süre önce Düzenli ifade Hizmet Reddi saldırılarının farkına vardım ve kod tabanımda bulabildiğim her yerde "kötü" normal ifade kalıplarını veya en azından kullanıcı girdisinde kullanılanları kökten kaldırmaya karar verdim. Yukarıdaki OWASP bağlantısında ve wikipedia'da verilen örnekler yararlıdır, ancak sorunu basit terimlerle açıklamak için harika bir iş çıkarmazlar.

Wikipedia'dan kötü regexlerin açıklaması :

• normal ifade, karmaşık bir alt ifadeye tekrarı ("+", "*") uygular;
• tekrarlanan alt ifade için, aynı zamanda başka bir geçerli eşleşmenin son eki olan bir eşleşme vardır.

Örneklerle, yine Wikipedia'dan :

• (a+)+
• ([a-zA-Z]+)*
• (a|aa)+
• (a|a?)+
• (.*a){x} x> 10 için

Bu, daha basit bir açıklaması olmayan bir sorun mu? Normal ifadeler yazarken bu sorundan kaçınmayı veya onları mevcut bir kod tabanı içinde bulmayı kolaylaştıracak bir şey arıyorum.

Kötü Regexes Neden Bir Sorun?

Çünkü bilgisayarlar, kastettiğiniz şey olmasa veya tamamen mantıksız olsa bile, onlara ne söylediğinizi tam olarak yaparlar. Bir Regex motorundan, belirli bir girdi için, belirli bir model için bir eşleşme olduğunu veya olmadığını kanıtlamasını isterseniz, motor, kaç farklı kombinasyonun test edilmesi gerektiğine bakılmaksızın bunu yapmaya çalışacaktır.

İşte OP'nin gönderisindeki ilk örnekten ilham alan basit bir model:

^((ab)*)+$

Giriş göz önüne alındığında:

ababababababababababab

Normal ifade motoru benzer (abababababababababababab)bir şeyi dener ve ilk denemede bir eşleşme bulunur.

Ama sonra maymun anahtarını içeri atıyoruz:

ababababababababababab a

İlk önce motor deneyecek (abababababababababababab)ama bu ekstra yüzünden başarısız oluyor a. Bu, felaketle sonuçlanan brack izlemeye neden olur, çünkü bizim modelimiz, (ab)*iyi niyet göstergesi olarak, yakalamalarından birini serbest bırakacak ("geri dönecektir") ve dış modelin tekrar denemesine izin verecektir. Normal ifade motorumuz için bu şuna benzer:

(abababababababababababab)- Hayır
(ababababababababababab)(ab)- Hayır
(abababababababababab)(abab)- Hayır
(abababababababababab)(ab)(ab)- Hayır
(ababababababababab)(ababab)- Hayır
(ababababababababab)(abab)(ab)- Hayır
(ababababababababab)(ab)(abab)- Hayır
(ababababababababab)(ab)(ab)(ab)- Hayır
(abababababababab)(abababab)- Hayır
(abababababababab)(ababab)(ab)- Hayır
(abababababababab)(abab)(abab)- Hayır
(abababababababab)(abab)(ab)(ab)- Hayır
(abababababababab)(ab)(ababab)- Hayır
(abababababababab)(ab)(abab)(ab)- Hayır
(abababababababab)(ab)(ab)(abab)- Hayır
(abababababababab)(ab)(ab)(ab)(ab)- Hayır
(ababababababab)(ababababab)- Hayır
(ababababababab)(abababab)(ab)- Hayır
(ababababababab)(ababab)(abab)- Hayır
(ababababababab)(ababab)(ab)(ab)- Hayır
(ababababababab)(abab)(abab)(ab)- Hayır
(ababababababab)(abab)(ab)(abab)- Hayır
(ababababababab)(abab)(ab)(ab)(ab)- Hayır
(ababababababab)(ab)(abababab)- Hayır
(ababababababab)(ab)(ababab)(ab)- Hayır
(ababababababab)(ab)(abab)(abab)- Hayır
(ababababababab)(ab)(abab)(ab)(ab)- Hayır
(ababababababab)(ab)(ab)(ababab)- Hayır
(ababababababab)(ab)(ab)(abab)(ab)- Hayır
(ababababababab)(ab)(ab)(ab)(abab)- Hayır
(ababababababab)(ab)(ab)(ab)(ab)(ab)- Hayır
                              ...
(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(abababab) - Hayır
(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ababab)(ab)- Hayır
(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(abab)(abab)- Hayır
(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(abab)(ab)(ab)- Hayır
(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ababab)- Hayır
(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(abab)(ab)- Hayır
(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(abab)- Hayır
(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)(ab)- Hayır

Olası kombinasyonların sayısı, girdinin uzunluğuna göre üssel olarak ölçeklenir ve siz farkına varmadan, normal ifade motoru bu şeyi çözmeye çalışan tüm sistem kaynaklarınızı tüketiyor, tüm olası terim kombinasyonlarını tüketene kadar, sonunda pes ediyor ve "Eşleşme yok" şeklinde raporlar. Bu arada sunucunuz yanan bir erimiş metal yığınına dönüştü.

Kötü Regexes Nasıl Tespit Edilir

Aslında çok zor. Ne olduklarını ve genellikle onlardan nasıl kaçınılacağını bilmeme rağmen kendim bir çift yazdım. Regex'in şaşırtıcı derecede uzun sürdüğünü görün . Bir atomik grupta yapabileceğiniz her şeyi sarmak , geri izleme sorununu önlemeye yardımcı olabilir. Temel olarak, normal ifade motoruna belirli bir ifadeyi tekrar ziyaret etmemesini söyler - "ilk denemede eşleştiğini kilitle". Bununla birlikte, atomik ifadelerin ifade içinde geri dönüşü engellemediğini , bu ^(?>((ab)*)+)$nedenle yine de tehlikeli olduğunu, ancak ^(?>(ab)*)+$güvenli olduğunu unutmayın (eşleşecek (abababababababababababab)ve ardından eşleşen karakterlerinden herhangi birini bırakmayı reddedecek, böylece felaket geri dönüşü önleyecektir).

Ne yazık ki, bir kez yazıldıktan sonra, normal ifadelerde hemen veya hızlı bir şekilde sorun bulmak aslında çok zordur. Sonunda, kötü bir normal ifadeyi tanımak, diğer herhangi bir kötü kodu tanımak gibidir - çok fazla zaman ve deneyim ve / veya tek bir felaket olayı gerektirir.

İlginç bir şekilde, bu cevap ilk kez yazıldığından beri, Austin'deki Texas Üniversitesi'ndeki bir ekip, bu "kötü" kalıpları bulmak için açık bir amaçla Normal İfadelerin statik analizini gerçekleştirebilen bir aracın geliştirilmesini açıklayan bir makale yayınladı. Araç, Java programlarını analiz etmek için geliştirildi, ancak önümüzdeki yıllarda, özellikle ReDoS saldırılarının oranı artmaya devam ettikçe , JavaScript ve diğer dillerdeki sorunlu kalıpları analiz etme ve tespit etme etrafında geliştirilen daha fazla araç göreceğimizden şüpheleniyorum .

Normal İfadeler
Valentin Wüstholz, Oswaldo Olivo, Marijn JH Heule ve Isil Dillig
The University of Texas at Austin kullanan Programlarda DoS Güvenlik Açıklarının Statik Tespiti

"Kötü" normal ifade dediğiniz şey, yıkıcı geri dönüşü sergileyen bir normal ifadedir . Bağlantılı sayfa (yazdığım) kavramı ayrıntılı olarak açıklıyor. Temel olarak, bir normal ifadenin eşleşmesi başarısız olduğunda ve aynı normal ifadenin farklı permütasyonları kısmi bir eşleşme bulabildiğinde, yıkıcı geri izleme gerçekleşir. Normal ifade motoru daha sonra tüm bu permütasyonları dener. Kodunuzun üzerinden geçmek ve normal ifadelerinizi incelemek istiyorsanız, bakmanız gereken 3 temel konu şunlardır:

1. Alternatifler birbirini dışlamalıdır. Birden fazla alternatif aynı metinle eşleşebiliyorsa, normal ifadenin geri kalanı başarısız olursa motor her ikisini de deneyecektir. Alternatifler tekrarlanan bir grup içindeyse, felaket bir geri dönüş yaşarsınız. Klasik bir örnek, (.|\s)*normal ifade çeşidinin "satır sonlarıyla eşleşen nokta" moduna sahip olmadığı durumlarda herhangi bir miktarda herhangi bir metnin eşleştirilmesidir. Bu, daha uzun bir normal ifadenin parçasıysa, yeterince uzun aralıklı bir konu dizesi (her ikisi .ile eşleşen \s) normal ifadeyi bozar. Düzeltme, (.|\n)*alternatifleri birbirini dışlayan veya hatta [\r\n\t\x20-\x7E]ASCII yazdırılabilirler, sekmeler ve satır sonları gibi hangi karakterlere gerçekten izin verildiği konusunda daha spesifik hale getirmek için kullanmaktır .

2. Sıralı olan nicelendirilmiş belirteçler, ya birbirlerini karşılıklı olarak dışlamalı ya da aralarından gelenleri karşılıklı olarak dışlamalıdır. Aksi takdirde her ikisi de aynı metinle eşleşebilir ve normal ifadenin geri kalanı eşleşmediğinde iki niceleyicinin tüm kombinasyonları denenir. Klasik bir örnek, a.*?b.*?c3 şeyi aralarındaki "herhangi bir şey" ile eşleştirmektir. Ne zaman cilk tutulamayacak .*?hat veya dosyanın sonuna kadar karakter karakter genişleyecektir. Her genişletme için ikincisi .*?, satırın veya dosyanın geri kalanıyla eşleşecek şekilde karakter karakter genişler. Düzeltme, aralarında "hiçbir şey" olamayacağının farkına varmaktır. İlk koşunun durması bve ikinci koşunun durması gerekir c. Tek karakterlerlea[^b]*+b[^c]*+ckolay bir çözümdür. Artık sınırlayıcıda durduğumuz için, performansı daha da artırmak için iyelik nicelik belirteçlerini kullanabiliriz.

3. Bir miktar belirleyiciye sahip bir belirteç içeren bir grup, grup içindeki nicel belirteç yalnızca kendisiyle karşılıklı olarak özel olan başka bir şeyle eşleştirilemedikçe, kendi nicelik tanımlayıcısına sahip olmamalıdır. Bu, iç niceleyicinin daha fazla yinelemesine sahip dış niceleyicinin daha az yinelemesinin, iç niceleyicinin daha az yinelemeli dış niceleyicinin daha fazla yinelemesiyle aynı metni eşleştirmesinin hiçbir yolu yoktur. Bu, JDB'nin cevabında gösterilen problemdir.

Cevabımı yazarken bunun web sitemde tam bir makaleyi hak ettiğine karar verdim . Bu artık çevrimiçi.

Bunu "bir tekrarın tekrarı" olarak özetliyorum. Listelediğiniz ilk örnek iyi bir örnektir, çünkü "a harfi, bir satırda bir veya daha fazla kez. Bu yine arka arkaya bir veya daha fazla kez olabilir".

Bu durumda aranacak şey, * ve + gibi nicelik belirteçlerinin birleşimidir.

Dikkat edilmesi gereken biraz daha incelikli bir şey de üçüncü ve dördüncü. Bu örnekler, her iki tarafın da doğru olabileceği bir OR işlemi içerir. Bu, ifadenin nicelleştiricisi ile birleştirildiğinde, giriş dizesine bağlı olarak LOT potansiyel eşleşmelerle sonuçlanabilir.

Özetlemek gerekirse, TLDR tarzı:

Diğer operatörlerle birlikte niceleyicilerin nasıl kullanıldığına dikkat edin.

Şaşırtıcı bir şekilde birkaç kez kaynak kodu incelemeleri yapan ReDOS ile karşılaştım. Önereceğim bir şey, kullandığınız Normal İfade motoru ile bir zaman aşımı kullanmaktır.

Örneğin, C # 'da bir TimeSpanniteliğe sahip normal ifadeyi oluşturabilirim .

string pattern = @"^<([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+\/>)$";
Regex regexTags = new Regex(pattern, RegexOptions.None, TimeSpan.FromSeconds(1.0));
try
{
    string noTags = regexTags.Replace(description, "");
    System.Console.WriteLine(noTags);
} 
catch (RegexMatchTimeoutException ex)
{
    System.Console.WriteLine("RegEx match timeout");
}

Bu normal ifade, hizmet reddine karşı savunmasızdır ve zaman aşımı olmadan dönüp kaynakları tüketir. Zaman aşımıyla birlikte, RegexMatchTimeoutExceptionverilen zaman aşımından sonra bir atar ve kaynak kullanımına neden olarak Hizmet Reddi durumuna neden olmaz.

Kullanımınız için çalıştığından emin olmak için zaman aşımı değerini denemek isteyeceksiniz.

Kötü normal ifadeleri algılama

1. Nicolaas Weideman'ın RegexStaticAnalysis projesini deneyin .
2. Weideman'ın aracı ve diğerleri için bir CLI'ye sahip olan topluluk tarzı vuln-regex-dedektörümü deneyin .

Pratik kurallar

Kötü normal ifadeler her zaman karşılık gelen NFA'daki belirsizlikten kaynaklanır ve bunları regexper gibi araçlarla görselleştirebilirsiniz .

İşte bazı belirsizlik biçimleri. Bunları normal ifadelerinizde kullanmayın.

1. Kantifikatörleri iç içe yerleştirme (a+)+(aka "yıldız yüksekliği> 1") Bu, üstel patlamaya neden olabilir. Suback'ın safe-regexaracına bakın .
2. Örtüşen Ayrılıklar gibi nicelleştirilmiş (a|a)+. Bu, üstel patlamaya neden olabilir.
3. Sayısal Örtüşen Bitişikliklerden Kaçının \d+\d+. Bu, polinom patlamasına neden olabilir.

Ek kaynaklar

Bu makaleyi süper doğrusal normal ifadeler üzerine yazdım . Diğer normal ifadelerle ilgili araştırmalara çok sayıda referans içerir.

Bunun kullanımdaki regex motoruyla ilgili olduğunu söyleyebilirim. Bu tür normal ifadelerden her zaman kaçınamayabilirsiniz, ancak normal ifade motorunuz doğru şekilde oluşturulmuşsa, o zaman daha az sorun olur. Normal ifade motorları konusunda çok sayıda bilgi için bu blog dizisine bakın .

Geri izleme bir NP-Complete sorunu olduğu için makalenin altındaki uyarıya dikkat edin. Şu anda bunları verimli bir şekilde işlemenin bir yolu yoktur ve girdinizde bunlara izin vermemek isteyebilirsiniz.

Bu tür normal ifadeleri tanıyabileceğinizi sanmıyorum, en azından hepsini değil ya da ifadelerini kısıtlayıcı bir şekilde sınırlamadan. ReDoS'leri gerçekten önemsiyorsanız, onları korumaya almaya ve işlemlerini bir zaman aşımıyla durdurmaya çalışırdım. Maksimum geri izleme miktarını sınırlamanıza izin veren RegEx uygulamaları da olabilir.

Bazı basitleştirme kurallarını küçük test girdileri üzerinde çalıştırarak veya normal ifadenin yapısını analiz ederek uygulayabileceğinizi düşünebileceğim bazı yollar var.

• (a+)+ yedekli operatörlerin yerine konması için bir tür kural kullanılarak azaltılabilir. (a+)
• ([a-zA-Z]+)* yeni artıklık kuralı birleştirme kuralıyla da basitleştirilebilir ([a-zA-Z]*)

Bilgisayar, normal ifadenin küçük alt ifadelerini rastgele oluşturulmuş ilgili karakter dizilerine veya karakter dizilerine karşı çalıştırarak ve bunların hangi gruplarda sona erdiğini görerek testleri çalıştırabilir. Birincisi, bilgisayar, normal ifadeler gibidir. a'lar istiyor, öyleyse deneyelim 6aaaxaaq. Daha sonra, tüm a'ların ve yalnızca ilk groupm'nin tek bir grupta sona erdiğini görür ve a sayısı kaç olursa olsun, +grupta yer aldığı için önemli olmayacağı sonucuna varır . İkincisi, sanki, normal ifade bir sürü harf istiyor, öyleyse deneyelim -fg0uj=ve sonra yine her grubun tek bir grupta olduğunu görüyor, böylece +sonunda kurtuluyor .

Şimdi sonrakileri ele almak için yeni bir kurala ihtiyacımız var: ilgisiz seçenekleri ortadan kaldırma kuralı.

• İle (a|aa)+, bilgisayar ona bir göz atıyor ve sanki büyük ikincisini seviyoruz, ama onu daha fazla boşluğu doldurmak için kullanabiliriz, elimizden geldiğince çok aa alalım ve başka bir şey elde edip edemeyeceğimize bakalım. biz bittikten sonra. Bunu, "eaaa @ a ~ aa" gibi başka bir test dizesine karşı çalıştırabilir. bunu belirlemek için.

• (a|a?)+Bilgisayarınızın a?, aradığımız dizelerin bizim aradığımız droidler olmadığını fark etmesini sağlayarak kendinizi koruyabilirsiniz , çünkü her zaman her yerde eşleşebileceği için, beğenmediğimize karar veririz (a?)+ve onu atarız.

• Biz korumak (.*a){x}eşleşmesi karakterler olduğunu fark için edinerek azaten tarafından yakaladı olurdu .*. Daha sonra bu parçayı atarız ve içindeki fazlalık niceleyicileri değiştirmek için başka bir kural kullanırız (.*){x}.

Böyle bir sistemi uygulamak çok karmaşık olsa da, bu karmaşık bir sorundur ve karmaşık bir çözüm gerekli olabilir. Ayrıca, bitmezse onu öldürmeden önce normal ifadeye sınırlı miktarda yürütme kaynağına izin vermek gibi, diğer insanların ortaya koyduğu teknikleri de kullanmalısınız.