0902 웹해킹 1일차(Application Security) → 수정해야 할 것

웹 기본과 실습 환경

웹 해킹 연습

OWASP TOP 10 2021

모의 웹해킹 실습

 

<웹 기본과 실습 환경>

HTTP프로토콜과 HTML의 특징

HTTP20과 TLS13

실습환경 구축

 

웹의 아버지 ‘팀 버너스리’

● 인터넷: 1974년 시작(로버트 칸, 빈트 서프) → CLI

Gopher, Archie, Telnet 등등, 이 당시는 사진 문서는 넣을 수 있었다만 링크는 넣지 못함

WWW: 1988년에 팀 버너스리가 처음 개발

팀버너스리는 물리학자인데, CERN(유럽 물리입자 연구소)에서 일했음

문서, 사진, 링크를 넣을 수 있었다.

 

웹 해킹이 시작된 원인은 기업들이 회사소개, 상품 소개에 사진, 설명, 링크를 넣음으로써 많은 사람들이 사용하기 시작하였고, 이를 사용하기 위해 사람들은 회원가입을 하고 사람들이 많아짐으로써 데이터 베이스가 만들어지고, 스크립트가 만들어 지고 이를 관리하기 위해 보안(암호화, 방화벽 등등)이 필요해지고 클라우드 서버를 운영하기 시작.

점점 복잡해지니까 구성상의 문제점, 취약점 등이 발견 → 다양한 공격이 알려지게 됨.

웹 브라우저(클라이언트)와 웹 서버간에 암호화

웹 서버의 설정 이슈

데이터 베이스의 설정 이슈 → 잘못 설정하면 sql인젝션

스크립트 공격 이슈 → XSS, CSRF, SSS, WebShell 등 → 난독화

 

www의 통신 방법은 http(hypertext transfer protocol)

http는 하이퍼텍스트를 교환하는 프로토콜

클라이언트와 서버는 어플리케이션이다.

클라이언트: 웹 브라우저,SSH client, FTP client

서버: 웹서버(ISS, Apache2, Nginx 등)

http는 stateless(비연결유지 프로토콜), 연결상태를 유지하지 않음. 사진, 텍스트, 링크를 다 받으면 연결이 끊긴다. (클라이언트와 서버 간의 대화가 끊김, 인터넷이 끊기는 것 x)

마우스를 클릭하면 다시 연결을 시작한다 → 하지만 누군지 모름

로그인: id/pw → 고객님 어서오세요. 마우스 클릭 → 누구세요? (연결 상태가 끊겼기 때문에, id, pw를 입력하면서 cookie를 생성하게 되는데, 쿠키를 생성해서 서버에다가 알려준다. 쿠키를 생성해서 서버에 달려준다. http에 쿠키를 넣어서 보낸다. )

(연결이 끊기면 모르는 상태가 되어버림)

쿠키도 취약점이 있어서 보안 이슈가 된다.

기존 프로토콜들은 연결된 상태가 유지가 되었다.

보안의 가장 큰 적은 편리를 추구하는 것

http1.0은 이미지, 검색창, 텍스트를 따로따로 보낸다. 연결 설정 → 다운로드 → 연결 해제 이것을 계속해서 반복해서 따로따로 보낸다.

http1.1은 한 번 연결에 여러 개의 파일들을 다운로드 받아볼 수 있었다. (www을 주도하는 회사는 구글인데(ms는 윈도우), 구글에 너무 많은 의존을 방지하기 위해서 일부 기술들을 도입)

http/2: 헤더 압축(바이너리), 파이프라인, server push 기능 (윈도우10 IE11, 크롬, 에지, 파이어폭스9)

 

HTTP2.0: HTTP101(헤더에는 post, host, content-type, content-length가 있고 밑은 body/ HTTP2.0은 헤더 프레임, 데이터 프레임이 있다.)

 

텍스트를 사용했을때보다 바이너리를 사용할떄 좋은 점은 크기가 약 2/3로 줄어든다.

전세계적으로 전기가 덜 소모되고, 환경보호에 영향을 줄 수 있다.

 

