wonder

XSS 만약 이벤트핸들러를 블랙리스트 기반 필터링을 한다면 onpointerout 도 활용합니다. 파일다운로드 HackTricks LFI path traversal list 참고하면 좋습니다. 만약 디렉토리 스캔 탐지 로직이 없다면 fuzzing(gobuster, wfuzz 활용)하면 됩니다. 파일업로드 파일업로드 무조건 png해야되는데 240자넘으면 shorten되서 php로 저장됩니다. 파일업로드 화이트리스트 기반 확장자 필터링하지 않는다면 cgi, 확장자 외에도 .cer, .asa, cdx, hta, phar 확장자 악용 할 수 있어 막아야합니다.

정보 누출 DB일반향 암호화(해시) 처리를 안했다면 https통신을 해서 MITM 공격은 안당하더라도 SQLi , 내부망 등 뚫렸을 경우에 비밀번호가 크랙되어 2차 피해가 일어날 수 있습니다. 따라서 로그인 후 응답값으로 해시값이 와도 정상적인 로직이 아닌데, 평문값이 오는 것은 더욱 취약합니다. 데이터 평문전송 AWS > tomcat 8.5 TLS 1.0, 1.1 비활성화 방법 server.xml 파일의 SSL이 적용된 connector 설정 부분에 TLSv에 대한 설정을 추가 파일업로드 파일명만 뜨더라도 jpg 이미지 파일 주소 > jsp경로가 예측가능하다면 웹쉘 및 reverse 쉘 실행이 가능합니다. 따라서 원론적으로는 파일 확장자를 화이트리스트 기반 필터링 해야하며 만약 뚫리더라도 기능을 하지못..

정보 누출 elb2.0은 직접적인 서버 정보는 아니니 심각하게 취약하다고 보기가 어렵습니다. microsoft-httpapi/2.0 도 IIS이긴 하지만 취약하다고 보기 어렵지만 서버 헤더 정보는 제거하기 쉬우니 남겨둡니다. apache-coyote/1.1 톰캣 8.0 이하에서 뜨는 부분이고, 8.5 이상에서는 Server 속성에 포함시키지 않는 것이 기본값이므로 어느정도 버전 예측이 가능합니다. 취약입니다. 403 forbidden은 사람마다 다르며 애매합니다. 정말 애플같이 보안철저한 곳에서는 403이 중요 리소스가 있으니 예측불가하도록 취약하다고 보고 남겨두지 않습니다. +이행점검 시 해야할 마무리 DoA 점수 매기고 -> 담당자 입장에서 단/중/장기 초기계획이 필요합니다. 엑셀 위험평가

XSS 값을 크게 넣거나 음수로 넣어봅니다. 에러나면서 XSS 삽입이나 정보 누출될 가능성이 있습니다. 모바일 앱 해킹 시간날 때 후킹 우회해봅니다. 연습사이트도 합니다.

불충분한 인증 비밀번호가 틀렸고 응답도 다르지만 user id에 대해 접속이 가능했습니다. XML기반 로그인에서 400 > 200 으로, body 내용도 로그인 오류응답을 > 정상적인 응답값으로 바꿔서 되는지 확인해 봅니다.

일반 점검 때도 놓치면 안되겠지만 리뉴얼 후 다시 확인할 때는 어떤 기능이 추가 되었는지, 숨겨져 있지만 기능을 놓친 건 없는지 확인해야합니다. 모두 똑같은 기능처럼 보이지만 기능 위주로 찾으려다 보면 이벤트 페이지, 댓글, 사진 업로드, 새로운 내부 검색 등 숨겨져 있는 게 있을 수 있습니다. XSS 또한 해당 사이트가 프레임워크를 통해서 XSS 등을 막아놓았다면(기본적으로 까지 해놓았습니다.), 하위 도메인(?.wonder.com) URL을 찾을 경우 파라미터 중에서도 XSS 처리가 안되어있는 경우도 있습니다. 에디터 등에서 textarea가 있다면 거기 안에서만 갇혀 생각하는 게 아니라 빠져나올 생각도 해봅니다. 잘 대응 되어있는 사이트의 경우는 파라미터들이 최대한 응답안하도록 해..