안전한 코딩 가이드라인이 어떻게 진화하는가
안전한 코딩 가이드라인이 어떻게 진화하는가
지난 주 나는 우리의 보안 코딩 지침을 최신 상태로 가지고 자바 봄의 취약점을 연구했다. 나는 우리의 플랫폼에서 기존의 도전을 겪고 있었고 JSP 페이지에 URL 매개 변수를 표시하여 XSS에서 몇 가지를 발견했다. 잘못된 코드 예제는 다음과 유사한 것으로 보입니다.
<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에 작업 데모를 게시 .
그리고 물론 나는 지금 읽는 우리의 보안 코딩 지침을 업데이트 : "표시하거나 스프링 표현 언어 (SpEL)를 사용하여 URL 매개 변수를 평가하지 마십시오."
공격자가 응용 프로그램 서버에서 기능을 수정하고 호출할 수 있습니다. - 데이터 및 기능에 대한 무단 액세스뿐만 아니라 계정 납치 및 원격 코드 실행. - 성공적인 공격의 기밀성 및 무결성 우려.
https://www.owasp.org/index.php/Expression_Language_Injection
블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.
Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.
개발자 중심 보안에 대한 최신 연구 보기
광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.
안전한 코딩 가이드라인이 어떻게 진화하는가
지난 주 나는 우리의 보안 코딩 지침을 최신 상태로 가지고 자바 봄의 취약점을 연구했다. 나는 우리의 플랫폼에서 기존의 도전을 겪고 있었고 JSP 페이지에 URL 매개 변수를 표시하여 XSS에서 몇 가지를 발견했다. 잘못된 코드 예제는 다음과 유사한 것으로 보입니다.
<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에 작업 데모를 게시 .
그리고 물론 나는 지금 읽는 우리의 보안 코딩 지침을 업데이트 : "표시하거나 스프링 표현 언어 (SpEL)를 사용하여 URL 매개 변수를 평가하지 마십시오."
공격자가 응용 프로그램 서버에서 기능을 수정하고 호출할 수 있습니다. - 데이터 및 기능에 대한 무단 액세스뿐만 아니라 계정 납치 및 원격 코드 실행. - 성공적인 공격의 기밀성 및 무결성 우려.
https://www.owasp.org/index.php/Expression_Language_Injection