* frame은 packet을 실어나르는 단위 (컨테이너선 ---> frame/ 컨테이너 ---> packet(데이터를 넣은 상자))

 

http request 헤더

Request~Connection 까지 헤더에 들어가는 부분

Request(필수): 어떤 매소드를 사용하는지, 어떤 페이지를 요청하는지, 어떤 버전을 사용하는지, 이러한 것들을 표시하는 부분. get 방식만 있는 것이 아니라 host라든지 put, trace 같은 옵션들이 있다.

referer: 어디서 오셨는지(경유해서 왔는지) 확인하겠다 ex) 내가 쇼핑몰에서 물건을 검색했는데, 그 물건이 정상가로 판다. 근데 네이버에서 검색해서 들어갔다오면 싸게 파는 경우가 있다. 해당 쇼핑몰은 내가 직접 접속했는지 네이버를 통해서 왔는지 어떻게 알ᄁᆞ? 이를 알기 위해서 referer을 참고하게 된다.

user-agent: 웹 브라우저의 종류를 표시한다. 모질라가 웹 브라우저의 표준이다.

* MSIE: microsoft internet explore) ex) 스마트폰으로 뭘 살려고 보는데 할인쿠폰을 준다. 근데 pc로 접속하면 할인 쿠폰을 준다. 내가 스마트폰으로 접속했는지, pc로 접속했는지 어떻게 알ᄁᆞ? 웹 브라우저의 종류를 보고 알 수 있다. 구글 크롬을 쓰는지, 사파리를 쓰는지 여기서 알 수 있다. 조작도 가능하다.

host(필수): 이 요청을 받아줄 서버, 요청을 누구한테 하나요?(요청을 받는 호스트의 IP주소 또는 Domain name을 표시한다.)

get요청일때는 request와 host는 반드시 들어가야 하고 나머지는 선택사항, 필요한 경우 넣어도 되고 안넣어도 되고

리눅스 명령어를 referer, user-agent를 조작해서 웹 해킹이 가능하다.

 

http response

서버가 클라이언트에게 웹 페이지를 준다.

body부분에 웹 사이트 내용(사진, 설명(텍스트), 링크)이 들어있다.

클라이언트 웹 브라우저 화면에 사진, 설명, 링크가 보인다.

헤더 부분에는 response ~ content-type

response(필수): 버전, 에러코드가 들어간다. 200이면 정상

server: 서버의 종류를 작성한다.

content-length(필수): 웹 페이지에 body부분에 들어가는 내용, 사이즈가 얼마인가를 알려준다.

content-type(필수): 내용물이 뭐냐, 뭐 들어가냐 ex) 택배를 보낼 때 직원이 뭐 보내는지 물어본다.

 

HTTP Reauest Method(양식)

GET, POST 요청을 많이 사용한다.

페이지만 요청할거면 GET요청, 그냥 검색하려면 GET요청/ 로그인 하려고 한다. 그러면 POST/ 서버에다가 파일을 올리려고 하면 PUT(악성코드를 올릴 수 있기 때문에 못하게 한다.)

PATCH: 파일을 일부 수정하는 것(바이러스를 붙일 수 있기 때문에 사용X)

TRACE: 에코백(중간중간 거쳐간 경로)을 받는다. (해킹 위험이 있어서 안됨)

OPTIONS: 어떤 매소드를 사용하는가? (혹시나 push, patch, delete를 원할 수 있기 때문에 금지)

DELETE: 서버 주인도 아닌데 DELETE할 수 있기 때문에 사용 불가능

안전한 매소드는 GET, POST 뿐이다.

POST는 언제 사용하는가? 데이터를 보내고 처리를 해달라고 할 때, 로그인/ 게시판에 글쓰기 같은 것들을 처리해준다.

그 외 메소드는 위험하다 → ISMS-P 인증심사에서 결함으로 간주(거의 탈락)

GET, HEAD는 BODY를 사용하지 않는다. 서버에 어떤 액션을 하지 않고 요청만 한다. 그래서 GET은 page요청, 검색어 입력 → HTTP BODY를 사용하지 않는다.

