Калі рэгулярныя выразы пагаршаюць прадукцыйнасць
Адзін радок рэгулярнага выразу C# можа паставіць API на калені. Дрэнна напісаныя шаблоны выклікаюць катастрафічныя адкаты, перагружаюць працэсар і блакуюць патокі. Гэта класіка. Адмова ў абслугоўванні з дапамогай рэгулярных выразаў (ReDoS) — гэта тонкі, але небяспечны вектар атакі, схаваны ў вашым кодзе.
⚠️Небяспечны прыклад, толькі для адукацыйных мэтаў. Не выкарыстоўвайце ў прадукцыйнай версіі.
string pattern = @"(a+)+$"; // Vulnerable regex c# Regex regex = new Regex(pattern); bool isMatch = regex.IsMatch("aaaaaaaaaaaaaaaaaaaaaaaa!"); Гэты рэгулярны выраз для C# мае ўкладзеныя квантыфікатары, якія выклікаюць экспанентны зваротны адлік. Доўгі, шкоднасны радок можа замарозіць канчатковую кропку або мікрасэрвіс.
Бяспечная версія:
string pattern = @"^a+$"; // Safe simplified regex for C# Regex regex = new Regex(pattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(200)); bool isMatch = regex.IsMatch("aaaaaaaaaaa"); Адукацыйная заўвага: Заўсёды выкарыстоўвайце тайм-аўты (Параметры рэгулярных выразаў + Прамежак часу) і спрасціць укладзеныя групы. У рэгулярных выразах C# праверка прадукцыйнасці з'яўляецца патрабаваннем бяспекі, а не аптымізацыяй.
Чаму шаблоны рэгулярных выразаў C# становяцца ўразлівымі
Неадназначныя квантыфікатары (.*, .+або (а+)+) і неабмежаванае паўтарэнне робяць рэгулярныя выразы распаўсюджанай мішэнню для DoS.
Калі яны з'яўляюцца ў кантэкстах, кіруемых карыстальнікам, такіх як праверка ўводу або аналіз журнала, адна створаная карысная нагрузка можа манапалізаваць працэсар.
⚠️Небяспечны прыклад, толькі для адукацыйных мэтаў. Не выкарыстоўвайце ў прадукцыйнай версіі.
// Vulnerable email validation regex for C# var pattern = @"^([a-zA-Z0-9_\-\.]+)@([\w\-]+\.)+([a-zA-Z]{2,4})$"; var input = "a".PadLeft(10000, 'a') + "@example.com"; Regex.IsMatch(input, pattern); // May hang or cause ReDoS Бяспечная версія:
// Safer regex c# pattern var pattern = @"^[^@\s]+@[^@\s]+\.[^@\s]+$"; Regex regex = new Regex(pattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(300)); bool isValid = regex.IsMatch("user@example.com"); Адукацыйная заўвага: Пазбягайце неадназначных паўтораў, абмяжоўвайце памер уваходных дадзеных і заўсёды правярайце прадукцыйнасць рэгулярных выразаў пад нагрузкай. Функцыянальны фрагмент кода, прымяненне тайм-аўтаў і максімальнай даўжыні ўводу ў якасці ахоўнікаў у прадукцыйным рэжыме.
Рэальны ўплыў на API і CI/CD Рабочыя працэсы
Небяспечны рэгулярны выраз для C# не абмяжоўваецца формамі праверкі. Распрацоўшчыкі ўбудоўваюць шаблоны ў фільтры журналаў, супастаўленні вэбхукаў і аўтаматызаванае сканаванне. CI/CDадзін небяспечны шаблон можа спыніць увесь працэс pipeline.
⚠️Небяспечны прыклад, толькі для адукацыйных мэтаў. Не выкарыстоўвайце ў прадукцыйнай версіі.
// Regex used to match commit messages in a CI job var regex = new Regex(userInputPattern); if (regex.IsMatch(commitMessage)) { /* process */ } If userInputPattern contains (a+)+$, it can freeze the build agent.Ніколі не апрацоўвайце рэгулярны выраз, прадастаўлены карыстальнікам, без праверкі або кантролю часу чакання.
Бяспечная версія:
// Safe usage in CI/CD context if (userInputPattern.Length < 100 && !userInputPattern.Contains("++")) { Regex regex = new Regex(userInputPattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(100)); if (regex.IsMatch(commitMessage)) { /* safely process */ } } Адукацыйная заўвага: Праверце знешні ўвод рэгулярных выразаў перад выкананнем. Дадайце відавочныя праверкі даўжыні і прымусова ўвядзіце тайм-аўты. pipelines.
Бяспечныя практыкі прадухілення DoS-аварый з дапамогай рэгулярных выразаў у C#
Прадухіленне ReDoS у рэгулярных выразах на C# павінна быць убудавана ў вашу распрацоўку, і Працоўны працэс DevSecOps. Вось як зрабіць яго бяспечным па змаўчанні:
Best Practices
- Заўсёды ўсталёўвайце тайм-аўты на ўсіх вылічэннях рэгулярных выразаў.
- Пазбягайце катастрафічных мадэляў, без укладзеных квантыфікатараў або неадназначных груп.
- Абмежаваць памер уводу перад пераходам да рэгулярнага выразу.
- Папярэдняя кампіляцыя давераных шаблонаў з RegexOptions.Скампіляваны.
- Ачысціць выразы, уведзеныя карыстальнікам або дадайце ў белы спіс дазволеныя шаблоны.
Міні-кантрольны спіс прафілактыкі
- Праверце кожны рэгулярны выраз на наяўнасць C# у вашай кодавай базе.
- Ужываць Прамежак часу тайм-аўты паслядоўна.
- Абмежаваць даўжыню ўваходных дадзеных для API і CI.
- Праверце прадукцыйнасць рэгулярных выразаў перад выпускам.
- Аўтаматызаваць статычны рэгулярны выраз сканаванне ў CI/CD.
Адукацыйная заўвага: Разглядайце шаблоны рэгулярных выразаў як ненадзейны код. Яны заслугоўваюць такой жа ўважлівасці, як SQL або выкананне каманд.
Як Xygeni выяўляе рызыкоўнае выкарыстанне рэгулярных выразаў C#
Ксігені Code Security аўтаматычна выяўляе небяспечныя шаблоны рэгулярных выразаў C# падчас статычнага аналізу. Ён вызначае катастрафічныя адкаты, прапушчаныя тайм-аўты і заканамернасці, якія могуць прывесці да завісання сэрвісаў. In CI/CD, Ксігені дзейнічае як а Брама DevSecOps, блакуючы небяспечны рэгулярны выраз для C# перад яго аб'яднаннем або разгортваннем.
# Never expose real tokens, credentials, or internal URLs in pipelines - name: Regex Safety Scan run: dotnet xygeni validate --rules regex ,performance --fail-on-riskАдукацыйная заўвага: Інтэграцыя Xygeni забяспечвае бяспечную апрацоўку рэгулярных выразаў ва ўсіх зборках і асяроддзях, прадухіляючы рэгрэсіі і DoS-атакі перад разгортваннем.
Ваш рэгулярны выраз магутны, пераканайцеся, што ён не зброя
Уразлівасці ReDoS ператвараюць нявінныя на выгляд рэгулярныя выразы C# у зброю адмовы ў абслугоўванні. Небяспечныя рэгулярныя выразы для шаблонаў C# з'яўляюцца распаўсюджанай памылкай, пакуль яны не завісаюць або не перашкаджаюць працы. CI/CD.
Зрабіце бяспеку рэгулярных выразаў часткай вашай гігіены праграмавання:
- Заўсёды выкарыстоўвайце тайм-аўты.
- Пазбягайце ўкладзеных квантыфікатараў.
- Абмежаваць увод карыстальніка.
- Аўтаматызуйце праверкі з дапамогай Xygeni Code Security.
Рэгулярныя выразы заўсёды будуць магутнымі, але пры дбайным праектаванні вашы шаблоны рэгулярных выразаў на C# не стануць вашай наступнай справаздачай аб інцыдэнце.
