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 강의를 기반으로 작성되었습니다.