| PHP | PHP 7.0 |
|---|---|
| CMS | Rhymix 2.0 |
그누보드 사이트인 sir 보다가 최근글에 보안문제글이 올라와서 알게 되었는데요
php는 다른언어와 달리 요청처리하고 재시작하니까
상태저장이 안되서 세션을 파일이나 DB에 저장하는데
그누보드쪽은 세션 폴더가 그대로 노출되서
어느그누보드사이트주소/data/session/sess_02h3ovo0vottmbd97s51dbb5ob <- 이건 쿠키의 PHPSESSID(PHP세션쿠키)
이런식으로 접근하면 세션이 다운받아지게되서 세션에 주요정보가 전부 노출되는 위험이 있는데
라이믹스도 PHP 라서 걱정되는데
라이믹스도 이러한 문제가 있을까요??
?
어쩌다 저런 문제덩어리를 xe 보다 많이 쓰게되었는지 한숨..
개발자가 아닌 일반인들은 문제덩어리냐 탄탄하냐, 구조적으로 잘 되어있냐 아니냐에는 관심없고, 겉보기... 즉 개발 의뢰하기 용이하냐, 보기 좋냐, 사용자가 많냐로만 판단하기 때문에 어쩔 수 없을 것 같습니다.
?
저건 PHP의 문제가 아니라 그냥 코딩을 잘못 한 거죠. PHP에서 나름 안전한 기본값을 제공하는데도 무시하고 세션 저장소를 멋대로 바꾸는 바람에 실제로 서버 세팅할 때도 그누보드는 많은 짜증을 유발합니다. 그렇다고 소스를 수정해서 쓰자니 나중에 더 큰 보안취약점을 패치하기 어려워질 위험이 있고요.
물론 20년이 다 되어 가는 오래된 프로그램인 만큼 오래 전 별 생각 없이 만들었던 기능들이 뒤늦게 문제를 일으킬 수 있는 것은 이해가 됩니다. 라이믹스도 10년 넘은 취약점을 얼마 전 몇 가지 패치했지요. 문제는 보안취약점이 제보된 지 두 달이 다 되어서 알 사람은 다 아는데도 개발팀으로부터 별다른 반응이 없다는 것입니다. 남의 세션이 아니라 자기 세션을 엿보는 거니까 별 것 아니라고 여길지도 모르고, 그거 접근 못 하도록 차단하는 일은 서버 담당자가 해야 하는 거 아님? 이라고 책임을 떠넘기려는 생각인지도 모릅니다. 어떤 경우든지 옆동네에 X로 시작하는 다른 CMS와 별 차이 없는 상황인 것 같습니다.
거의 그런셈으로 보이네요..
10년동안 알고잇는데 안고치는건... 이건 심각한건데.. 그누보드 사용자들이 그동안 모르거나 알아도 넘어가서 그냥 개발자들도 안건드린것 같네요 ㅡ,.ㅡ;
자기 세션만 볼 수 있으니까, 세션 탈취나 fixation 공격에 대한 원론적인 방어를 중요시하는 웹 보안 개론 수업에서는 크게 중요하지 않을 수도 있습니다. 그러나 그건 2000년대 초반 얘기고... 요즘은 캡챠, PG사 연동 정보, 소셜로그인 연동 키, 커뮤니티에서의 어뷰징 방지를 위한 다양한 기록, 어떤 관계로 엮인 다른 회원의 개인정보 등 사용자 본인에게도 노출되지 말아야 하는 정보를 세션에 많이 저장하곤 합니다.
어느 누구에게도 노출되지 않는다고 일반적으로 가정해 온 정보가 어느 누구에게라도 노출된다면 그것만으로도 신뢰를 깨뜨린 것이고, 이렇게 노출된 정보를 다른 공격에 활용할 수도 있기 때문에 요즘은 작은 것 하나라도 심각하게 받아들여야 합니다. 과거 XE나 최근의 라이믹스는 각 사이트의 재량에 따라 사용하는 비밀글이나 익명글 기능의 버그까지도 취약점으로 취급하여 신속하게 패치해 왔지요.
안타깝게도 대부분의 개발자들은 실제 현장에서 해당 정보가 어떻게 사용되고 악용되는지, 시대에 따라 보안에 대한 필요가 어떻게 바뀌고 있는지에 대한 고려보다는 여전히 2000년대 초반에 정립된 고전적인(?) 공격 패턴에 수동적으로 대응하는 데 그치는 것 같습니다. 세션 ID 안 털렸으니 됐다 이거죠. 요즘 세션 ID 털리는 사이트가 어딨나요? 개인정보 유출이나 스팸이 훨씬 더 큰 문제인데요.
90% 이상의 유저들이 방화벽이 따로 없는 일반 웹호스팅 환경에서 사용한다는 것을 알고 있을 텐데, 책임감있는 개발자라면 최소한 해당 디렉토리 접근을 막기 위한 .htaccess 규칙이라도 넣어주는 것이 맞지요. 그 사이 메이저 버전 변경까지 있었는데도 수정할 기회로 삼지 않고 서버 세팅에 떠넘기는 것은 책임 회피에 불과합니다.
RXE의 방식에도 문제가 있다면 게시판에서 FUD를 퍼뜨리지 말고 [email protected]로 제보 부탁드립니다. 모든 상황을 지원해야 하지만, 최대한 현실적인 상황을 고려해서 대응할 것입니다. 위와 같이 쉴드쳐주는 의견 때문에 개발자들은 안일해지고, 이 생태계 전반에 대한 신뢰도가 추락합니다.
이게 소프트웨어의 취약점일지는 모르겠네요.
기본 세션 폴더를 사용하면 두가지 위험성이 존재합니다.
1) 세션 공유
동일한 세션폴더를 사용하는 두 사이트에서, 공격하고자 하는 A사이트에서 세션을 굽고, 그 세션 ID를 B사이트에 입력하면 그대로 사용가능합니다.
$_SESSION['id'] = 'admin'; 같은 코드로 확인해보세요.
2) 성능 이슈
파일세션은 성능이슈가 있습니다.
하나의 사이트에서 세션 100만개 만들면, 거기 연결된 모든사이트의 session_start()가 느려집니다.
가끔 php 솔루션들을 보면은 gnuboard처럼 처리하는 것들이 있어요. 다만 outside of webroot 에 설정하라고 가이드되어 있겠지만, 호스팅 사용자 수준에서는 구성이 어려울겁니다.
그누는 그냥 General Purpose를 위해서 web accessable session folder 로 구현한 것 같습니다.
그누의 방식은 위의 2가지 취약점이 발생하지 않습니다.
Best Practice 는 Laravel 처럼 구성하는 것입니다.
호스팅을 사용한다고 가정하면 1) 2) 모두 CMS 차원에서 신경쓸 문제는 아닙니다. 고객 계정마다 경로와 권한을 분리하는 것은 너무나 명백하게 호스팅 업체의 역할이고, 제대로 분리할 경우 세션 폴더의 성능을 신경써야 할 만큼 각 계정의 접속자가 많지도 않으며, 만약 문제가 발생하더라도 호스팅 업체에서 간단하게 해결할 수 있으니까요.
호스팅을 사용하지 않고 독립적으로 서버를 운영한다면 1)의 중요성은 크게 낮아지고, 문제가 된다 해도 서버 관리자가 쉽게 해결할 수 있습니다. 2)는 다른 세션 핸들러를 설치하는 것으로 해소됩니다.
그누보드는 세션 저장 경로를 하드코딩해 놓아서 오히려 1) 2) 문제를 푸는 데 방해가 됩니다. php.ini에서 별도의 세션 경로를 지정하거나, memcache, redis 등 성능이 좋은 세션 핸들러를 사용하려고 해도 그누보드가 자기만의 경로를 고집하는 바람에 먹히지가 않습니다. 차라리 기본값 그대로 두었다면 호스팅 업체 or 서버 관리자가 보안면에서나 성능면에서 적절한 선택을 할 수 있을 텐데, 그누보드는 실제 책임자가 자신의 역할을 하는 것마저 적극적으로 방해하면서 최악의 선택을 고집하고 있는 셈입니다. 그래 놓고 서버 관리자의 책임이라고 떠넘긴다면 앞뒤가 맞지 않겠지요.
만약 정말로 위의 2가지 문제를 신경쓰다가 web accessible session folder라는 해결책이 나온 것이라면, 기업 인프라와 기업 IT 문화에 익숙한 개발자가 흔히 그누보드를 사용하는 중소규모 사이트들의 운영 환경을 이해하지 못한 채 설계한 결과라고 보여집니다. 한국 시장에서는 흔한 일이긴 하죠...
1번 이슈는 라이믹스에서 어느 정도 대응할 수 있을 것 같습니다. 같은 서버에서 여러 사이트가 동일한 캐시 방식(memcached 등)을 사용하는 경우에 대비하여, 설치 경로의 해쉬값을 캐시 키에 붙여서 서로 충돌하지 않도록, 그리고 다른 사이트의 캐시 키를 추측하기 어렵도록 하고 있거든요. 동일한 로직에 해쉬 알고리즘을 좀더 개선해서 세션에도 적용할 수 있겠습니다. 알려주셔서 감사합니다.^^
https://github.com/gnuboard/gnuboard5/blob/05035d6f6cb3a0175cd4f30abc62f1f6cf965cec/config.php#L116
https://github.com/gnuboard/gnuboard5/blob/ecd2b1c72abd02ac296435855a41c1de346e2ade/common.php#L211
세션 데이터를 불필요하게 웹에서 접근 가능한 경로로 설정하는 그누보드의 문제일 뿐 PHP의 문제가 아닙니다. 라이믹스는 굳이 세션정보 저장 경로를 변경한게 아닌 이상 영향받지 않습니다.