R4v!dus

메타 태그란 웹 서버와 웹 브라우저간 교환되는 데이터 정보를 정의하는데 사용되며 보이지 않는 정보를 제공해준다.

<meta />

닫는 태그가 없는 태그로 태그의 속성을 통해 정보를 제공해 준다.

메타 태그 속성에는 http-dquiv, name, content 3가지 속성이 있다.

각 속성별로 속성값이 존재하며 속성값에 따라 나타내는 값이 다르다.

CSRF는 Victim의 의지 및 의도와는 무관하게 Attacker가 의도한 특정 행위를 웹 사이트에 요청하는 공격 기법이다.

원리는 사용자가 웹 사이트에 로그인한 상태에서 CSRF 공격 소스가 삽입 된 페이지를 열면 웹 사이트를 공격 하게 된다.

웹 사이트는 신뢰하는 사용자의 요청이기에 이를 수행함으로써 공격에 노출되게 되는 것이다.

굉장히 많은 종류의 CSRF 모식도가 그려져 있는데 그중 하나를 퍼왔다. 이를 이용하여 설명 하고자 한다.

1.공격자가 사용자에게 공격소스가 삽입된 페이지를 보낸다.

2.로그인 되어 있는 사용자는 이를 실행하고 소스 대로 여러가지 행위를 요청한다.

3.웹은 소스대로 행위에 대한 결과 값을 공격자에게 송신한다.

이 모식도는 사용자의 정상적인 Session값을 탈취하여 공격자가 사용자를 대신하려는 것으로 보인다.

CSRF는 위 그림과 같은 일련의 방식으로 일어난다.

사용자가 어떻게든 공격 소스를 실행 하게끔 만드는게 이 공격 기법의 핵심이며 이를 위해 여러 방법이 사용된다.

(방법에 따라 모식도가 조금씩 달라진다.)

대응 방안

-Referrer 검증

Back-end에서 requet의 referer를 확인하여 전에 들어온 주소와 도메인이 일치하는지를 검증 하는 방법이다.

쉬운 보안이지만 CSRF의 전반적인 공격의 방어가 가능하다. XSS취약점이 존재할 경우 방어가 무의미하며 리퍼의경우 값이 변조 될수 있다. 그러면 어떻게 해야되는가?

X-CSRF 커스텀 헤더를 사용하는것이다.

웹 브라우저는 커스텀 헤더를 다른 도메인으로 전달하지 않는다.

따라서 공격자가 공격 페이지를 만들더라도 X-CSRF 헤더가 포함되지 않음을 알수 있다.

그렇다면 만들면 되지 않느냐? 아니다 XHR객체를 사용하더라도 정상적인 요청은 생성할 수 없다.

-CSRF Token 사용

사용자 세션에 임의의 값을 저장하여 모든 요청에 대하여 서버단에서 검증하는 방법이다.

XSS 취약점이 있을경우 무용지물

-Double-Submit Cookie Pattern

웹 브라우저의 Same Origin 정책으로 공격자가 쿠키값에는 접근 할수 없다는 점을 이용하여 브라우저는 토큰 값과 시크릿키값을 서버로 부터 받는다.

브라우저에서 write 요청시 header에 토큰 값을 주고 쿠키 값에 시크릿키를 부여하여 서버의 미들웨어에서 토큰값을 decode해 decode한 시크릿 쿠키 값과 일치하는지 체크한다.

XSS나 메타태그를 이용하여 쿠키값을 조작 할 수 있어 완벽하지는 않다.

사진 참조: https://stackhoarder.com/2019/08/19/laravel-%EA%B8%B0%EB%B3%B8-10-csrf-protection/

커맨드 인젝션이란 웹 요청에 시스템 명령어를 삽입 하여 실행 하는 공격이다.

OWASP TOP10에도 속할 정도로 위험한 취약점에 해당한다.

OWASP TOP10

https://www.owasp.org/images/b/bd/OWASP_Top_10-2017-ko.pdf

