'분류 전체보기'에 해당되는 글 438건

rubiya 님의 Stored XSS 글을 보다가 몇가지 실험을 해보았고, 그 결과를 공유한다.

일단, rubiya님의 글은 다음과 같다.

간단히 해당 글을 요약하자면, 웹해킹 분야의 워게임 사이트인 webhaking.kr에 존재하는 문제 중 운영자가 의도하지 않은 취약점이 해당 문제에 존재하였고, 해당 취약점을 이용하여 Stored XSS가 이루어진다는 내용이다.

Stored XSS가 단순히 게시글 등록으로 이루어진 것이 아니라, Indirect SQL Injection을 통해 이루어졌다는 점도 흥미롭다.

Indirect SQL Injection에 대해서는 바로 이전 포스팅에서 간단히 설명해두었으니 해당 게시글을 참고해주길 바란다.

모든 내용이 이해가 갔는데, 1.jpg 부분을 통해 소스코드를 발견한 부분이 참 흥미로워서 개인적으로 확인 및 추가 실험을 진행해보았다.

일단 실제로 [tar -cvf *]를 하였을 때 실제로 첫번째 파일에 해당 디렉토리의 모든 파일의 내용이 들어가는지 확인해보았다.

1. 실제 동작하는지 확인

먼저 디렉토리에 3개의 파일이 있는 상태이고, 가장 첫번째 파일의 크기는 9Byte임을 알 수 있다.

이 상태에서 tar -cvf *를 하였고 그 결과 2개의 파일(2.txt, 3.jpg)가 묶였다는 것을 볼 수 있으며 1.jpg 파일의 크기가 10240으로 크게 바뀐 것을 통해 묶인 결과가 1.jpg로 된 것을 볼 수 있다.

vi로 1.jpg를 확인하였을 때 2.txt 파일에 들어있는 [FLAG!!]라는 문자열도 보이는 것을 확인할 수 있다.

이는 tar 명령어를 사용할 때 압축결과 파일명을 따로 작성하지 않을 때 해당 디렉토리의 첫번째 파일에 묶인다는 것을 이용한 것이다.

이 분석을 통해 [웹 서버에서 접근 가능한 디렉토리에는 tar 파일을 두지 않아야하며 만약 둬야한다면 예측 가능한 tar 파일명을 쓰지 않아야한다] 정도의 교훈(?)을 얻을 수 있었다.

--------------------

Q. 만약 명령어를 사용할 수 있는 상태이지만 로그인된 user명이 권한이 낮아 root 권한만 읽을 수 있는 파일을 읽지 못하는 상황이라면?

A. 당연히 tar 를 이용해서도 볼 수 없다.

3개의 파일(1.jpg, 2.txt, 3.jpg) 파일이 root 만 볼 수 있는 파일일 때 tar -cvf *를 하면 Permission denied가 뜨며 묶을 수 없다. 

뭔가 당연한데 혹시나 될수도 있지 않을까 했는데 역시나였다..ㅋㅋㅋ

오늘은 인터넷을 돌아다니다가 [Indirect SQL Injection]이라는 것에 대해 알게 되었다.

일단 Indirect SQL Injection이란 무엇을 의미하는지 보도록 하자.

말그대로 번역을하면 간접적인 SQL Injection이다.

이를 조금 더 풀어서 이야기하자면 비정상적인 데이터를 삽입하였을 때 바로 Injection이 터지는 취약점이 아니라, 삽입한 데이터가 조회될 때 비로소 Injection이 터지며 정보가 노출되는 취약점이라 생각하면 된다.

이에 대한 예시는 아래 블로그를 참고하였다.

이 두 블로그 글을 참고하면 어떤 느낌인지 올 것이다.

Real World에서도 충분히 발생될 수 있다는 생각이 들었고, 추후 개발할 때에도 신경써서 개발해야겠다는 생각이 들었다.

만약 Indirect SQL Injection과 관련된 Writeup을 작성하게 될 경우 해당 포스팅을 링크걸어둘 생각으로 작성해둔다.

파일 다운로드 취약점이 발생되었을 때 DB에 접근할 수 있는 정보 혹은 업로드하는 파일의 소스코드를 봐서 FU 취약점이 발생될 수 있는지를 확인한다. 이 때 Spring Framework에서 Controller의 위치를 한번에 알 수 있는 방법이 있는지에 대해 공부한 일련의 과정을 정리해둔다.

※ View 위치 찾기

1. /WEB-INF/web.xml

 (1) Spring에서 MVC를 구현하기 위한 Dispatcher Servlet을 찾는다.

 (2) Dispatcher Servlet에 포함되어 URL Mapping을 담당하고 있는 servlet-context.xml의 경로를 찾는다.

그림1. /WEB-INF/web.xml (출처 : https://all-record.tistory.com/165?category=733072)

◎ 만약 위와 같이 servlet-context.xml이 존재하지 않은 경우

contextConfigLocation 초기화 파라미터를 설정하지 않은 경우, DispatcherServlet은 WEB-INF/[서블릿이름]-servlet.ml 파일을 설정파일로 사용한다.

2. servlet-context.xml 경로

 (1) Controller에 의해 리턴된 View를 찾아주는 ViewResolver를 찾는다.

 (2) 해당 ViewResolver의 속성인 prefix와 suffix를 통해 내가 요청한 URL의 view page가 어디인지 찾는다.

그림2. servlet-context.xml (출처 : https://all-record.tistory.com/165?category=733072)

※ Controller 위치 찾기

view는 찾기 쉽지만 우리가 원하는 실제 코드는 controller에 있다. 이를 찾기 위해서는 우리가 URL에 입력한 것이 각 controller의 @RequestMapping Annotation에 있는지를 찾아야 한다.

그렇다면 각 controller의 파일명을 알 수 있는 방법이 있을까?

정확하지는 않지만 일단 지금까지의 결론은 다음과 같다.

1. web-xml에 dispatcherServlet을 등록함

2. dispatcherSerlvet 안에 <annotation-driven />과 함께 component-scan을 통해 패키지 안에 @controller라고 적어둔 annotation을 기준으로 컨트롤러를 스캔한다.

3. 이후 요청은 스캔한 컨트롤러들을 기준으로 동작한다.

결론 : 모든 컨트롤러가 적혀있는 특정 파일은 존재하지 않다.

추가적으로 더 알게된 내용이 있으면 추가하겠음.

참고 ) 

이론 : https://all-record.tistory.com/165?category=733072

실제 파일 위치들 예제 : http://pgm-progger.blogspot.com/2014/01/spring-base-setting.html