Горячая точка против уязвимости
Прежде всего, обратите внимание, что SonarQube информирует вас о горячей точке безопасности, а не об уязвимости. Это означает (цитируя the docs ):
Hotspot безопасности выделяет чувствительный к безопасности фрагмент кода, который разработчик должен просмотреть. После проверки вы либо обнаружите, что угрозы нет, либо вам нужно применить исправление для защиты кода.
[...]
С Hotspot, чувствительным к безопасности элементом кода выделен, но на общую безопасность приложения не может повлиять. Разработчик должен проверить код, чтобы определить, нужно ли исправление для обеспечения безопасности кода.
Важным выводом здесь является то, что SonarQube не сообщает вам, что что-то не так. Он говорит вам, что вы должны внимательно посмотреть код, чтобы определить , является ли что-то не так.
Другими словами, он говорит вам, что ваше регулярное выражение может быть уязвимым для ReDoS атаки, не то, что это на самом деле. Если вы просматриваете код и обнаруживаете, что уязвимости нет, совершенно нормально просто устранить проблему, не меняя ничего.
Так почему именно SonarQube предлагает вам проверить этот код?
SonarQube фактически не определяет, уязвимо ли регулярное выражение для ReDoS или нет (поэтому оно помечено как точка безопасности, а не уязвимость). Вместо этого он помечает все нетривиальные регулярные выражения и напоминает вам просмотреть их, чтобы определить, являются ли они уязвимыми или нет. Как объяснено в документации правила , оно рассматривает любое регулярное выражение как нетривиальное, содержащее более одного вхождения любого из символов *+{.
, поскольку оба ваших регулярных выражения нетривиальны по этим критериям, оба помечены.
Так уязвим ли ваш код?
Нет, ни одно из ваших регулярных выражений не уязвимо. Фактически, единственный оператор повторения, используемый в любом выражении, - это {}, и поскольку вы предоставляете верхнюю границу во всех случаях, неограниченного повторения даже не существует.
Однако я бы сказал, что вашим первым регулярным выражением является достаточно сложный, чтобы быть читабельностью и кошмаром обслуживания. Поэтому вам следует подумать о том, чтобы заменить его другим подходом (например, разбить строку на отдельные числа и проверить, что каждое число находится в требуемом диапазоне).
Так что вам следует делать?
Определив что регулярные выражения не являются уязвимыми, вы должны отклонить горячую точку.
В комментариях было отмечено, что сообщение исчезнет go, если вы разделите строку регулярного выражения на несколько строк или переместите ее в Переменная. Причина, по которой это работает, заключается в том, что SonarQube обманывает и не находит регулярное выражение. Таким образом, это изменение не сделает ваш код лучше или безопаснее, оно только запутает SonarQube и никоим образом не предпочтительнее, чем просто отклонить сообщение. Как правило, не рекомендуется запутывать ваш код только для того, чтобы ваши аналитические инструменты stati c закрылись.