브라우저를 통해서 서버에 요청을 보내면 자동으로 session에 대한 정보를 담아 cookie로 전달해줍니다. 이때 sesion의 정보를 JSESSIONID라는 이름의 변수에 넣어 보내고, 재요청시에도 JSESSIONID는 항상 들고 전달하고 전달 받아 재방문한 사용자인지, 최초방문한 사용자인지 알 수 있습니다.
Session은 인증이라고도 볼 수 있습니다.
클라이언트가 서버에 요청 시 session을 통해서 사용자 인증을 할 수 있습니다. 이는 클라이언트가 요청에 대한 응답을 받으면 통신선이 끊어지기 때문에 session으로 해당 사용자가 이전의 그 사용자라는 것을 인증해주는 것입니다.
반면에 socket 통신은 양 끝에 포트를 달고 통신하는 것이기때문에 통신선이 끊기지 않고 계속 유지가 됩니다. 따라서 따로 인증을 할 필요가 없어 session이 필요 없습니다.
http header 에는 클라이언트의 요청/ 요청에 대한 응답 등의 정보들이 담겨있습니다.
하지만 이 header에 대한 정보들을 다르게 넣어 서버에 전송하여 공격할 수 있습니다. 아무리 서버에서 웹브라우저 이외의 접근을 막아도 header의 정보를 위조해서 서버에 요청하면 서버는 어쩔 수 없이 그대로 정보를 받아들일 수 밖에 없습니다.
HTTP Method에는 GET, PUT, DELETE, POST 4가지 방식이 있습니다. 개발자가 마음대로 코딩해서 GET방식만으로 DELETE 매핑의 기능을 구현해낼 수 있습니다. GET 방식은 하이퍼링크로 구현 가능하기 때문입니다.
하지만 GET 이외의 POST, PUT, DELETE 매핑 방식은 사용자로부터 데이터를 받고, RETURN을 받기도 하기 때문에 데이터 조작이 가능해집니다. jsp에서 PUT, DELETE 매핑 방식을 이용하기 위해서는 JAVA Script를 이용해야 합니다.
그렇다면 JAVAScript만 막는다면 하이퍼링크 공격 밖에 하지 못하기때문에 공격에 대한 방어를 더욱 효율적으로 할 수 있습니다. 예를 들어 블로그 게시판에 데이터를 조작할 스크립트 자체를 게시글 내용에 적는다면, 다른 사람이 해당 게시글을 상세보기 할 때 해당 코드가 실행되면서 공격을 할 수 있게 됩니다.
따라서 서버에서는 javascript를 통한 접근을 막는 것이 default 값입니다. 물론 원하는 서버만 접근할 수 있도록 수정해줄 수 있습니다.
서버와 클라이언트가 같은 IP주소를 가지고 있다면 javascript가 포함된 html이 서버에 요청해도 정상적인 응답을 받을 수 있습니다.
하지만 HTML IP가 localhost:8000이고, 서버의 IP가 localhost:5000이라면 같은 도메인이 아니기때문에 javascript 요청은 모두 다 막습니다. 포트가 다르기때문에 다른 도메인입니다. 이를 CORS Policy라고 합니다. 따라서 CORS Policy는 javascript로 공격당할 수 있기 때문에 만들어진 것입니다.
그렇다면 안드로이드에서는 어떨까요?
안드로이드에서 서버로 요청을 하면 안드로이드에서는 자바스크립트로 요청하는 것이 아니기때문에 정상적은 응답을 받을 수 있습니다.
CORS Policy는 자바스크립트를 통한 접근을 모두 막는 것이 default 값이기 때문에 꼭! 설정을 해주어야 합니다. 서버를 배포하고 싶다면 당연히 클라이언트가 다른 도메인에서 접근을 할 수도 있기때문에 그에 맞는 설정을 꼭 해주어야 합니다.
클라이언트가 서버에 요청을 보내면 서버는 톰켓에 요청을 보내게 됩니다. 톰캣에서 request/response 객체를 대신 생성해줍니다. 이 때 session에는 JSESSIONID라는 클라이언트의 정보를 담은 데이터를 클라이언트의 cookie에 전송해줍니다. 클라이언트의 cookie가 자동으로 JSESSIONID를 저장합니다.
정리하자면 클라이언트가 서버에 요청을 하면 cookie에 JSESSIONID를 돌려줍니다. http header에 cookie라는 키 값이 있으면 자동으로 브라우저에 돌려주고, 클라이언트의 cookie에 JSESSIONID를 자동으로 저장해줍니다.
그렇다면 안드로이드에서 접근을 한다면 어떨까요?
안드로이드로 요청을 하면 http header에 cookie를 담더라도 안드로이드는 cookie 저장을 하지 않습니다. 이유는 앱에는 그런 정책이 없기 때문입니다. 브라우저에서 저장하는 이유는 정해진 정책이 있기 때문입니다. 만약 안드로이드에서도 session 방식으로 인증을 하고 싶다면 응답 받는 response정보에서 header를 보고 cookie를 직접 꺼내어 저장해야 합니다.
클라이언트가 서버에 재요청을 한다면 JSESSIONID를 들고 요청을 합니다. request header에 JSESSIONID를 자동으로 들고 가는데 이는 브라우저의 cookie 영역에 저장되어 있기 때문입니다. 다른 서버에서 요청하면 해당 서버에 대한 cookie가 없기때문에 들고가지 않습니다.
JSESSIONID를 통해서 최초요청인지, 재요청인지를 알 수 있습니다.
그렇다면 JAVAScript로 요청했다면?
최초 요청(GET)일때 쿠키를 돌려주고 재요청일 때 PUT이나 DELETE같은 매핑을 한다면 서버에서 공격당할 수 있기때문에 막아버립니다.
댓글