security lint) Unsafe Regular Expression, 이메일 정규표현식 검사

https://www.npmjs.com/package/eslint-plugin-security

eslint-plugin-security

위의 플러그인을 사용하여 관리를 할 때 발견한 에러이다. 

해당 모듈은 아래 글에서 처음 사용하였다.

2021.08.30 - [개발] - eslint plugin security 모듈

eslint plugin security 모듈

728x90

Regular Expression을 사용하는 부분은 많았지만 해당 에러가 발생하는 부분은 정규표현식에 대한 조건이 많은 부분이였다.

 

참고로 여기서 난 오류에 대한 설명은 위에 모듈 링크에 설명이 써져 있었다.

이번 오류를 살펴보자면, unsafe regular expression 즉, 정규표현식을 사용하는 과정에서 보안에 문제가 있다는 것인데 시간이 오래 걸려서 이벤트 루프를 막아버리는 문제가 발생할 수 있다는 것이다. npm에 설명된 링크를 보고 싶은데 회사 보안에서 막혀서 볼수가 없었다.. 폰으로 보내서 봐도 막혀 있는걸 보니 검색을 더 해야 할거 같다.

 

https://stackoverflow.com/questions/51710707/es-lint-security-flagging-an-unsafe-regular-expression

es-lint-security flagging an unsafe regular expression

/^[A-Za-z.,'-]([A-Za-z.,' -]*[A-Za-z.,'-])?$/

여기서,  아래와 같이 고쳐주어야 오버플로우를 통한 공격을 막을 수 있다고 한다.

([A-Za-z.,' -]* ?)

Consider the regular expression (x+x+)+y. Let's see what happens when you apply this regex to xxxxxxxxxxy. The first x+ will match all 10 x characters. The second x+ fails. The first x+ then backtracks to 9 matches, and the second one picks up the remaining x. The group has now matched once. The group repeats but fails at the first x+.When y fails, the regex engine backtracks. The group has one iteration it can backtrack into. The second x+ matched only one x, so it can't backtrack. But the first x+ can give up one x. The second x+ promptly matches xx. The group again has one iteration, fails the next one, and the y fails. When y fails, the regex engine backtracks. The group has one iteration it can backtrack into. The second x+ matched only one x, so it can't backtrack. But the first x+ can give up one x. The second x+ promptly matches xx. The group again has one iteration, fails the next one, and the y fails. Backtracking again, the second x+ now has one backtracking position, reducing itself to match x. The group tries a second iteration. The first x+ matches but the second is stuck at the end of the string. Backtracking again, the first x+ in the group's first iteration reduces itself to 7 characters. The second x+ matches xxx. Failing y, the second x+ is reduced to xx and then x.

If you try this regex on a 10x string in RegexBuddy's debugger, it'll take 2558 steps to figure out the final y is missing. For an 11x string, it needs 5118 steps. For 12, it takes 10238 steps. Clearly we have an exponential complexity of O(2^n) here. At 21x the debugger bows out at 2.8 million steps, diagnosing a bad case of catastrophic backtracking.

Regex engines (like .NET) will keep going forever, while others will crash with a stack overflow (like Perl, before version 5.10). Stack overflows are particularly nasty on Windows since they tend to make your application vanish without a trace or explanation.

대충 해석을 해보자면 시간복잡도를 고려해 보았을 때 정규 표현식끼리 연산을 넣게 되는 경우, 들어온 값의 마지막 부분에서 에러가 날 경우, 연산이 계속하여 반복되고, 여기서 발생하는 백트랙킹을 진행하게 되면 시간복잡도가 O(2^n)로 매우 높게 잡히는 것이 문제였다. 정규 표현식에 대한 시간 복잡도를 줄여야 해당 보안 문제를 해결할 수 있는 것으로 보인다. 문제는 이메일 검증의 정규 표현식이 너무나도 복잡하다는 것.

https://emailregex.com/

Email Address Regular Expression That 99.99% Works.

다음과 같은 사이트에서 이메일 정규표현식을 볼 수 있었다. 하지만 이 경우에도 시간복잡도가 높게 나오는 것은 마찬가지며 다른 린터에서 에러를 추가로 발생시켰다.

https://www.oreilly.com/library/view/regular-expressions-cookbook/9781449327453/ch04s01.html

Regular Expressions Cookbook, 2nd Edition

위에 사이트가 가장 깔끔하게 나온것 같다. 정규표현식에 대한 동물책이였다.

 

일단 문제에 대한 보고만 했지만 일반적으로 위와 같은 에러를 피하기 위해서는 위의 정규표현식을 사용하는게 맞는것 같다.