최근에 해킹당한 고객이 있었으며 Â 및 Æ와 같은 사이트에 이상한 캐릭터가 나타나는 것을 알았습니다. 해커 wp_options가 데이터베이스 의 테이블에서 blog_charset을 UTF-7로 변경 한 것으로 나타났습니다 . UTF-8로 다시 설정했지만 UTF-7로 설정된 시간 동안 보안 취약점이 발생할 수 있는지 궁금합니다.
몇 가지 검색을 수행하여 버전 2.0.6에서 수정 된 WordPress UTF-7 취약점이 있음 을 발견했습니다 . 최신 버전의 WordPress를 실행 중이므로 해당 익스플로이 트를 사용할 수 없었지만 UTF-7과 관련된 다른 익스플로잇이 있습니까? 실제로 해커가 고통스럽지 않고 blog_charset을 변경할 이유가 있습니까? 나는 그들이 어떻게 들어 왔는지 결정하려고 노력했지만 이것이 어떻게 든 연결되어 있는지 궁금합니다.
답변:
<와 >같이 부호화 +ADw-및 +AD4-에서 UTF-7 . 이제 다음을 상상해보십시오.
누군가 +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-가 주석 텍스트로 보냅니다 . 이스케이프 처리되지 않은 모든 위생을 통과합니다.
데이터베이스는 들어오는 모든 데이터를 UTF-8로 예상하고 처리합니다. 모든 UTF-7 스트림도 유효한 UTF-8이므로 SQL 오류가 발생 mysql_real_escape하거나 htmlspecialchars건드리지 않습니다.
WordPress는 헤더를 보냅니다 text/html;charset=utf-7.
WordPress는 이스케이프 된 데이터를 예상하면서 주석을 표시합니다. 그러나 이것은 브라우저에서 UTF-7로 처리되므로 JavaScript가 실행됩니다.
예, 보안 문제입니다.
UTF-7은 모든 브라우저에서 지원되는 것은 아니며 대부분 텍스트를 Windows-1252 (또는 OS의 기본 인코딩) 또는 UTF-8로 렌더링합니다. 주요 문제는 탈출이 더 이상 작동하지 않는다는 것입니다.
인코딩 값을 다시 변경하는 것은 해결책이 아닙니다. 이 때문에 정기적 인 방문자는 그것을 절대 변하지 않을 수 있는 열린 문을 찾을 수 있습니다.
또한 필요할 수 있습니다 (테이블의 모든 인코딩을 다시 변환) : https : //.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation- UTF-8로