diff --git "a/14\354\236\245/\354\230\244\355\230\234\354\204\261.md" "b/14\354\236\245/\354\230\244\355\230\234\354\204\261.md" new file mode 100644 index 0000000..28eeeb3 --- /dev/null +++ "b/14\354\236\245/\354\230\244\355\230\234\354\204\261.md" @@ -0,0 +1,84 @@ +# 웹사이트 보안을 위한 리액트와 웹페이지 보안 이슈 +* 보안 이슈는 버그와 같이 개발자의 실수에서 비롯되는 경우도 있지만 이러한 코드나 프로세스가 보안에 문제가 된다는 것을 인지하지 못하는 경우에도 발생한다. + +## 리액트에서 발생하는 크로스 사이트 스크립팅 (XSS) + +* dangerouslySetInnerHTML +* useRef를 이용한 직접 삽입 + +### XSS 문제를 피하는 방법 + +* 제3자가 삽입할 수 있는 HTML을 안전한 HTML 코드로 한 번 치환하는 것 + + DOMpurity + + sanitize-html + + js-xss + +* 서버는 '클라이언트에서 사용자가 입력한 데이터는 일단 의심한다'라는 자세로 클라이언트의 POST 요청에 있는 HTML을 이스케이프하는 것이 제일 안전 + +* 리액트의 JSX 데이터 바인딩 시에는 XSS를 방어하기 위한 이스케이프 작업이 존재함 + +## getServerSideProps와 서버 컴포넌트를 주의 + +* getServerSideProps가 반환하는 props 값은 모두 사용자의 HTML에 기록되고, 전역 변수로 등록됨 + +> 🤘 window.atob ? window.btoa ? +> https://developer.mozilla.org/en-US/docs/Web/API/atob + +```js +const encodedData = btoa("Hello, world"); // encode a string +const decodedData = atob(encodedData); // decode the string +``` + +## 태그의 값 + +* `` 사용하지 않기 + + href에 사용자가 입력한 주소를 넣을 수 있다면 보안 이슈로 이어지기 때문 + + 버튼을 쓰는 것이 마크업 관점에서도 좋음 + +## HTTP 보안 헤더 설정하기 + +* Strict-Transport-Security + + HTTPS를 사용하도록 강제하는 헤더 + +* X-Frame-Options + + 페이지를 frame, iframe, embed, object 내부에서 렌더링을 허용할지 + + SAMEORIGIN을 통해 같은 origin에 대해서만 허용할 수 있음 + +* Permissions-Policy + + 브라우저가 기능을 제어할 수 있도록 하는 헤더 + + geolocation, microphone, camera, fullscreen, payment 등 + + https://www.permissionspolicy.io/ + +> MIME? +> Multipurpose Internet Mail Extensions +> Content-type의 값으로 사용됨 +> +> 이름처럼 원래 메일에서 사용하던 인코딩 방식, 현재는 Content-type에서 대표적으로 사용 + +* Referrer-Policy + + HTTP 요청에는 Referer라는 헤더가 존재 + - 현재 요청을 보낸 페이지의 주소를 나타냄 + - Referer는 오타이나, 이미 표준으로 등록된 이후에 오타임을 발견해서 계속 사용중 + + Referrer-Policy 헤더는 이러한 Referer 헤더에 사용할 수 있는 데이터를 나타냄 + + 구글에서는 이용자의 개인정보 보호를 위해 strict-origin-when-cross-origin 혹은 그 이상을 권장 + +> 🤘 원래는 로그인한 회원만 볼 수 있는 게시물을, +> 홍보를 보고 온 사람은 바로 볼 수 있게 하는 요구사항이 있었는데요 .. +> 이 레퍼러를 이용해 분기해서 처리했던 경험 공유 드립니다요.. + +## 보안 헤더 설정하기 + +* https://nextjs.org/docs/advanced-features/security-headers + + +## 보안 헤더 확인하기 + +* https://securityheaders.com/ + +## 취약점이 있는 패키지 사용 피하기 + +* lock.json의 모든 의존성을 파악하는 것은 불가능 + + 그러니 깃허브 디펜더본을 이용하자 + +> 여러분은 쓰시고 계신가요?? +> 그렇다면 PR이 올라오면 누구 담당???