웹 어플리케이션 개발 시 웹, 서버 통신 간 암호화 방식 질문

Question

안녕하세요, 웹 어플리케이션 개발을 하고 있는 4년차 개발자입니다.상황닷넷 웹폼 프로젝트를 진행 중인데 이미 HTTPS를 적용하였으나, payload가 피들러, 크롬 개발자 도구 등에 평문으로 노출이 되고 일부 값을 변경하여 재전송 공격이 가능하다는 보안 점검 의견을 받았습니다.아마 postman, insomnia, fiddler 등 API 툴 사용해서 request를 보낸 것 같아요.이에 보안 대책으로 파라미터 노출 방지를 위해 AES-256 알고리즘을 사용하여 전 파라미터를 통으로 암호화하였습니다.예시) POST xxx-form-urlencoded 기준일 때 foo: sgkjfdbngkljdhgnksdfg==대충 요런식으로 처리브라우저 단에서 JS를 이용하여 AES-256 암호화 시 key 및 iv의 보관에 관련된 문제가 있어 별도 언어를 통해 웹어셈블리(이하 wasm)로 제작을 했고, key, iv는 wasm 내부에 보관되어 있었습니다.이후 추가적인 보안 점검 진행하였고 wasm 파일의 바이너리를 까서 key, iv를 결국 찾아내어 통과가 되지 않았습니다.해결책현재 상황 및 제가 알고 있는 기준으로는 암호화 key를 클라이언트 단에 보관하는 것은 불가능하므로 AES-256 등의 대칭키 알고리즘 및 현재 로직을 폐기하고 RSA의 비대칭키 알고리즘 로직을 도입하는 것을 생각하고 있습니다.공개키를 사용하여 암호화를 한다면 비밀키로만 복호화가 가능하니 클라이언트 단에서의 보안 대책은 해결될 것 같긴 합니다.다만, 이런 상황은 처음이어서, RSA 비대칭 키 알고리즘을 제 상황에 도입하는 것이 적절한지 긴가민가합니다.주변에 보안 관련해서 멘토가 없는 관계로 누가 저에게 "너가 하려는 것이 맞다", "아니다", "이 방식은 생각해보았냐" 등 의견을 여쭤보고 싶습니다.p.s.고객은 설득이 불가능한 상태이며, 써드파티 솔루션 연동 시 같은 문제가 발생하여 파라미터 암호화를 진행해야하는 점 말씀드립니다.

캐티 · Answer

https://kimbatt.github.io/js-Z/https://obfuscator.io/#google_vignette이거 두 개를 섞어서 웹 워커를 켜면 되는거 아니나요. 아마도 두번째 거가 ai한테 쉽게 들통나는 약한거여서 두번쨰 -> 첫번쨰 이중으로 걸면 될거여요. 디버깅을 하지 못하도록 엔드포인트 함수를 주지 말아야 한다는 점에 유의하여야 하겠쩌. 이럼 코드 안에 iv key 머든지 들어있어도 뜯어내기가 앵간할거여요.난독화를 심하게 하였다 하더라도 wasm이 더 취약한거 아니나요. 직접 실행 코드는 변화를 주는데 한계가 있어서 망하는 수가 있고, 일반적으로 키 값은 엉클어놓지 아니하는 이상 코드에 어레이로 들어가 있어서 뜯어지는 수가 있어요. 이럼 망하빈다. 이러하여서 직접 실행 코드는 일반적으로 vm으로 보호를 해버리는 거여요. 음 .. 이럼에도 리소스 메모리 블록을 보호하기 앵간하여서 망해요.나는 전에 rsa-oaep sha-256으로 하여쩌. 자바스크립트에 암호 엔진에 들어있어서 그대로 사용하면 좋고, 사이닝은 ecdsa p-384로 하여쩌. 이거는 이케이케 잘 처신하여야 할거여요.

초무쿤 · Answer

SSL을 믿지못하는SI 노답케이스 똥 중 하나인데..(사실은 기원을 찾아가보먄 분리발주 이전 SI회사들이 어떻게던 남겨먹으려는 암복호화 솔루션 팔이..)설득 불가라니 어짤수가요..;;Ps. 사실 민감정보는 query string에만 안들어가면 되는것을..빨짓인거 같지만 post 돠는 바디부분도 굳히 암호화 해야되갰다면 업비트 api들 한번 보시죵. 굳히 저럴 필요가 있나 싶지만 거기도 뭐 비슷한 이유때문에 어거지로 우겨낳은듯..

만두랑 두부랑 · Answer

비대칭 암호화를 하시는 것이 맞습니다. 가장 간편하고, 가장 저렴한 솔루션입니다. 저라면 모든 파라메타를 json에 몰아넣고 한방에 암호화할 것 같습니다. 그럼 파라메타 이름도 노출이 안되니까요.

웹 어플리케이션 개발 시 웹, 서버 통신 간 암호화 방식 질문

3개의 답변

Q&A 목록