P0l4ris

#File Inclusion

 - PHP 기반 웹 어플리케이션에서 클라이언트(사용자)가 직접 파일을 업로드 할 수 있을 때 발생하는 취약점.

 - RFI (Remote FIle Inclusion)과 LFI (Local File Inclusion)으로 나뉘어져 있다.

(1)#RFI : Remote File Inclusion -> 원격 파일 실행 (include나 requir같은 함수에서 URL전달값을 검사하지 못할 때)

 - php파일들이 업로드 되어 있는 것을 확인하였다.

#게시글 업로드가 없으니 내부적으로 파일을 생성하여 넣어보겠다.

 - /etc/passwd 파일을 위에서부터 5줄 출력

#end

(2)#LFI : Local File Inclusion -> 내부적 파일 실행 (시스템에 이미 존재하는 파일이 include함수로 들어갈 때)

 - /etc 디렉터리에 hi라는 파일안에 Hello?라는 메세지를 넣었다.

#url 조작

 - ../ : 한 단계 상위 디렉터리로 이동.

 - etc폴더의 hi파일이 출력되는 것을 볼 수 있다.

#Missing Function Level Access Control

  - 엑세스 제어 수준 기능 누락

 -> 민감한 요청 처리기의 인증검사가 불충분하거나 존재하지 않는 경우.

  --> 권한 없는 사용자가 민감한 정보를 포함하는 URL을 액세스하거나, 권한없는 기능을 노출 가능. (OWASP 中)

(2)

 - 숨겨진 항목을 찾으라고 한다. 

  -> html에서 페이지에 출력은 안되지만 존재하게 만들 수 있다. (input type = hidden)

#개발자도구

 - network 목록에서 페이지가 처음 로드될 때 Response(응답)코드를 본다.

#hidden찾기

 - hidden이 여러 개 나오는데, hidden-menu가 왠지 찾고 있는 숨겨진 메뉴일 것 같다.

  -> ul(리스트)를 보니 /users로 가는 링크 "Users"와 /config으로 가는 링크 "Config"이 있다.

#end

(3)

 - SQL 삽입 취약점 같은 곳에서 데이터 덤프가 발생하지만, 제어가 부족하거나 존재하지 않아

   발생할 수 있다.

 - 댓글, 유출 된 정보에 주목하여라.

 - 다른 브라우저 또는 계정을 사용할 수 있다.

 - 이미 수집한 (숨겨진 메뉴 아이템) 사용자 목록을 가져온 다음 자신의 사용자 계정에

   '해시'를 확인하여라.

#숨겨진 메뉴 분석

 - Users 가 사용자 목록인 것 같다. a herf="/users"라는 것은

   메인 페이지("localhost/webgoat") 밑의 경로라고 볼 수 있다.

#localhost/webgoat/users 접속

 1) 서버 내부적 에러 코드 500

   -> users 파일은 찾을 수 있으나(not 404), 처리과정에서 오류가 발생

 2) templates/list_users.html 을 파싱하는데 실패하였다.

 3) TemplateEngin : 특정 데이터 모델에 따른 입력자료를 합성하여 결과문서를 출력해주는 소프트웨어

   -> 데이터가 없거나, 템플릿이 없는 경우인데.

       윗 부분에서 템플릿이 없다고 이미 오류코드를 출력했다.

#template 배제하고 데이터를 요청하기 위해 request 분석

 - Content-type : request에 실어 보내는 body의 정보를 표시

#Content-type : Application/java 추가

 - hash가 잘 출력된다.

#end

#CSRF : Cross Site Request Forgery)

 - 인터넷을 사용하는 사용자가 자신의 의지와는 무관하게 공격자(해커)가 의도한 행위(생성, 삭제, 변경) 등 을

   특정 웹사이트에게 요청하게 만드는 공격

 - 희생자(사용자)의 권한에 한해서 실행(공격) 가능.

 - 조건

  -> 요청을 전송받는 사이트(서비스)에 희생자가 연결이 맺어진 상태(로그인 중)

  -> 희생자가 해커가 만든 사이트 혹은 게시글에 접속 혹은, 파일을 실행

  -> 웹 어플리케이션에서 정상적인 경로의 요청과 비정상적인 경로의 요청을 서버가 구분하지 못해야 함.

#패스워드 변경을 시도하고, 요청을 전송하지 않고 프록시에 고정.

#변경 후 응답받은 페이지를 분석

 - <form ...> : 폼 데이터를 서버로 보낼 때, 데이터가 도착할 url(action 속성), 방식(method) 등이 포함.

 - action="#" : 현재 페이지에 남아 있음.

   -> 해당 페이지에서 변경을 수행.

#form 태그의 action속성으로 html form 파일(.html)을 하나 생성.

 - action : 작업을 수행할 경로

 - input type="hidden" : 페이지에 입력받는 곳이 보이지 않게 해줌.

 - autocomplete : 자동완성 여부 (패스워드를 브라우저에 저장함)

 - name : 적용할 대상

 - value : 적용할 값

 - tyep="submit" : 버튼 생성

 -> 즉, (공격자의) 지정한 비밀번호들을 (희생자가) 버튼만 누르면 자동으로 전달되어서 적용되게 변경.

#파일 시나리오(메일)

#파일 실행

#end 

 - 버튼을 누르니 "비밀번호가 변경되었습니다." 멘트가 뜨고,

   비밀번호 검사를 하니 지정한 비밀번호가 유효하다고 출력된다.

tip) 이 문제를 실습하다 value를 잘못 지정해서 로그인이 안된 적 있는데,

     localhost/dvwa/setup.php에서 database를 다시 생성해주면 초기화 된다.