POST는 로그인, 게시판 글쓰기, 파일 업로드 등등 → HTTP BODY를 사용한다.

PUT: 파일을 서버에 저장한다 → 악성코드를 업로드 함

DELETE: 서버에 있는 파일을 삭제 → 서버의 중요한 파일이 지워질 우려가 있다.

OPTIONS: 어ᄄᅠᆫ 메소드를 사용 가능한지를 물어보는 것 (해킹에 취약)

 

ex) WebDav: 개발자들이 웹 사이트를 공동 개발할떄 사용하는 공유폴더(파일을 업로드, 수정, 삭제 가능/ 업로드하면 악성코드를 심을 수 있고, 수정은 fetch, 삭제는 delete)

→ 인터넷에 연결해서 사용하면 매우매우 위험. 개발자들은 그래서 폐쇄된 네트워크에서 사용한다.

 

GET

페이지를 요청한다, 검색할 때 사용한다.

전체 HTTP트래픽에 약 95%는 대부분 GET요청

사진, 텍스트, 링크를 요청

‘?’ 는 URI와 쿼리 스트링의 구분자 역할을 한다.

 

https://www.google.com/search?(URL) q=%ED%9E%8C%EB%82%A8%EB%85%B8(QUERY)

 

POST는 BODY에다가 로그인, 게시판, 파일 업로드 내용들을 올린다.

클라이언트가 서버에게 보내는 모든 내용은 BODY에다 넣어서 보낸다.

 

ex) 우편물을 비교하자면 get요청은 편지만 보내는 것, post는 택배같은 것들을 보내는 것.

id, password가 평문으로 가면 안되기 때문에 ssl/ tls을 사용한다. 웹 페이지 위에 자물쇠가 보이는 것

 

SSL(secure socket layer)

netscape사에서 제작, 웹브라우저와 웹 서버간 암호화 방식

취약점이 너무 많음 SSL1.0과 SSL2.0은 취약점이 발견되어서 사용 중지.

SSL3.0을 서용하다가 또 취약점이 발견됨

 

TLS(Transfer layer security)

SSL의 후속 버전을 TLS로 바꿧는데 많은 전문가들이 참여해서 표준화하기로 함.

즉, SSL을 표준화하면서 이름을 TLS로 변경(누구나 사용 가능)

취약점이 대부분 보완됨

1999년 이후로는 계속 TLS만 사용한다. 그런데 사람들이 SSL이라는 이름을 너무 옛날부터 쓰다보니 아직도 SSL이라는 표현을 쓰지만, 실제로는 SSL을 사용하지 않고 있다.

SSL/TLS라고 표기하고 실제로는 TLS만 사용한다.

 

SSL암호화하는 과정

웹 브라우저(클라이언트) → 웹 서버, 서버에 인증서(공개키)를 받아온다.

서버쪽에서 키를 받아와서 클라이언트에서 키를 만들어서 서버에가 전달하며 공유한다.

서버에 공개키로 암호화해서 준다. (안전하게 줘야하기 때문에)

 

TLS1.2 와 TLS1.3을 비교

TLS1.2에서는 4단계는 해야지 암호화가 이루어지고, 데이터를 주고 받을 수 있다. TLS1.3은 두 번 만에 끝난다.

그러고 나서 데이터를 주고 받을 수 있다. (시간이 줄어든다. 10^6에서 10^4로 줄어든다.)

 

HTTPS

HTTP(80포트, 평문) + SSL/ TLS = HTTPS(443포트, 암호문)

 

SNI를 활용한 불법 사이트 차단 원리

