일단 테스트는 해보지 않았지만,
글삭제나 댓글삭제라든지 충분히 응용하여 공격할 수 있습니다.
물론, 권한이 없는 사용자의 경우 삭제가 되지 않겠지만,
권한이 있는 사용자라면?! 글을 읽는 순간 다른 글이 삭제될 수도 있는 거겠죠..! (테스트는 해보지 않음)
그 외에도 회원탈퇴의 경우 이전 페이지 확인(?)등의 절차가 있다면 문제가 없을 것이고...
아무튼, 권한 사용자가 게시글이나 댓글을 보는 순간 특정 act가 실행될 수 있는 것은 매우 심각한 이슈인 것 같습니다.
무섭네요 덜덜덜
그렇군요..-_-;;
근데 문서추천을 보면
if(!Context::get('is_logged')) return new Object(-1, 'msg_invalid_request');
$document_srl = Context::get('target_srl');
if(!$document_srl) return new Object(-1, 'msg_invalid_request');
$oDocumentModel = getModel('document');
$oDocument = $oDocumentModel->getDocument($document_srl, false, false);
$module_srl = $oDocument->get('module_srl');
if(!$module_srl) return new Object(-1, 'msg_invalid_request');
$oModuleModel = getModel('module');
$document_config = $oModuleModel->getModulePartConfig('document',$module_srl);
if($document_config->use_vote_up=='N') return new Object(-1, 'msg_invalid_request');
$point = 1;
$output = $this->updateVotedCount($document_srl, $point);
$this->add('voted_count', $output->get('voted_count'));
return $output;
이렇게 되어 있던데, Context::get()이 post로 받는 부분인가요 ?
ModuleHandler.class.php 382줄
if($type == 'controller')
{
$allowedMethod = $xml_info->action->{$this->act}->method;
if(!$allowedMethod)
{
$allowedMethodList[0] = 'POST';
}
else
{
$allowedMethodList = explode('|', strtoupper($allowedMethod));
}
if(!in_array(strtoupper($_SERVER['REQUEST_METHOD']), $allowedMethodList))
{
$this->error = "msg_invalid_request";
$oMessageObject = ModuleHandler::getModuleInstance('message', $display_mode);
$oMessageObject->setError(-1);
$oMessageObject->setMessage($this->error);
$oMessageObject->dispMessage();
return $oMessageObject;
}
}
controller 타입에 대해서 제한한다는 코드가 있는데요?
콘노리님 댓글처럼 proc으로 시작하는 act는 POST 방식을 강제하고 있으므로 당장 게시글 삭제 등의 심각한 문제가 발생할 가능성은 낮다고 보이지만, 실제로 이 제한이 완벽하게 작동하고 있는지는 별개의 문제입니다. 자세히 살펴봐야겠네요. (음, 역시 admin 예외가 관건이군요 ㅠㅠ)
그러나 만약 XE에 종종 발생하는 XSS 취약점을 기반으로 또다른 공격을 쌓아올린다면 POST 방식의 요청을 위조하는 것도 불가능하지는 않습니다. 각각은 큰 문제가 되지 않는 취약점도 2가지 이상이 겹치면 심각해질 수 있어요. 따라서 일단 XSS 취약점이 존재하는 버전의 XE는 모두 위험하다고 볼 수 있겠습니다. (최신버전을 제외한 거의 모든 버전 ㅠㅠ)
또한 이렇게 같은 사이트내에서 공격을 한다면 현재 XE에서 사용하는 checkCSRF() 함수도 무용지물이 되어버립니다. XE는 리퍼러 헤더를 통해 CSRF를 막고 있는데, 같은 사이트내에서는 항상 리퍼러 체크를 통과하니까요.
정정합니다. YJSoft님 말씀이 맞습니다. 코어의 버그 때문에... 굳이 다른 취약점과 조합하지 않더라도 지금 상태 그대로 치명적입니다.
@misol님께서 추천만 주고 가셨당..?!
지금 이 글을 읽으신 분들 다 추천이 되는데,(초반에 코드가 잘못 입력되어서 변경했는데..)
제가 작성한 추천 코드가 먹히는 건가요?! 덜덜 아니면 다 추천해주신건가..
이..이것은... 추천포인트 얻는 글..?.ㅋㅋ (참고로 코드 먹힘)
