Browser Security
XSS
보안이 약한 웹 어플리케이션에 대한 웹 기반 공격
클라이언트가 서버를 신뢰하기 때문에 발생하는 이슈이다. 클라이언트 입장에서는 서버가 제공한 데이터는 정상적일 것이라 생각한다.
그러나 악성코드가 있다면..??
스팸문자가 왔을 때 (절대 열어보지 마요...) 함께 오는 url을 열었을 때 이상한 곳으로 접속이 된다던지, 개인 정보가 빠져나가게 되는 것도 이 XSS의 공격이다.XSS 공격의 희생자는 해당 어플리케이션이 아닌 사용자가 되는 것이다.
웹의 구동을 위해서는 자바스크립트를 사용하게 되는데, 자바스크립트는 하는 일이 매우 많다. 그래서 XSS 공격에서 악성 컨텐츠는 자바스크립트를 활용하여 전달된다.
XSS공격은 자바스크립트의 innerHTML 로 접근하여, 안에 <script> </script>를 삽입하여 전달한다.
- 이에 대한 접근을 방지하기 위해서는
innerHTML의 사용을 지양하는 것이 좋다. - 또한 정규표현식을 사용하여 꺽쇠 기호
< >의 필터링을 통해 인식하지 못하게 하는 방법도 있다. - 요새는 브라우저에서 일반적인 XSS 공격이 막혀있다.
CORS
Cross Origin Resource Sharing
브라우저는 origin정책을 갖고 있다.
➡️ 하나의 웹사이트는 하나의 서버랑만 연결해야 한다는 정책이다.
결론부터 말하자면 CORS는 이런 서로 다른 origin간의 리소스를 공유한다.
A서버에 연결하면 원천적으로 B서버와의 연결을 막아버리는 것을 Same-origin policy 라고 한다.
여기서 'CORS가 무엇인가' 하면, 이 Same-origin policy 의 예외사항을 만들어주는 것이다.
결국 서버에서 CORS를 허용하게 되면, 예외적으로 해당서버는 CORS를 허용하기 때문에 A서버에 연결이 되어 있어도 B서버와 연결할 수 있는 것이다.
그렇다면 우선 Same-origin policy 은 어떻게 판별하는가 궁금증이 생길 것이다. 즉 같은 서버인 것을 판별하는 조건이 되는데, 아래 3가지가 이에 해당한다.
"프로토콜 호스트(도메인) 포트번호 "
https:(프로토콜)//velog.io(도메인)/write?id=3e21d57e-0fd2-4fbf-bd8b-ca29e8381(포트번호)fe3
✅ 이렇게 CORS의 허용으로 인해 브라우저는 프론트 & 백엔드 모두 통신이 가능한 상태가 되었다.
CORS는 브라우저가 자발적으로! 브라우저의 어플리케이션 "사용자" 들을 보호하기 위한 정책이다.
접근 제어 시나리오
브라우저가 CORS를 처리하기 위한 세 가지 방법에 대한 시나리오이다.
1. Simple requests (단순 요청)
바로 메인요청에 들어가서 확인한다.
- GET, HEAD, POST 중 한 가지 메서드여야만 한다.
- 기본으로 셋팅된 헤더만 가능하다.
'Content-Type':'application/x-www-form-urlencoded'or'multipart/form-data'or'text/plain'셋 중 하나이고, 커스텀 헤더를 전송하지 말아야 한다.
2. Preflighted requests (프리플라이트 요청) - OPTIONS method !
메인요청에 들어가기 전에 옵션 메소드를 미리 먼저 확인한다.
simple requests에 해당되지 않는 경우에preflighted requests로 온다.- PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH 메소드 중 하나라도 사용되는 경우에 해당된다.
- 커스터마이징한 헤더도 전송한다.
3. Requests with credentials (인증 정보를 포함한 요청)
서버에서 클라이언트 브라우저에 쿠키를 심을 때가 있는데, 그 안에 세션토큰을 넣어 놓을 때가 있다. 로그인을 안했어도 쿠키동의하면, 장바구니에 물건을 넣거나, 자주 보는 항목을 보여주거나 할 때 쿠키를 사용하기도 한다. 서버에 요청을 할 때 쿠키에 있는 정보를 같이 보낼 것인가 고려할 때 하는 요청이다.
Micro service architecture
-- 업뎃 중 --