불법 사이트는 보통 해외에다가 서버를 두고 운영하는 사람들이 많다. 불법 사이트를 차단하려면 1. 서버 IP차단: 사용자 브라우저가 불법 해외 서버 IP에 접근하는 것을 막으면 된다. 2. 운 룰 처단: 나쁜 사이트에 IP를 알려줘. 그러면 알려주지 않는다. 그런데 사이트 운영자들이 새로운 IP로 옮겨 다닌다. 그러면서 자꾸 사용자들에게 접속을 하라고 유도를 한다. 그런 경우에는 HTTP차단: HTTP통신할 때 호스트 이름이 표시가 된다. HTTP헤더에 보면 호스트를 보고 차단을 한다. 그런데 HTTPS를 하면 내용, 헤더도 암호화를 한다. 그러면 내용이 뭔지 모른다. 그러면 불법 사이트를 방문하는지 알기 어려워진다. 이를 대비해 HTTPS를 사용가능 경우에는 내가 누구다 라는 것을 한 번 밝히는 과정(SNI필드)이 있다. 그걸 보고 차단을 한다. SNI는 처음에는 암호화없이 평문으로 표시가 된다. 그러고 연결을 못하게 하여 차단을 한다. 이러한 나쁜 사이트를 딥 웹, 다크 웹이라고 한다.

 

표준문서: SGML, HTML, XML, XHTML

HTML은 처음에는 SGML이 있었다.SGML은 미 국방부에서 사용하는 표준 문서 양식, 아주 옛날에는 제안서를 갖고와라. 근데 제안을 하는 업체가 100군데라면 그러면 500권의 제안서가 나오게 된다. 이 500권을 체육관에 빌려다가 하는데, 이 제안서 책들을 쌓아놓는다. 그래서 심사를 한다. 그런 거를 미국방부에서는 한 두 개가 아니라서 종이로 가져오지 말고, 파일로 제출하라. 이랬더니 각 회사마다 다른 형식의 파일들을 만들게 된다. (doc, ppt, pdf, xls...등) 이렇게 여러 가지 방식으로 만들면 힘들다. 이러면 해당 파일의 sw를 다 설치를 해야 한다. 이러면 너무 복잡해지니 미 국방부에서 SGML양식으로 작성한 다음에 저 양식으로만 내라 라고 한다.

 

ex) 항공모함 매뉴얼을 종이로 출력해서 싣고 다니면, 항공모함이 2cm내려간다. 그래서 종이로 출력하면 안된다. 그래서 모든 문서를 파일로 만들되 SGML로 만들어서 제출하라.

 

그런데 SGML의 단점은 작성이 어렵다. SGML은 일반인들이 작성할 수 없다. ᄄᆞ로 배워야한다. HTML보다 어려움. 그런 문제 때문에 SGML을 간단하게 만든 것이 HTML을 만들었다. 이것을 웹의 표준 문서로 정함. 그런데 HTML은 간단해서 좋은데, 문제점은 웹에서만 동작하지 호환이 안된다. (확장성, 호환성 부족) 이러한 문제 때문에 나온 것이 XML, XML의 특징은 내용과 형식을 분리한다. 이 때문에 변경내용이 생길 때, 형식은 그대로 두고 내용만 바꿀 수 있다. HTML은 사진, 설명, 링크가 안된다. 로그인, 회원가입 안된다. 그래서 나온게 JSP/ASP/ PHP/자바스크립트(스크립트 종류) 이러한 것들이 등장하게 된다. 차이점은 JSP/ASP/ PHP은 server side script, 자바스크립트는 client side script, 그래서 최근에는 이러한 스크립트 뿐만 아니라 파이썬, Ruby 등등등 (최근에는 스크립트 전성시대) 이러한 것들은 컴파일이 필요 없고, 즉석해서 실행이 된다. 그러다보니 간단하고 편리하고 굉장히 좋다. 이러한 점들이 장점이라서 웬만하면 스크립트로 한다.

 

에러코드

200: 정상이다.

300번대: permenant, temporary(잠ᄁᆞᆫ 이동)

400번대: not found, 찾아갔는데 없다.

500대: 서버에러, 내부에서 서버 설정을 잘못해서 접속이 안되는 상태

503번: 서버가 일시적으로 공격을 당하든지, 되게 바ᄈᆞ서 접속을 할 수 없다.

 

http 에러코드

400번대 에러 특징: 클라이언트 쪽에서 잘못된 요청을 한 경우

401 unauthorized: 로그인 실패 후 권한이 없다는 의미

