레이피엘의 블로그

 일반적으로 웹 어플리케이션을 서비스할 때 개인정보와 같이 민감한 정보가 포함된 페이지는 https(HTTP over SSL)프로토콜, 이외의 일반적인 페이지는 http프로토콜을 이용하여 구성하는 웹 어플리케이션이 상당수를 차지합니다. 이렇게 http/https프로토콜이 혼재해 있는 경우 페이지 이동간에 프로토콜이 변경되면 세션 공유가 되지 않아 세션이 끊기는 문제가 발생하는 경우가 있습니다. 본 아티클에서는 http와 https 프로토콜을 혼용하여 사용할 경우 안전하게 세션을 공유하는 방법에 대해서 알아보도록 하겠습니다.

세션 공유가 안되는 원인

 위와 같은 환경에서 세션 공유가 되지 않는 원인은 기본적으로 웹 어플리케이션에서 세션 관리를 위해서 주로 사용하는 쿠키의 특성에 기인합니다. 쿠키는 웹 사이트의 호스트명(Hostname),  하위 패스 등의 속성 조합으로 관리되며 매 요청시 평가되어 조건에 해당하는 경우 전송됩니다. 여기서 문제가 되는 속성이 바로 secure 속성입니다. secure 속성이 지정되지 않은 경우에는 http, https 양쪽 모두 쿠키가 전송되지만 secure 속성이 지정된 경우에는 https 프로토콜에서만 전송되기 때문입니다.

 예를 들어 https로 되어있는 페이지로 최초 접속한 사용자에게 발행된 세션 쿠키에 secure 속성이 있는 경우 해당 사용자가 로그인 후에 http 프로토콜의 페이지로 이동하는 경우 세션 쿠키가 전송되지 않기 때문에 서버에서는 신규 접속으로 인식하여 세션 쿠키를 새로 발행하게 됩니다. 따라서 사용자는 로그인 하였음에도 불구하고 비 로그인 상태가 되어 다시 로그인 해야하는 상황이 발생되게 됩니다. 사용자중에는 로그인 페이지를 북마크에 넣어두고 접속하는 경우가 있기 때문에 특정 사용자에게 많은 빈도로 나타날 가능성이 있습니다.

해결책

• 전 영역을 https프로토콜로 통합

• 서브 도메인(sub domain)을 이용하여 http와 https프로토콜의 호스트를 별도로 서비스

• 별도의 Secure 속성의 쿠키를 이용

1. WAS의 설정이나 어플리이션에서 세션 쿠키를 직접 발행하는 방법을 통해 세션 쿠키는 secure속성이 없는 상태로 발행되도록 설정
2. https영역에 최초 접속했을 경우 별도의 secure 쿠키를 발행하고 해당 쿠키 값을 세션등 서버영역에 해당 값을 보존
1. 이후 https프로토콜로 접속할 경우에는 클라이언트가 전송한 secure 쿠키의 값과 서버영역에 보존된 값을 비교하여 일치하지 않는 경우 세션 쿠키 누출의 가능성이 있는 것으로 판단하여 접속을 차단

 위에서 언급한 방법중에서 개인적으로는 역시 전 영역을 https로 통합하는 방법을 추천해 드리고 싶습니다. 프로토콜 전환간에도 세션을 안전하게 보호하기 위해서 어플리케이션의 별도 구현이 필요하므로 구현에 따른 유지보수 비용, 구현 미스에 따른 개인정보 유출 가능성 등에도 대비해야 하기 때문입니다. 게다가 프로토콜을 혼용해서 사용할 경우에는 각 영역별로 사용할 데이터에 대한 민감도에 대한 평가를 사전에 해야하기 때문에 설계단계에서의 비용도 추가로 발생할 가능성이 있습니다.

 또한 최근에 구글 크롬의 경우는 http프로토콜을 이용한 접근의 경우 안전하지 않다고 표시하기 때문에 사이트 자체에 이미지에도 부정적인 영향을 미칠 수 있으며 완벽하지는 않지만 페이크 사이트 혹은 피싱 사이트에 대해서도 약간의 대책이 될 수 있기 때문에 적극적으로 검토해보는 것이 좋겠습니다.

 최근 프로젝트 수행중에 프로젝트에대한 보안성 진단을 받았는데 취약점 리스트에 robots.txt가 존재하지 않아 개인정보가 검색 결과에 노출될 가능성이 있다는 진단결과를 받았습니다. robots.txt와 보안과의 상관관계에 대해서 알아보도록 하겠습니다.

