애플리케이션 보안 수업 1일차 (22/09/02)
- Web
- 인터넷 : 1974년 시작 (로버트 칸, 빈트 서프) Gopher, Archie, Telnet 등
- www : 1988년 팀 버너스 리
- CERN : 유럽의 물리입자 연구소 (사진+ 설명 + 링크)
- 복잡해지면서 구성상의 문제점, 취약점 등이 발견되었고 다양한 공격이 알려지게 됨
- 웹브라우저(클라이언트)와 웹서버간에 암호화 이슈 → 취약한 암호화
- 웹서버의 설정 이슈
- 데이터베이스 설정 이슈 → SQL인젝션
- 스크립트 공격 이슈 → XSS, CSRF, SSS, WebShell 등 → 난독화
- 클라이언트 : 웹 브라우저, SSH client, FTP client
- 서버 : 웹서버(IIS, Apache2, Nginx 등)
- HTTP
- Stateless (사진, 텍스트, 링크를 받으면 연결 끊김) // 마우스 클릭 시 재연결
- 쿠키 취약점 : Cookie를 생성 후 서버에 알려줌 → http에 cookie를 넣어 전송
- 보안의 가장 큰 적은? : 편리를 추구하는 것
- 텍스트를 사용할 때보다 Binary를 사용하면 크기가 약 2/3로 줄어들게 됨
- Frame : Packet을 실어 나르는 단위
- 컨테이너선 → Frame (2계층 전송 단위)
- 컨테이너 → Packet (데이터를 넣은 상자) (3계층 전송 단위)
- HTTP Request 헤더
- Request (필수) : 사용하는 Method(메서드), 요청하는 페이지, 사용하는 버전 표시
- Referer : 접속 전 경유한 사이트
- User-Agent : 웹브라우저의 종류를 표시하는 부분
- Host (필수) : 요청을 받는 호스트의 IP주소 or Domain Name 표시
- Referer, User-Agent에 리눅스 명령어를 사용해 공격하는 취약점이 존재하는 경우 있음
- HTTP Request Method
- 안전한 메서드 : GET, POST
- 그 외 나머지 메서드는 위험 → ISMS-P 인증심사에서 결함으로 간주
- GET
- GET : 페이지 요청, 검색어 입력 → HTTP Body를 사용하지 않음
- POST : 로그인(ID/PW), 게시판 글쓰기, 파일 업로드 등등 → HTTP Body 사용
- PUT : 파일을 서버에 저장 → 악성코드를 업로드
- DELETE : 서버에 있는 파일을 삭제 → 서버의 중요한 파일이 지워질 우려가 있음
- OPTIONS : 어떤 메서드를 사용 가능한지를 물어보는 것
ex) WebDav : 개발자들이 웹사이트를 공동 개발할 때 사용하는 공유폴더 (파일 업로드, 수정, 삭제 가능)
→ 인터넷에 연결해서 사용하면 매우 매우 위험, 폐쇄된 네트워크에서만 사용해야 함
- 힌남노
[https://www.google.co.kr/search?q=힌남노]
[https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=1&ie=utf8&query=힌남노]
- SSL (Secure Socket Layer) / TLS (Transport Layer Security)
- Netscape에서 만든 웹브라우저와 웹서버 간 암호화 방식
- SSL1.0, SSL2.0, SSL3.0 모두 취약점 발견 (현재는 사용X)
- SSL을 표준화하며 TLS로 변경 (누구나 사용 가능)
- 취약점 대부분 보완
- 1999년 이후 TLS만 사용
- XML 특징
내용과 형식 분리 → 변경내용이 있을 때 형식은 그대로 두고 내용만 변경 가능
- 스크립트의 종류
- ASP, JSP, PHP : Server Side Script
- Javascript : Client Side Script
- Python, Ruby 등 (최근에는 스크립트 전성시대) → 컴파일 필요없음, 즉석에서 실행 (간단, 편리 등)
- HTTP Error Code
1. 400번대 에러의 특징 : Client 쪽에서 잘못된 요청을 한 경우
401 unauthorized : 로그인 실패 후 권한 없음
403 forbidden : 접근하면 안 되는 페이지 or 디렉터리
404 Not found : 없는 페이지
2. 500번대 에러의 특징 : Server 쪽에서 잘못한 경우
500 internal server error : 설정을 잘못한 경우
502 bad gateway : 서버 쪽 통로 연결에 문제
503 service unavailable : 서비스를 일시적으로 할 수 없음 (DDoS 공격, 많은 서비스 요청)
※ 에러는 공격자에게는 큰 힌트가 되므로 에러를 같은 메시지로 알려줘야 함
→ 통일된 메시지로 응답해야 함 ( ex 지금은 접속이 원활하지 않습니다. 잠시 후에 다시 접속 바랍니다.)
→ 모의 해킹 시, F12(개발자 도구)와 Proxy도구를 사용해서 1/4 정도 해결
- SQL Injection
- SQL 인젝션의 공격 원리
- 웹브라우저와 웹서버는 HTTP로 통신, 웹서버와 Database는 SQL로 통신
- 공격자는 SQL 공격 구문을 웹서버에 전달 → 웹서버에서 Database에 SQL문을 작성하는데 공격 구문이 따라붙게 됨 → Database에서 SQL 공격 구문이 그대로 실행 → 조작된 요청이 전달될 수 있음
ex) 로그인을 하는 경우
select * from [테이블명] where id='' or 1=1 --' and pw=' ';
- SQL 인젝션의 핵심 3요소
1. 주석처리 : 뒷부분 무력화
- 오라클 DB, MS-SQL : --
- MySQL, MariaDB : #
2. 로직 : 논리적으로 참이면 됨
' or 1=1 --
' or 2>1 --
' or 'a'='a' --
select * from [테이블명] where id='admin' and pw='' or 1=1 --';
' or 'a'='a
select * from [테이블명] where id='admin' and pw='' or 'a'='a';
3. SQL 중첩문 사용하기
- 앞의 SQL문을 마감 후, 다른 SQL문을 뒤에 붙여서 실행하도록 유도
select ~~~~~~~~; drop table ~~~~~~;
select * from [테이블명] where id='admin' and pw=''; drop table member ~~~~~';
- 앞의 select문을 뒤의 select문과 union으로 연결
select * from [테이블명] where id='admin' and pw='' union select ~~~~~~~~ ';
※ 주의사항 : 앞의 select문에서 요청한 개수와 뒤의 select문에서 요청한 개수가 일치해야 함
select id, pw from [테이블명] where id='admin' and pw='' union select userid, accont_number from [테이블명] ~~~~~~~~ ';
- 다른 사이트에 해킹 공격 시 정보통신망법 위반 : 71조 (5년 이하의 징역 또는 5천만원 이하의 벌금)
- DVWA의 SQL 인젝션
user id에 1~9번까지 넣으면 사용자 이름(first name)과 성(surname)이 출력
select firstname, surname from [테이블 이름] where userid='' or 1=1 #';
' or 'a'='a' # // '가 홀수개이면 주석 사용
' or 'a'='a // '(Single Quot)가 짝수개이면 주석 불필요
' or 2>1 #
' or 'S'<'T' #
' or 'S'<'Super' #
' or 'A'<'Z' #
- SQL 인젝션 대응 방법
- Escape처리 : 특수문자의 고유 기능을 하지 못하도록 → 특수문자 앞에 \(백슬래시) 붙임
ex) 4 + 5 = 9 -----> 4 \+ 5 \= 9 , \' or 1\=1 \#
특수문자 중에 \x00, \n, \r, \, ', " and \x1a 앞에 \를 붙여서 Escape 처리
- \x : hex구분자로 사용
- \n : (Line Feed, 줄 내림)
- \r : (Carriage Return, 커서를 왼쪽 끝으로 이동)
- \r\n : 줄바꿈
- Secure Coding 함수 : mysql_real_escape_string( ) 함수 (PHP에서 사용)
- mysqli_real_escape_string( )를 mysql_real_escape_string( )에 포함시킴 → mysql_real_escape_string( )만 사용
- Cookie
- Cookie값의 보안 이슈
- A의 쿠키값을 공격자가 훔쳐가면, 공격자가 A인 척하고 사이트에 접근
- Cookie값의 저장 요청 : 광고회사에서 사용자에 대한 접속 빈도를 측정하기 위해서 쿠키값 저장 요청
→ 비용 정산을 위한 근거자료