WEB 기초
안녕하세요.
또 처음으로 돌아왔네요..
저는 웹지식에 대한 부실공사가 너무 잘돼있어서
이번에 웹 기반지식을 깔끔하게 다져볼까 합니다.
1. 각각의 기능과 종류
1) 브라우저
▶ Internet Explorer, Firefox, Chrome 등이 있습니다.
▶ 사용자가 웹서비스 요청시 사용합니다.
▶ 서버로부터 온 응답을 해석하여 화면에 보여줍니다.
▶ 브라우저가 해석하는 클라이언트 언어는 html, css, java_script가 있습니다.
2) 웹서버
▶ IIS, Apache, Tomcat, nginx 등의 웹서비스데몬이 있습니다.
▶ 사용자가 요청한 데이터를 읽습니다.
▶ 웹서버만으로 처리할 수 없는 것은
WAS(Web Application Server)와 DB(Database)서버와 함께 처리합니다.
3) WAS
▶ ASP, ASP.net, CGI, JSP, PHP 등이 있습니다.
▶ 주로 정적인데이터(html, png, css 등)를 웹서버에서 처리한다면
▶ 웹어플리케이션서버는 동적인데이터(DB를 조회하거나 서블릿컨테이너 등)를 처리합니다.
4) DB
▶ Oracle, MySQL, MsSQL 등 수십가지가 있습니다.
- 결국 사용자 요청에 대한 응답데이터를 만들어 전송하는 행위랍니다.
2. HTML 송수신 과정
1-1) 세션연결
1-2) 데이터 송수신(요청한 html을 응답)
▶ .html을 받았다면 웹페이지를 브라우저에 띄울 수 있죠?
1-3) 세션종료
그러나 웹페이지를 브라우저에 띄울 때 이미지파일 등 추가자원이 필요하다면?
2-1) 새로운 세션연결
2-2) 데이터 송수신(그림파일의 경로를 요청, 그림파일로 응답)
▶ 그림파일을 받았으니 브라우저에 띄울 수 있죠?
2-3) 세션종료
이와 같은 과정을 반복한답니다.
단 빨라서 보이지 않을 뿐이죠
하하
3. 직접확인
1) 개발자도구
크롬브라우저에서
F12를 열어 개발자도구를 열고
naver.com에 접속을 하였습니다.
2) network 탭
"index.html"에서 필요한 데이터를 받아온 자취를 확인할 수 있죠?
3) 속성
[1] Name
▶ 요청한 파일명을 말합니다.
▶ 하나씩 클릭해보면 이미지를 누르면 이미지가 나오고
js파일이면 자바스크립트의 내용을 확인할 수 있습니다.
▶ 스타일시트도 마찬가지로 확인가능합니다.
[2] Status
▶ HTTP 상태코드를 말합니다.
[3] Type
▶ 요청한 파일이 어떤파일인지를 말합니다.
▶ 이미지면 jpeg, png 등으로 나오겠고
js면 script로 나오겠고
css면 stylesheet로 나오겠죠?
[4] Initiator
▶ .html내 어느코드가 이 파일을 요청하는지를 의미합니다.
▶ 누르면 .html파일 내 요청한 곳을 확인할 수 있습니다.
[5] Size
▶ 응답받은 파일의 크기를 의미합니다.
▶ 처음들어가는 경우는 전부 받아오기 때문에 사이즈가 나오지만
다시접속하는 경우 메모리캐시나 디스크캐시 등에 필요한정보가 남아있습니다.
(새로 얻어오지 않고 로컬자원을 사용하기 때문에 빠르겠죠?)
[6] Time
▶ 마이크로초(백만분의 일초)단위 기준입니다.
▶ 즉, 네이버에 접속시 페이지가 바로 보여지지만
실제로는 굉장히 많은 통신을 하며 세션을 맺고 끊는다는 의미겠죠?
[7] Waterfall
▶ 받아온 순서대로 얼마나걸린지 정렬을 해줍니다.
(연결시간, 요청시간, 대기시간, 응답시간, 다운로드시간 등)
▶ 어떤 데이터를 얻어오는데 어떤행위를 하면서 어느정도의 시간이 걸렸다는 것과 같이
순서에 따른 소요시간을 알 수 있답니다.
추가로 Name에 있는 파일명을 누르면
헤더정보를 직접 확인하거나 미리볼 수 있답니다.
4. HTTP 요청 및 응답 패킷
| 1) HTTP Request 구성 |
| [1] GET /275 HTTP/1.1 ▶ GET메서드 요청, 페이지디렉터리는 /275, HTTP/1.1 [2] Host: ccurity.tistory.com ▶ ccurity.tistory.com 도메인을 요청 [3] Referer: https://www.google.com ▶ 경유지(참조) URL을 말하며 여기를 통해서 접속했다는 것을 알 수 있음 [4] User-Agent: Mozilla/5.0(Windows NT 10.0; Win64; x64) ...중략... Chrome/81.0.4044.131 ▶ 사용자가 요청한 OS 및 웹브라우저 종류 [5] Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*; ......이하 생략 ▶ 요청한 데이터 타입 [6] Cookie: a=123; b=234; JSESSIONID=abcdefghijklmnopqrst123456; ▶ 클라이언트에 저장된 사용자의 상태정보(쿠키) |
1-1) 메서드(추가설명)
▶ 클라이언트가 서버에 요청하는 목적이나 종류를 의미합니다.
| 메서드 | 내용 |
| GET | URL에 해당하는 서버의 자원을 얻기위한 전송요청 (2084자 이하, ?id="파라미터"& 등등, body는 없음) |
| POST | 서버가 처리할 자료를 전송, 주로 GET으로 보낼 수 없는 것 (길이제한 없음, \r\n\r\n 뒤 작성하는 부분이 body) |
| HEAD | URL에 해당하는 서버의 자원 중 헤더만 요청 |
| TRACE | 요청한 자원이 수신되는 경로를 확인하는 기능 |
| PUT | URL내 자원을 생성하는 기능(서버 내 파일쓰기) |
| DELETE | URL내 자원을 삭제하는 기능(서버 내 정보제거) |
| OPTIONS | 요청한 URL이 어떤 메서드를 지원하는지 확인하는 기능 |
▶ 불필요한메서드사용 취약점 : TRACE, PUT, DELETE 등은 사용자가 웹서비스 이용시 필요하지 않는 메서드죠?
▶ 서버에서 해당메서드가 들어오면 다른 메서드로 변경하여 응답을 하거나 요청을 갔다 버려서 취약점을 없앨 수 있습니다.
| 2) HTTP Response 구성 |
| [1] HTTP/1.1 200 OK ▶ HTTP버전과 요청에 대한 응답코드 [2] Date: Mon, 04 May 2020 22:43:54 GMT [3] Server: Apache ▶ 웹서버의 정보 [4] Content-Length: 70754 ▶ 응답패킷의 길이 [5] Content-Type: text/html; charset=utf-8 ▶ 컨텐츠의 종류, 여기서는 utf-8인코딩으로 구성된 html [6] body[\r\n\r\n(개행 2번 이후)] ▶ Content-Type에서 html이라고 했으니 html의 코드가 들어있겠네요. <!doctype html> .. 생략 |
▶ 301은 리다이렉트시킬 때 사용
▶ 주로 인증과 관련된 페이지에서 300대 코드가 발생했다면 인증 실패를 의미
▶ 주로 짧은 시간 내 대량의 404에러가 발생한다면 스캐너툴이나 크롤러를 돌렸을 가능성이 있음!
5. 궁금증
※ 쿠키는 말이죠?
▶ 클라이언트에 저장되는 키와 값으로 저장된 데이터입니다.
▶ 이름, 값, 유효시간, 도메인, 요청경로으로 구성됩니다
▶ 좀 더 말하면 4KB이하의 문자열로 구성되어 있죠
※ 쿠키와 세션의 동작방식은?
▶ 클라이언트가 서버에 페이지를 요청(?id=abc&pw=1234)하겠죠?
▶ 서버는 데이터베이스를 조회해서 해당 회원이 있다면
▶ 서버의 세션공장에서 클라이언트에 대한 세션ID를 생성합니다.
▶ 열심히 만들었으니 HTTP헤더(Set-Cookie)에 쿠키내에 세션ID를 포함해서 응답합니다.
- Set-Cookie: <cookie_name>=<cookie_value>
▶ 클라이언트가 다시 요청할 때는 HTTP헤더(Cookie)에 쿠키를 포함해서 요청합니다.
- Cookie: <cookie_name>=<cookie_value>
▶ 서버에서 쿠키를 검증 후 세션ID를 통해 해당 클라이언트 정보를 가져옵니다.
▶ 정보를 처리 후 응답 시 쿠키의 필요에 따라 쿠키정보를 업데이트 후 HTTP헤더에 쿠키를 포함해서 응답합니다.
▶ 쿠키의 유효시간이 만료되지 않는 한 브라우저 종료 후 재접속해도 인증정보가 남아있죠!
※ 엇, 그러면 세션은 뭔가요?
▶ 세션은 쿠키를 바탕으로 사용자정보를 관리합니다. 단 파일이 아닌 메모리상에서 말이죠!
▶ 서버에서는 클라이언트를 식별하기위해 세션ID를 부여합니다.
▶ 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증된 상태를 유지하고 있죠
▶ 세션타임아웃기능을 이용해서 일정시간동안 잠수탔던 클라이언트의 세션ID는 서버에서 소멸시킬 수도 있습니다.
▶ 세션은 사용자정보를 클라이언트에 두는 쿠키보다는 안전하지만, 사용자가 많아질수록 서버의 자원이 부족해질 수 있습니다.
※ 도데체 쿠키와 세션 무슨차이져(동작방식도 비슷한거 같은데...중얼중얼)?
▶ 세션도 쿠키를 사용해서 비슷하지만 쿠키는 클라이언트의 파일로 저장되고 세션은 서버의 메모리에 올라가 있습니다.
▶ 그 말은 쿠키는 서버의 자원을 사용하지 않고 세션은 서버의 자원을 잡아먹는다는 말이겠죠?
▶ 각각의 클라이언트에 파일로 저장되어 위변조될 가능성이 있는 쿠키보다는 서버에서 관리하는 세션이 보다안전하죠
▶ 보안적으로 본다면 라이프사이클만큼 중요한 것도 없습니다.
- 쿠키는 만료시간이 있긴 하지만 브라우저가 종료돼도 파일로 남아있고
- 세션은 브라우저 종료 시 만료시간에 상관없이 소리소문없이 사라진답니다!
※ 그럼 좋은게 1도 없어보이는 쿠키 대신 세션만 사용하면 되지 않나요?
▶ 조금 더 얘기하면 서버에서 처리를 거치는 세션보다는 쿠키가 빠르답니다.
▶ 위에서도 말했지만 세션은 서버의 자원을 사용하기 때문에 동시접속자가 많은 서버가 힘들어해요..(부들부들)
※ 위에서 캐시에 대해서도 언급했는데 쿠키가 캐시인가요?
▶ 쿠키가 사용자정보를 저장한 파일이라면 캐시는 브라우저가 참고해서 사용하는 것?이라고 보면 됩니다.
▶ 음.. 캐시는 이미지나 자바스크립트, 스타일시트(CSS) 파일을 의미합니다.
▶ 처음 접속 시 해당 서버에서 사용하는 파일을 받아온 후 캐시에 있다면 브라우저는 서버에 다시 요청하지 않습니다.
▶ 이 덕분에 속도는 빨라질 수 있지만 종종 페이지가 변경되야하는 부분이 새로고침해도 변경되지 않을 때가 있죠?
▶ 캐시 삭제 후 다시 접속하면 변경되서 보인답니다.
그 외 CSRF 글 적을 때 다루었는지 기억은 나지 않지만 요새는 토큰기반의 인증시스템도 많이 사용한다고 합니다.
보안을 위해서 쿠키를 제어하기 위한 몇 가지 옵션이 있는데요.
- Secure 옵션은 HTTPS프로토콜에서 암호화된 요청에 대해서만 전송하는 옵션입니다.
- HttpOnly 옵션은 XSS를 방지하는 document.cookie API를 호출할 수 없도록 합니다.
저는 어떤식으로 코드가 짜여진지는 모르지만 이런 옵션이 있다면 잘 가져다 쓰는 것도 좋지 않을까요?
'Try Attack > Web Hacking[basic]' 카테고리의 다른 글
| Cross Site Script(XSS) (0) | 2019.09.20 |
|---|---|
| 불충분한 세션관리 (0) | 2019.09.20 |
| command injection (0) | 2019.09.20 |
| Web hacking 이론 (0) | 2019.04.27 |
| File Upload (0) | 2018.08.12 |
댓글