CSS/JS 문서 편집을 위한 별도의 사용자 권한 생성

Tracked in Phabricator:
Task T190015

문제점

관리자는 매우 위험한 권한을 보유합니다. 관리자는 Common.js와 같은 문서를 편집함으로써 수백만 명의 독자와 수천명의 편집자의 기기에서 코드를 실행시킬 수 있습니다. (인터페이스 편집자와 같은 비슷한 권한도 마찬가지입니다.) 이러한 점은 잘 알려진 반면, 이것이 얼마나 심각하게 악용될 수 있는지 이해하는 사람은 거의 없습니다.

• 악의적인 코드를 독자와 편집자가 실행하게끔 함으로써 기본적으로 어떤 일이든 할 수 있습니다. 비밀번호나 신용카드 번호를 피싱하거나, 기부금을 다른 곳으로 넘기거나, 익명 편집자의 신원을 유출하거나, 다른 편집자인 척 편집하거나, 악성 코드를 설치하게끔 하거나, 스팸을 보내거나, DDoS 공격을 주도하는 등…….
• 다른 위험한 권한(검사관 등)은 돈을 버는 데 악용될 수 없지만, 이 권한은 공격자에게 아주 짭짤한 돈벌이 수단이 될 수 있습니다. 최근에 저희는 이러한 권한을 오용해 방문자의 기기에서 암호화폐 채굴기를 돌리는 사람을 발견했습니다. 돈을 쉽게 벌려는 공격자라면 훨씬 악질적인 수단을 사용할 길도 열려 있습니다.
• 피해는 위키 하나에서만 그치지 않습니다. 위키미디어 위키는 통합 계정 시스템을 사용하므로, 한 위키에서의 공격이 다른 위키의 관리자 권한을 탈취하여 공격 범위를 넓히는 데에 사용될 수 있습니다.

따라서 변절한 관리자와 관리자 계정을 탈취한 공격자는 매우 심각한 위협이며, 이러한 위협을 줄이기 위한 행동이 요구됩니다. 관리자 계정이 주기적으로 탈취되는 마당에 지금껏 큰 일이 일어나지 않은 것은 작은 기적에 불과하며, 우리는 이 운에 의존해서는 안 됩니다.

동시에 위키미디어 공동체가 스스로 사이트를 가꿀 능력은 매우 중요하며 보존되어야 합니다. 편집자를 위한 소도구는 작업을 무척 수월하게 만들어 줍니다. 독자에게 적용되는 변경 사항은, 수백개의 위키에 존재하는 광범위한 문제와 사례에 대해, 중앙 집중식 개발 과정은 흉내낼 수조차 없는 유연한 대응을 가능하게 합니다. 바깥에서 도움을 구하는 대신 자주적으로 문제를 해결할 수 있다는 점은 위키 공동체의 권한 분산과 동기부여 측면에서도 매우 중요합니다. 각 위키의 CSS/JS 환경은 각 위키 공동체가 결정할 수 있어야 합니다.

해법

대부분의 관리자는 CSS나 자바스크립트를 편집하고 싶어하지 않거나 그럴 일이 없습니다. 먼저, 각 언어에 대한 지식이 필요한데, 대부분 관리자는 그렇지 못합니다. 이미 CSS나 JS 코드를 수정하는(혹은 앞으로 수정하고 싶어하는) 사람들의 작업이 방해를 받아서는 안 되지만, 그러한 권한을 쓰지도 않는 사람은 계정이 탈취당해도 위키가 피해를 받지 않게 하기 위해서라도 그러한 권한을 가져서는 안 됩니다. 또한 JS 편집자에 대해 관리자보다 더 엄격한 기준을 적용하고자 하는(일반적으로 현명한 일입니다) 공동체의 의사는 위키 소프트웨어에 의해 지원되어야 합니다.

이를 실현하기 위해서 ‘기술 관리자’ 사용자 권한이 도입되며, 이 권한을 가진 사용자만이 사이트 전체에 적용되는 CSS/JS 문서를 편집할 수 있게 됩니다. 기본값으로는, 기존 관리자 권한의 부여와 마찬가지로, 사무관과 사무장이 해당 권한을 부여할 수 있습니다. 새 기술 관리자 권한을 어떻게 부여할 것인가는 각 위키의 공동체(혹은 위키미디어 공동체가 전역 정책을 도입할 경우 위키미디어 공동체)에 맡겨져 있습니다.

이러한 해법에는 다음과 같은 여러 장점이 있습니다.