robots.txt란?

  robots.txt는 로봇 배제 규약(robots exclusion protocol) 혹은 robots.txt 규약(robots.txt protocol)으로 알려진 규약으로서 웹 크롤러(Web Crawlers)에게 해당 웹사이트에 대한 크롤링 지침을 전달하기 위한 용도로 사용됩니다.

robots.txt가 존재하지 않을 경우

 robots.txt가 존재하지 않으면 보안적인 관점에서 어떤 문제가 있는지 생각해 보도록 합시다. 특정 웹 어플리케이션에 개인정보가 출력되는 'A'라는 페이지가 존재한다고 가정해 봅시다. 이 페이지를 배제 리스트 상에 지정하였을 경우 크롤링 대상에서 제외되므로 우려하는 검색결과에서 누출되는 것을 막을 수 있다고 생각할 수 있습니다. 하지만 크롤링 대상에서 제외된다는 것이 접근할 수 없다는 의미는 아닙니다. 위의 A페이지는 누구라도 직접 접근이 가능하며 규약을 지키지 않는 크롤러도 존재할 수 있습니다. 어떤 의미에서는 드러나지 않게 가져가는 크롤러의 경우가 좀 더 악의적일 수 있습니다. 즉 robots.txt가 존재하지 않는 것은 보안과는 관련이 없다는 사실을 알 수 있습니다. 이런 누출을 막기위한 방법은 해당 페이지에 접근 가능한 권한이 있는지 확인하는 절차를 거치는 접근 제어가 필요합니다.

robots.txt가 존재할 경우

 이제 또 다른 경우를 생각해 보도록 합시다. 개인 정보가 출력되는 'B'라는 페이지가 존재하며 해당 페이지는 관리자만 접근할 수 있다고 가정해 봅시다. 이 페이지는 관리자만 접근 가능한 영역에 존재하므로 공개된 영역에는 링크가 걸려있지 않습니다. 무차별 대입(Brute force)이외에 이 페이지의 존재여부를 알 수 없습니다. 하지만 이 페이지를 아래와 같이 크롤링 배제 리스트에 추가할 경우 악의를 가진 사람(혹은 단체)가 robots.txt를 열람하면 B페이지가 존재하는 것을 알 수 있습니다.

User-Agent: *
Disallow: /B

 물론 B페이지는 관리자 권한을 통한 접근 제어를 하고 있으므로 당장 접근해서 기밀 정보를 획득할 수 없습니다. 하지만 B라는 페이지가 존재한 다는 것을 아는 것만으로도 악의를 가진자는 해당 페이지를 매일 모니터링해 볼 수 있습니다. 어느날 해당 어플리케이션 수정 미스로 접근 제어가 풀려 버린다면 기밀 정보가 누출 될 수 있습니다. 또한 B이외에도 비슷한 여러 페이지가 등록되어 있다면 해당 어플리케이션의 디렉토리 구조를 파악해서 취약점을 유추해 낼 수 있을지도 모릅니다.(악의를 가진자가 특정 어플리케이션을 목표로 삼았다면 가장 먼저 하는 것이 정보수집이며 디렉토리 구조등도 당연히 정보에 포함됩니다)

※관리자 영역의 경우 네트워크와 같은 물리적인 영역에서 접근이 불가능하도록 제어하는 것이 좋으나 가능하지 않을 경우에는 해당 페이지에 권한 없이 접근시 404 코드(해당 페이지가 존재하지 않음을 나타내는 http status)를 반환하는 것도 고려해 볼 만 합니다. 실제로 apache tomcat 서버의 경우는 WEB-INF이하에 접근했을 경우 404 코드를 반환합니다.

 관리자 페이지가 아닌 누구나 회원가입해서 열람 가능한 페이지라면 악의를 가진자도 열람 가능하므로 디렉토리 구조를 파악할 수 있습니다. 이 경우에는 접근 제어 및 검증을 좀더 꼼꼼하게 진행해야 합니다.(관리자 페이지는 대충해도 된다는 의미는 아닙니다.)

 위에서 작성한 것처럼 robots.txt 자체는 보안과 별로 관련이 없다는 것을 알 수 있습니다. 다만 접근 제어를 실수했을 경우를 대비해서 검색결과에 누출되는 등과 같은 광범위한 누출을 방지하기 위해서 작성해 놓아도 무방할 듯 합니다. 하지만 그 내용은 공개되지 않는 영역의 구조를 파악할 수 없도록 잘 확인해야 합니다. 혹은 META 태그를 이용하여 해당 페이지에 직접 기술하는 방법도 유용할 듯 합니다.

