앵하니의 더 나은 보안

문제 인식특정 웹 서비스에서 json 형식으로 데이터를 주고 받는 웹 서버임에도 XSS 취약점이 동작하는 것을 확인했다.Content-Type이 application/json은 XSS가 동작하지 않는 걸로 알고있는데 여기서는 왜, 어떻게 동작한 걸까? 문제 해결바로바로 서버에서 렌더링해서 줄 때 취약한 방식으로 렌더링해서 주기때문이다.뭔말이냐? 취약했던 대상 웹 서비스에서는 vue.js를 사용해 프론트엔드를 구현했는데,이 vue.js에서 안전하지 않은 렌더링 방식으로 구현했다는거다.  렌더링 방식으로 v-html 디렉티브를 사용했는데, 컨텐츠 타입에 상관없이 프론트엔드에그대로 포함시켜버리는 친구라고 한다. 그래서 XSS 취약점이 발생해 버렸던것뿌슝 빠슝 그럼 반대로 진단자는 이런 환경임을 어떻게 알아볼..

서론특정 웹서비스에서 휴대폰 등록기능을 단순히 reCAPTCHA 봇 기능만으로 사람인지 아닌지 판단하는,마치 손안대고 코푸려는 행태에 분노가 일어 reCAPTCHA에 대한 인증 우회를 진행하는 크롤러를 만들어보았다.어떤원리로 reCAPTCHA 퍼즐을 풀 수 있고, 어떻게 selenium을 사용했는지 소개하겠다. 본론우선 reCAPTCHA에 대한 퍼즐 검증은 크롬 확장프로그램 Buster: Captcha Solver for Humans를 통해 할 수 있다.Buster: Captcha Solver for Humans를 통한 우회 원리는 다음과 같다.그림을 선택하는 캡챠가 노출되면, 음성 캡챠로 모드를 전환음성 데이터를 확인 후, 해당 데이터를 Buster: Captcha Solver for Humans 확장..

XST(Cross-Site Tracing) 취약점은 XSS 취약점이 존재할 때Trace 메소드를 사용해서 사용자의 세션을 탈취해낼 수 있다. 근데 이건 XSS도 마찬가지로 할 수 있는데 XST라는 취약점이 왜 따로 분류 돼있는건지 궁금해서 한번 찾아봤다. 본론XST가 XSS와의 별개로 따로 떨어져있는 이유를 먼저 말하자면, HttpOnly 보안헤더 이놈 때문이다. 이 HttpOnly 보안헤더는 자바스크립트가 웹 쿠키에 접근하려할때 해당 접근을 막는 역할을 한다. 실제로 자바스크립트가 웹 쿠키에 접근해야되는 일이 잘 없기때문에 이렇게해서 XSS로부터 쿠키 값 탈취를 막는다하더라도 서비스에 큰 지장이 없다. HttpOnly의 힘HttpOnly는 HTTP 패킷상으로 HTTP 헤더 내 쿠키 값 설정이 끝나고 마..

서론XSS 취약점이 존재하는 사이트에 CSRF는 발생할 가능성이 아주 높다. 그럼 반대로 XSS가 없는 사이트는 CSRF 또한 없는 걸까? 물론 아니다. CSRF의 그 이름처럼 Cross SIte. 즉 제2, 제3의 다른 사이트에서 대상사이트로의 변조된 요청이 들어올 수 있다. 그래서 XSS가 없다해도, 제2 제3의 사이트에서 요청 위조 공격이 들어올 수 있으니 XSS 취약점이 없다해도 CSRF의 발생 가능성은 존재한다.그럼 다른사이트에서의 CSRF 공격은 어떤식으로 수행해볼 수 있을까?말만 들었을때는 XMLHttpRequest 객체나 뭐 form 객체, A태그 등등 여러가지 써서 가능해보이는데 실제로 가능한지 시연해보겠다. 본론CSRF 공격 대상 웹 서버(127.0.0.1)구축한 웹서버는 기본적으로 로..