• 사이트 공격에 사용될 수 있는 계정의 수가 대폭 줄어듭니다. 공격에 사용될 계정이 적다는 것은, 다른 웹사이트의 비밀번호 데이터베이스가 유출되더라도 어떤 계정이 공격에 사용될 가능성이 낮음을 의미합니다. (또한 일반적인 관리자가 자신의 계정을 공격당할 걱정을 조금 덜 해도 된다는 말이기도 합니다.) 계정이 더 적으면 수상한 접속을 감시하기도 더 쉽습니다.
• 계정의 수를 떠나서, 가장 위험한 계정들을 공격 대상에서 제거할 것입니다. CSS/JS 문서를 편집할 수 있는 대부분의 사용자는 일반적으로 더 나은 IT 지식을 가지고 있고, 따라서 시스템이나 비밀번호의 보안에 더욱 신경을 씁니다.
• 향후에 일반적인 관리자에게 영향을 미치는 일 없이 (이중 인증 강제와 같은) 강력한 보안 조치를 적용할 수 있게 됩니다.

기술적인 상세 사항: 새 권한(editsitecss 및 editsitejs)이 미디어위키에 신설됩니다. 미디어위키 이름공간의 .css 또는 .js 문서를 편집하려면 editinterface 권한과 해당하는 editsiteXXX 권한이 필요합니다. 관리자 등 현재 editinterface 권한을 가진 사용자는 (걸리적거리는 일 없이 전환이 이루어질 수 있도록) 잠시 동안의 이행 기간 동안 새 권한을 부여받지만, 결국 권한이 회수되어 기술 관리자 외의 어떤 사용자도 권한을 보유하지 않게 됩니다.

여러분이 도울 수 있습니다

• 이 협의 절차가 종료되면, (대략 2주 정도의) 이행 기간 동안에는 기술 관리자 권한이 존재하지만 일반 관리자도 CSS/JS 문서를 편집할 수 있습니다. 이 기간 동안 CSS/JS 문서를 편집하는 사용자가 기술 관리자로 추가되도록 해 주시고, 누가 해당 권한을 얻을 지 정해 주세요. (이행 절차가 어떻게 될 지는 각 공동체에 맡겨져 있습니다. 해당 권한을 요청하는 관리자에게 권한을 부여하는 정도의 간단한 작업이 될 수도 있습니다.)
• 아울러 활동하고 계신 위키에, 이 권한에 대한 설명과 이행 기간 이후에 권한을 부여하는 절차가 마련되게끔 해 주시기 바랍니다. 다시 한 번 말씀드리자면, 그냥 신임 관리자에게 기술 관리자도 하고 싶은지, 그리고 자바스크립트에 대한 지식이나 기본적인 보안 습관을 갖고 있는지를 물어보는 것으로 끝낼 수도 있습니다. 어찌 되었든, 기술 관리자에게는 적어도 관리자 수준의 신뢰나 행동 양식, 또는 그 이상의 수준을 요구할 것이 권장됩니다(기술 관리자 사용자 권한 설명 문서를 참조하세요).
• 추가적인 특별한 권한을 필요로 하는 CSS/JS 편집 프로세스에 대해 알려주세요 (기술 관리자가 어떤 권한을 기본적으로 더 가져야 할 지 결정하는 데 도움이 됩니다). 예를 들어, 기술 관리자도 문서를 지워야 하나요? 아니면 콘텐츠 모델을 변경할 필요가 있나요?
• 더 나은 권한 이름을 추천해 주세요! ‘기술 관리자’는 별로에요. 고려해야 할 점은 다음과 같습니다. 권한 이름은 위키 외부의 소스 코드 개발자(미디어위키 개발자, 툴포지 도구 관리자 등)와 혼동되어서는 안 되고, 루아(모듈 이름공간) 개발자와도 혼동되어서는 안 되며, 특정 위키에는 ‘인터페이스 편집자’가 여전히 존재할 것입니다. 이상적으로는 이 권한은 적어도 관리자 수준의 신뢰가 요구된다는 것을 이름에 담아야 합니다.
• 이 문서에 적혀 있지 않은 문제를 알아차렸거나, 아니면 이 변경 사항을 더 유용하게 하거나 덜 귀찮게 할 만한 아이디어가 있다면 말해 주세요!

토론 문서에 의견을 남겨 주세요. 어떤 언어든 사용할 수 있습니다.

FAQ

누가 이 작업을 주도하나요?

이 문서와 해당하는 코드 변경은 User:Tgr이 (개인 자격으로) 준비했습니다. T190015와 wikitech-l의 토론을 바탕으로, 저는 이 문서가 미디어위키 개발자 공동체의 총의를 얻었다고 믿습니다.

이거 의견 요청인가요?

