나는 자바 9의 새로운 기능을 찾아이 발견했습니다 JEP 290: Filter Incoming Serialization Data 그리고 다른 기사에 따르면이 자바 deserialisation 데이터와 보안 문제가 있습니다 : Deserialization of untrusted dataJava 9 용 "수신 직렬화 데이터 필터링"은 데이터 deserialisation 보안 취약점을 해결합니까?
첫 번째 기사에서 텍스트에 기반을, I 이것이 두 번째 기사의 문제에 대한 피드백임을 믿는 이유가 있지만, 나는 정말로 확신하지 못합니다. 이 버그는 여전히 Java에 대한 것입니까? 그렇다면 새로운 Java가이 문제를 완전히 해결합니까?
우선, 신뢰할 수없는 데이터의 직렬화는 Java의 버그가 아니며 설명했습니다.
이 취약점은 응용 프로그램 개발자/설계자가 신뢰할 수없는 출처에서 가져온 일련의 데이터가 유효성을 검사하지 않고 응용 프로그램에 의해 deserialize되는 방식으로 응용 프로그램을 설계 할 때 발생합니다.
이해해야 할 중요한 점은이 취약점은 잘못된 응용 프로그램 디자인으로 인해 발생한다는 것입니다.
JEP 290을 사용하면 개발자 및/또는 보안 엔지니어가 데이터를 직렬화하기 전에 유효성을 검사 할 수 있습니다. 직렬화 필터링을 올바르게 수행하면 일부 비 직렬화 공격을 완화하는 데는 도움이되지만 문제를 완전히 해결하지는 못하며 대규모 구성 및 배포는 매우 복잡합니다.
현재 직렬화 필터링 기능에 대한 자세한 평가를 읽을 수 있습니다 https://dzone.com/articles/a-first-look-into-javas-new-serialization-filterin
더 나은 직렬화 취약점을 이해하고 당신이 당신의 응용 프로그램을 보호 할 수있는 방법은 더 여기 읽을 수 있습니다 : https://dzone.com/articles/why-runtime-compartmentalization-is-the-most-compr
위의'readObject()'또는'readResolve()'메소드를 사용하는 클래스는 아무 것도하지 않고 원치 않는 동작을 유발할 수 있습니다. 응용 프로그램 설계 오류 무엇이든지. 유효성 검사를하지 않아도 응용 프로그램이 객체를 가져올 때 이미 너무 늦었습니다.이 기능이 도입 된 이유 * NB 두 링크가 모두 같은 위치를 가리 킵니다 – EJP
나쁜 디자인은 앱이 신뢰할 수없는 소스의 데이터를 역 직렬화 할 수 있다는 사실에서 비롯된 것으로, 이는 잘못된 디자인 결정입니다.이 취약점을 정확하게 반영하기 위해 "신뢰할 수없는 데이터의 역 직렬화"라고하며, "직렬화 필터링" 화이트/블랙 리스팅은 우회 될 수있는 주요 한계가 있기 때문에 여전히 취약 할 수 있습니다 .CERT에 따르면이 문제를 해결하기위한 권장 방법은 ** 재 설계/재 설계 ** 어플리케이션. 이것은 이것이 설계상의 문제임을 확인시켜줍니다. 유효성 검사는 좋은 첫 번째 단계이지만 문제를 해결하지는 못합니다. – Maestros
NB 링크는 주제에 대해 쓴 두 개의 개별 기사를 가리 킵니다. – Maestros
내가 충분히 아니에요 귀하의 질문에 완전히 답변 할 수있는 자격이 있지만 JEP 290을 이해하면 애플리케이션 개발자는 필터링을 구현해야합니다. 따라서 개발자가 비 직렬화 취약점을 해결할 수있는 충분한 권한을 API에 부여해야합니다. – Nicolai