TIL이 진짜 쉽지가 않다 잠시 공백동안 한 것을 정리해보면 웹해킹 연습을 위한 간단한 게시판을 구현을 했고 거기에 이때까지 공부했던 기법들을 한 번 시도해보고 있었다. 게시판은 흔히들 할 수 있을 MERN으로 구현을 해보았는데 각 프레임워크들이 보안설정을 너무도 잘해놓은 나머지 HTML인코딩같은 보안조치들이 너무 잘 되어있어 아무것도 할 수 있는 것이 없어 못 올리고 있었다.
근데 이제와서 생각해보면 내가 저것들을 뚫을 피지컬이나 사고나 실력이 됐다면 애당초 여기에 없었을 것이다. 그래서 일부러 취약점을 만들고 실제로 그 취약점들이 실행이 되는지에 초점을 맞춰보았다.
- XSS
이건 서버단에서 하는 것인지 mongo단에서 하는 것인지는 모르겠는데 내가 게시판에 등록하려는 내용들이 html encoding을 통해 mongoDB로 들어가게 되는 것을 확인했다.
이런 식으로 <>나 " 등 XSS의 위험이 있는 특수문자들을 모두 인코딩하여 db에 넣어지는 모습을 볼 수 있다.
하지만 이런 html encoding을 내가 우회하여 db에 순수한 <>을 넣을 수 있었다면 난 이미 이 자리에 없고 다른 곳에 있었을 것이다.
그래서 어쩔 수 없이 내가 어차피 db관리자겠다, 그냥 내가 db에 저장된 html encoding이 된 것을 다시 직접 디코딩하여 일부러 취약점이 실행되도록 바꿔주었다.
사실 이런 XSS 공격의 주된 목적은 해당 스크립트를 실행하게 되는 피해자들의 쿠키와 그 안에 있는 세션 id를 탈취하여 그 피해자의 '권한'을 탈취하는 것이므로 직접 document.cookie를 찍어보았다.
이것처럼 해당 페이지의 쿠키가 잘 나오는 것을 알 수 있다.
그런데 여기서 한 가지 더 이슈가 있다.
바로 express-session에서는 httponly 속성이 있는데 false를 주면 위에 사진처럼 sid(sessionid)가 뜬다
하지만 httponly 속성을 true로 한다면 말그대로 자바스크립트가 아니라 html로만 접근을 할 수가 있다하여 밑의 사진처럼 alert(document.cookie)를 하더라도 session id가 뜨지 않게 된다.
그러나 웹페이지의 성능을 위해서는 저 httponly라는 속성을 false로 해야한다는데 보안을 위할 것인지 성능을 위할 것인지 조금 딜레마가 생기지만 어차피 요즘 html encoding이 잘 되어있기에 내가 웹 개발자였다면 성능을 선택했을 것이다.
- CSRF
사실 위에 있는 XSS처럼 html의 태그들이 실행이 되고 그에 따라 자바스크립트 구문도 실행이 되어야 가능한 공격기법이라 결국은 XSS와 비슷한 기법이지만 굳이 이렇게 구분을 해서 쓴 이유는 XSS와 그 목적이 조금은 다르기 때문이다.
XSS는 악성스크립트가 삽입된 여러가지 형태의 게시물이나 요청값을 가지는 것을 조회하는 피해자의 권한탈취가 주 목적이라면
CSRF는 은연중에 다른(혹은) 같은 오리진의 웹사이트의 요청값을 자바스크립트 구문에 삽입해 피해자가 자신도 모르게 공격자가 정의해놓은 페이로드대로 행동하는 것을 의미한다.
이렇게되면 이걸 받는 서버단에서는 피해자의 쿠키와 세션은 정상적으로 가지고 있기에 실제로 동작하게 된다.
공격의 목적의 예시
XSS : <img src ="invalid"공격자의 웹서버로 document.cookie"
-> 말그대로 조회자 모르는 사이에 공격자에게 cookie와 그 안에 있는 session id가 넘어가게 되고 이렇게 되면 공격자는 그 쿠키를 이용해 똑같은 로그인을 할 수 있다.
CSRF : <img src ="invalid"
-> guntak이라는 계좌로 10000원의 돈을 보내주세요라는 요청을 조회한 사람의 권한으로 자동실행하게 된다. (해당 태그에는 안적혀있지만 안보이게 하기위해 height와 width를 0으로 맞추면 된다.)
하지만 CSRF를 실제로 redirect할 시나리오가 없어서 실습은 못하고 이렇게 글만 적게 되었다.
여담인데 위에 공격 목적의 예시에 각 태그 맨 오른쪽의 >를 생략해놓았는데
이렇게 html태그가 실행되는 것을 볼 수 있다.
(아 ㅋㅋ 이러면 지금 이 사이트에 XSS같은 공격을 시도할 수 있다는 것 같은데 임시저장해놓고 alert만 시도해봐야겠다.)
헉 된다 ㅋㅋ
사실 이렇게 되면 CSRF도 될거같긴한데 이건 아마 CORS나 SOP선에서 막혔을 것 같다.
이렇게 클라이언트단에서 일어날 수 있는 대표적인 두가지 공격기법에 대해서 알아보았다.
서버사이드를 겨냥한 공격은 SQL Injection이 있는데 웹해킹 교과서라고 불리는 책에 의하면 사실 이제 SQL Injection은 그냥 거의 막혔다고보면 무방하다기에 조금 더 다른 공부를 해서 게시를 할 것이다.
지금 랩실에서 진행하고 있는 게시판 웹사이트 모의해킹을 위해서 사전공부를 하고 있는데 웬만한 프레임워크는 보안조치가 되어있는지라 여러가지 우회법을 찾아보고 적용하는데 되는 것이 없어서
TIL에 올릴 것이 없는 것은 정말 아쉽지만 일단 계속해서 html encoding을 우회할 수 있는 방법을 찾아볼 것이다.
