1. client: 침대에서 뒤적뒤적 거리며 핸드폰을 만지며 인터넷을 하는 일반인 2. server: 그 일반인들이 들어가는 사이트를 관리하는 컴퓨터
2. HTTP 1. hypertext transfer protocol(하이퍼텍스트 작성할때 규칙정도록 이해하자...!) 2. 웹에서 일반적으로 client와 server가 통신할때 쓰는 약속 3. 이 request와 response과정은 선조들이 정해놓은 약속에 의해 이뤄진다.
3. 웹페이지 접근
1. https://wiki.plus.or.kr/login 을 친다. 2. 브라우저는 HTTP요청으로 변환 후 전송(HTTP request) 3. 서버에서는 HTTP 요청을 해석해 결과를 내놓음(HTTP response)
4. HTTP request
1. GET method: url에 ?name1=value1&name2=value2 같은 식으로 정보 전달
--> 아무래도 보안면에서 취약하다.. 당연한 이야기지만, 예를 들어 당신의 비밀번호가 url에 다 뜬다고 쳐보자 ,,, 큰일나는거다..! 그리고 GET메도는 주로 데이터 목록을 가져올때(조회할때) 이용한다. 당연히 데이터 목록을 조회하기 위해서는 데이터를 가져와야 할때니 쿠키기능이 저장되어 있을것이다.. 그렇가면 쿠키란 무엇인가? ㅋ 컴퓨터용어에서 간단히 말하자면 일종의 일시적 저장 메모리기능을 가지는 하드디스크 역할정도로 보면 될듯하다.
2. POST method : body에 name1=value1&name2=value2 같은 식으로 정보 전달
--> 아무래도 보안면에서 GET method보다는 강하다. body부분은 해커나 사용자가 어떻게 건들수가 없다.. 게시물에서 글을 작성하거나 할때 글이 생성된다.. GET메소드와 차이점은 바로 쿠키 기능이 없다고 생각하면 된다.
5. cookie,set-cookie
•Cookie는 request header의 한 종류 (일종의 콘센터)(브라우저)
•Set-Cookie는 response header의 한 종류(일종의 어뎁터)(서버)
•
•cookie는 browser의 local storage이며, Set-Cookie:로 야 이 쿠키들 저장해! 라고 서버에서 알려주면 저장하게 되고 reqeust를 보낼 때 저장한 쿠키들을 Cookie: 로 보냄
•보통 로그인 정보(session)를 cookie로 많이 저장함 : 로그인 하면 유저가 특정 쿠키를 갖게 하고 쿠키 체크로 유저 확인
•User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
7. referer
request header의 한 종류 원래는 referrer이 맞는 표현이지만 그냥 굳은 표현 사용자가 어느페이지에서 request를 보낸건지 알려주는 용도(예를 들어 링크를 탄 페이지) ex: Referer: https://www.google.com
8. location response header의 한 종류 대신 갈 주소를 알려줌 브라우저가 바로 이 location으로 점프해줌 주로 redirection response code 3xx 와 같이 쓰임
location: https://www.example.org/
9. url encoding 기본적으로는 nonprintable,non ascii 문자를 printable로 치환하기 위한 encoding 필요에 따라 encode하거나 decode하는 경우가 많음 사용하는 틀에 따라 내가 쓴 내용을 url:encode/decode해서 보내는 경우도 있고, 그대로 보내는 경우도 있으니 주의
예를 들어 크롬 브라우저 url창은 기본으로 한번 decoding 을 해준다.
10. client side web page
•브라우저의 주소창에 쳐서 보낸 request의 response body는 브라우저가 받는 웹페이지! -> HTML 문법
브라우저: 크롬,오페라,사파리 ,IE(INTERNET EXPLORER의 약자) 웹 서버: nginx,apache등 웹 어플리케이션: PHP,Django,Flask,node.js등 데이터베이스:MYSQL,SQLite,MariaDB등
12. client와 server의 구별
•webhacking.kr 가입을 해보자
•http://webhacking.kr 에서 준 index.html 에 주석으로 숨겨진 join 버튼이 있다
•여기서 버튼이 중요한 게 아니라 버튼을 누르면 발동하는 request :
•get method로 http://webhacking.kr/join/includ2_join__frm__0001.php?mode=aa9b0aabbaf0e39e7a71536e68ec8538라는 곳에 요청을 보내야 join 페이지가 나온다는 사실이 중요한 것 (onclick=location.href는 버튼을 누르면 브라우저가 저 페이지로 가게 해주는 기능)
•결국 client가 받은 웹페이지는 server에 어떤 기능이 있는지 안내해주는 역할도 하는 것이다
13. client와 server의 구별 •webhacking.kr join 페이지를 봐보자
•<form method="post" name="joinfrm"> : post method request 날리는 기능, joinfrm이라는 이름으로 접근 가능
•<input type="text" name="id"> : post method request의 body에서 name을 지정, value는 input한 값 (사용자가 빈칸에다 쓴 정보)
•<input type="button" onclick="join_ck()"> : 버튼을 클릭하면 join_ck()라는 js function 실행
•join_ck() : joinfrm의 구성요소 체크를 한 후 joinfrm.submit()으로 post request를 드디어 날림
14. request는 거짓말이 가능하다 --> 즉 해커가 사용하는 주 해킹기술임 ㅋㅋ
•referer : request header이므로 얼마든지 주작 가능
•cookie : request header이므로 얼마든지 주작 가능
•애초에 내가 의도한 버튼을 눌러야 request를 날리도록 웹페이지(html)을 구성했는데 버튼을 누르지 않아도 request는 얼마든지 가능
•
•이처럼 원래 referer는 사용자가 어느 페이지에서 왔는지 알려주는 header고, cookie는 클라이언트의 상태를 담기 위해 만들어진 header임
•브라우저는 이 약속을 토대로 referer, cookie를 보내준다
•하지만 결국은 client쪽에서 자발적으로 보내는 것이기 때문에 사실과 다른 정보를 보내는 것이 가능하다
15. bad server example
•client : 야 id는 hae고 pw는 bin이야 로그인 버튼 꾹 -> GET method http://example.org?id=hae&pw=bin 의 형태로 request 전송
•server : 오 GET이 왔군 id는 hae고 pw는 bin이니 db를 검사해서 id-pw 쌍이 있는지 확인해보고 있으면 쿠키를 할당해줄게 (session) -> Response header의 Set-Cookie : login_id=hae;
•client : 야 내가 쓴 메모가 보고 싶어 -> GET method http://example.org/memo, request header의 Cookie : login_id=hae;
•server : 어 메모가 보고 싶다고? login_id Cookie가 있는 상태네? ㅇㅋ 로그인했구나 넌 hae니까 니가 쓴 메모를 보여줄게
•client : ...? 야 내가 쓴 메모가 보고 싶어 ㅎㅎ -> GET method http://example.org/memo, request header의 Cookie : login_id=admin;
•ㅇㅋ 넌 admin이구나 admin이 쓴 메모를 보여줄게
16. request는 거짓말이 가능하다
•이때문에 client side filtering (js)은 억제력이 별로 없다 전부 개무시하고 보내기 가능
•결국 client side에서 어떤 생각치 못한 request가 들어와도 다 튕겨낼 각오로 server를 구성해야 하는 것
17. 요구되는 능력
•js 많이(해석, 코딩)
•html css 조금 (대충 해석만 해도 일단은 ㄱㅊ?)
•서버 설정 숙지 (이것도 알아서 ㅎ)
•웹의 원리 숙지
•킹색 (검색)
18. HTTPS(중요~!)
•인증서를 통해 서버를 검증하고, HTTP 통신을 암호화 (HTTP 통신은 평문 전송이므로 너무 취약해서)
•보통 툴들에서는 https 통신도 복호화해서 보기 가능
19. URL(Uniform Resource Locator) 과 URI(Uniform Resouce Identifier) 의 차이
