시큐어 코딩 가이드라인의 진화

지난 주에 필자는 보안 코딩 지침을 최신 상태로 유지하기 위해 Java Spring의 취약점을 조사했습니다.플랫폼의 기존 문제를 살펴보다가 XSS에서 JSP 페이지에 URL 매개 변수를 표시하는 과정에서 몇 가지 문제점을 발견했습니다.잘못된 코드 예제는 다음과 비슷할 것입니다.

<input type="text" name="username" value="${param.username}">

올바른 해결책은 URL 매개 변수를 완전히 제거하는 것이었으며 설명에는 URL 매개 변수를 올바른 방법으로 이스케이프하는 것도 안전하다고 언급되어 있습니다.

이제 제 일은 개발자들이 이해할 수 있는 방식으로 보안 코딩 가이드라인을 만들고 보안 코드를 작성하면서도 가능한 한 제한적으로 만드는 것입니다.이런 경우에는 개발자가 의도한 기능을 그대로 유지할 수 있도록 하고 URL 매개 변수를 이스케이프하여 안전하게 사용할 수 있도록 권장하고 싶습니다.이렇게 하면 코드에 더 이상 XSS 취약점이 포함되지 않습니다.위 예시는 다음과 같이 보안을 설정할 수 있습니다.

<input type="text" name="username" value="${fn:escapeXml(param.username)}">

그리고 이것은 며칠 동안 우리의 보안 코딩 지침이었는데, 제가 우연히 발견하게 될 때까지 표현식 언어 주입에 관한 OWASP 페이지.이 페이지에서는 스프링 표현식 언어 (SPEL) 가 어떻게 남용되어 원격 코드 실행을 포함하여 심각한 영향을 미칠 수 있는지 설명합니다.보안 코딩 가이드라인을 준수하는 코드가 여전히 이 취약점의 영향을 받을 수 있는 경우가 있는지 알아내는 것은 제 몫이었습니다.그래서 SpEL 표현식을 평가하는 간단한 테스트 애플리케이션을 작성하고, Xml 이스케이프를 사용하거나 사용하지 않고 입력값을 테스트하여 포착되지 않는 시나리오를 찾을 수 있는지 확인했습니다.그리고 실제로 해봤는데, XMLeScape에서 잡아낸 문자를 전혀 포함하지 않는 악의적인 표현식들도 있었습니다.저는 GitHub에 작업 데모를 게시했는데, 여기에서 찾을 수 있습니다. 이리.

물론 보안 코딩 가이드라인을 업데이트했습니다. 이 가이드라인에는 이제 “Spring Expression Language (SpLE) 를 사용하여 URL 매개변수를 표시하거나 평가하지 마십시오.”

이 문제가 미치는 전반적인 영향은 다음과 같습니다. - 공격자가 응용 프로그램 서버의 기능을 수정하고 호출할 수 있습니다. - 데이터 및 기능에 대한 무단 액세스, 계정 하이재킹 및 원격 코드 실행. - 성공적인 공격으로 인한 기밀성 및 무결성 문제.

https://www.owasp.org/index.php/Expression_Language_Injection