proc 로 시작되는 act의 모든 post 요청을 별도의 명시적 허용없이 전부 막아버려면, 확실하게 처리가 가능하겠지만, 기존에 제작한 3rd party 모듈들과 상당한 충돌이 일어날것 같아요. 코노리님이 이야기 해 주신것처럼 당장 코어의 다운로드 부분과 알림센터에서 부터 문제가 발생하고 있죠.

 

core 의 모든 proc에 checkCSRF 함수를 도배하여 POST를 체크하는 방법으로도 가능하지 않을까요? 호환성 면에서는 더 나을것 같아서요.

  • profile

    checkCSRF 함수는 리퍼러가 같은 도메인 소속인지 체크하는 기능입니다.

    이번처럼 게시판에서 링크를 걸어버리면 리퍼러가 같은 도메인으로 들어가기 때문에
    checkCSRF 함수로는 막을 수 없을 것 같은데요...

  • profile ?

    checkCSRF함수가 POST인지도 체크하고 있는것으로 알고있어요.
    https://github.com/xpressengine/xe-core/blob/master/config/func.inc.php#L1559

  • ? profile

    아, 그 부분을 활용하자는 말씀이었군요. 저는 그 아랫부분을 생각하고 있었어요.

    그래도 이번 취약점은 모든 모듈의 관리자전용 기능에 영향을 미치는 것이라
    코어뿐 아니라 서드파티 모듈도 안전하지 않거든요.
    모든 모듈에서 일일이 checkCSRF 함수를 호출해야 한다면
    너무 많은 서드파티 모듈들이 위험에 노출될 것 같아요.

  • profile
    보안 옵션을 만들어두면 좋겠군요.

    보안옵션 활성화하면 보안이 지켜지만, 서드파티 일부기능이 작동되지않을 수 있다는 경고와 함께 말이죠.
  • profile profile

    옵션으로 처리하기엔 너무 심각한 문제 같습니다. XE 역사상 최악의 보안취약점 몇순위에 들지도 모르는데...

     

    작년의 드루팔 SQL injection 사건이 생각나네요.

    패치 공개 8시간만에 실제 해킹이 일어났었죠 ㅎㄷㄷㄷ

  • profile profile

    일단, ajkj님 말씀대로 모든 proc에 checkCSRF 함수를 도배하구요.

    보안 옵션을 넣어서... 서드파티 보안도 지켜주자는 겁니다. 사용자의 선택에 맡겨서...
    (서드파티 일부기능이 작동되지않을 수 있다는 경고와 함께하는 보안 옵션..)

  • profile profile
    모듈마다 사용 여부를 선택할 수 있도록 해준다면 괜찮을지도 모르겠네요.

    알림센터에 메시지 하나쯤 지워진다고 하늘이 무너지는 건 아니니까요...
  • ?
    제가 만든것도 대다수 먹통될것 같은 느낌이군요.. 저는 exec_xml() 함수를 많이 사용했는데..
  • ? profile
    자칫하면 또다시 호환성 대란이 발생할 수 있겠네요 ㅠㅠ

    더 무서운 건, 호환성 때문에 업데이트를 안 하는 사람도 많을 거라는 사실....
  • profile
    큰문제네요. 여러모듈을 제작해서 사용하는 사이트의 경우 사이트의 많은 기능이 마비되는 사태가 벌어질수도 있겠습니다.
  • ?
    XE1 이 유지/보수 단계로 가는 만큼(개인적인 추측입니다) 코어팀에서 3rd party 호환성문제를 신경써 주었으면 좋겠습니다.
    잘못하면 호환성 대란이 일어 날 수 있을것 같아요.
  • profile

    호완성 때문에 큰일 군요. 보안이 더 큰 문제지만...

    일단, ajkj님 말씀대로 모든 proc에 checkCSRF 함수를 도배하구요.

    보안 옵션을 넣어서... 서드파티 보안도 지켜주자는 겁니다. 사용자의 선택에 맡겨서...
    (서드파티 일부기능이 작동되지않을 수 있다는 경고와 함께하는 보안 옵션..)

  • profile

    그나저나, checkCSRF() 이 함수, 기본 도메인이 없으면 무조건 FALSE를 리턴 하던데요..

  • profile profile
    기본 도메인도 XE의 골칫덩이 중 하나죠. 없으면 그냥 현재 도메인을 기본 도메인으로 취급해 주면 안되는지...
  • profile profile
    리퍼러과 비교할 도메인이 있어야 한다는 것을 이해하지만...
  • profile profile
    맞아요 극혐입니다 ㅜㅜ
  • profile
    https://xetown.com/index.php?mid=lakepark&category=5779&document_srl=14977

    예전 NuriCMS였다면 이런 큰 문제는 없었을텐데 말이죠... 제가 젤 처음에 한게 act 관리 였으니...
  • profile profile
    그러게요 ㅠㅠ

    어차피 하위호환성을 다소 깨뜨릴 각오로 패치하는 거라면 최대한 간단하게, 그래서 실수의 여지가 적게 코딩하면 얼마나 좋을까요... 애초에 중구난방으로 설계한 것을 그대로 끌고 가면서 자꾸 패치하려다 보니 코드는 점점 복잡해지기만 하고, 언젠가 똑같은 부분에서 또다른 취약점이 나타나도 이상하지 않을 것 같아요.