403 forbidden: 접근하면 안되는 페이지 또는 디렉터리

404 not found: 없는 페이지

500번대 에러 특징: 서버 쪽에서 잘못한 경우

500 internal server error: 설정을 뭔가 잘못한 것

502 bad gateway: 서버쪽 통로 연결 분제

503 service unavailiable: 서비스를 일시적으로 할 수 없음. (DDOS공격을 당하거나, 사람이 너무 많이 몰려서...)

 

→ 에러는 공격자에게는 큰 힌트가 된다. : 에러를 알려주지 말고, 똑같은 에러 메시지로 출력해야 한다. ex) 지금은 접속이 원활하지 않습니다...

→ 따라서 통일된 메시지로 응답해야 한다.: 지금은 접속이 원활하지 않습니다. 잠시 후에 다시 접속하시길 바랍니다.

 

웹 트래픽의 변화

2015년까지만 해도 latop이나 데스크톱으로 이용하는 사용자가 많았지만, 2017년 1월달부터 모바일 사용자가 다른 사용자보다 많아지기 시작했다. 그래서 지금은 모바일 폰으로 웹 사이트를 방문하는 사람들이 많아졌다. 그래서 공격자들이 생각할떄, 악성코드를 모바일폰으로 선택할 가능성이 높아졌다.

 

산업 분야별 웹 취약점 특징

다 똑같은 공격을 하는 것은 아니다. 대상에 ᄄᆞ라서 공격이 달라진다. 금융분야에서는 코드 퀄리티, 코드와 관련된 취약점을 공격할 가능성이 높다. 암호화이슈, 정보유출 순으로 높다. government

 

개발자 도구 활용(F12)

이미지를 다운로드 하지 못하게 한다든지 활용한다. 개발자 도구는 오류가 있거나 하면 즉석해서 수정하거나 해서 동작이 잘되는지 확인하는 것, 실제로 어떤 조작행위를 하는 경우도 있다 EX) 어떤 사람이 문제가 막혀 있어서 개발자 도구를 이용해서 해결하려고 할 때

 

웹해킹 보안 모의 해킹을 할떄, F12(개발자 도구)와 Proxy도구를 이용해서 1/4정도는 풀린다.

→ 실제로도 비슷하다.

 

injection

웹 서버와 데이터 베이스는 sql로 대화한다. http에서는 별로 문제가 되지 않는 injection구문을 넣어도 http에서는 별다른 동작을 하지 않는다. 의미 없는 값이 되는데 sql문으로 따라 붙게 되면 select문의 지대한 영향을 미친다. 특히 where조건절 자체를 무력화시키기 위한 방법으로 이러한 문구를 집어 넣는다. ex) adc가 있는데, 그게 거짓이라 할지라도 or 무조건 참이 된다. 전체가 참이 되니까, 이 DB서버에 있는 사용자들의 목록이 웹 서버에 전달되고, 웹 서버는 HTTP방식으로 웹 클라이언트에게 개인정보목록을 전달한다. 이런 공격을 SQL인젝션이라 한다. SQL공격구문을 중간에 주입했다.

 

* SQL인젝션 공격 원리

웹 브라우저와 웹 서버는 HTTP로 통신, 웹 서버와 데이터 베이스는 SQL로 통신을 한다.

공격자는 SQL공격구문을 웹 서버에 전달 → 웹 서버에서 DB에 SQL문으로 작성하는데, 공격 구문이 따라 붙게 된다.

DB에 도착해서는 SQL공격 구문이 그대로 실행된다. 그러면 조작된 요청가 전달될 수 있다.

결과가 공격자에게 return되는 방식

 

주석 처리를 하는 이유

ex) 로그인 사례

select * from [테이블명] where 조건문(id=’ or 1=1 -- ‘ and pw=’ ‘):

→ or앞에 id는 null상태가 되는데, false or true니까 true되고 로그인 된다.

주석을 사용하는 이유는 뒤에 있는 세미콜론 같은 것을 처리하기 복잡하니ᄁᆞ 주석으로 무력화를 시킨다. 주석을 사용하는 이유는 ...

 