※검색 결과에서 특정 웹 어플리케이션의 취약점을 알아내어 개인정보를 탈튀하거나 혹은 검색결과에서 직접 개인정보를 알아내는 일은 'Google Hacking'이라는 용어가 붙어있을 정도로 알려져있는 보안 취약점입니다

참조

 - http://www.robotstxt.org/

 최근에 filezilla server를 다운로드 받기 위해서 filezilla의 웹사이트로부터 다운로드 링크를 클릭하고 깜짝 놀랐습니다. filezilla 의 다운로드 링크는 souceforge로 연결되어 있고 자동으로 다운로드가 시작되는 형태로 제공되는데 다운로드에 사용한 Chrome에서 위험성을 경고하며 차단했기 때문입니다. 사실 위험성을 경고하고 계속 진행할 수 있는 형태의 알림이었다면 신경안쓰고 계속진행했을지도 모르겠습니다. 아니 계속 진행했겠지요. 하지만 계속 진행이 불가능했기 때문에 Internet Explorer를 이용하여 다시 다운로드를 시도했습니다. 그런데 Internet Explorer에서도 안전하지 않다는 경고와 함께 다운로드가 차단되는 것이 아닙니까?

Chrome 차단 스크린샷

※화면상에 Chrome이용자의 경우 블럭 당할 수 있으므로 다른브라우저로 다시 시도해달라고 씌어져있다.

Internet Explorer 차단 스크린샷

 위와같이 시도한 브라우저 두개다 차단당하고보니 무언가 문제가 있는지 생각하고 원인을 찾아보니 SourceForge를 이용해서 다운로드를 진행할 경우 해당 소프트웨어의 인스톨러가 직접 다운로드 되는 형식이 아닌 SourceForge용 인스톨러로 랩핑(Wrapping)된 형태의 인스톨러가 다운로드 된다는 사실을 알 수 있었습니다.

 스크린샷 위쪽이 별도로 검색해서 다운로드 받은 파일이고 아래쪽이 SourceForge에서 받은 파일입니다. 파일 아이콘은 물론 용량에도 차이가 있습니다.

※유감스럽게도 FireFox에서는 차단없이 다운로드가 되었습니다.

 차단당하는 파일을 실행해 볼 용기(?)는 없어 실제로 실행해보지는 못했지만 랩핑 되어있는 파일이 용량이 적은걸로 보아 실행시에 다운받아서 설치하는 하는듯 보였고, 이 설치 과정에서 보안에 취약할만한 무엇인가가 의도하지 않게 추가적으로 설치되는게 아닌가 하는 생각이 들었습니다.

 위와 같은 상황을 겪고보니 그동안 보안에 대해서 인식하고 대처하고 있다고 생각했었지만 습관적으로 SourceForge와 같이 알려진 사이트들은 안전하다고 안일하게 생각해 온게 아닌가 하는 생각이 들었습니다. 사실 국내의 인터넷 환경 자체도 ActiveX등의 설치를 강요받고 있기에 예를 누르도록 훈련되어 있는지도 모르겠습니다만 이런 안일함이 헛점을 만들고내고 있었습니다.

 아무튼 FileZilla는 다운로드 받아야 했으므로 별도의 다운로드 링크를 통해서 다운로드 받았습니다. 그동안은 SourceForge라는 신뢰성(?)있는 사이트를 통해서 다운로드 받아서 신경쓰지 않았지만 다운로드 받은 파일의 검증을 해야할 필요가 있었습니다. 이럴때 사용할 수 있는 것이 파일의 해시값을 이용한 CheckSum 검증입니다. 해시라는 것은 일종의 패턴이라고 보시면 될 듯 합니다. 대상이 되는 데이터(여기서는 파일)로 부터 일정한 공식(혹은 함수)에 의해 산출된 값을 의미하는데 같은 파일을 이용하면 항상 같은 결과 값이 산출되므로 많은 오픈 소스들이 파일을 검증하는 방법으로 채택하고 있습니다. 해시값을 구해서 검증하는 것 자체는 단순히 다운로드 받은 파일이 받으려고 했던 파일이 맞는 것인지 검증하는 것 뿐이지만 이런 검증을 거치므로서 보안위협을 배제할 수 있습니다.

FileZilla 해시코드

 FileZilla의 경우 위의 스크린샷 처럼 여러번 클릭해서 확인할 수 있었습니다만 일반적으로는 해당 파일의 다운로드 링크와 함께 확인할 수 있는 경우가 대부분 입니다. 해당 파일의 해시값을 확인했으면 실제 다운로드 받은 값으로부터 해시값을 산출하여 확인한 해시값과 비교하여 검증해야 합니다. 그러면 해시값을 산출하는 방법에 대해서 알아보도록 합시다.

