응애 뉴비 게시글 작성 구현 질문

코딩 채널

알림 알림 중 알림 취소

구독자 4408명 알림수신 85명 @은월영

프로그래밍 및 코딩 채널

질문 응애 뉴비 게시글 작성 구현 질문

밀레니엄퀘스트

추천 0 비추천 0 댓글 23 조회수 299 작성일 2024-05-31 04:15:31 수정일 2024-05-31 04:16:25

⚠️ 이 게시물은 작성자가 삭제할 수 없도록 설정되어 있습니다.

https://arca.live/b/programmer/107590968

아카같은 게시글 작성 기능 개발중에 문제가 생겼어.

게시글 작성에서 삽입한 이미지 URL을 받아오는 거 까지는 성공했는데,

이 URL을 어떻게 서버에 저장할지 모르겠어.

이미지 URL을 바로 서버로 보내려니 사이즈가 너무 크고,

클라이언트에서 DB에 저장하려니 보안 문제가 생길 거 같아서 보류

지금은 Blob을 이용해서 문제를 해결해 보려고 하는 중이야

더 좋은 방법이나 팁이 있으면 알려줘잉

사용중인 에디터는 Quill이고 URL은 아래처럼 받아왔어

[ { "insert": { "image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCA=} } ]

댓글 [23] 글쓰기

MiA

2024-05-31 04:28:34 답글

*수정됨

1. db에 블롭으로 바이너리를 그대로 밀어넣는다
2. 이미지를 base64 같은 걸로 인코딩해서 조오오온나 긴 문자열로 저장한다. 
3. 서버에 파일 전송 기능과 파일시스템 관련 로직을 구현한다.


2가 제일 편하고, 퀼 기본값이 2일걸?
다만 이 방법은 클라이언트 사이드에서 이미지를 인코딩/디코딩 할 경우 XSS가 가능하긴 해.

펼쳐보기▼

밀레니엄퀘스트

2024-05-31 04:32:11 답글

perl

2024-05-31 06:17:57 답글

data uri 때문에 xss가 터지는 문제가 있음?
img src나 onload같은데 이상한거 쑤셔넣어서 문제 생기는건 흔한데 그건 data uri의 문제 이전에 에디터에서 마크업 정보를 올리는 방식 자체의 문제니까 data uri의 문제라고 하기엔 좀 그렇고
이런건 많이 안만져봐서 떠오르는 방법이 없네

펼쳐보기▼

밀레니엄퀘스트

2024-05-31 06:30:41 답글

내 경우엔 그냥 "payload가 준내 커서 못 보내준다"라고 뜨네

data uri랑 xss 부분은 내가 알못이라 답하기 힘듬

펼쳐보기▼

perl

2024-05-31 06:33:26 답글

보통 별도로 설정 안하면 419가 뜨는데 이건 base64때문에 사이즈가 늘어난걸 제외하더라도 그냥 이미지가 조금만 고화질이 돼버리면 터질 수 있는 문제라 서버 설정도 만져줘야되긴 함

펼쳐보기▼

밀레니엄퀘스트

2024-05-31 06:42:52 답글

이런 방법이 있었네 ㄳㄳ
방금 서버 limit 늘려서 해결했음

펼쳐보기▼

MiA

2024-05-31 11:51:54 답글

*수정됨

임베드 태그에 src 어트리뷰트로 data uri를 허용하면 script 태그를 새니타이징 해도 XSS가 가능하긴 할 걸? 해본적은 없긴 한데

펼쳐보기▼

perl

2024-05-31 16:01:42 답글

이미지를 상정하고 blob을 다룰텐데 브라우저가 사용하는 이미지 라이브러리(아니면 해석 모듈? 이름은 잘 모름)에서 img src를 보고 스크립트를 돌리진 않을 것 같은데

펼쳐보기▼

MiA

2024-06-01 01:42:54 답글

*수정됨

img태그 자체에서 실행 가능하다는 게 아니라 새니타이저가 data uri 자체를 막게 하지 않으면, datauri는 새니타이저의 입장에서 블랙박스가 되기 때문에 특별한 이유가 없으면 datauri를 막아두는 편이 안전하다는 이야기를 좀 잘못 전달한 것 같다. 
결론부터 말하면 탬플릿 엔진이 반드시 src 어트리뷰트에만 data uri가 들어갈 수 있도록 처리하면, img src어트리뷰트에는 알려진 xss 취약점은 없을 거임. 원하는 바이너리를 전달할 수 있으니 xss 이외의 취약점은 있을 수 있지만.


img태그는 src안에 있는 정보를 프리컴파일, 프리렌더링 하니까 img태그를 이용한 xss는 이스케이핑을 이용해서 onerror 속성을 주는 등의 방식을 써야 xss가 되는 거 맞아.  그런데 알다시피 자바스크립트는 위의 img태그 내의 src어트리뷰트 같은 프리컴파일, 프리렌더링이 필요한 일부 경우를 제외하면 주어진 리터럴이 문서의 구조 자체를 변조할 수 있는 방식으로 작동함.

서버사이드에서 인코딩하는 게 아니라 클라이언트 사이드에서 인코딩 된 데이터를 페이로드에 올려서 들어 오는 거라면 해당 데이터를 사용해서 페이지를 돌려 줄 때 결과물에 어떤 코드가 주입 될지 예측하기 어려워서, 페이지 요청에 대한 response에 sanitizer를 돌려 주는 방법이 제일 안전한데, 여기서 data URI가 허용되면 sanitizier가 base64를 디코딩해서 체크해보고 지워주진 않거든.


<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgiWFNTIik7PC9zY3JpcHQ+Cg=="> 이렇게 object나 ifram같은 태그는 실제로 디코드 된 리터럴을 그대로 인터프리터가 순차적으로 읽기 때문에 스크립트 태그를 인코딩해서 넣으면 실행도 되고, 새니타이저도 인식 못 해서, 사용자 입력이 인터프리터 상 리터럴로 작동할 수 있는 모든 경우에 취약점이 될 수 있어

펼쳐보기▼

perl

2024-06-01 01:46:59 답글

그건 script object 이런걸 막는게 맞지
보통은 아예 사용 가능한 태그랑 attribute 자체를 화이트리스팅하는 경우가 더 많은걸로 알고있음

data uri 자체를 막아버리면 브라우저에서 지원하는 contenteditable로 구현한 대다수의 웹 에디터들은 외부 이미지 복사해서 그냥 갖다붙여버리면 paste 이벤트 처리해서 업로드하는 노가다로 처리하지 않으면 전부 이미지를 data uri로 꽂아버리는데 이것도 문제고

문제의 근본적인 원인은 뭔가 실행을 시킨다는것이니 자스 코드가 실행될 것 같은 부분을 막아야지 문제가 있는 벡터를 막게되면 계속해서 다른 패턴으로 들어올거라 근본적인 해결책이 되긴 어려울거임

펼쳐보기▼

MiA

2024-06-01 01:47:26 답글

*수정됨

그 object script를 막는 게  브라우저 자바스크립트 엔진이 아니라 새니타이저인데, 
dataUri는 새니타이저를 우회한다는 이야기야 실제로 data:를 새니타이징 하는 경우도 많이 있어

서버 입장에서는 새니타이징을 하고 나서 response를 돌려주면, 그 뒤에 돌려준 페이지를 브라우저가 어떻게 사용할지에 대해서 아무 것도 할 수 없으니까.

펼쳐보기▼

perl

2024-06-01 01:49:42 답글

*수정됨

그걸 할 수도 있지만 근본적으로는 object나 script, 그리고 on~ 계열등의 attribute들만 막으면 data uri를 굳이 막을 이유가 없음

내가 말하고 싶은건 비유하자면 저 화이트리스팅을 통해서 압축 해제 방법(위험한 태그나 attr)을 막아버리면 압축 파일(data uri)에 바이러스가 들어있어도 실제로 까서 실행할 방법이 없으니 괜찮다는 소리임

펼쳐보기▼

MiA

2024-06-01 01:49:55 답글

data uri를 쓰지말란 소리가 아냐. data uri를 새니타이징 하지 않는 게 취약점이 될 수 있냐는 질문에 대한 원론적인 대답일 뿐이지. 
실제로 data uri 자체는 널리 쓰이고 있는데 뭐 ㅋㅋ

펼쳐보기▼

perl

2024-06-01 01:50:26 답글

취약점이 될 수도 있지만 그건 더 근본적인 문제점을 제대로 해결하지 않았을 때의 문제점이지
data uri는 꽤 안전한 편임

펼쳐보기▼

MiA

2024-06-01 01:51:57 답글

*수정됨

아니 object, script, on~계열의 어트리뷰트를 막는 역할을 할 수 있는 게 웹브라우저랑 새니타이저 둘 뿐인데, 브라우저는 당연히 입력된 리터럴의 출처를 모르니까 새니타이저밖에 못 막고, 이건 새니타이저의 xss 필터를 우회할 수 있는 취약점이라 니가 말하는 것처럼 태그와 어트리뷰트만 보고 '막을'수는 없어. 

사용자 입력이 리터럴로 작동하는 경우 자체에 주의를 기울여서 막는 게 유일한 해법이고, 실제로 그렇게 하고 있음.

펼쳐보기▼

perl

2024-06-01 01:54:01 답글

그 내가 무슨 말을 하는지 잘 모르겠는데 그러면 내가 sanitizer로 안전한 태그(iframe srcript object등 제외)와 안전한 attr(일부 style id class 등)만 허용하게 해 뒀고, data uri를 거르지 않는다고 설정해 뒀을때, data uri를 어떤 식으로 주입해야 XSS가 발생할지 예시를 하나만 들어줄 수 있음?

펼쳐보기▼

MiA

2024-06-01 01:56:37 답글

*수정됨

아, 여기서 말하는 '태그와 어트리뷰트만 보고 막을 수 없어'는 디코딩 될 페이로드의 이야기임. 페이로드에 다른 태그나 어트리뷰트가 있는 경우, 사용자 입력이 리터럴로 작동한다면 막을 수 없다는 거고, 

니가 말하는 방법론은 사용자 입력이 리터럴로 작동하는 것 자체를 막기 위해서 그렇게 될 만한 태그를 전부 막는다는 거고

'사용자 입력이 리터럴로 작동하는 경우 자체에 주의를 기울여서 막는 게 유일한 해법이고, 실제로 그렇게 하고 있음.' 이 그런 의미였음.
기본적으론 니 인식이 틀리지 않았어.

펼쳐보기▼

perl

2024-06-01 01:57:58 답글

뭐 애초에 나는 처음부터 data uri 자체는 크게 문제가 될 게 없다는 입장이었음

sanitize는 절대 클라에서 돌아갈 수 없는건 너무 뻔하고 그 부분은 논란이 될 거리도 아니라고 생각함 그 얘기는 난 한 적 없는데 나와서 이해가 안 간듯

펼쳐보기▼

MiA

2024-06-01 01:58:57 답글

*수정됨

나도 현실적인 보안 문제라기보단, 질문의 요지가 '취약점이 있는가?'였으니까  굉장히 원론적인 이야기를 하려고 한 건데, 설명을 잘 못해서 이야기가 복잡해졌네. 내가 말하는 새니타이징 할 수 없다는 건 페이로드를 새니타이징 할 수 없다는 거고, 니가 말하는 '위험한 태그'는 페이로드가 리터럴로 작동하는 것 자체를 막는 다는 거고. 여기서 서로 이야기가 엇갈린 듯
말을 잘 못해서 미안하다

펼쳐보기▼

MiA

2024-06-01 02:00:45 답글

*수정됨

어디까지나 리터럴 임베드가 사용자 입력에 의해 성립 할 때, 임베드 될 페이로드를 새니타이저에 의존해서 xss를 방지한다고 할 경우 페이로드에 datauri 자체를 허용하지 않는 게 아니라면 dataURI는 xss필터를 우회할 수 있다. 라는 이야기였어. 
이런 방법론이 아주 안 쓰이는 것 까진 아니거든

펼쳐보기▼

MiA

2024-06-01 02:06:09 답글

*수정됨

그리고 아까도 말했지만 나도 data uri를 '쓰면 안된다'라는 의도로 말하는 게 아님. 이미 당연히 쓰고 있는 거고, 니가 말한 원칙이 지켜지면 문제가 없으니까 쓰고 있는 거니까.

옛날에 설계된 웹서버나 옛날 브라우저에선 현실적으로 문제가 될 수도 있는 몇가지 취약점이 있긴 한데, 그건 data uri 자체가 문제가 아니니까

펼쳐보기▼

perl

2024-06-01 02:27:17 답글