SQL 인젝션의 핵심 3요소

주석처리: 뒷부분 무력화

–오라클DB, MS-SQL: --

MYSQL, MariaDB: #

 

로직: 논리적으로 참이 되기만 하면 됨

ex) ‘ or 1=1 --

‘ or 2>1 --

‘ or ’a’=’a’ --

‘ or ’S‘ < ’T‘ #

select * from [테이블명] where id =’ ‘ and pw=’ or 1=1 --‘;

싱글쿼트가 하나 더 남으면 ‘—’ 을 사용하지 않아도 된다

→ select * from [테이블명] where id =’ ‘ and pw=’ ‘or ’a’=’a‘‘;

 

SQL중첩문 사용하기

앞의 SQL문을 마감하고 다른 SQL문을 뒤에 붙여서 실행하도록 유도함

select ~~~~~~; drop table ~~~~~~~;

select * from [테이블명] where id =’ ‘ and pw=’; drop table member ~~~~‘;

원래 패스워드를 넣어야할 자리에 null이 들어가서 끝난다. 그러면 로그인에 실패하게 된다.

그러고 테이블이 지워진다.

 

 

2. 앞의 select문을 뒤의 select문과 union으로 연결

select * from [테이블명] where id =’ ‘ and pw=’ union select‘;

※ 주의사항: 앞의 select문에서 요청한 개수와 뒤의 select문에서 요청한 개수가 일치해야 한다.

select id, pw from [테이블명] where id =’ ‘ and pw=’ union select userid, account_number from [테이블명]~~~‘;

예상되는 셀렉터문

: select firstname, surname from [테이블명] where userid=’‘ or 1=1 — 또는 # ‘;

 

싱글쿼트가 ᄍᆞᆨ수개이면 주석이 불필요하지만, 홀수개이면 주석이 필요로 하다.

 

 

* SQL인젝션 대응 방법

escape처리: 특수문자의 고유 기능을 하지 못하도록 해야 한다. → 특수문자 앞에 \(백슬래시)를 붙인다.

ex) 4+5=9, 이거를 이스케이프 처리하게 되면 4 \ + 5 \ =9

 

예를 들면) \‘ or 1=1 \# 이렇게 하면 이 구문이 제대로 동잒할 수 없게 된다. 이렇게 하면 정상적인 sql공격이 안 된다.

→ 사람이 일일이 붙일 수 없어서 secure coding함수를 사용해야 한다.

 

sql 인젝션을 차단하기 위해 만든 시큐어 코딩 함수가 있다. : mysql_real_escape_string()함수 → php에서 사용한다. sql인젝션 차단 전용 함수

특수 분자 중에 \x00, \n, \r, \,‘, “and \x1a (인젝션에 활용되는 것들)앞에 \를 붙여서 escape처리를 한다.

→ \x: hex구분자로 사용, \n: line feed, 줄 내림, \r: carriage return, 커서를 왼쪽 끝으로 이동

 

줄바꿈: \r\n (줄내림과 줄바꿈은 다르다.)

 

쿠키를 사용하는 이유: stateless여서 연결이 끊기면, 같은 사용자인 것을 알아보지 못한다. id/ pw는 지식 기반 인증 방식이라면 쿠키는 소유기반인증 방식.

쿠키는 개인정보로 취급 받는다.

 

gmarket을 ssg에서 인수 → 회원 통합 : ssguid와 같은 쿠키값을 별도로 부여한다. → 내부적으로는 인식 가능하도록 사용

이런 식으로 식별자를 별도로 추가하도록 한다.

 

쿠키값의 보안 이슈

A의 쿠키값을 공격자가 훔쳐가면, 공격자가 A인척하고 사이트에 접근한다. → 100만원으로 물건 주문

쿠키 값을 많이 저장하라고 요청한다. → 광고회사 같은 곳에서 사용자에 대한 접속 빈도를 측정하기 위해서 사용 ex) 광고회사는 쿠키 값을 확인한다. 그러고 돈을 받는다. 크롬은 쿠키 차단 안됨.