이 변경 사항이 공동체의 의향에 따라 결정될 사항인지를 따진다면, 아닙니다. 이것은 투표가 아닙니다. 소프트웨어 보안상의 결정은 편집자들의 총의가 아닌 미디어위키 개발자의 총의에 의해 결정됩니다. 최종 결정은 항상 그렇듯 코드 검토에서 이루어집니다. 그럼에도 불구하고 당신의 의견을 원합니다! 토론을 통해, 여기에서 제안된 것과 다른 방식을 취할 이유가 밝혀질 수도 있고, 중요한 세부 사항, 이를테면 새 사용자 권한이 어떤 작업을 더 할 수 있어야 하는지 등을 결정할 수도 있을 것입니다. 공동체가 소프트웨어 변경을 정책과 지침, 절차상의 변경으로 바꾸는 데 걸리는 시간을 줄여줄 수도 있습니다.

이거 최근에 터진 일에 대한 땜질 처방인가요?

아닙니다. 그 사건이 이 변경 사항의 중요성을 일깨우는 데에 도움이 되었으면 하기는 하지만, 이 아이디어는 몇 년간 의논되어 왔으며, 이 협의의 대상이 되는 변경 사항은 3월에 준비되었습니다.

이 변경 사항이 이뤄진다 쳐도, 여전히 관리자가 사이트 전체에 영향을 미치는 JS 파일을 배포할 방법이 있을 텐데요?

언젠가는 처리될 (어려운) 기술적 문제입니다. 어쨌든, 관리자에게서 JS 편집 권한을 빼고, 잘 알려지지 않은 적은 수의 사용자에게 부여하게 되면 공격 대상이 줄어들고, 남은 사용자를 추적하기 편하겠죠.

CSS는 왜 JS랑 똑같이 취급되나요?

CSS가 JS보다는 덜하긴 하지만 다음과 같은 이유로 여전히 위험합니다.

• 그림과 관련된 CSS 속성은 편집자의 익명성을 훼손하는 데에 사용될 수 있습니다.
• 일부 오래된 브라우저에서는 CSS를 통해 자바스크립트를 불러올 수 있습니다.
• CSS도 편집 토큰을 훔칠 수 있습니다(따라서 다른 사용자의 이름과 권한을 도용할 수 있죠). 다만 브라우저의 지원이 부실해서 아직까지는 제한적입니다.
• 피싱 공격을 준비하는 데에는 CSS에 기반한 클릭재킹이 사용될 수 있습니다.

데이터에 따르면 CSS를 편집하는 거의 모든 관리자는 JS파일도 편집하므로 두 권한을 따로 다룰 이유는 없습니다.

나중에, 안전하다고 판단된 CSS의 일부 속성을 편집할 권한이 재도입될 수 있습니다. TemplateStyles 프로젝트를 참조하세요.

이거 TemplateStyles .css 파일도 포함하나요?

아뇨, 미디어위키 이름공간의 CSS 문서만 영향을 받습니다. TemplateStyle CSS 문서는 위험한 작업을 실행할 수 없도록 자동적으로 검토됩니다.

자바스크립트가 처음부터 악의적인 일을 할 수 없도록 막는 건 어때요?

그러한 작업(CSP라든가, 편집에 대한 검토라든가)에도 장점이 있지만, 이것이 공격을 완전히 완벽하게 방어하지는 못합니다. 프로그램의 취약점을 사전 검토하는 것 자체가 불가능합니다. 그리고, 그러한 작업은 더 많은 시간과 노력을 필요로 합니다. 단기적인 관점에서, 자바스크립트를 편집할 수 있는 사용자의 수를 줄이는 것이 더 가능성 있는 전략입니다. 장기적으로는 그러한 작업도 병행할 수 있겠죠.

editusercss, edituserjs 권한은요?

(잘 알려져 있지 않고 잘 안 쓰이는) 그 권한들도 다른 사용자에게 영향을 미치는 CSS/JS 문서를 편집할 수 있게 합니다. 똑같이 다른 사용자의 계정을 탈취하는 데 사용될 수 있으므로, 동일한 제한이 적용됩니다. (장기적으로 T197087를 참조하세요)

editsitejson은요?

그건 미디어위키의 .json 문서를 편집하는 권한입니다. (봇이나 소도구의 설정을 위해 최근에 미디어위키가 별도로 인식하도록 변경되었습니다) w:JSON은 코드가 아니라 데이터이고, 따라서 이 권한의 편집은 위험한 것으로 간주되지 않으며 관리자들은 새 권한 없이 해당 문서를 편집할 수 있게 됩니다; 따라서 소도구는 .json 문서의 수정으로 악의적인 코드가 실행될 수 없게 작성되어야 합니다.