웹 내부에서 시스템 명령어를 실행하는 경우 입력값을 제대로 검사하지 않는다면 공격자 마음대로 시스템 명령어를 실행 할 수 있게 된다. 이는 웹 개발자가 공격자를 위해 웹쉘을 제공하는 거나 다름이 없다.

정상적으로 동작하는 서버를 대상으로 공격자가 ;cat /etc/passwd를 요청하는데 이는 ping IP;cat /etc/passwd 형식으로 수행이 된다.

대응방법

Command Injection 공격은 취약한 함수를 사용함에 따라 발생한다.

취약한 함수로는

perl  :  open(), sysopen(), system(), etc....

php :  exec(), system(), popen(), include(), eval(), preg_replace(), etc...

등이 있다.

또한 |, &, ; 와같은 멀티라인을 지원하는 특수문자는 검사 해주는 것이 중요하다.

브루트 포스 일명 무차별 대입 공격은 공격자가 공격 대상에게 무수하게 많은 요청을 보내 하나 맞아 떨어지는 것을 찾아내는 공격 기법이다. 가능한 모든 경우의 수를 검색해 보는 것이기에 이론적으로는 정확도가 굉장히 높다.

여기서 눈 여겨봐야 될 것은 공격자의 컴퓨터 자원이다. 브루트 포스의 경우 병렬 작업이 가능하여 여러대의 컴퓨터 혹은 병렬 프로그래밍 기법을 사용하여 공격에 걸리는 시간을 단축 시킬 수 있다. 

브루트 포스 공격은 크게 두가지로 구분 할 수 있다.

1. 자동 부루트 포스 : 무식하게 모든 경우의 수를 전부 대입하는 방법이다.

문자열은 0~9 a~z A~Z 그리고 특수 문자들까지 경우의 수를 따져보면 자릿수가 늘어날때마다 기하급수적으로 증가한다.

ex)48^n (n은 자릿수)

그렇기에 많은 회원가입 서비스들이 몇자리 이상, 대소문자, 특수문자를 섞어 쓰는 것을 권장한다.

이는 단순히 문자열의 복잡성을 증가시켜 브루트 포스의 공격을 완화시키는 방법이지만 효과는 확실하다.

http://howsecureismypassword.net/를 통해 재미삼아 자신의 비밀번호가 얼마나 안전한지 확인 해볼 수 있다.

2. 딕셔너리 어택 : 사전에 있는 단어를 순차적으로 대입하는 방법이다.

사전에 적힌 문자열을 참조하여 사람들이 많이 사용하는 단어들을 공격에 사용한다.

*만약 딕셔너리에서 자신이 사용하는 비밀 번호를 발견한다면 교체하는 것을 권장한다.

대응 방법

무차별 적인 대입 공격을 컴퓨터는 순식간에 처리해 줌으로 이를 뒷바침해준다. 그렇다면 처리 속도를 의도적으로 늦춰주는 방법은 어떨까?

속도를 늦출 수야 있지만 언젠가는 풀리기 때문에 근본적인 해결책은 되지 못한다.

처리 지연 시간이 길면 일반적인 사용자는 피해를 보며 공격자는 공격 성공까지의 시간이 늦춰질 뿐이다.

그렇기에 n회 인증 내에 성공하지 못하면 locking이 되는 방식이 도입되었다.

여러 웹 사이트에서 사용 되고 있으면 휴대용 단말기에서도 사용 되고 있다.

또한 브루트 포스에 한정하여 캡챠도 좋은 방안중에 하나이다.(캡챠도 완벽하지는 않다 우회가 가능 하기 때문이다.)

현재는 많은 대응 방법이 나와있다.

갭챠의 새로운 버젼인 리캡챠도 대응 방안의 하나이다.

브루트 포스 공격에 대한 대응 방안이기에 완벽히 안전하지는 않다.

추후에 이 방법들의 우회도 다루어 보도록 하겠다.