Windows fciv 커맨드

C:\>fciv -add 파일명 -both

 Windows플랫폼의 경우 빌트인(built-in)커맨드는 존재하지 않지만 별도로 제공하는 fciv커맨드(File Checksum Intergrity Verifier)를 이용하여 이용하여 검증할 수 있는데 아쉽게도 위에서 다운로드 받은 FileZilla 인스톨러의 경우 Sha512 해시값만 제공하고 있는데 fciv커맨드의 경우 md5, sha1 해시만 지원하므로 사용할 수 없었다.

※fciv는 윈도우 사이트에서 다운받을 수 있습니다.

온라인 해시 변환 사이트

 OS의 빌트인 커맨드를 이용하는 방법이 가장 간단하고 안전하지만 위처럼 아쉽지만 지원하지 않는 경우에는 다른 방법을 이용하는 수밖에 없습니다. 이경우 선택할 수 있는 방법으로 온라인 해시 변환 사이트입니다. 검색 사이트 등에서 파일, 해시 등으로 검색하면 다양한 사이트를 찾을 수 있습니다.

 위의 스크린샷은 검색으로 찾은 사이트(http://hash.online-convert.com/sha512-generator) 중 하나를 골라서 해시값을 산출한 결과 화면이다. 물론 해당 사이트가 과연 신뢰할 수 있는가에 대한 의문이 생길 수 있을 듯 합니다. 위처럼 다운로드 사이트와 검증 사이트가 다를 경우 불특정 다수의 조작된 파일과 해시값을 동시에 가지고 있어야 하므로 현실적으로 어렵다고 할 수 있습니다. 하지만 100%안전하다고 할 수 없으므로 서버에서 사용할 프로그램등과 같이 리스크 대비 큰 피해가 예상되는 경우에는 사용을 자제하라고 말씀드리고 싶습니다. 개인적인 용도에서는 피해대비 이익이 적으므로 괜찮지 않을까 생각됩니다.

※본 포스팅의 예제처럼 오픈소스등과 같이 공개적인 파일의 검증에만 사용하시기 바랍니다. 절대 기밀성이 필요한 파일을 알 수 없는 사이트에 업로드하지 마십시오.

※본 포스팅에서는 보안의 관점에서 해시값 검증을 이용한다고 언급되어있지만 보안적인 부분 이외에도 전송오류를 잡아내기 위한 용도로도 사용할 수 있습니다.

프로그래밍

public String getFileHash(final String algorithm, final File target)
			throws NoSuchAlgorithmException, IOException {

	final MessageDigest md = MessageDigest.getInstance(algorithm);
	InputStream is = null;
	try {
		is = new FileInputStream(target);
		byte[] buffer = new byte[1024];
		int readBytes = 0;

		while ((readBytes = is.read(buffer)) > -1) {
			md.update(buffer, 0, readBytes);
		}

		StringBuilder builder = new StringBuilder();
		byte[] digest = md.digest();
		for (byte b : digest) {
			builder.append(Integer.toHexString(0xff & b));
		}
		return builder.toString();
	} finally {
		if (is != null) {
			try {
				is.close();
			} catch (IOException e) {
				e.printStackTrace();
			}
		}
	}
}
//실행예
getFileHash("SHA-512", new File("D:/FileZilla_Server-0_9_49.exe"));

리눅스(Linux) 플랫폼

 리눅스 플랫폼의 경우는 다양한 빌트인 커맨드를 제공하므로 따로 준비해서 이용할 필요는 없습니다. 윈도우 이용하는 분들도 별도로 리눅스 서버가 존재한다면 업로드하여 검증을 진행하면 편리할 듯 합니다.

#md5sum
#sha1sum
#sha224sum
#sha256sum
#sha384sum
#sha512sum

 사실 해시를 이용한 파일 checksum 검증은 주로 오픈소스의 경우에 제공되는 경우가 많습니다. 그 이유는 오픈소스의 경우 재정적인 문제로 자체적으로 다운로드를 제공하기가 어렵기 때문에 여러 기관의 협조등에 의해서 다운로드를 제공하는 경우가 많고 다양한 미러링이 제공되는 경우가 많아 다운로드를 통제할 수 없기 때문입니다. 이러한 보안 취약점을 보완하기 위해서 자체 다운로드에서 다운받지 않은 경우 해시를 이용한 검증을 통해서 보안 취약점을 배제할 수 있습니다.

 여러분도 다운로드 받은 파일의 출처가 의심스럽다면 한번 검증해 보는건 어떨까요?