옆동네 보안문제ㄷㄷ 라이믹스도 세션위험한지 질문드립니다.

어쩌다 저런 문제덩어리를 xe 보다 많이 쓰게되었는지 한숨..

개발자가 아닌 일반인들은 문제덩어리냐 탄탄하냐, 구조적으로 잘 되어있냐 아니냐에는 관심없고, 겉보기... 즉 개발 의뢰하기 용이하냐, 보기 좋냐, 사용자가 많냐로만 판단하기 때문에 어쩔 수 없을 것 같습니다.

거의 그런셈으로 보이네요..

10년동안 알고잇는데 안고치는건... 이건 심각한건데.. 그누보드 사용자들이 그동안 모르거나 알아도 넘어가서 그냥 개발자들도 안건드린것 같네요 ㅡ,.ㅡ;

자기 세션만 볼 수 있으니까, 세션 탈취나 fixation 공격에 대한 원론적인 방어를 중요시하는 웹 보안 개론 수업에서는 크게 중요하지 않을 수도 있습니다. 그러나 그건 2000년대 초반 얘기고... 요즘은 캡챠, PG사 연동 정보, 소셜로그인 연동 키, 커뮤니티에서의 어뷰징 방지를 위한 다양한 기록, 어떤 관계로 엮인 다른 회원의 개인정보 등 사용자 본인에게도 노출되지 말아야 하는 정보를 세션에 많이 저장하곤 합니다.

어느 누구에게도 노출되지 않는다고 일반적으로 가정해 온 정보가 어느 누구에게라도 노출된다면 그것만으로도 신뢰를 깨뜨린 것이고, 이렇게 노출된 정보를 다른 공격에 활용할 수도 있기 때문에 요즘은 작은 것 하나라도 심각하게 받아들여야 합니다. 과거 XE나 최근의 라이믹스는 각 사이트의 재량에 따라 사용하는 비밀글이나 익명글 기능의 버그까지도 취약점으로 취급하여 신속하게 패치해 왔지요.

안타깝게도 대부분의 개발자들은 실제 현장에서 해당 정보가 어떻게 사용되고 악용되는지, 시대에 따라 보안에 대한 필요가 어떻게 바뀌고 있는지에 대한 고려보다는 여전히 2000년대 초반에 정립된 고전적인(?) 공격 패턴에 수동적으로 대응하는 데 그치는 것 같습니다. 세션 ID 안 털렸으니 됐다 이거죠. 요즘 세션 ID 털리는 사이트가 어딨나요? 개인정보 유출이나 스팸이 훨씬 더 큰 문제인데요.

90% 이상의 유저들이 방화벽이 따로 없는 일반 웹호스팅 환경에서 사용한다는 것을 알고 있을 텐데, 책임감있는 개발자라면 최소한 해당 디렉토리 접근을 막기 위한 .htaccess 규칙이라도 넣어주는 것이 맞지요. 그 사이 메이저 버전 변경까지 있었는데도 수정할 기회로 삼지 않고 서버 세팅에 떠넘기는 것은 책임 회피에 불과합니다.

RXE의 방식에도 문제가 있다면 게시판에서 FUD를 퍼뜨리지 말고 devops@rhymix.org로 제보 부탁드립니다. 모든 상황을 지원해야 하지만, 최대한 현실적인 상황을 고려해서 대응할 것입니다. 위와 같이 쉴드쳐주는 의견 때문에 개발자들은 안일해지고, 이 생태계 전반에 대한 신뢰도가 추락합니다.

이게 소프트웨어의 취약점일지는 모르겠네요.
기본 세션 폴더를 사용하면 두가지 위험성이 존재합니다.

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 등)을 사용하는 경우에 대비하여, 설치 경로의 해쉬값을 캐시 키에 붙여서 서로 충돌하지 않도록, 그리고 다른 사이트의 캐시 키를 추측하기 어렵도록 하고 있거든요. 동일한 로직에 해쉬 알고리즘을 좀더 개선해서 세션에도 적용할 수 있겠습니다. 알려주셔서 감사합니다.^^