완전히 비공개인 포럼(익명 접근 불가)의 경우, 기본 로컬 저장소 구성에 보안이 강화된 미디어 옵션이 없다는 것은 나에게 큰 실수로 보입니다. 비공개 포럼을 운영하는 많은 사람들이 자신의 게시글 첨부 파일이 모두 공개적으로 접근 가능하다는 사실(URL를 알면)을 인지하지 못하고 있을 것이라고 놀라지 않을 것입니다. 내 게시글의 텍스트가 익명으로 접근할 수 없다면, 직관적으로 첨부 파일도 익명으로 접근할 수 없을 것이라고 생각할 것입니다.
이러한 요청에 대한 지지를 확인해 보기 위해 이슈를 제출하는 것이 가치가 있을까요? 이미 존재하는 이슈가 있나요? 이 문제는 이미 자체 호스팅 하드웨어를 소유하고 있으며, 클라우드 저장소(특히 AWS S3 가격)에 비용을 지불하고 싶지 않은 우리처럼 작고 가난한 그룹에게 현재 치명적인 장애 요인입니다. 왜냐하면 미디어가 익명으로 열람되지 않도록 보장하기 위해 그렇게 해야 하기 때문입니다.
또한, 이 질문의 순진함이 용서되기를 바랍니다. 하지만 업로드와 백업을 위한 개별 버킷에 대한 지원이 이미 존재하나요? 보안 업로드를 위한 세 번째 버킷을 지원하는 것이 어려운 일일까요? 공개 업로드는 공개 버킷에, 보안 업로드는 보안 버킷에 저장되고, 개별 객체 ACL은 필요하지 않습니다. 그리고 객체의 보안 상태가 변경되면 버킷 간에 이동시키면 되지 않을까요?
게시글 본문은 보호되는데 첨부파일은 보호되지 않는다는 점이 이상하다고 생각하는 게 미친 짓은 아니지 않나요?
하지만 의도적인 공유와 우발적인 공유 사이에는 큰 차이가 있습니다. 당연히 전자를 막을 실질적인 방법은 없습니다. 하지만 후자는 현재 사람들이 기반 기술에 대해 이해하지 못하기 때문에 쉽게 발생할 수 있습니다. 예를 들어 첨부 이미지가 포함된 게시글의 이메일 알림이 비회원에게 무심코 전달되는 경우가 그렇습니다. 보안 미디어 기능과 분리된 이메일 내 첨부파일 비공개(마스킹) 옵션이 좋은 대안이 될 수 있을 것입니다.
사람들이 의도적으로 첨부파일 링크를 공유하더라도, 그것이 보호된 카테고리에서 온 것임을 단순히 잊었을 수 있습니다. 이상적인 상황에서는 해당 카테고리에 접근 권한이 없는 사람에게 첨부파일 링크는 무용지물이 되어야 합니다.
또한 S3 구현체 중 하나에 현재 또는 향후 버그가 있을 경우, 버킷 내 리소스의 익명 열거나 객체 URL의 추측 및 무차별 대입 공격이 가능해질 수도 있습니다. 이상적인 상황에서는 온프레미스 S3 인터페이스가 인터넷 전체와 방화벽으로 격리되어, Discourse 서버만 직접 접근할 수 있기를 원합니다.
로그인이 필요한 사이트에서 업로드를 안전하게 처리할 수 있는 간단한 해킹 방법을 하나 알게 되었습니다.
기본적으로 업로드를 위해 Authentication Based on Subrequest Result | NGINX Documentation 를 설정하면 됩니다. 유일한 문제는 로그인 요구가 활성화되어 있을 때 403/401을 반환하는 URL을 찾을 수 없다는 점입니다. 그래서 로그인하지 않은 상태에서 업로드에 접근하면 500 에러가 발생합니다. 이는 누군가 업로드 URL을 가지고 있고 로그인하지 않은 상태에서 접근을 시도할 때만 발생하는 일이므로, 그렇게 심각한 문제는 아닌 것 같습니다.
대략 다음과 같은 구조입니다:
# JP
location = /auth {
internal;
proxy_pass http://discourse/categories;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
# END JP
location ~ ^/uploads/ {
auth_request /auth; #$JP
# 참고: 헤더를 최상위 레벨에서 정의하여 상속할 수 없다는 점이 정말 번거롭습니다.
#
보안 업로드를 위한 별도의 버킷 기능을 구현할 계획이 없으며, S3가 아닌 환경이나 ACL이 없는 환경에서 보안 업로드를 작동하도록 할 계획도 없습니다. 향후 이러한 작업에 대한 충분한 수요가 발생하여 시간과 자원을 투입하는 것이 합리적이라고 판단될 경우, 해당 작업을 검토할 수 있습니다.
CDN URL을 올바르게 입력했는데도 불구하고, https://forum.cdn.hashhackers.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc
대신에 왜 https://hashhackersforum.s3.us-east-2.amazonaws.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc
을 사용하고 있나요?
아… 또 보안 업로드를 해야 할 이유가 없는 곳에서 그렇게 하고 있네요. 배지는 아바타, 카테고리 로고, 기타 항목과 기본적으로 공개된 이미지이므로 보안으로 표시되어서는 안 됩니다. 배지 이미지가 보안으로 표시되지 않도록 수정하고, 이미 보안으로 설정된 항목을 수정하는 마이그레이션 스크립트가 필요합니다.
이 기능이 아예 동작하지 않았을 줄 알았는데, 2.8.0에서 이 부분에 영향을 줄 만한 내용은 아무것도 없었어야 합니다.
답변해 주셔서 감사합니다. Ruby를 처음 사용해 보는데, 이 언어가 얼마나 명확할 수 있는지 정말 놀랐습니다. 몇 시간 동안 디버깅을 해 본 결과, 어디를 봐야 할지 찾은 것 같습니다. 말씀하신 것과 정반대로 한 것 같습니다 Badge 모델에 몇 줄을 추가했고, 이제 이미지 로딩이 됩니다. 또한 for_site_setting이라는 플래그가 있다는 것도 확인했습니다. S3의 객체에 대한 ACL을 조정하기 위해 이 정보를 기반으로 한다고 생각하며, 해당 컬럼에 false를 설정했습니다.
app/models/badge.rb
def image_url
if image_upload_id.present?
return upload_cdn_path(image_upload.url) if !image_upload.url.include?(SiteSetting.Upload.absolute_base_url)
uri = URI.parse(image_upload.url)
Rails.application.routes.url_for(
controller: "uploads",
action: "show_secure",
path: uri.path[1..-1],
only_path: true
)
end
end
다음 업그레이드에서 무엇이 변경되는지 확인하여 더 자세히 알아보겠습니다.
프로덕션 환경에서 사용해야 할 최적의 버전을 알려 주실 수 있나요?
Badge 모델에 몇 줄을 추가했고, 이제 이미지 로딩이 됩니다. 또한 for_site_setting이라는 플래그가 있다는 것도 확인했습니다. S3의 객체에 대한 ACL을 조정하기 위해 이 정보를 기반으로 한다고 생각하며, 해당 컬럼에 false를 설정했습니다.